IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-08-04. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
3.4.2 Returning items
1054 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1111 EDT Adjourned
(at 2016-08-18 06:00:03 PDT)
draft-ietf-insipid-session-id
I agree with Alissa's Discuss.
I'm wondering, given that RFC 7329 is informational and given that this doc is backwards-compatitile to it, if this doc really obsoletes RFC7329, or just updates it...?
(I'm entering a DISCUSS to make sure we get discussion of this topic among the ISEG before we progress the document. Whatever the outcome, I expect to clear the DISCUSS and go back to a YES position after the telechat.) Please see the thread resulting from Elwyn's gen-art review from the 2nd IETF last call, called specifically because of the downref to RFC 7206 that was added after the first LC. This downref was due to the definitions of "communication session" and "session ID" from that RFC. https://mailarchive.ietf.org/arch/msg/gen-art/3cLlqju62bY1w5MTA72YpOjL_GQ
I'm wondering why Section 11. (Compatibility with a Previous Implementation) is even needed if this document is Obsoleting RFC7329. I understand that there might be a transition period between the two versions, but the fact that concerns with the compatibility have already come up in Suresh's DISCUSS and that the text itself says that "we will herewith attempt to achieve backwards compatibility" (no guarantee, just an attempt), leaves me with a bad taste that rules are being added that may complicate the new implementation...
* Section 5
I do have a concern about backward compatibility regarding the sess-uuid. Looks
like this document allows the sess-uuid to contain either uppercase or
lowercase hex digits ("sess-uuid = 32(DIGIT / %x41-46 / %x61-66)")
while the legacy version in RFC7329 does not allow uppercase hex digits. Looks
like a compliant implementation of the spec using upper case hex digits will
fail to interoperate with a legacy implementation. I do not have a particular
preference, but either this rule needs to be tightened or there needs to be
some text added to Section 11 to say this will cause an interoperability issue.
* Section 4.1
The namespace ID in section 4.1 is specified as the initialization of a C
structure as described in Appendix C of RFC4122. It is missing a semicolon at
the end to make it legal.
OLD:
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
}
NEW:
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
};
* Agree with Alissa's DISCUSS regarding persistence
I am very interested in the resolution of Ben's Discuss.
I agree with Alissa'a discuss that any identifier value that could be used as an index must not persist.
I'm a Yes, anticipating that Alissa's Discuss and Suresh's Discuss are resolved, and I appreciate the effort required to produce this specification. It meets an important need.
== Section 12 == "This document allows for additional parameters (generic-param) to be included in the Session-ID header. This is done to allow for future extensions while preserving backward compatibility with this document. To protect privacy, the data for any generic-param included in the Session-ID header value MUST NOT include any user or device information." To preserve the privacy properties of the session identifier, I think this prohibition needs to extend further -- not just to any user or device information, but to any identifier that persists beyond the current session. Otherwise some parameter defined in the future could easily be used to correlate sessions, while the identifier is currently specified so as to avoid that.
== General == I do not think RFC 7206 needs to be a normative reference, but I'm also fine with the downref. == Section 6 == "It should be noted that messages received by an endpoint might contain a "local-uuid" value that does not match what the endpoint expected its peer's UUID to be. It is also possible for an endpoint to receive a "remote-uuid" value that does not match its generated UUID for the session. Either might happen as a result of service interactions by intermediaries and MUST NOT affect the communication session." The MUST NOT at the end there is vague and also seems a bit contradictory to the statement in Section 4.2 that "How a device acting on Session Identifiers processes or utilizes the Session Identifier is outside the scope of this document." Could you clarify what the intent of the last sentence is, and how it squares with the idea that actions taken (or not taken) based on session identifiers are not being specified here? == Section 7 == "The Session-ID header field value included in a CANCEL request MUST be identical to the Session-ID header field value included in the corresponding request." Does "corresponding request" mean original request, as in Section 6? I think it would be clearer if the text said "original INVITE request" both here and in Section 6. == Section 11 == 'altering the nil "remote-uuid"' seems like it could be phrased less awkwardly. "Standard implementations SHOULD NOT expect pre-standard implementations to be consistent in their implementation" -- I don't think this needs normative language. == Section 12 == I think the note about billing purposes is outside the scope of the document and should be removed. Or if not, it needs further motivation -- if someone wanted to bill based on the number of sessions a UA initiated, why would using the session identifier be an inappropriate way of counting those?
draft-ietf-bess-ir
I have some concerns about this document that I don't believe can be easily fixed. This document is extremely hard to read and understand, and therefore comprehend if there are any implications to the information provided. I'm really not sure that this can be addressed here without a significant rewrite. (that might be because the topic itself is deep) A second is related to how the document positions itself. Its status is for Standards Track, yet in the introduction it says: In this document, we provide a clearer and more explicit conceptual model for IR P-tunnels, clarifying the relationship between an IR P-tunnel and the unicast tunnels that are used for data transmission along the IR P-tunnel. and This document does not provide any new protocol elements, or any fundamentally new procedures; its purpose is to make explicit just how a router is to use the protocol elements and procedures of [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself from an IR P-tunnel. Which to me screamed out informational, while then updating 6513 and 6514. However there are parts of the document that imply a semantic change in the use of fields or labels. Eg sect 10, use of timers when switching Upstream Multicast Hop.. so strongly suggesting a standards position. It feels like this document started out to do one thing, eg clarify the model of IR P-Tunnels and then acquired an extended set of tasks in dealing with MPLS label allocation policies. As I can't see a way to make a clear assessment of this document, I am taking an ABSTAIN position, and I will not block publication.
Considering the discussion among the IESG, I wanted to give a strong endorsement for this document. Yes, the document is "complex" to read as it updates RFC6513/6514, and both of these documents required the reader to have normatively understood many other RFCs. Yes, the subject is complex for a non-subject expert reader. This document provides the "additional details" to implement complex capabilities (e.g. multi-vendor interoperability make before break procedures) these vendors (and the WG as noted by the Acknowledgements and list discussion) have found lacked in clarity in the original RFCs. I thank the authors and WG for taking the time to write this RFC as this additional work on implementation aspects after an RFC is rubber-stamped is critical. On many of the questions raised, a good discussion can be found on the list, especially Thomas's and Eric's thread: https://mailarchive.ietf.org/arch/msg/bess/AydZrp0Lf9fUohKrgVHG9kzbycY
I would like to Discuss with the other ADs tomorrow on how they perceived the content in the draft, and how well they've been able to review it and convince themselves of its correctness. I had trouble and my Gen-ART reviewer had trouble....
Qin Wu <bill.wu@huawei.com> reviewed this document for the opsdir
draft-ietf-isis-rfc4971bis
The first sentence in section 4 says: Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Is this the authoritative text for a new requirement, or is that preexisting behavior defined elsewhere? If the former, why would we expect an implementation that does not implement this spec (perhaps the implementors haven't read it) to honor this requirement? If the latter, then please state it descriptively (i.e. without 2119 keywords), preferably with a citation.
I would like to get clarification on the following points before recommending
approval of this document:
1)
Section 2 says:
The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3,
more than one Router CAPABILITY TLV from the same source MAY be
present.
Section 3 says:
Where a receiving system has two copies of a CAPABILITY TLV from the
same system that have different settings for a given attribute, the
^^^^^^^^^^^^^^^
procedure used to choose which copy shall be used is undefined.
The word "attribute" only occurs once in the document, so it would be better if
it is replaced for clarity. Does "a given attribute" mean "a single sub-TLV" or
"all sub-TLVs included in a CAPABILITY TLV instance"?
If "a given attribute" means "a single sub-TLV", then I have the following
followup questions:
What happens in real world if there are two CAPABILITY TLVs which contain
different attributes? Are they treated as cumulative (i.e. this is a nice trick
to overcome CAPABILITY TLV length limit), does the second CAPABILITY TLV value
always overrides earlier instances of the CAPABILITY TLV?
I think the document should state what happens. If there is no consistent
behaviour in this area, the document should says so as well.
1) In Section 4, 1st sentence: how can this specification have requirements on implementation that don't support this extension? As per Alia: RFC1195 says " Any codes in a received PDU that are not recognised shall be ignored and, for those packets which are forwarded (specifically Link State Packets), passed on unchanged." So I think the document should mention RFC 1195 and don't use RFC 2119 keywords for something which is already stated there. For example: OLD: Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. NEW: As per RFC 1195, routers that do not support the Router CAPABILITY TLV will silently ignore the TLV(s) and continue processing other TLVs in the same LSP. 2) Should subTLVs have an IANA registry? Or is there an existing one already?
* Section 4 requires the CAPABILITY TLV to be leaked without any change based on the text below "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level without change even though it may contain some sub-TLVs which are unsupported by the Router doing the leaking. " but Section 2 requires a router leaking the TLV from level-2 to level-1 to set the D bit and this violates the "without change" requirement. I think this inconsistency needs to be resolved somehow. P.S.: One possible way would be to add some exception text for the D bit into the above text in Section 4. Another would be to remove the restriction against change (I noticed that this restriction did not exist in RFC4971 - was this check added to fix some issue identified during deployment?).
Just one nit: the TLV is not new anymore (from the Abstract and other places in the text).
I know this is a bis doc that mainly clarifies one point. However, as there were also other smaller updates, here are some additional comments that could be considered: 1) To me the text in section 2 reads like: if S is not set D should be ignored. Is this correct? If so, it could be spelled out like this. If not, what happens if S is not set but D is? 2) The text says: „Where a receiving system has two copies of a CAPABILITY TLV from the same system that have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined.“ Why is there no default given here? Not defining something like this can lead to problems. I would strongly recommend to define a default behavior. 3) Further it says: „How partial support may impact the operation of the capabilities advertised within the Router CAPABILITY TLV is outside the scope of this document.“ While it might be true that this is specific to the capability, I would put a MUST requirement in here for future specifiactions: Partial suport MUST be defined in the document that describes the subTLV. 4) On this sentence: „Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP.“ What does "silently" mean here? Is it not allowed to log such an event? I would recommend to either clarify that "silently" means here or remove that word. 5) In this sentence: "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level without change even though it may contain some sub-TLVs which are unsupported by the Router doing the leaking.“ I would recomend to use the normative language differently to be clear about what it applies to: "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST NOT change sub-TLVs which are unsupported by the Router doing the leaking.“ 6) In section 5: „Note that an integrity mechanism, such as the one defined in [RFC5304] or [RFC5310], should be applied if there is high risk resulting from modification of capability information.“ Why is that a SHOULD and what's a „high risk“? It should me either "MUST be applied at high risk" and defining what a high risk is, or it should be "SHOULD be applied at (any) risk".
Ron Bonica performed the opsdir review.
draft-ietf-isis-remaining-lifetime
Two small comments: 1) Maybe explain briefly also in this doc what ZeroAgeLifetime is; that would be helpful! 2) You write: „Retention of stale LSPs therefore has no negative side effects other than requiring additional memory for the LSPDB.“ -> Can this lead to a memory exhaustion attack instead? Should this be discussed in the security section?
I have just a few minor comments: - 1, 2nd paragraph: "... the checksum field MUST NOT be altered..." That sounds more like a statement of fact than a normative requirement. -1, paragraph 4: I’m no expert here, but are where the originator might want to let the LSP expire before it becomes unreachable? (e.g. during a graceful shutdown?) -2, 4th paragraph from end: "An additional action is added: " This document adds the additional action, or ISO10589 adds it?
I have some comments related to the normative language in the document (and some other minor points later) — they don't raise to the level of a DISCUSS, but I would like to see them addressed before publication. 1. There are several parts of the text where statements of fact, or normative requirements from other documents are reflected using rfc2119 language. I think that use of rfc2119 is inappropriate and (in the case of references to ISO10589) inaccurate [*]. Please find a way to reflect the requirements without using rfc2119 language. These are the pieces of text I'm referring to: a. Section 1. (Problem Statement): "…as the checksum field MUST NOT be altered…" b. Section 2. (Solution): "[ISO10589] specifies that maximumLSPGenerationInterval MUST be…" c. Section 2. (Solution): "The pseudo-node LSPs generated by the previous DIS are no longer required and MAY be purged by the new DIS." d. Section 3.3. (Impact of Delayed LSP Purging): "LSPs from a node which is unreachable (failure of the two-way-connectivity check) MUST NOT be used." 2. In Section 3.1. (Inconsistent Values for MaxAge): "Implementors of this extension MAY wish.." Note that the "MAY" is modifying "wish", which is meaningless when talking about normative language. Suggestion: simply s/MAY/may The "MUST" in the following sentence is enough. 3. In Section 3.2. (Reporting Corrupted Lifetime): "…an implementation MAY wish to retain the value of RemainingLifetime received…" Similar to the previous comment; in this case the "MAY" is not even necessary because the behavior (to retain) is not needed for interoperability. If you want to keep it, s/MAY wish to retain/MAY retain 4. There are several instances of "RemainingLifetime" -- that is fine, but you seem to be inconsistent with "Remaining Lifetime". And there's even one "Lifetime" by itself… 5. s/w/with (Section 2). [*] I haven't read ISO10598 in a while, but I'm pretty sure it doesn't use rfc2119 language…
Tim Wicinski, tjw.ietf@gmail.com performed the opsdir review, some nits that I haven't seen comment on yet. Hi I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed: draft-ietf-isis-remaining-lifetime-02 Status: Ready with nits Spelling Nits: Abstract: "Corruption of the Remainining Lifetime Field" *Remaining* 2 (vi): not result in LSPDB inconsistency among routers in the newtork. *network* (vi): vi. If the RemainingLifetime of the new LSP is less than MaxAge it is set to MaxAge Period at end of sentence It appears that you interchange 'Remaining Lifetime' and 'RemainingLifetime' (14 for the former, 19 for the latter). I could not understand the pattern. Was this intentional? tim _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-sipcore-dns-dual-stack
Thanks! This seems very useful in the preparation for Happy-Eyeballs. One question: Why does a client need to look up ALL addresses if it already knows that it itself only support one specific address familiy? And related to this question: Shouldn't it be named "multi-stack client" instead of "dual-stack client"?
* Section 3.1 It is not clear to me what exactly the normative addendum is requiring the client to do as regards to the DNS query while implementing "The dual-stack client SHOULD look up all address records". Does this mean that the client should do a AAAA (28) query followed by (or in parallel or preceded ) for a A (1) query? I think it would be good to clarify the types and ordering/concurrency of the queries. * Section 4 I am a bit puzzled by the merging of the address lists from two separate DNS queries in relation to RFC6724. This is how I see the destination address selection in RFC6724. The application ends up calling some kind of name resolution API (something like getaddrinfo()) with a hostname/FQDN (say sip-1.example.com) and this results in a set of addresses being returned. The destination address selection algorithm specified in Section 6 of RFC6724 then orders these addresses and picks one. I am not seeing how the second FQDN and its associated set of addresses become involved in the RFC6724 process. Is this something that you are adding on top of RFC6724? Please clarify.
I appreciate this work. I do have one comment. Could you provide some explanation for the reader as to why SIP is "different", following this statement? Even an example would be useful. Unfortunately, in common SIP situations, it is not possible to "race" simultaneous request attempts using two address families.
draft-ietf-radext-ip-port-radius-ext
I fully support Alissa's discussion points and have two more to add: 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very future-proof: there are other transport protocols that have ports or identifiers that may want to be supported in future. Also it is not clear to me from the document why this information is needed at all in the described use cases. Therefore I see two possible ways forward: Either remove the IP-Port-Type TLV or extend it to also cover other cases. Related to this point I would like to mention that RFC6887 is not restricted to UDP/TCP and therefore the following sentence in section 2 is not correct: "Note that the definitions of [...] "internal port", [...] "external port" [...] are the same as defined in Port Control Protocol (PCP) [RFC6887]" 2) The IE doctors have provide feedback to IANA that the Information Elements in this doc are underspecified (not confirm with rules in RFC 7013) and should therefore be not registered. Addressing this feedback could lead to a mayor rewrite of this doc, especially in the relation to the use and definition of transportType and receptively IP-Port-Type TLV, and should therefore be done before a final IESG decision.
I originally intended the two comments under "Major Issues" to be points for a
DISCUSS position. But I see Alissa has already captured the essence of them in
her DISCUSS. Therefore I will ballot NO OBJECTION for now, and will watch that
discussion.
Major Issues:
The guidance for IP-Port-Local-Id TLV contemplates using persistent client
identifiers, such as MAC addresses. Is that necessary? I suspect the answer
will be "yes". But if that is the case, the draft really needs a privacy
considerations section to discuss the implications and tradeoffs.
- 3.1.1, paragraph 7: "However, the RADIUS server is not required to honor such
a
preference."
Please describe what it means to "not honor" such a preference? Does the server
report an error? Does the transaction succeed, but report a different limit?
Does the server just ignore the preference and do its own thing? (I expect this
applies to any number of failure conditions.)
Minor Issues:
- Please clarify the applicability to IPv4 and IPv6. Specifically, I note that
you define TLVs for "internal" IPv4 and IPv6 addresses, but only for "external"
IPv4 address. I assume that to mean that this supports Nat44 and Nat64 use
cases, but not anything that uses IPv6 in the "external" realm? (Whatever the
answer, it would be helpful to have a paragraph or two to make that explicit.)
-2, definition of "port-based device":
Wouldn’t that more properly be called a port-mapping device? (anything using
TCP or UDP would seem to be port-based)
-3.1.1, last paragraph:
This language precludes new extension packet types from using the attribute
without updating this document. Is that really the intent? Would it make sense
to say something like "... MUST NOT appear in any other RADIUS packet types
defined at the time of this writing. If a future packet type uses the
attribute, the specification of that packet type will need to define it's
usage"? (Note that this issue repeats several times in the document.)
Editorial Comments and Nits:
- The use of the term "session" seems inconsistent. In some places it seems
like an IPFlow or a NAT mapping, but in other places it seems like a network
connection (i.e. NAS attachment.)
- 1, list item 1:
Singular/plural mismatch for "packet". Either "packet" should be "packets", or
you need an article before RADIUS. (e.g. a RADIUS...packet.) Note that this
error repeats many times in similar patterns throughout the document.
-1, list item 2, last sentence:
Convoluted sentence. Can it be simplified?
-1, last paragraph:
It would be helpful to mention that this draft defines IPFIX elements near the
top of the section, and also in the abstract.
-2, definition of "Internal IP Address": "refers to the IP address that is used
as a
source IP address"
Used by what device?
-2, definition of "mapping":
I cannot parse the text. (Note that while the last paragraph in the section
says this is taken from 6887 and 6888, neither of them seem to use this
specific language.)
-4.1, second paragraph: " A CGN function in a broadband network would most
likely co-located on a BNG." There's a missing word in there somewhere. Maybe a
"be" before "co-located"?
-6, last paragraph:
The paragraph doesn't parse. Should "deployed" be "deployments"?
* Why are the the uint8 and unit16 based types getting stuffed into 32 bit fields inside the TLVs? This feels like a complete waste. Is there any specific reason this is required? * Does the IP-Port-Limit include the count of ports already allocated through the IP-Port-Forwarding-Map or not? * I agree with Alissa's DISCUSS points about the lack of error handling and the privacy issues and Mirja's DISCUSS point about restricting transport protocols to TCP and UDP.
(1) I find the absence of any definition of error handling behavior in this document to be a problem. I realize that the attributes specified in this document are meant to be transmitted between components that are all operated by the same administrative entity, but implementors can still make mistakes, and for those cases it seems like error handling should be defined. For example: - What happens if the AAA server sends an IP-Port-Limit-Info attribute with a larger limit than the CGN is able to allocate to that particular user? What is the CGN supposed to do and how is that communicated back to the AAA server? - What happens if the CGN sends an IP-Port-Range attribute that encompasses a larger range than a previously sent IP-Port-Limit-Info? What is the AAA server supposed to do? - What happens if the AAA server sends an IP-Port-Forwarding-Map attribute to map a port that is not within the requesting host's allocated range? Is the CGN expected to change the mapping and send a CoA with a different IP-Port-Forwarding-Map, or communicate some sort of error, or something else? There are surely other error cases. I think it's worth going through the uses of each attribute and specifying all the error handling behavior. This seems especially important since part of the motivation for these attributes is for identification and the consequences of erroneous identification could be severe for the user. Discussion of those consequences is also missing from Section 6. (2) Section 3.1.2 says: "For port allocation, both IP-Port-Range-Start TLV and IP- Port-Range-End TLV must be included; for port deallocation, the inclusion of these two TLVs is optional and if not included, it implies that all ports that are previously allocated are now deallocated." How does an AAA server distinguish between port allocation and deallocation requests if a deallocation request includes a range start and range end? Is the server supposed to assume that whatever range is specified by the most recently received IP-Port-Range attribute represents the only range of allocated ports for the host? What is the meaning of sending an IP-Port-Range request with only a start value or an end value but not both (as seems to be allowable by the above)? (3) The specification of IP-Port-Local-Id seems to allow for unnecessary exposure of potentially sensitive information. There is no explanation given for why the combination of the other identifiers included in IP-Port-Range and IP-Port-Forwarding attributes is insufficient to identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As defined, it sounds like implementations could put basically any user, device, or interface identifier in there. If this TLV is actually necessary to communicate what these attributes are trying to accomplish, the justification for it should be provided and the limitations on when this field may be used and what kind of identifiers can appear here should be stated. (4) The shepherd write-up discusses two different approaches to defining the sub-TLV types and then says: "Both approaches were considered as valid and the WG has decided to let IANA decide what the approach is preferred when allocating the TLV-Type for the sub-TLVs defined in this document." This is not appropriate. The document needs to explicitly define how the types should be allocated and should not leave the decision to IANA. I see that IANA has already noted that Section 7.3 is ambiguous about this; the WG needs to make a choice. (5) Section 6 seems to be missing a discussion of the consequences of communicating erroneous port range and port mapping information. Since part of the motivation for these attributes is identification of the host, this needs to be discussed.
(1) What does it mean for an IP-Port-Range attribute to have IP-Port-Type 1 or 2? Can numbers in the whole range be used for any of the port or identifier types? Or is the range expected to be split up somehow among the multiple types? I think this needs to be explained. (2) In 4.1.4, how does the ISP know that Joe is traveling?
I agree with Alissa's questions.
Maybe it is just me, but I found that the idea that most subattributes are the
same size, but right aligned to be wasteful. Is this a common design pattern
for Radius?
I am agreeing with Alissa on privacy concerns.
On page 12:
IP-Port-Int-IPv6-Addr TLV
This TLV contains an IPv4 address that is associated with the
Typo: should be IPv6?
internal IP port number contained in the IP-Port-Int-Port TLV.
For IPv6 network, either this TLV or IP-Port-Local-Id TLV must
be included as part of the IP-Port-Forwarding-Map Attribute.
Refer to Section 3.2.5.
draft-ietf-radext-datatypes
-2.1.2, first paragraph: "The specification may, of course, define a new data type and use it in the same document." Am I correct to assume that any such definition must (or maybe MUST) be registered? (Maybe that's already covered in 6929?) -4.1: I'm curious why new data types need a policy as strong as "standards action". Is there a concern that people will get this wrong without the full weight of the IETF consensus process? Is there a concern that the numbering space will run out? Would it be reasonable to have a "specification-required" policy, with some guidance to the designated expert(s)? (Or is it because such data types need to be referenceable from standards track documents, perhaps related to the guidance against vendor-specific types?)
It would have been nice to consolidate the IANA-related sections (4 and 6) in one place.
* Section 3.10 It is not clear from this definition how exactly a sender needs to encode this attribute on the wire. e.g. From the spec it looks like an IPv6 prefix such 2001:db8:dead:beef::/64 can legally be encoded using anywhere between 8 octets and 16 octets. What exactly is the preferred encoding? If you intend to allow all of the encodings can you please add an explicit statement to say so.
* I am not sure why this document uses Reserved fields in sections 3.10 and 3.11. Is it for alignment? Please clarify. I don't see exactly why aligning a 4 octet or a 16 octet value to a 16 bit boundary would provide any value. (I personally think such padding related stuff should be in the definition of the radius attribute that uses the datatype and not in the datatype itself but I will not block on this.) * Section 3.7 I think this text is confusing because "octet string" and network byte order do not seem to be compatible. Suggest rewording OLD: The "ifid" data type encodes an Interface-Id as an 8-octet string in network byte order NEW: The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in network byte order * Section 3.10 and 3.11 The separator between the Reserved field and the Prefix Length field is off by one position.
In Section 4.1, if the registration policy is Standards Action doesn't that obviate the need to say anything about IETF Review?
I think this is a very useful document, thank you for writing it. Some comments: In 3.4: ABNF needs an informative reference to RFC 5234. In 3.16: there is a reference to Section 2.13. There is no such section in the document. Did you mean 3.15? In 4.1: does the "value" even need to be in the IANA registry, considering that it never appears on the wire? In 4.2: I would recommend that you instruct RFC Editor to remove the CSV content, as it is not useful long term. So basically IANA can use the data, then the section can be shortened.
"As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet." Given the Name must be unique, I don't see why a Value field is needed. Related: There is an inconsitency between section 4.1 and 6 regarding the use of Description/Name.
draft-ietf-jose-cfrg-curves
I note that the reference to RFC7748 is a normative downref that does not appear to be mentioned in the last call announcement. It’s not in the downref registry, but since it's an algorithm spec, it probably should be. I don't suggest any particular course of action; I merely bring it up in case people hadn't already noticed.
draft-ietf-manet-smf-sec-threats
Thanks for your work on this draft!
draft-ietf-i2rs-protocol-security-requirements
A few comments: 1) I don't think copy&paste from RFC4949 is necessary. I would recommend to remove this part and just name the definitions that are needed. 2) The following sentence seems to indicate that the refernce to RFC4949 should be normative. "The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]." As I don't think this is needed, I would recommend to rather spell out the properties here in this sentence. Also, to be honstest I not sure what this sentence tells me at all. So maybe stating clearing what you mean (instead of just having the reference) would help anyway. 3) To me it's not really clear why there are several requirments docs (that also are connected and refer each other; see e.g. section 3.6 and SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). Couldn't those docs be combined to one requiremnet doc? 4) Section 3.1 says: "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements:" Why is this needed is RFC7921 already sets these requirements?
I have the same concerns as others around the secure transport, but I'm not
putting in a DISCUSS because the concerns are already well represented. Just
one additional comment on the topic:
I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be
able to transfer data over a secure transport and optionally MAY be able to
transfer data over a non-secure transport") and this text from Section 3.
(Security-Related Requirements): "…MUST be able to exchange data over a secure
transport, but some functions may operate on a non-secure transport." The
latter text talks bout "some functions" using a non-secure transport, while
SEC-REQ-09 implies that everything may use it.
Other comments from Section 3.1. (Mutual authentication of an I2RS client and
an I2RS Agent)
-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets
the following requirements". I'm not sure what you mean my "sets", as there
are no requirements (labeled as such) in the architecture document. If there
are, then this section doesn't seem to be needed (as others have mentioned).
Maybe "these requirements are derived from the architecture", or something
similar may be more appropriate.
-- What is a "valid identifier"? A couple of requirements where a "valid
identifier" "MUST" be confirmed are listed, but no indication as to what that
may be in this document or the architecture one. The definition of identifier
doesn't help…
-- SEC-REQ-05 and SEC-REQ-06 sound the same to me. What is the difference?
BTW, if there is a difference, instead of "IETF" I think that "standardized"
may be better.
Version 8 resolved my discuss point for section 3.4. Thanks! I don't think it resolved my discuss point for 3.2. I'm clearing anyway, because I think my point has been made. I would prefer the language to say that anything not explicitly marked as non-confidential in the relevant data model MUST be sent over a protected transport. But I will leave it to the authors to do the right thing. I will leave my non-discuss comments below for reference. I think version 8 resolves at least some of them. Any remaining are up to you; none of them are show stoppers. -2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent". I agree with Alissa about equating privacy and confidentiality. -3.1,: I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right? It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection” part in 6? -3.4: Isn't 15 simply a restatement of the third item under 14? 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they grant permission?)
s/One mechanism such mechanism/One such mechanism/
Thanks for your work on this draft. There may be some overlap in points, I tried to minimize them... ---- Section 3.1: I don't see any actual requirements for mutual authentication in this section, just requirements for identifiers. Did I miss something? Are all mutual auth schemes in scope? Are there any considerations for mutual authentication (passwords, keys, etc.)? ---- I share the same concern as others for secure transport, but since there are already discusses on that, I have one comment to add to the existing discusses below.
Section 3:
Can you clarify the second to last sentence? Do you mean there are sections
that indicate an insecure transport should be used?
I2RS allows the use of an
insecure transport for portions of data models that clearly indicate
insecure transport.
Perhaps:
I2RS allows the use of an
insecure transport for portions of data models that clearly indicate the use
of an insecure transport.
----
Section 3.2
I agree with Alissa's discuss point on the following sentence (that could also
be reworded a bit):
A non-secure transport can be can be used for publishing telemetry
data or other operational state that was specifically indicated to
non-confidential in the data model in the Yang syntax.
----
Section 3.4: In the following text:
SEC-REQ-15: The integrity that the message data is not repeated means
that I2RS client to I2RS agent transport SHOULD protect against
replay attack
I'm not sure why this just doesn't say:
SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect against
replay attack
The additional text doesn't add anything and sounds a bit confusing.
----
Nit:
I'm not sure these definitions add any value as they seem to restate the term
defined:
I2RS protocol data integrity
The transfer of data via the I2RS protocol has the property of
data integrity described in [RFC4949].
I2RS component protocols
Protocols which are combined to create the I2RS protocol.
-----
I also agree that the definitions from 4949 should be removed.
Thank you in advance.
== Section 3.2 == "A non-secure transport can be can be used for publishing telemetry data or other operational state that was specifically indicated to non-confidential in the data model in the Yang syntax." What kind of telemetry data is it that is of no potential interest to any eavesdropper? This is not my area of expertise so I'm having a hard time conceiving of what that could be. I'm also wondering, since I2RS agents and clients will have to support secure transports anyway (and RESTCONF can only be used over a secure transport), why can't they be used for all transfers, instead of allowing this loophole in the name of telemetry, which undoubtedly will end up being used or exploited for other data transfers? If the argument was that this loophole is needed for backwards compatibility with insecure deployments of NETCONF or something like that I think it would make more sense, but my impression from the text is that those will have to be updated anyway to conform to the requirements in this document.
In general I agree with Mirja that where other documents already provide
definitions, they should be referenced, not copied or summarized, in this
document.
== Section 2.1 ==
Using "privacy" as a synonym for "confidentiality" is outmoded, I think, given
current understanding of the many other facets of privacy (see, e.g., RFC
6793). I would suggest dropping the definition of data privacy and just using
the word confidentiality when that is what you mean.
== Section 2.2 ==
"The I2RS protocol exists as a higher-level protocol which may
combine other protocols (NETCONF, RESTCONF, IPFIX and others)
within a specific I2RS client-agent relationship with a specific
trust for ephemeral configurations, event, tracing, actions, and
data flow interactions."
Reading the provided definition of "trust," I'm not sure what "with a specific
trust for" means in the sentence above.
"The I2RS architecture document [I-D.ietf-i2rs-architecture]
defines a secondary identity as the entity of some non-I2RS entity
(e.g. application) which has requested a particular I2RS client
perform an operation."
Per my comment above, I would suggest just referencing the definition from the
architecture document. The text above is circular ("the entity of some ...
entity") and conflates an identity with an identifier.
== Section 3.1 ==
Agree with Mirja that this section is superfluous.
== Section 3.3 ==
Since the normative recommendation here isn't to be enforced by the protocol,
why is it SHOULD rather than MUST? Same question applies to SEC-REQ-17.
== Section 3.5 ==
Is the omission of normative language from Sec-REQ-20 purposeful?
draft-ietf-kitten-aes-cts-hmac-sha2
There was a Gen-ART review from Vijay, with a question about the contents of the Context field. I don't think the document necessarily needs a change or even new text here, but at the very least we need an answer from the authors. I got the same question as Vijay when reading the draft.
First mention of UTF-8 needs a reference to RFC 3629.
conflict-review-behringer-ncrg-complexity-framework