IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-12-01. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
Telechat:
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
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:
Telechat:
7. Agenda Working Group News
1410 EST Executive Session
(at 2011-12-01 07:30:03 PST)
draft-ietf-speechsc-mrcpv2
I'm trying to extract the ABNF and compile it, but I'm getting errors and at least some of them seem like real errors. I did have to do some hand-editing to make the extract work, though. Here are some of the errors that I'm getting: stdin(140:0): error: Rule set-cookie was already defined on line 128 of stdin 128: stdin(614:0): warning: rule Abort-verification previously referred to as abort- verification stdin(288:0): error: Rule positive-speech-length was already defined on line 214 of stdin 214: Ask me for the input file and the full errors list if you need it. But I do think that the document's ABNF should compile cleanly before we can approve it. Of course, I could have missed something when I did my hand-editing. Finally, there are no errors if I parse the appendix that has the ABNF but there are errors if I parse the extracted ABNF. And there seems to be real differences, such as duplication of rules between many sections. E.g., 8.4.1 and 8.4.15 both define positive-speech-length. Please demonstrate that the two sets of ABNF are equivalent.
I have one Discuss issue that should be easy to resolve. I have a concern that the name of the "vendor-specific parameters" is somewhat misleading, and the purpose and details of the "MRCPv2 vendor-specific parameters" registry are not well-defined. However, I need to get some clarification before I can make my Discuss actionable. As I understand the syntax of "vendor-specific parameters", such a parameter is identified by a Domain Name (in reverse order), followed by the name of the parameter. I also understand the registration policy for the "MRCPv2 vendor-specific parameters" to be FCFS, with a recommendation that the "assignment requests adhere to the existing allocations of Internet domain names to organizations, institutions, corporations, etc." Do I have it right that there is no attempt to determine if the submitter of a request has authority to add a registration to the registry under a given Domain Name? E.g., Alice, an employee of organization A, could submit a request to register com.b.new-parameter and there would be no checking that Alice has authority to register com.b.new-parameter. I don't see any description of the value types, ranges or semantics associated with the registered vendor-specific options. Is it the intention of the registry to list the known vendor-specific parameters without any additional information?
Editorial suggestion: I haven't checked the ABNF snippets in the body of the document against the ABNF Normative Definition in section 15. If it's important to include the ABNF snippets in the body of the document, in my opinion it would be prudent to add a sentence to section 15 explicitly identifying the ABNF Normative Definition as definitive (and, as labeled, normative) relative to the snippets in the body of the document. Minor editorial suggestion: the term "channel identifier" is first used in section 3, constrained there to be "unambiguous", then defined (twice) in section 4 and referenced again (along with the "unambiguous" contraint) in section 6. For clarity, I suggest giving the definition once, preferable at first use of the term. Even more minor editorial suggestion: the term "CRLF" is used several times and then finally defined in section 6.2.11. Might be better to define at the first use of the term.
A few things to check and maybe tweak but actually the security considerations and references already do a pretty good job for such a big spec. #1, p12, What is an "unambiguous channel identifier"? Security questions might revolve around collision probabilities etc. This intro section seems to assume that its ok if the server allocates separate ids, but bad clients might guess others' ids. Clarifying "unambiguous" would probably fix this if you said that those ids also need to be hard to guess. #2, p42, What do you mean by "identifying information" in 6.2.14? If its *personally* identifying information (PII) such as a user's name or (possibly) IP address then the RECOMMENDATION may be wrong. If not PII then what's meant here? If you just meant identifying the client UA or something that'd probably be fine but it'd be better to be clear about that. #3, p42, What set of client cookies MUST be sent to the server? I'm just checking that its not supposed to be a browser's full set of cookies. #4, p57, Can I really ask a server to say something for 10^19 seconds? "Say Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhh..." for 115740740740740 days seems like a fine DoS to me. Suggest you RECOMMEND some sanity checking of input on that or maybe I'm reading it wrong? (Would the same apply to any of the other constructs with 19DIGIT in their abnf?) #5, p94 and elsewhere, all messages that contain URLs that the other party might de-reference SHOULD come with a health warning - they can be abused in various ways. 12.4 doesn't really cover that and would seem like a fine place to warn about blindly following URLs. Can't think of an RFC with good text for that right now, but I'd say there might be one if you poke about. #6, p140, speaker verification - have none of the caveats for when its considered safe to use this changed since 2005? (When RFC 4313 was published.) That seems a bit unlikely. Has someone looked to see what's the current state of the art wrt cheating on systems like this? #7,p160, surely the DELETE-VOICEPRINT method and others imply a need for authorization. Where's that covered? I didn't see it in section 12. Am I missing something? #8, p170 says that one-time URIs might be useful. I think that needs to say that if used, it MUST be infeasible to guess them. Should be a simple enough change.
- This is abominably long;-) - p9, "based on" MRCP is a bit vague, be nice to know what kinds of change was planned, done etc. and what kinds of (in)compatibilities exist between this and that. - p9, "break the RTSP protocol" seems a bit dramatic, some details would be better, but maybe being coy is the best that can be done without opening cans of worms. - p15, ist sentence of 4.1 is odd, "such as SIP" is supposed to mean what exactly? Is there an alternative? - p17, (last para, and p24 last para) isn't it just a conflict to say servers MUST support TLS, but yet servers MAY not support TLS? You can't have it both ways. I think maybe s/support/use/ might fix it, i.e. saying "MAY use TCP without TLS in controlled environments." - p23, (and elsewhere) wheere are "recvonly" etc. defined? Don't you need a reference or to defined those? - p26, what does "This field MAY be printed..." mean? Printed? - p40, can the fetch-timeout be handed to a server by a client? If so, could it be the basis for a DoS on the server? If so, then that should be noted in the security considerations and (given the length of the document) also in 6.2.12. - p41, as for p40 - can client's cause servers to cache stuff for long periods as a DoS attempt? - p169, saying you SHOULD "employ" TLS seems to imply that TLS is mandatory to implement. It'd be good to be explicit about that. - p169/170, says "If appropriate...SRTP...is RECOMMENDED" When is SRTP "appropriate"? If its not appropriate, then what else can be done?
Section 5: MRCPv2 messages are textual using the ISO 10646 character set in the UTF-8 encoding (RFC3629 [RFC3629]) to allow many different languages to be represented. This sentence does not appear to be true, given that later you refer to message bodies containing binary data made up of octets. I am left to wonder what this is supposed to mean. The MRCPv2 protocol headers (the first line of an MRCP message) and header field names use only the US-ASCII subset of UTF-8. Internationalization only applies to certain fields like grammar, results, speech markup etc, and not to MRCPv2 as a whole. The first sentence is probably OK, but I have no idea what the second sentence means. I suspect you're talking about *localization*, not *internationalization* (for example, that header fields names and contents are not subject to localization because they are protocol elements), but to be honest, I'm not really sure. Something is wrong in those two sentences. Please see if you can straighten this out.
I agree with Stephen (and likely everyone else) that this document is abominably long. It could have reasonably been broken up into multiple documents, which would have made readability much better. I have a sneaking suspicion that it will be impossible to implement a completely independent interoperable implementation just from this spec. I also have a sneaking suspicion that this will never advance beyond Proposed Standard. I understand that this document suffers from being the result of a long process, but incremental publication and experience (instead of dumping everything into a grand unified document the first time out of the gate) would have made for better output. Still, I'm not willing to stop the document at this point. The work seems important, and you need a record of what everyone is doing. One question off the top: Shouldn't this document be obsoleting RFC 4463? So, on to some actionable fixes: Section 4.2: If the client specifies a value of "existing", the server MUST respond with a value of "existing" if it prefers to share an existing connection or with a value of "new" if not. That should be a MAY, not a MUST: "If the client specifies a value of "existing", the server MAY respond with a value of "existing" if it prefers to share an existing connection or with a value of "new" if not." Section 4.4: An MRCPv2 implementation MUST either multiplex or mix unless it cannot correctly do either, in which case the server MUST disallow the client from associating multiple such resources to a single audio stream by rejecting the SDP offer with a SIP 488 "Not Acceptable" error. The first MUST is superfluous. Instead: "If an MRCPv2 implementation neither multiplexes nor mixes, it MUST disallow the client..." Note that there is a large installed base that will return a SIP 501 "Not Implemented" error in this case. To facilitate interoperability with this installed base, new implementations SHOULD consider adding configuration to treat a 501 in this context as a 488 when it is received from an element known to be a legacy implementation. s/SHOULD consider adding configuration to/SHOULD "Considering" is not something that gets 2119 language. Treating a particular SIP error in a particular way is. Section 5: However, to assist in compact representations, MRCPv2 also allows message bodies to be represented in other character sets such as ISO 8859-1 [ISO.8859-1.1987]. This may be useful for languages such as Chinese where the default character set for most documents is not UTF-8. No reason to cite 8859-1 since that's not what Chinese would use. If you want to site BIG5 or another character set used for Chinese as an example, that might make sense. But I suspect that UTF-8 is probably used by most of these languages now and, given the compressibility, this is no longer really needed. If it needs to be here for backward compatibility, so be it, but I don't think you can really defend the need for other than UTF-8 at this point for any other reason. Some questions: Section 9.6.3.4: Do you really need ISO 8601, or can you use RFC 3339 instead? A more limited set would be better. ABNF. Overall, you should re-use elements whenever possible from other canonical texts if you can avoid re-inventing them for yourself. So: Why did you create LWS instead of using the RFC 5234 LWSP? They're identical. Why use UTF8-NONASCII instead of the productions in RFC 3629 (UTF8-2 / UTF8-3 / UTF8-4)? Is there nowhere to pull the URI definition from? Re-creating ABNF for this stuff seems fraught. Other issues: Why is weight-value needed? It's not reused and FLOAT could go in its place. Why is quoted-string needed in completion-reason? Why not just *UTFCHAR?
1. There is no indication whatsoever in the document about how this protocol is managed. I do not know to what extent MRCPv1 was deployed, but assuming it was there should be some operational experience about the operational model, how performance is measured, how problems are detected and signalled to the operators and debugged. This needs not necessarily be part of the same document (this one is already one of the largest we have reviewed in the IESG in the last few years), but I would like to have some clarity and information about these issues, and understand if these will be dealt with maybe in future work before I can approve the document. 2. In the Introduction section: > MRCPv2 is based on the earlier Media Resource Control Protocol (MRCP) [RFC4463] Should not this document update RFC 4463? Would not a log of changes between MRCPv2 and MRCP be useful? Are there any backwards compatibility or migration issues that need to be taken into consideration by operators?
The Abstract and then section 4.1 mention that MRCP > relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities But then the rest of the document only describes the interaction of MRCPv2 with SIP and SDP. My question is whether the 'such as' is really justified or should be just dropped from the two places.
IANA has questions about the XML ns and schema registrations requested by draft-ietf-speechsc-mrcpv2-27.txt. QUESTION: the URIs for the ns and schema registrations are listed as "http://www.ietf.org/xml/schema/nlsml" and "http://www.ietf.org/xml/ns/mrcpv2". Is this correct? Aside from the fact that those links don't work, every other ns and schema registration has a URI in the form "urn:ietf:params:xml:schema:example" and "urn:ietf:params:xml:ns:example". See http://www.iana.org/assignments/xml-registry-index.html
This ought to be easy enough to address: s6.2.15: What is the "Age" attribute used for? It's not clear to me what it's supposed to indicate.
#1) I support Stephen's discusses. #2) s1, s4, s.4.3, s4.3, and s4.5: It's interesting that s1 says that mapping to SCTP isn't covered in this document but through there's still statements about SCTP: s4: MRCPv2 requires a connection-oriented transport layer protocol such as TCP or SCTP to ... s4.2: (The usage of SCTP with MRCPv2 may be addressed in a future specification). s4.2: The server MUST NOT close the TCP, SCTP or TLS connection if it is currently being shared among multiple MRCP channels. s4.3: The MRCPv2 messages defined in this document are transported over a TCP, TLS or SCTP (in the future) s4.5: Multiple resource control channels between a client and a server that belong to different SIP dialogs can share one or more TLS, TCP or SCTP connections between them; the server and client MUST support this mode of operation. The statements in s4.2 and s4.5 are made with normative requirements so is this document really not saying anything about SCTP? It's probably best to just remove all references to SCTP after s1. #3) s3: Not trying to be to penny ante here but should the architecture diagram also include TLS? #4) s3.2: Always trying to promote security in examples maybe add: sips:mrcpv2@example.net #5) s4.2 and 6.2.1: Along the same lines as Stephen's discuss: I was expecting this section to say how the channel identifier is made unambiguous. #6) s4.5: Clients and servers MUST use the MRCPv2 channel identifier, carried in the Channel-Identifier header field in individual MRCPv2 messages, to differentiate MRCPv2 messages from different resource channels (see Section 6.2.1 for details). #7) s5.3: otherwise, it must … otherwise it MUST ? #8) s8.13: The request-state field must have … The request-state field MUST have? #9) s9.4.26: is this recognition-mode = "Recognition-Mode" ":" normal-value / hotword-value CRLF normal-value = "normal" hotword-value = "hotword" the same as: recognition-mode = "Recognition-Mode" ":" "normal" / "hotword" CRLF normal-value and hotword-value aren't used anywhere else. #10) s9.4.6, 9.4.7, 9.4.8, 9.4.15, 9.4.16, 9.4.17, 9.4.18, 9.4.28, 9.4.29: Similar question to Stephen's about positive-speech-length. #11) s10.4.7: Contains: Implementations MUST support 'http', 'https' [RFC2616], 'file' [RFC3986], and 'cid' [RFC2392] schemes in the URI. Note that implementations already exist that support other schemes. I think it's supposed to be: Implementations MUST support 'http' [RFC2616], 'https' [RFC2818], 'file' [RFC3986], and 'cid' [RFC2392] schemes in the URI. Note that implementations already exist that support other schemes. Also, in lots of other places it just says support for http and https and now file and cid get thrown in. Is this consistent throughout the draft? #2^19) Tell me you haven't hidden the meaning of life in this document or an offer for free beer and I missed it ;)
draft-ietf-6man-rpl-routing-header
I have two Discuss issue that should be easy to resolve. 1. I think there is an inadvertent omission of some text. From section 4.2: When forwarding an IPv6 datagram that contains a SRH with a non-zero Segments Left value, if the IPv6 Destination Address is not on-link, a router SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the packet's Source Address. There should also be text explicitly requiring that the router drops the datagram. 2. This issue requires a little clarification before I can provide an actionable Discuss issue. Is it possible to deploy RPL in a network in which not all of the nodes in the network participate in RPL? E.g., can there be "leaf" nodes, the equivalent of hosts, that do not participate in RLL and that exchange datagrams with immediate neighbors that are RPL routers? If so, I think there needs to be additional text similar to that in section 5 describing how a RPL router must ensure that it doesn't forward a datagram containing an SRH to a non-RPL leaf node.
Comment added on 11/30. The working group summary is pretty terse. I think it would be helpful to explain that the design and use of the option morphed several times during the working group discussion before it arrived at its current state. Also, the working group summary should refer to the roll (not RPL) working group.
I have no objection to the publication of this document, but I have a number of small editorial questions/comments that I hope you will address along the way. Section 2 First, RPL routers implement a strict source route policy where each and every IPv6 hop is specified within the SRH. appears to be in conflict with 2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] This probably just needs clarifying text in the paragraph. There is explanation of when the situation occurs (after the numbered list). --- Section 3 Next Header Shouldn't your base reference be RFC 2460? If IPv6 was to choose to diverge from IPv4, which one would you follow? --- Section 3 Routing Type You do not mention the use to which this field is put anywhere in your document. It should probably go here. --- Section 3 Reserved You have not said how the Reserved field is handled. --- It would have been useful to state (section 4.1?) how "segments left" is set on the initial SRH and whether the first entry in the address list includes the source node. --- Section 4.2 else if 2 or more entries in Address[1..n] are assigned to local interface and are separated by at least one address not assigned to local interface { This check is more specific than the text previously indicated. This is the first mention of non-adjacent repeat addressing. --- Section 4.2 swap the IPv6 Destination Address and Address[i] Do you really mean swap? Or do you just want to set DstA = Address[i] ? --- Section 4.2 I'm surprised that you check and decrement the hop limit so late in the cycle.
Same discuss point as for the other RPL doc. Should have the same solution as well. What countermeasures exist for the attacks listed in section 6? I guess at least some hop-by-hop authentication and integrity would provide some accountability and prevent some spoofs. Doesn't RPL have some such mechanism that can be used? If so, then wouldn't it be right to RECOMMEND support for that and maybe even use of that?
- how are RPL routers supposed to know which of them are border routers at what point in time? Doesn't needing to know this further constrain the applicability of this scheme? - is it allowed for a RPL router to just drop an SRH and replace it with an entirely new SRH? - s1, "necessary mechanisms" is a bit odd, be better to name them if they're known/agreed already. - 6.1 seems to imply that all the attacks listed can be mounted from within the LLN. Truth in advertising would call for saying that explicitly.
I'm stepping right out of my knowledge box so I might get back in it quite quickly: I find it interesting that you've modeled SRH on SSSR: The function of SRH is intended to be very similar to IPv4's Strict Source and Record Route option [RFC0791]. but RFC 6274 says this about the SSSR option: As with the LSRR, while the SSSR option may be of help in debugging some network problems, its security implications outweigh any legitimate use of it. Some of the security implications are as follows: Among other things, the option can be used to: o Bypass firewall rules o Reach otherwise unreachable Internet systems o Establish TCP connections in a stealthy way o Learn about the topology of a network o Perform bandwidth-exhaustion attacks I guess the ship may have sailed but I'm curious why one thinks is not worth using but this is modeling behavior after it. Are these issues introduced now as well?
draft-ietf-6man-rpl-option
1. The first sentence of section 4: Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY include both. Under what circumstances would a RPL router include an SRH but not a RPL Option? 2. This issue requires a little clarification before I can provide an actionable Discuss issue. Is it possible to deploy RPL in a network in which not all of the nodes in the network participate in RPL? E.g., can there be "leaf" nodes, the equivalent of hosts, that do not participate in RLL and that exchange datagrams with immediate neighbors that are RPL routers? There is a hint that such a deployment is anticipated in the phrase "attachment router" in section 4. If so, I think there needs to be additional text similar to that in section 5 describing how a RPL router must ensure that it doesn't forward a datagram containing a RPL Option to a non-RPL leaf node.
I have no objection to the publication of this document, but I have a umber of questions/nits that I hope you will consider. Section 1 To that end, this document proposes a new IPv6 option, s/proposes/defines/ --- Setion 2 Every RPL router along a packet's delivery path processes and updates the RPL Option. If the received packet does not already contain a RPL Option, the RPL router must insert a RPL Option before forwarding it to another RPL router. Surely that means that the absence of the option indicates a defect in the upstream router. This issue is also present in section 4 where there is some flexibility about whether to include the RPL Option, but no guidance. --- Section 3 Please consider using RFC2119 language (e.g. "shall") --- Section 3 Nodes that do not understand the RPL Option MUST discard the packet. You cannot state this in this way. Nodes that do not understand the option will not implement this spec! You probably simply need: As defined in [foo] nodes that do not understand an option on a received packet MUST discard the packet. --- Sections 3 and 7 Please check "sub-TLV" and "TLV". I think you have used them interchangeably.
Same discuss point as for the other RPL doc. Should have the same solution as well. What countermeasures exist for the attacks listed in section 6? I guess at least some hop-by-hop authentication and integrity would provide some accountability and prevent some spoofs. Doesn't RPL have some such mechanism that can be used? If so, then wouldn't it be right to RECOMMEND support for that and maybe even use of that?
- Why does this header need an instance ID when the SRH did not? - I don't get why this wasn't part of the core RPL spec, if in fact "RPL requires..." this as stated at the start of section 2. - s2, s/This draft specifies the use.../This draft also specifies the use.../ would be clearer as the non-tunnelled option is also allowed here. - s4, this says the router MUST include the RPL option - but is that needed in *every* packet? - s6, it would be better to give more detail of the several potential attacks, so that people could know to look out for or mitigate those.
The Gen-ART Review by Joel Halpern on 22-Nov-2011 included a suggestion for improved clarity. Please consider it. While calling a bit the O bit does not appear unreasonable, I note that when looking at the packet form, the difference between the O bit and the mbz bits marked as 0 is small, and a likely source of confusion for the reader.
Please double-check the first paragraph of section 4 to make sure that "ICMPv6 errors generated by inserting the RPL option" is really what you mean to say - are you talking about errors that resulted from inserting the option itself, or possibly other ICMP errors that might result from other data in the tunnel header?
I support Stephen's discuss.
draft-ietf-dime-priority-avps
- The document assumes I already know what a "priority parameter" is, I don't, and that's a problem for the reader. I think at least a reference to where this is defined would be good. If there's no single definition then just explaining why a bunch of new AVPs are needed would be fine. - is the title of 3.3.1 correct? The other sections are named for the AVP but this isn't. Maybe a typo? The AVP in 4.1 matches the section title but not the AVP name in the body of 3.3.1. 3.4.2 seems to have the same problem.
1) The Introduction says "The influence attributed to prioritization may also affect QoS, but it is not to be confused with QoS." but section 4 records this in the IANA QoS Profile registry, and section 5 says this documents describes an extension for conveying QoS information. Doesn't this confuse prioritization with QoS? 2) I am unclear on the relation between 3GPP-defined AVPs and the AVPs defined here. The last paragraph of 1.1 says the 3GPP work is not relevant to the current document; then why mention it? I think it is relevant in that it impacts prioritization, but the 3GPP prioritization is limited to within a walled garden. You don't say so, but I assume this means the AVPs defined in this document do NOT operate in a walled garden. Do the ETSI AVPs also operate in a walled garden? I suggest that this should be made clearer by specifying more clearly the intended scope of the ETSI, 3GPP, and IETF AVPs. 3) I think an important missing element here is the impact these different scopes have on operational considerations. What does an operator need to know about the prioritization caused by these AVPs from different SDOs, and how do they interact if multiple types of prioritization is present? Which ones take precedence, assuming comparable values of prioritization? 4) The 3GPP is supposed to be for use in a walled garden; what happens if it "escapes into the wild"? Is there anything an operator can/should do to make sure this doesn't happen, such as configuring a firewall to prevent the AVPs from crossing network boundaries? 5) prioritization might affect QoS. What sort of operational impact might this have, if some traffic prioritized by, for example, a diffserv codepoint is overridden by an AVP? Are there certain types of traffic that operators should make sure AVPs do not override the protocol-defined QoS? 6) What is the persistence of these AVP settings? Do these AVPs only affect the current session, and the AVP-driven prioritization is removed when the authorized session ends, or does the AVP-driven prioritization continue after the current session closes? 7) in 3.1, passive vocie is used to state "Defending-priority is set when the reservation has been admitted." That is a bit ambiguous to me. Do I understand correctly that the defending-priority AVP is **set** by the client in the request message before admission, but the prioritization is only **set** by the NAS in its internal enforcement calculations when the session is admitted? Can the text clarify who the actors are, and when and what each of them sets? 8) in 3.1.1, "value that would be encoded in the signaled ... element." encoded in what message? where is this policy element encoded? Can you provide a reference? 9) in 3.2, "The admission priority of the flow is used to increase the probability of session establishment for selected flows." I don't understand the relationship between "the flow" and "selected flows", and the relationship between these flows and AAA sessions. Is "the flow" the AAA-authorized session flow? Are the "selected flows" in the same authorized session? or does this AVP afffect flows in other AAA-sessions? Is the admission priority of the flow refering to the admission-prioirty-AVP, or the admission-priority parameter that the AVP models?
1) I agree with other comments about the confusion surrouding integrity- protected values. 2) The second paragraph of section 5 says "Use .. MUST take into consideration
The first paragraph of the Security Considerations section is unclear. It appears to instruct elements (not clear which elements) to ignore integrity protected values. Does it mean integrity protected values that fail integrity check? It indicates that protocol specific error messages should be sent when these values are ignored - which protocol(s)? Is the paragraph trying to say something more than "local policy can override the policy requested by protocol messages"?
s3.4 includes the following: Consequently, SIP-Resource-Priority and Application-Level-Resource-Priority AVPs convey the same priority semantics, but with differing syntax. Should guidance be given about what happens when the two conflict (i.e., where high =11, one says high and the other says 10)? Also should some guidance be given as to when to use one or the other?
draft-ietf-trill-rbridge-mib
Has a MIB doctor review been done yet? It seems like one is still needed. I am not a MIB expert, but I think I see a number of issues. --- I'm afraid Sean's Comment needs to be captured in a Discuss. Please resolve the downref to RFC 4663 either by moving it to Informative (which seems reasonable) or by reissuing the last call. --- I would like help from the OPS ADs (and MIB Doctors) on this point: It seems to me that section 6.7 needs a new conformance statement to be applied to ISIS-MIB. The text in the sectionappears to be in two parts: - Implementation guidance (what value to return on a GET from a Trill implementation) - Implementation requirements (which tables/objects to implement or not (conformance statement). --- RbridgeNickname ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The 16-bit identifier used in TRILL as an abbreviation for the RBridge's 48-bit IS-IS System ID. The value 0 means a nickname is not specified, the values 0xffco through 0xfffe are reserved for future allocation, and the value 0xffff is permanently reserved." SYNTAX Unsigned32 (0..65471) As specified, if the reserved values are ever allocated for any reason you will have to respin the MIB module. You probably don't want to have to do that, so why not allow 0..65534? (By the way, if 0xffff is outside the available range, it is by definition permanetly reserved, so maybe you don't need to say anytng about it.) --- There seems to be some confusion about defaults. There are a number of cases where the DESCRIPTION clause states a specific value for the default of a read-write or a read-create object. For example: rbridgeBaseForwardDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Modified aging time for address entries after an appointed forwarder change. The default value is 15. The value of this object MUST be retained across reinitializations of the management system." REFERENCE "RBridge section 4.8.2" ::= { rbridgeBase 3 } This appears to be missing a DEFVAL clause unless you mean something different by "default". If you actually mean that the default in an implementation of the protocol is 15, then it is not appropriate to mention it here. In other objects (rbridgeBaseUniMultipathEnable, rbridgeBaseMultiMultipathEnable) you have "The default is implementation-specific." If this applies to the implementation of the management agent then you might guide the implementer. If it applies to the implementation of the protocol, then it doesn't really belong here. I suggest you look at each DESCRIPTION clause where there is a default described and work out whether you should: - add a DEFVAL clause - reomove the txt - extend the text to give additional advice to the implementer of the management agent. (By the way, sometimes you have included the DEFVAL just fine.) --- rbridgeBasePortIfIndex OBJECT-TYPE SYNTAX InterfaceIndex Should this be InterfaceIndexOrZero? What would happen if the entry was deleted from IF-MIB? --- I expected to see some mention of rbridgeSnoopingAddrType in the conformance statement to limit its applicability to only a few of the address types. --- rbridgeDtreeActiveTrees OBJECT-TYPE SYNTAX Unsigned32 Shouldn't this more properly be a Gauge32?
You should mainly be saying "MIB module" where you say "MIB" --- Some of the IMPORTS clause entries usefully point to the RFCs housing the imported TCs. It would be great if you could include the references for all the others. --- I appreciate the many REFERENCE clauses. Could add one to RbridgeNickname. --- -- Implementation of the rbridgeBase subtree is mandatory for all -- RBridges. Does this mean
- What does "TBD for this section" mean in 5.1? I assume that was meant to be deleted but that got missed?
Thanks to the Gen-ART Review by Roni Even on 20-Nov-2011 for catching the concern reported below. Section 5.10 says: The defined notifications are focused on the TRILL protocol functionality. Notifications are defined for changes in the Designated RBridge status and the topology. TBD for this section is what notifications are required from imported MIBs and how can the TRILL notifications be throttled. The TBD needs to be filled in before this document ia approved.
The MIB has: rbridgeVlanIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4094|4096..4294967295) What's so special about 4095? You might borrow some text from RFC 4363, which says: DESCRIPTION "A value used to index per-VLAN tables: values of 0 and 4095 are not permitted. If the value is between 1 and 4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with global scope within a given bridged domain (see VlanId textual convention). If the value is greater than 4095, then it represents a VLAN with scope local to the particular agent, i.e., one without a global VLAN-ID assigned to it. Such VLANs are outside the scope of IEEE 802.1Q, but it is convenient to be able to manage them in the same way using this MIB."
I hit the nits checker button. There's a downref to 4663 that wasn't called out in the IETF LC. Easiest thing to do is probably to move it to an informative reference because 4663 is all about process and there's really nothing to implement.
draft-ietf-kitten-sasl-openid
The Gen-ART Review by Brian Carpenter on 24-Nov-2011 includes a request for better clarity. Please consider this comment. > 2.2. Discussion > > As mentioned above OpenID is primarily designed to interact with web- > based applications. Portions of the authentication stream are only > defined in the crudest sense. That is, when one is prompted to > approve or disapprove an authentication, anything that one might find > on a browser is allowed, including JavaScript, fancy style-sheets, > etc. Because of this lack of structure, implementations will need to > invoke a fairly rich browser in order to ensure that the > authentication can be completed. This language remains rather loose. At least, I believe, "fancy" and "fairly rich" need to be replaced by more specific terms such as "complex" and "sufficiently powerful" respectively. I think there may be interoperability issues hidden here in any case, but that is probably inevitable.
[Updated with a second topic of conversation.] 1. The Apps Area Review by William Mills on 28-Nov-2011 raised three major technical issues and two minor technical issues. These issues merit a response. The review was sent to the KITTEN WG list and can be found here: http://www.ietf.org/mail-archive/web/kitten/current/msg02858.html 2. Section 2 states: OpenID defines two methods for indirect communication, namely HTTP redirects and HTML form submission. Both mechanisms are not directly applicable for usage with SASL. Why are these mechanisms not applicable? Because the SASL client here might not contain or be able to invoke a full browser? Because the SASL server can't handle HTTP redirects or HTML forms? For some other reason? (A forward reference to Section 2.2 might be useful, if appropriate.) The same paragraph goes on to state: To ensure that a standard OpenID 2.0 capable OP can be used a new method is defined in this document that requires the OpenID message content to be encoded using a Universal Resource Idenitifier (URI). How will a standard OpenID Provider be able to use a new mechanism? Are there security concerns with encoding the message in a URI (e.g., inclusion of credentials or transaction-ids or other sensitive data, given that URIs might leak out of a secure context)?
There are several instances of "URL" instead of "URI"; is the difference meant to be significant?
Hiya! 1) s2 contains the following: 4. The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response. If the association is an encrypted channel how is it used to sign subsequent messages? I think this is an HMAC and it ain't a signing operation. r/sign/mac and r/signature/mac. Then again didn't Elliot offer some text in response to the secdir review that's even more specific? 2) s3.1: It's unclear to me that the changes suggested during the secdir review have been incorporated in to s3.1. I think that Simon & Steve agreed to remove the following from s3.1: The GS2 header carries the optional authorization identity. and make the last paragraph: The syntax and semantics of the "gs2-header" is specified in [RFC5801], and we use it here with the following limitations. The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb- flag" MUST be "n" because channel binding is not supported by this mechanism. (i.e., removing the last sentence) but then Jeff came back with another suggestion. Just want to make sure this gets properly resolved. 3) This one I got from Alexey OpenID specifies the use of Base64 but it doesn't say which alphabet is to be used. Must this document specify which alphabet is used?
1) It would be nice if the Figure showed that the RP is the SASL server. You use RP and SASL server and you use client and SASL client and it would be really nice if you just picked one set of terms and used it consistently in the steps in s2. For a split second step 1 made me ponder whether a fourth box was needed in the Figure. 2) It would be nice if it said to whom the response is sent in the following: 6. The SASL client now sends an response consisting of "=", to indicate that authentication continues via the normal OpenID flow. 3) In the following I assume it's the OP who approves/disapproves the authentication: 8. Next the client optionally authenticates to the OP and then approves or disapproves authentication to the Relying Party. so maybe: 8. Next the client optionally authenticates to the OP and then the OP approves or disapproves authentication to the Relying Party. 4) Instead of should be expected to respond in the following: 10. The RP MAY send an OpenID check_authentication request directly to the OP, if no association has been established, and the OP should be expected to respond. maybe just: "should respond"?
draft-ietf-krb-wg-gss-cb-hash-agility
I asked Ari Keränen to review this specification, and he had trouble understanding the description relating to the Exts field, and he also spotted an error in the IANA considerations text. Can some changes be accommodated to make Section 3 clearer and the IANA considerations corrected?
Ari Keränen's review: Is this the first document describing the format for the Exts field in the GSS checksum? It seems so, but the document isn't too explicit about that. I think the definition for the format of the Exts field would deserve at least its own section in the document (i.e., split the format of the field and and how it's used for hash agility into two different sections). And perhaps could also mention in the abstract that the format of the field is defined in this document (now it just says that "extensions are defined" which seems a little understatement). 3. Channel binding hash agility [...] All fields before "Exts" do not change from what is described in [RFC4121], they are listed for convenience. The 0x8003 GSS checksum MUST have the following structure: This is a bit confusing (had to read it a few times and maybe I still got it wrong). Could maybe rephrase this into something like: The 0x8003 GSS checksum MUST have the following structure (only the "Exts" field is changed from what is described in [RFC4121], other fields are listed only for convenience):
Please consider the editorial comments in the Gen-ART Review from Francis Dupont on 5-Nov-2011. See the comments here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06908.html
An informative reference to RFC 6151 might be good in the 1st sentence of the introduction.
draft-ietf-sieve-convert
Section 2 If a "convert" action cannot be completed -- perhaps because the conversion failed, or because the requested conversion is not available -- the message MUST remain unchanged, and the script processing continues. In particular, no error condition is raised, and no partial conversions are allowed. To be clear, you mean '...MUST remain unchanged by that "convert" action,...' and '...and no partial conversions due to a single "convert" action are allowed.' As written it implies no change is allowed (and changes already made must be unpicked). And (for my own clarity) this means that if there are two conversions that would be carried out by a single convert command, the first replacement is successful and the second fails, the result must not include either replacement. Maybe it would help to really spell this out. --- I think you might comment on infinite recursions. Suppose in your example 3.1 you had written require ["convert"]; convert "image/tiff" "image/tiff" ["pix-x=320","pix-y=240"]; (as I see in the middle of 3.4) It is easy to see how this might be interpreted as an infinite loop, but also easy to cover the case with a line of text that says the output of any conversion must be considered as atomic so that the conversion never applies to its own output. It would probably be possible to come up with worse (explosive) scenarios.
Does rfc5259 support doing things in loops? If not, then it seems like this makes the potential DoS on the server worse to the extent that the client can craft a CPU intensive loop. If applicable, then that should be noted.
In Section 2.1, it might be helpful to cite RFC 5228 on the definition of "implicit keep".
draft-ietf-ippm-loss-episode-metrics
Please s/draft/document/ --- In the definition of Type-P-One-way-Bi-Packet-Loss-Stream I was surprised that there is no statement that the packet pairs are contiguous. That is, that there is no other packet transmission between the second packet in the first pair and the first packet in the second pair. Given the term "stream" I expected this to be the case, but the text is silent and the definitions apply only to the time of transmission in a way that allows interspersion. Could you consider clarifying (either way) to be sure to state your intentions. --- Section 10 would be clearer if it said "This document requests no actions from IANA."
- 1.1, 2nd para refers to "by Gilbert and...by Elliot" but doesn't give references. Those would be good to include. - Is section 8 appropriate to include? If so, it'd be more useful if "some of the material" could be more tightly scoped I guess.
The Gen-ART Review by Peter McCann on 19-Nov-2011 raised several editorial suggestions. Please consider them. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06942.html
It may be obvious, but I believe that some of the Metric Units section should aboid ambiguity about the numbers in the definition of the metrics. Section 6.1.3: s/A number in the interval [0,1]/A decimal number in the interval [0,1]/ Section 6.2.3: s/A non-negative number of seconds./A non-negative integer number of seconds./
draft-ietf-tsvwg-sctp-strrst
- A reference for SCTP on 1st use would be better. - section 7 typo: s/application must/applications must/ ? (And is that a 2119 "must"?) - I can use this to add up to 2^16 new streams? Wouldn't that be a good DoS vector? Maybe add text that implementations might either have a max-new-streams setting or else that they should react to adding lots of streams?
The Gen-ART Review by Vijay Gurbani on 30-Nov-2011 raised one technical issue and a few editorial suggestions. The technical issue deserves a respons. Also, please consider the editorial comments. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06947.html
This is a good document describing in clear terms a useful extension. I think it would have been valuable for authors defining protocols that run over SCTP, implementers writing code to implement such protocols and operators who deploy them to add text to the document describing the impact that this new feature has on existing protocols (like IPFIX for which SCTP is a mandatory transport) or future protocols that will use SCTP as transport.
In Section 5.1.2: A1: The sender MUST stop assigning new SSNs to new user data provided by the upper layer for the affected streams and queue it. This is because it is not known whether the receiver of the request will accept or deny it and moreover, a lost request might cause an out-of-sequence error in a stream that the receiver is not yet prepared to handle. Do the first and third instances of "it" refer to "new user data"? If so, for clarity I suggest changing them to "such data". In Section 5.1.3: B2: If the sender wants all incoming streams to be reset no Stream Numbers SHOULD be put into the Incoming SSN Reset Request Parameter. I suggest "Stream Numbers SHOULD NOT". Also, why would an application override this SHOULD NOT?
The following phrase is used a couple of times in s4.*: This optional field, if included maybe use 2119 language: This OPTIONAL field, Also in s4.4: Either both optional fields Maybe: Either both OPTIONAL fields
draft-ietf-netconf-system-notifications
The security consideratiions could be improved by discussing what threat is posed by the specific data points. For example, netconf-config-change "indicates that the system configurastion has changed." I don't understand just what vulnerability this describes; is the concern about disclosing information about the system? or alerting a listening attacker that the system might now be more vulnerable? The sensitivity/vulnerability is not described. Ditto for many of these bullets.
idnits 2.12.12 reported: Unused Reference: 'RFC6021' is defined on line 623, but no explicit reference was found in the text
[comment redacted]
I assume the ";" in the following could be removed: } // container changed-by-parms; it just stuck out because none of the other single line comments ended with ;.
draft-ietf-netconf-access-control
- I'd still be happier if there were more text advising developers to be careful mapping from an authenticated identity to a NACM user name and associated groups, and in particular calling out a pitfall or two in doing that (e.g. i18n in names, null characters in authenticated identity). That is there by reference (to RFC 6241 I guess) but it'd be better to be explicit I think. (In section 3.3.1 ideally.) - Its still not quite clear to me how the "transport layer" can provide group memberships properly. RFC 6421 doesn't say and 2.5 just says that something "such as a RADIUS server" could be used. I think you could add a security consideration saying that unless you have the same level of security in how you get the username and group membership information, then you might be in trouble. E.g. if SSH provides the username with fairly good security, but then RADIUS is used for group memberships with less good security, then you may have a problem. - typo: 3.7.1 s/contents enabled,/contents is enabled,/
I concur with Stephen Farrell's comments about the incompleteness and vagueness of the text about derivation and handling of user names and group names.
#1) I agree with Stephen & Peter. #2) s2.6: It might be nice to clarify this somewhat: It ought to be possible to disable part or all of the access control model without deleting any access control rules. s3.1.1: and here: o The entire ACM can be disabled during operation, in order to debug operational problems. I agree it ought to be possible but it ought to be possible only by appropriately authorized users (i.e., the admin). #3) s3.1.2: Contains the following: It is expected that the mandatory transport mapping NETCONF Over SSH [RFC6242] is also supported by the server, and that the server has access to the user name associated with each session. Why isn't this a MUST/SHOULD kind of sentence: Servers MUST support the NETCONF Over SSH [RFC6242] It is expected that the mandatory transport mapping, and the server MUST have access to the user name associated with each session.
draft-ietf-eai-frmwrk-4952bis
Thank you for this very clearly and concisely written document. I have only a few minor editorial comments: Section 7.1: s/left hand part/local part/ and right hand part/domain part/ for consistency with convention elsewhere in the document? Also in section 7.1: is US-ASCII equivalent to ASCII and can US-ASCII be replaced by ASCII for consistency? It's not terribly important, but the rest of the document is written carefully enough that when I read "US-ASCII" I thought it might have some significance relative to ASCII as used throughout the rest of the doc. In section 10.1, what, exactly, are "EAI mailbox names"?
The phrase "this document" is used in a confusing manner in the first two bullets of section 5. For example, bullet 1 reads o SMTP extensions. This document [RFC5336bis-SMTP] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses. However, "this document" refers to the referenced specification [RFC5336bis- SMTP] rather than this document (the framework). Perhaps the clause could be deleted in both bullets. Then bullet 1 would read: o SMTP extensions. [RFC5336bis-SMTP] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses.
p21: s/Expecting and most/Expecting most/
Thank you for this clear, well-written document. Several sentences struck me as difficult to parse... 1. In Section 8.1: It is likely that the most common cases in which a message that requires these extensions is sent to a system that does not will involve the combination of ASCII-only forward-pointing addresses with a non-ASCII backward-pointing one. I suggest: Sometimes a message that requires these extensions is sent to a system that does not support these extensions; tt is likely that the most common cases will involve the combination of ASCII-only forward-pointing addresses with a non-ASCII backward-pointing one. 2. In Section 10.1: While these are permitted by the protocols and servers are expected to support them and there are special cases where they can provide value, taking advantage of those features is almost always bad practice unless the intent is to create some form of security by obscurity. I suggest: These formations are permitted by the protocols and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity. 3. In Section 10.1: o In general, it is wise to support addresses in Normalized form, using either Normalization Form NFC and, except in unusual circumstances, NFKC. Is the intent to say that it is best to use NFC and to use NKFC only in unusual circumstances? 4. In Section 11.1: The mailto: schema [RFC2368] and discussed in the Internationalized Resource Identifier (IRI) specification [RFC3987] may need to be modified when this work is completed and standardized. I suggest: The mailto: schema, defined in RFC 2368 [RFC2368] and discussed in the Internationalized Resource Identifier (IRI) specification [RFC3987], may need to be modified when this work is completed and standardized. 5. In Section 12: The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading including providing syntax and functions to support passing alternate, all-ASCII, addresses with the non-ASCII ones and special headers to indicate the downgraded status of messages. Yes, "downgrading including providing" is impressive, but I suggest: The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading, which included the definition of syntax and functions to support passing alternate, all-ASCII, addresses with the non-ASCII ones as well as special headers to indicate the downgraded status of messages. 6. In Section 14: Expecting and most or all such transformations prior to final delivery be done by systems that are presumed to be under the administrative control of the sending user ameliorates the potential problem somewhat as compared to what it would be if the relationships were changed in transit. I suggest: This potential problem can be mitigated somewhat by enforcing the expectation that most or all such transformations will be performed prior to final delivery by systems that are presumed to be under the administrative control of the sending user (as opposed to being performed in transit by entities that are not under the administrative control of the sending user). Finally, a reference to RFC 5280 seems appropriate in Section 14 when mentioning PKIX.
draft-ietf-appsawg-rfc3462bis
Concur with Russ' discuss.
Cleared my Discuss after discussion
typo: Missing a word in the intro: "message is overly and"
Please retain the part of Appendix B that lists the changes from RFC3462 to this memo.
draft-weil-shared-transition-space-request
I will change this ballot to "YES" when a /10 has been allocated for this space.
I understand the commercial imperatives that the ISPs face, and appreciate this is a dilemma. However, the authors have not so far generated an adequate degree of consensus (as evidenced by discussions on the IETF list) that the deployment of this technology "makes the Internet work better". Indeed section 5 indicates that the deployment of this technology makes the Internet worse by reducing it to a network that only supports a limited range of services (Web, Mail and IM) sanctioned by the ISP. This seems contra to the mission of the IETF. If this were a clearly defined limited application network, a case could be developed for accepting restrictions, but the application described here is connectivity to the Internet and hence access to new innovative services. The authors need to gain consensus in the IETF, that there is no other solution to the problem in hand, and hence that the significant restriction on the type of user application supported is justified.
I am posting a Discuss position for this document because the IESG should discuss some fundamental issues of how we should make a decision about publication of this document. I also have concerns about whether the IESG is the appropriate body to approve this request. I intend to post an Abstain position after my questions are answered and I clear my Discuss. The conversation about this document and any attempt to determine consensus is difficult because the issues are technical, economic, political and psychological. We (the IESG) are well-equipped and responsible for decisions about technical issues, but less so for the other issues. I've been reading most of the e-mail in the consensus call on ietf@ietf.org. Here are some of the questions I think I've seen discussed: Does the assignment of the requested /10 enable or hinder the deployment of IPv6? Is CGN a viable service model for IPv4? Is the reserved /10 required for the deployment of CGN? Can the deployment of CGN be prevented by not assigning Shared CGN address space? What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? Can alternative /10s be used such as 10.64.0.0/10 or 240.0.0.0/10? How many ISPs really want this assignment and how many don't care because they don't need it? Most of these questions are, in fact, not technical questions and I don't think the IESG can answer them. The document itself addresses only a few issues, giving one reason not to use each of the alternatives: o legitimately assigned globally unique address space o usurped globally unique address space (i.e., squat space) o [RFC1918] space In particular, the reason for not using RFC 1918 space is simply asserted with no support facts. If the IESG is to make a decision, I would like to walk through the following questions: Is the IESG the appropriate body to make the decision? If no, where should the decision be made, perhaps with technical advice from the IETF? Should the IESG identify any specific /10 for use as Shared CGN Space? If no, do not approve the document. Does this document describe the usage scenarios, constraints and caveats sufficiently well to allow the use of a /10 as Shared CGN Space? If no, ask for a revision. Should the IESG approve a request to IANA for a /10 as described in the document? If yes, publish the document. Should the IESG request that IANA identify some other /10 (or similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or 240.0.0.0/10 for use as Shared CGN Space?
I agree with the comments and discuss positions from others that say there is not IETF consensus on this document.
I concur with Stewart that there does not appear to be IETF consensus around this I-D. I am concerned that the alternative to this has been presented as "if you don't allocate the address space, the ISPs will just squat on another space." However, this also seems to be less worser than any other proposal on the table.
Based on recent discussion, I agree with Ralph that the issue of whether or not some other address space would work here (e.g. 240/10) needs to be clarified before this should go ahead.
I believe there is not IETF Consensus for approving a /10, and there is not IETF consensus to approve this document. This document describes a number of problems that occur with CGN. I believe CGN does not make the Internet run better, and approving Shared CGN space is counter to the IETF mission. Widespread deployment would be damaging to the Internet. Given the difficulties of reaching a subscriber's address from the global Internet, this would appear to add additional burden to establishing a VPN from, say, a hotel room to a user's home network. Given that subscribers would share addresses, CGN could create serious security holes that need to be mitigated. The Security Considerations section does not discuss the issues and mitigation. The document describes a number of alternatives to keeping IPv4 running longer, but it appears IETF consensus has not been reached that this is a significantly better alternative than other approaches to extending IPv4. The document describes a number of changes that would need to be to networking equipment to support the shared CGN space, and even with those changes, CGN would introduce significant problems to the Internet. It appears there would be a lot of work yet to be done to make CGN deployment make the Internet run better. The IETF DOES have consensus on an alternative approach - IPv6. The document does not compare the problems introduced by CGN versus those introduced by IPv6, not does it compare the necessary equipment chnages for CGN support to the IPv6 alternative. Many of the issues of IPv6 have already been addressed, and much existing equipment is IPv6-ready. The document does not demonstrate why the CGN alternative would be technically superior to the IPv6 alternative. I am interested in seeing answers to the many questions raised by the IETF. Until the IETF reaches consensus that this is the right approach to IPv4 exhaustion, I expect to abstain rather than approve this document.
Ralph sumarized well and in details the reasons for which the IESG cannot approve this document under its current form and at this point in time. I will probably change my DISCUSS into an Abstain after the telechat, unless we come with a different plan of action.
I concur with the DISCUSS position lodged by Stewart Bryant.
draft-ietf-lisp-alt
You say, "EID-prefixes are expected to be allocated to a LISP site by Internet Registries." For IPv4, this may be a non-starter. This viability of ALT, like the base document, depends on the viability of the Interworking document that we have not seen yet.
===== Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. SB> Whilst this may be true the text sounds like it fell off the SB> back of a marketing slide. ===== Legacy Internet: The portion of the Internet which does not run LISP and does not participate in LISP+ALT. SB> A rather pejorative term. Particularly as LISP is an SB> experimental protocol. ========= 3.3. Caveats on the use of Data Probes It is worth noting that there has been a great deal of discussion and controversy about whether Data Probes are a good idea. On the one hand, using them offers a method of avoiding the "first packet drop" problem when an ITR does not have a mapping for a particular EID- prefix. On the other hand, forwarding data packets on the ALT would require that it either be engineered to support relatively high traffic rates, which is not generally feasible for a tunneled network, or that it be carefully designed to aggressively rate-limit traffic to avoid congestion or DoS attacks. There may also be issues caused by different latency or other performance characteristics between the ALT path taken by an initial Data Probe and the "Internet" path taken by subsequent packets on the same flow once a mapping is in place on an ITR. For these reasons, the use of Data Probes is not recommended at this time; they should only be originated an ITR when explicitly configured to do so and such configuration should only be enabled when performing experiments intended to test the viability of using Data Probes. SB> This text looks like it needs to be in the main LISP spec. SB> There also needs to be text discussion the impact of the SB> cache system on connectionless flows. ======== SB> There does not seem to be a definition of "PI"
This Discuss is related to my Discuss on draft-ietf-lisp. From section 4.2: EID-prefixes are expected to be allocated to a LISP site by Internet Registries. Wow. That expectation makes for some experiment! Shouldn't this expectation be highlighted somewhere in draft-ietf-lisp? What are the requirements for these allocations, both relative to other allocations of EID-prefixes and allocations of IP address space?
What does this phrase from the definition of EID-prefix mean: EID- prefixes are routed on the ALT (not on the global Internet) Perhaps "information about EID-prefixes is exchanged among ALT routers through BGP" or "Map-Requests are routed through the ALT to the ETR that owns the requested EID-prefix"? From section 4: An ITR uses the ALT to learn the best path for forwarding an ALT Datagram destined to a particular EID-prefix. Really? Does the ITR really learn the best path? I thought the forwarding was all done transparently by the ALT routers. In section 6.1, I think LISP+ALT MUST "use newly-assigned AS numbers that are unrelated to the ASNs used by the global routing system." Presumably the lisp WG or some appropriate authority on behalf of the experiment will formally request the ASNs from IANA? From section 7: The ALT BGP peering topology should be arranged in a tree-like fashion (with some meshiness), with redundancy to deal with node and link failures. I would need some additional detail if I were to participate in the experiment. I thought the ALT routers formed a mesh of sorts. Does "tree-like fashion (with some meshiness)" mean a tree topology within a LISP site and a mesh among sites?
I think it is not right to make references (even Informative) to two I-Ds that have very clearly expired and gone away. Both [I-D.murphy-bgp-secr] and [I-D.white-sobgparchitecture] are substantially retired and are clearly not "work in progress". I suggest you look at work done in KARP and SIDR for starting points in the discussion of BGP security developments. You might also look at TCP/AO.
I picked out the same sentence as several others... EID-prefixes are expected to be allocated to a LISP site by Internet Registries.
This document is essentially ready for publication as Experimental, but I would like to ask about the status of one 10-year expired informational reference (I-D
#1) s10.1: So the answer to the following question: Mapping Integrity: Can an attacker insert bogus mappings to black- hole (create Denial-of-Service, or DoS attack) or intercept LISP data-plane packets? is ...? Maybe just rephrase this a statement? Just looking for truth in advertising.
#1) s10.2: In the following, I think you're talking about the HMAC in TCP not BGP so in the following: Use of HMAC Protected BGP/TCP Connections: HMAC is used to verify message integrity and authenticity, making it nearly impossible for third party devices to either insert or modify messages. r/HMAC Protected BGP/TCP Connections/HMAC-Protected TCP Connections for BGP peers r/HMAC/HMAC (e.g., TCP-AO [RFC5925]) and maybe an informative reference to RFC 5925? #2) s10.3: I tend to agree with Adrian on the references to S-BGP and soBGP. The IETF has decided to work on BGP security in SIDR lets point there and not muddy the waters with references to long expired draft.
draft-ietf-lisp
Experimental Status =================== What are the success criteria for this experiment? Is the experiment successful if LISP is deployed at a non-trivial number of sites and nothing breaks? Are achievement of LISP's goals to be included in the success criteria? For example, must the experiment cause a reduction in the size of the global routing tables to be considered a success? Experimental Scope ================== Considering the current state of LISP research, should the scope of the LISP experiment be constrained in any way? For example, would it be reasonable for a large enterprise to make all of its sites LISP sites? What benefits would the enterprise realize? To what risks would it be exposed? Would it be reasonable for that enterprise to share a LISP control plane with another enterprise? Again, what are the risks and benefits? Finally would it be reasonable for a major ISP to adopt LISP? To share a LISP control plane with another ISP? In answering this question, keep in mind that each of the open issues enumerated in Section 15 translate to operational risk. Operational risk is also introduced by issues that are not mentioned in Section 15. For example, little is known regarding the scaling characteristics of the cache-management system and control plane. Also, site partitioning may lead to more severe consequences than those described in Section 8.5 Routing Table Reduction ======================= During the transition period, when some sites have not yet deployed LISP, will LISP reduce the size of the global routing table? How? When answering this question, assume that connectivity is required between LISP and non-LISP sites. Architecture ============ Typically, Internet Protocols maintain a strict separation between the forwarding and control planes. Because of this separation, there is nothing that a user can do on the forwarding plane that would cause control plane state to be created or destroyed. This separation is fundamental to the stability of the Internet. To the best of my knowledge, the only Internet Protocol that violates this separation is PIM, which for many reasons, is not natively deployed in most large carrier networks. LISP, like PIM, intermixes the control and forwarding planes. Explain why this should not be viewed as a problem? Terminology ========== The definition of EID needs clarification. Assume that a IPv4-only host is contained by a LISP site. Assume also that the host requires connectivity to both LISP and non-LISP endpoints. Must that host be represented by two distinct 32-bit strings, an EID and a plain-old IPv4 address? Or can the same 32-bit string be used as both EID and the IPv4 address? Having answered that question, consider the following two statements: "host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned." "EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication" If the answer to the first question is yes, the first statement is problematic. If the answer to the second question is yes the second statement is confusing. TCP Friendliness ================ In section 4.1 you say, "Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR". What happens to the initial packet? If it is discarded, how will user experience of TCP connections be impacted? Forwarding Plane Encapsulation =============================== - Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1. - The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say? EID-to-RLOC UDP Map-Request Message =================================== You say, "A Map-Request is sent from an ITR when it needs a mapping for an EID wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map- Request is the destination-EID from the packet which had a mapping cache lookup failure." How did the ITR learn a route to this address? What device advertised it? Where will the packet arrive? Mapping Registration ==================== The map-versioning document says, "Indeed, ETRs belonging to the same LISP site must return for a specific EID- prefix the same mapping". This document should mention something about that. Also, it should explain how ETRs are kept in sync and what happens when they get out of sync. Interworking ========= The viability of LISP depends on the success of the Interworking model, which we have not seen yet.
The document needs to be clearer on what happens when the traffic is a high volume UDP source that only transmits occasionally. Say (but not limited to) some form of remote IPFIX collector that is occasionally triggered. My concern is a) Do we see a large chunk of the flow dropped on the floor until the mapping is learned - the conflict is between DOS attack and degradation of service WRT the "legacy Internet". b) Do we see a miss ordering of packets during as the system swaps from probe to normal operation c) Do we see a repeat of this as a result of cache aging. ======== I am also moving the following up to Discuss since it is related to the need for a clear description of the impact of the cache vs the existing behavior of the Internet. 5.4.2. A Stateful Solution to MTU Handling SB> It looks like there needs to be some discussion about SB> the state lifetime, and the issue of holding a stale SB> MTU vs transienting a flow by flushing the cache. Note that in both cases I am not requesting a change to the protocol, just a clear explanation of the expected behavior.
o End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers, which in turn, deliver packets to the destination the end-system has specified. The procedure a host uses to send IP packets does not change. SB> Hosts don't assume packets get to LISP routers they assume they get SB> to other hosts - they don't know about LISP routers ========== 5.1. LISP IPv4-in-IPv4 Header Format SB> It would be helpful to the reader to put a forward ref to SB> the definition of terms in 5.3 - same in 5.2. ========== UDP Checksum: The UDP checksum field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received SB> UDP-TUNNELS seems to be a normative reference to an expired SB> individual draft. That seems to risk this (LISP) document going SB> into limbo. The following text suggests that the reference SB> should be changed to informative anyway. .... The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. ========= 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SB> I cannot see a definition in this section of the terms SB> Source Map-Version and Dest Map-Version I: The I bit is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the Locator Status Bits field is reduced to 8-bits and the high-order 24-bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like: x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SB> s/LISP header would look like:/LISP header in this case is:/ SB> More importantly it is slightly confusing putting the 0 case SB> rider before the format, since at first glance it looks like SB> the format is only like this when L = 0. ========= o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). SB> Given that you have separated the host domain from the SB> ISP domain, I am not sure why this is a SHOULD. ========== When doing ETR/PETR decapsulation: o The inner header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the outer header Time to Live field, when the Time to Live field of the outer header is less than the Time to Live of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycle. This check is also performed when doing initial encapsulation when a packet comes to an ITR or PITR destined for a LISP site. SB> What LISP is doing is very similar in many respects to SB> MPLS does, and MPLS found that it needed both copy TTL and SB> not copy TTL. I am surprised that you did not follow that model. ======== 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The following UDP packet formats are used by the LISP control-plane. SB> They are not UDP pkt formats, they are UDP/IP packet formats. ======== 6.1.1. LISP Packet Type Allocations This section will be the authoritative source for allocating LISP Type values. Current allocations are: SB> Surely the section *is* the authoritative source? SB> Are you sure you do not need a registry for this? ======= 9.2. IPv4 Traceroute The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. SB> This sounds like quite a complicated mechanism. Did the authors SB> consider having the ITR do proxy traceroute?
I added this Discuss and changed my position to Discuss on 11/30. In reading draft-ietf-lisp-alt, I discovered I have a technical question about draft-ietf-lisp that needs to be answered before it can be correctly deployed. EIDs are defined to be "not routable on the public Internet." What are the global uniqueness properties required for EIDs, both among EIDs and between EIDs and globally routable IP addresses? How are EIDs with the appropriate properties chosen and coordinated among LISP sites?
My apologies for the changes to the Comments. Reading draft-ietf-lisp-alt raised a couple of new questions about this doc. I'll take this opportunity to get on a soapbox for a moment and ask for two bits of "truth in advertising" in the Introduction. First, I'd like to see a mention of the complementary observation that using a single ID-LOC avoids the necessity of a separate step to bind an identifier to its location and a database to manage those bindings. A mention of the scale of the binding database would be appropriate, too. Second, as I understand LISP, the EIDs are still ID-LOCs, not pure identifiers, within a LISP site. Outside any LISP site, an EID is a pure identifier. Which begs the question: exactly what is LISP providing, since it isn't providing a pure ID/LOC separation. E.g., a node can't move within a site without changing its ID, nor can it move between sites without changing its ID. Of course, this hybrid ID/LOC architecture helps with the scaling of the ID/LOC binding database. OK, I'm back down off my soapbox. I feel better now. Continuing... In section 4: first bullet of "basic rules": is it the case that end-systems are aware of LISP at all? I would write the first phrase of the third paragraph of section 5 as "Because EIDs and RLOCs can be either IPv4 or IPv6 addresses, ..." I don't understand the deployment method described in section 5.5. I think I understand the scenario, but I don't understand how RFC 1918 prefixes can be used as EID prefixes. How is an EID that has an RFC 1918 prefix disambiguated to do the EID-RLOC mapping? How is the numbering of RLOCs described in section 6.3, which maps RLOCs to bit positions in the Locator Status Bits field, determined? How is the numbering affected by RLOCs leaving and joining the set of RLOCs at a LISP site? In section 6.3, how does an ITR determine the original destination of an encapsulated datagram that triggers an ICMP Network or Host Unreachable message, so it can construct a meaningful ICMP Unreachable message to send to the original source of the datagram? Typo in section 6.5: s/will be yield/will yield/ In section 10.2, I understand how LISP can help avoid site renumbering, as described in RFC 4192, but I don't understand how it helps with renumbering a single node that moves within or between sites. What is the impact of host renumbering on LISP forwarding? For clarity in section 14.1, is this document asking IANA to create and maintain a registry of ACT values? Related typo: s/6.1.5/6.1.4/
If both the N bit and V bit MUST NOT be set in the same packet, then why would there be any rule defined for processing such a packet rather than to DROP it? It seems wrong to pretent that's okay and just treat it as if the V bit wasn't set. What is the advantage of this, and is there any risk? Section 5.4.1 is not clearly written, and seems fairly critical to proper performance. For instance, what does it mean when it says S is the maximum size of a packet that an ITR "would like to receive"? Is it the maximum that it *can* receive, the maximum that it can send on a next hop without fragmenting, etc.? From the description in the 2nd paragraph, the size would only be S/2 + H if the incoming packet were size S, in which case after adding H, it would be size L, NOT greater than L as the first sentence says. The definitions here really need to be tightened up and clarified. I believe the stateful solution in 5.4.2 is preferable to the stateless one which seems like it could have very bad effects if it really sets DF=1 and isn't keeping any state about whether smaller fragments need to be sent for a particular destination. The 5.4.1 algorithm doesn't solve this at all, and seems inadequate for providing a robust infrastructure. RLOC probing has an impact on the network capacity in-use and there is no way to sense when the overall rate of probing may simply be too great for some bottleneck to handle (due to some combination of the number of RLOCs being probed or the rate of probing). Losses can occur either of the probes or the map-replies. Even in cases where it isn't a significant source of congestion, the probing has to be implemented to avoid having bad things happen like accidentally causing synchronization of sending the probes such that this control traffic spikes periodically. Overall, unless the RLOC probing is better specified so that the risks and necessary precautions are well understood, this seems like a feature that could cause unexpected impact to data flows under some conditions.
In Section 5.3, UDP Checksum discussion, the reference to draft-eubanks- chimento-6man should probably be to draft-ietf-6man-udpzero instead. In section 5.4.1, what is "an architectural constant"? Should this just say "a constant"?
I'm inclined to agree with Russ that this is well-enough specified for an experimental status document, but I have some concerns. I don't see any statement of the scope of the experiment or how it will be judged. Traditionally, experiments are not released into the Internet but are operated in a controlled way in walled gardens. It appears that the intention with this experiment is that it should be conducted in the Internet, and that makes it important to examine te risks and uncertaintes. As part of the Discuss resolution on other LISP documents, and in accordance with the LISP WG charter, we had agreed that this specification would countain an upfront and clear statement of the issues and concerns. To remind you, the charter says: At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. and The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on I do not consider that this draft has adhered to the WG charter, and I consider the active encouragement of "early deployments" to be both against the spirit and the letter of the charter. If you believe that the experiment needs to be conducted "in the wild" you need to spend a bit more text explaining why this is safe and how the experiment is contained. --- Section 2 Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) I don't see that RLOCs are any more amenable to aggregation than today's IP addresses. That is, the allocation scheme for RLOCs could be run such that RLOCs are aggregatable, but could equally be run such that it is hard to aggregate. Maybe the points here are that: - network attachment points are not (currently) mobile - network attachment points are defined by the networks they attach to - network attachment points, by definition, impose an aggregation of end points. A way to solve this, if you wrote what you intended to write, would be a forward pointer to the section in the document that describes aggregation of RLOCs. Otherwise, perhaps just drop the parentheses. --- Section 2 One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]. Is the LISP working group undertaking controlled prototyping? Is the intention to state that "there are known protocotype implementations of [ALT]." Similarly, what does it mean to say "have been described but not implemented"? I guess: "At the time of writing, the authors are unaware of any implementations of..." --- Section 3 When using multiple mapping database systems, care must be taken to not create reencapsulation loops. What is this "care"? What about loops caused by transient conditions (or errors) in a single LISP mapping database? Shouldn't the payload TTL at least be decremented by one for each tunnel? Note that reencapsulation is not the same as nested encapsulation. You are clear about avoiding the latter (although some form of DPI may be required to achieve it). --- Step 7 of Section 4.1 doesn't make it clear what has happened to the first packet in the flow. I had assumed that it was buffered pending the Map-Reply, but I now suspect it was discarded as soon as the Map-Request was constructed. Can you add a clarification. --- Section 5 This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4. This recommendation is presumably upper case, but should be made clear in the pre-amble to section 5.4. --- Section 5.3 E: The E bit is the echo-nonce-request bit. When this bit is set to 1, the N bit MUST be 1. This bit SHOULD be ignored and has no meaning when the N bit is set to 0. See Section 6.3.1 for details. Confused. I think you need: E: The E bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N bit is set to 0. When the N bit is set to 1 and this bit is set to 1, this means blah. See Section 6.3.1 for details.
Abstract What is a "network-based protocol"? --- Please expand acronyms on first use. For example, xTRs. --- Please decide "an EID" or "a EID" and apply consistently. --- The architectural overview in Seciton 4 would be enhanced by a picture. The example in 4.1 would similarly benefit. --- Section 5 It is recommended in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. Is that REOMMENDED? --- Section 5.3 I agree with Wes about the N and V bits. --- Section 5.3 LISP Nonce When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo- nonce or providing a random nonce. "is clear/set" in what? The original message sent, or the new message received? --- Section 5.3 LISP Locator Status Bits Please say "(LSB)" in the text to match the figure.
While this is a lot of discuss points, most should be easily resolved especially since this is just going for experimental. #1 EID-to-RLOC database - the definition in s3 says "The" database, but there are in principle many. What happens if their security properties differ? I think this might be one to note in section 15 at least. #2, How does an ITR know or when to use the underlying routing system or the ALT? Is that just config or packet-by-packet? (4.1 4th bullet.) #3, Is ALT or an equivalent mandatory to implement or use really? If an ITR has no ALT or equivalent, then how would the Map-Request end up at the right ETR? #4, 5.4.1 says that reassembly (if needed) happens at the destination and not the ETR, but then later says that setting DF=1 in the encapsulated packet avoids "ETR fragment reassembly." Those seem to be in conflict. #5, Just checking - is there a missing "not" in this sentence from 6.1? "Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values." #6, Can a bad ITR cheat on an ETR by including Map-Reply Records in a Map-Request message? I think this is ok in the end, but just want to check. #7, [CONS] is needed to understand the Map-Request message format, so does [CONS] need to be a normative reference? What if an ETR gets a Map-Request but does not support [CONS]? Does it ignore the extra bytes in the message or ignore the message? If you said one of those then [CONS] could be an informative reference, but as-is I need to read [CONS] to know what to do with those bytes. [CONS] also seems to be needed to understand how TCP might be handled in 6.1.4 (in the discussion of the A bit), I'd say maybe just deleting the mention of [CONS] should be ok there. #8, 6.1.3 talks about a destination IP address being a destination-EID. That's odd. There's no field in 6.1.2 named that so you must mean the destination IP address of the UDP packet containing the Map-Request, but then you're sending a UDP packet to the Internet with an EID as its destination IP address which I thought was the main thing LISP wanted to avoid. I don't understand how that works since it seems to mean that all EIDs MUST be globally routable. Reading to the next paragraph perhaps you mean that such a request MUST be LISP encapsulated and sent to a Map-Resovler but then how would the ITR know which Map-Resolver RLOC to use for the EID in question? #9, Last para of 6.1.3. I think you need to say that an ETR MUST NOT add such a mapping to its map-cache until after it has been successfully verified. Its currently a "may" I think. If an implementation did add the mapping whilst verification was pending, then sending two Map-Requests with the mapping might work for an attacker if they can respond sooner than the mapping DB. If the ETR just added the mapping with no verification then I think the attack is clear - any ITR (or maybe any host?) can conincve any ETR that its the place to send stuff for any EID previously unknown to that ETR. Section 6.2 says that gleaned map-cache entries can be stored for "a few seconds" so this race may be a real issue. Probably easiest is to say something in 6.1.3 about such map-cache entries when they're in the "pending" state. #10, 6.1.4 defn of "S" bit: there is no field following the Mapping Protocol Data field in the diagram at the start of the section. I realise this may be a change resulting from an earlier comment of mine about [LISP-SEC] being normative at that point, but I think you'd be better off just saying that this bit is going to be used for some security stuff in future and leaving it at that and so deleting the figure at the top of page 33. (That should be enough to ensure that no other spec assumed that that bit is like the other reserved bits, which is all that ought be needed for now I think.) Section 6.1.8 has the same issue. #11, In the case where a 24-bit nonce is included in the 64 bit nonce field how are those bits encoded (LSB, MSB?) or if only 24 bits are provided then are the offsets in the figure at the start of 6.1.4 not used? Either would be ok but it needs to be stated or different implementers might do different things. #12, It looks from 6.1.6 like a Map-Register can be replayed. That's not a good thing. What prevents/detects such replays which should be a nice DoS if a site changes its config? Maybe that nonce ought not be zero and maybe there should be a Map-Server or ETR defined window during which nonces MUST be kept? (I may need to check [LISP-MS] again to see what's what there.) There may be a similar replay issue with Map-Notify messages, not sure. #13, What does "MUST be verified" mean exactly in 6.6.2? Do you mean via the mapping DB (I guess so) or something else? Just checking.
- intro: says "non-routable EIDs" - are there no cases where EIDs are routed? There are - you say they may be used for routing within the site (subnetting) in the definition of EID in section 3. Maybe say "non globally-routable EIDs"? - intro: "an Internet"? maybe "the Internet" - intro: maybe s/along administrative boundaries/along administrative boundaries meaningful to device owners/ the topology also works along administrative boundaries, just different (ISP) ones. - intro: "xTRs" used before being defined (end of 2nd last para), you could just say mapping modules or something generic here I guess. - section 3, typo, s/a address block/an address block/ in defn of PA addresses - s3, EID definition says " An EID is allocated to a host from an EID-prefix block associated with the site where the host is located." Doesn't that sound more like a PA address? Maybe s/is located/at home/ or something would be better? - s3, EID defn: "As the architecture is realized," is vague and maybe a bit misleading, I think you mean "At present," ? (And maybe s/must refer/ MUST refer/ in that same place?) - on 2119 language generally, are you assuming upper and lower case 2119 terms are both the same? If so I think its useful to say so. If not then there are a bunch of lower case 2119 terms that may need checking. (E.g. "may be used" in definition of EID-prefix is the next one I saw. I've no idea how many of those there are.) - s3, EID prefix defn: The term "smaller EID prefix" is a bit confusing maybe. I guess smaller here refers to the block size and not the number of bits in the prefix. Might help to say that just for clarity. - s3, EID prefix defn: typo "as a globally prefix" - s3, Recursive tunneling defn: typo, s/never are they/they are never/ same in defn of reencapsulating tunnels. - s3, Route-returnability defn: type, s/limits/this limits/ - s4, 3rd para typo: s/and strip/and strips/ - 4.1, step2 typo: s/EID destination/destination EID/ - 4.1, step3, is it a good idea to have 2119 language within an example like this? Probably best to repeat it later in any case. - 5.3, UDP header: typo s/a ITR/an ITR/ - 5.3, N bit: saying "Both N amd V bits MUST NOT be set..." is a bit ambiguous, I think you mean "at the same time" but it could be read to mean something different. - 5.3, decapsulation TTL handling: I wonder why you said SHOULD copy for the TTL field - while there is a condition, that could still be "MUST copy except when <foo>" I'd have thought. If there's a reason (other than <foo>) why you might do something else, it'd be good to say what that might be. Similar comment for the SHOULD copy on the ToS/traffic class. - 6.1.2 - What does the "A" bit actually mean? You don't say. And when is that set to 1? - 6.1.2 - IRC descrption, I think s/must/MUST/ in "must be encoded" would be better. - 6.1.2 - This reads oddly and could be cleared I think: "Source EID Address: This is the EID of the source host which originated the packet which is invoking this Map-Request." It reads oddly since EIDs are not supposed to be addresses really. I think it could be clearer if you say that this is almost always not an EID for an ITR (assuming that's right). Maybe just s/is invoking/caused/ would help too. - 6.1.3 - s/recommended/RECOMMENDED/ when talking about rate-limiting? and s/may optionally/MAY/ - 6.1.4- the TTL in 6.1.4 is specified in minutes with 32 bits available. That means a max of more than 8000 *years* is possible. Sheesh! That seems a bit optimistic. A 24 bit value would allow for 45 days which sounds more reasonable. Or, a 32 bit value in seconds would allow for 132 years which seems more than enough to me. Basically, this is just oddly done. I'd also argue that better would be to say that implementations MUST include some control over the max value here. (No need to say how to manage that, but it'd be good to make sure it can be managed.) Given that its probably late to change this, I guess some text recommending implementations do some sanity checking on this TTL would be good. - 6.1.4 ACT bits - I think this is saying these MUST be zero'd in any mapping data accompanying a Map-Request - is that right? If so, it'd be good to state that and that a receiver of a Map-Request MUST NOT act on them, e.g. by storing a negative cache entry or whatever (which might cause some security concerns, hard to tell though). - 6.1.5, should 10/8 addresses be used in these examples? Better to use the specfic example ranges I'd have thought. I think those are in RFC 5737. - 6.1.5, some forward reference to things like map-cache expiration time would be useful here. - 6.1.5.1, its probably more accurate to say that shared keys mean that its easier to detect misbehaviour or to hold someone to account for that, rather than say that its more difficult to misbehave. - 6.1.6, details of the P bit's usage "will be provided in a future version of this draft" has to be wrong at this point. - 6.1.6, might be good to say that the nonce is ok to be zero because the message is authenticated. - 6.1.8, I think it'd be better to say that [MLISP] message might, in future, be allowed. As-is, one could argue that [MLISP] needs to be a normative reference. - 6.3 uses the term CE-based ITRs but doesn't explain it and its not in section 3, nor is PE. - 6.2 references [LOC-ID-ARCH] from 2009. Is that still live? If not, is the reference useful? - section 12, The I in PKI already means infrastructure.
This is going for experimental, and I think it clears the bar for experimental. However, I think Section 6 could be much more clear.
LISP sounds like a serious protocol experiment. I would have liked there to be more discussion in either the document or in the writeup about how that experiment is going to conclude. That is, though I see the things in section 15 that indicate what it would take to really move this to the standards track, it would be nice to see some discussion about how interoperability is going to be measured as the experiment progresses.
1. I support Pete's COMMENT and Adrian's DISCUSS about the need to make more clear the goals of the experiment, the criteria of success and the limits of deployment while the document stays Experimental. 2. It would be more clear to split 14.1. into two sub-sections, especially as IANA is required to create a registry for LISP ACT if I understand correctly, while no action is required from IANA for the Flag Fields
Experiments are good. Although I share Pete's and Adrian's concerns about the scope of the experiment and the parameters for evaluating its success, I agree with Russ that the document is specified clearly enough to be implemented in an experimental fashion (modulo Ralph's question about global uniqueness).
This document is almost ready for publication as Experimental, but I would like to ask about the status of some of the Informative references before approving it. [CHIAPPA] points to a personal webserver (that redirects to a university server) - what's the expected stability of that reference. Where can I find the document pointed to by [RPMD]? [CONS] appears to be abandoned (the last update was in 2008) - are there plans to advance it?
Consider tightening the 3 steps listed in section 5.4.1. Step 2 is really the place you calculated L based on S and H.
#1) s5.3: LISP Nonce: Trying to figure out why you'd resend the same nonce. It seems like you're using it for reachability purposes? Why wouldn't you just use a new value each time? Are you send the same set of packets multiple times (i.e., retransmitting)? #2) s6.1.2 and s6.1.4: Nonces and Probes. This might be a typo but s6.1.4 (map- reply) includes: Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of the Map- Reply. I see in 6.1.2 you can set the P bit to indicate it's a probe and include the nonce in the request, but it says: P: This is the probe-bit which indicates that a Map-Request SHOULD be treated as a locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating the Map-Reply is a locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details. now if we look at the Nonce in 6.1.2 (map-request), it says: Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. so which bits of the 64-bit nonce in the reply do you take to make the 24-bit reply for the probe? There's a 24-bit nonce but that's in the encapsulation header. Is this just a typo?
s5: r/It is recommended in IPv4/It is RECOMMENDED in IPv4 ? s5.3: LISP Nonce: I looked in s6.3.1 for the obligatory reference to RFC4086 and didn't see it. There's one in 6.1.2 - just add another one in either s5.3 or s6.3.1 to provide the pointer to RFC4086 for the the LISP nonce generation recommendations. s6.1.3: This seems like this ought to be 2119ed: r/It is recommended that a Map-Request for the same EID-prefix be sent no more than once per second/It is RECOMMENDED that a Map-Request for the same EID- prefix be sent no more than once per second s6.1.6: r/and support for HMAC-SHA-256-128 [RFC6234] is recommended./and support for HMAC-SHA-256-128 [RFC6234] is RECOMMENDED.
draft-ietf-codec-guidelines
Section 6 would be much improved if bullet item 2 (IETF's own codec) stated that such codecs MUST be entirely separate in terms of their name, code points, and usage in applications from other codecs. That is, if IETF develops its own codec, it should assign specific code points for its use as well, not, e.g., reuse some code points that were already being used by a codec developed elsewhere.
Nit S/agains them/against them/
The WG charter says quite a lot about liaising its work with other SDOs. Although this I-D may be a bit foundational, it would not be harmful to offer other SDOs the chance to comment on the way we plan to proceed. I sense that a lot of voices were raised in the WG, and that is good, but I son't see any mention of communication with other SDOs in the write-up. I should like the ADs and chairs to ensure they have in place a proper mechanism to ensure the right documents are liaised at the right time in the cycle.
- I'm wondering if this is really only about audio - the title implies its more general but the body of the document is only specifically about audio. Suggest maybe adding audio to the title if that's correct and matches the wg's intent. - Step 5 of the list in section 2: this doesn't specify criteria for "sufficient" but I expected that's a normal WG consensus call for the lucky chairs. More interesting though is whether this has already happened or not? If so, then you can and maybe should use the past-tense. If not, when is this process going to be run? - p5 mentions "the requirements document" - why not add a reference? - p9 says errata "should be maintained" - that happens for all RFCs already.
Please consider the comments in the Gen-ART Review by Martin Thomson on 11-Oct-2011. The comment are here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06791.html
- I tend to agree with Stephen's comment that this document really is about an audio codec and it should say that. But let me go further and say that this document really is about *the* audio codec being developed in the codec working group. The document has some text that alludes to that (e.g., the title mentions "the Codec" and there are several mentions of "the group" in the document), but other places that is not clear and it sounds like it is giving guidelines for *any* codec (audio, video, otherwise) in *any* IETF working group (e.g., the intro says, "This document describes a suggested process for work at the IETF..."). I don't think this document intends to do the latter, and it would be useful to clarify some of that language. - The intro says "This document describes a suggested process...", and elsewhere it is worded as a "suggestion". I wouldn't mind if that got tightened up into more of a "guideline" or a "process" that the WG *will* follow. Of course, if the WG came to consensus that they wanted some latitude to ignore this guidance from time to time, I have no strong objection to leaving in the softer language. [For the moment, I will make the following a comment. However, if others on the IESG feel strongly about it, I can switch it to a discuss.] - I don't think BCP 79's language about "preferring" no-known-IPR or royalty- free-IPR technology is normative; I think it's descriptive. That is, it is fine if this particular WG wants to explicitly prefer no-known-IPR (or, secondarily, royalty-free-IPR), but don't blame BCP 79 as if it says that the WG *ought* to prefer them. I think the statements regarding doing things "in accordance with BCP 79" are bogus. They should be replaced with statements that the WG is doing things "as described by BCP 79".
Although I strongly support this work, I am recusing myself because I co- authored the first several versions of draft-valin-codec-guidelines, which was used as the starting point for the WG document.
So I'm not sure you need to do this, but a lot of times WG's develop requirements drafts and then they fret over whether to progress the before the solution draft or keep it as a living draft until after the solution draft is published. If the WG has considered this, then it might be worth saying whether or not you're going to progress the requirements draft prior to completing the solutions draft. You could add an informative reference to RFC 4648 for base64.
draft-ietf-hokey-arch-design
> inter-authenticator handovers.However, it is currently unclear how s/[.]/. /
The Gen-ART Review by Richard Barnes on 23-Nov-2011 raise some questions that deserve a response. Please see the review at: http://www.ietf.org/mail-archive/web/gen-art/current/msg06926.html
draft-ietf-csi-dhcpv6-cga-ps
This is a good document, even if the actual message is quite short and simple, and at times the draft struggles a bit to explain its conclusions clearly. FWIW, I disagree with some of the discusses that I have seen. I do have a few concerns (one shared with Russ), however: Section 3 claims without good justification that CGA parameters should be managed by a central entity. I think a reasonable case can be made for some parameters (like algorithms, Sec) but maybe not all. I can see also good reasons why central administration would be a bad idea (e.g., prefix is a local network matter and comes from the RAs). In any case, the document is silent about all this. Section 3 also suggests that with Sec>0 the generation of the hashes is something that should be centralized. Again, I can see also some reasons not to. In particular, Sec was not designed as a way to burden current machines but to enable higher cost searches when machines get faster. That is, if generating a Sec>0 value is a big burden for our computers, we should probably still use Sec=0. (I think there is a better argument than the one used in the draft. A very low-power host might want to delegate its key and hash generation to a more general purpose computer.) Section 4 should expand on what the implications for using CGAs by DHCPv6 servers. I believe that might actually be useful, as you could tie different transactions with the same DHCPv6 server together, ensuring that it is still the same node. But you could not prevent someone claiming to be a DHCPv6 server. I agree with other ADs that the draft should handwave less when it describes the security implications of some new design. The idea of the draft should be to describe what CGA can bring to DHCP security, and the security implications cannot be skipped. One example where you could easily write some more specific analysis is the above issue on using unauthorized CGAs by DHCPv6 servers and what the security impacts of that are.
Support DISCUSS positions from security ADs
- I agree with the thrust of discusses from the previous IESG review. Its hard to see why this document is useful. If there are problems with e.g. DHCP server authentication that can be solved in better ways, then write about that. If there are networks that prefer some CGA parameters over others then write about that Trying to mix these things seems counter productive at best and is not explained in the document that I can see. - For the 1st problem (DHCPv6 server address checking) I don't see that this describes a problem with a CGA related solution. There may be some tailored solution for this problem that is tractable that looks a bit like CGA but the argument as presented is backwards, you're saying "DHCP server auth is hard, CGA exists, therefore describing how CGA might be used for DHCP server auth is an interesting problem statement." That really is backwards esp. in the absence of an actual solution. (If you did have a clever scheme I'd forgive the lack of problem-statement purity;-) - For the 2nd "problem," is there evidence that its really a problem? If so, why not quote that? - The "computation delegation" seems to depend on the 2nd problem actually being a problem. Even if it were, what's that got to do with DHCP? CGA may depend on the prefix but that same prefix is used for hosts that don't use DHCP at all. And the significant computations don't depend on the prefix so can be done offline prior to any DHCP exchanges so again I don't that a real problem exists here related to DHCP. In summary - where's the evidence there are real problems? And if there is, what's the compelling argument for handling them in one document?
This is a wordy discuss, with the goal of explaining the myriad of things I think would need to be discussed before I could even consider approving this for publication. Ultimately, the discuss is about the lack of security considerations that would be needed to assess whether the proposals contained in the document are viable in an Internet environment. To a large degree, these comments mirror those from Tim and Russ. 1) The security considerations section basically says this document has not considered the security implications of the designs proposed here. Well, that's exactly why we have a security considerations section - to include the considerations of the security implications. This document includes multiple proposals for combining DHCPv6 and CGA; it might be better to write each one as a separate document, since the security implications of each of these proposals differs. The security considerations should discuss the threats associated with each proposal. Do we need to worry about man-in-the-middle attacks, and if so, how do we mitigate that threat? Do we need to worry about DoS attacks? Do we need to worry about integrity checking? replay? Do we need to worry about authentication? The document does discuss this by proposing an extenral authentication/authorization mechanism, but using an external certification mechanism to authenticate/authorize CGA generators is itself a proposal that would require its own security considerations. It might be possible to use a specific existing standard, such as IBE, but even that would need to consider security issues of combining the security assumptions of IBE and CGA and DHCPv6. And what about the overhead of having to support CGA plus an authentication/authorization mechanism? I think the real benefit of CGA is not needing an external CA; but if you need an external CA to authenticate/authorize the CGA generator, what have you gained? 2) I question whether disclosure of CGA parameters (apparently described in the document as privacy) is not problematic. If the information is available though the network management interface, what types of precautions must the network management interface provide, and what would be the effect of not providing those protections? Is there a cascading vulnerability issue - if somebody can access the parameters through a network management interface, can they use those parameters to spoof the DHCP server. to give themselves access to the network? What happens if they can change the DHCPv6 CGA parameters via the network management interface? Can they manipulate that to give themselves a back door to byoass the security of other protocols that depend on the CGA?
1) This is a comment meant to educate the editors. The change log is not very useful as written, and since it will be removed on publication, it would not be helpful to modify it now. Typically, a change log discusses the major technical changes that occur between revisions. This can help reviewers, such as the IESG, understand whether certain design discussions have taken place during the life of the document, and what design decisions were made. But the change log here only has information that exposes the timing of the revisions, e.g., after ietf73, and that is not useful.
The direction suggested by this document will undermine the privacy features associated with host-generated CGAs. In general, CGAs are not used in the same environment as a DHCP server, and I do not see a justification for this to change. Without providing a reason, this document asserts that local a administrator ought to manage CGA generation parameters. I am guessing that the concern is the computation burden, but this is not compelling. Further, RFC 3315 already allows a DHCPv6 server to reject a CGA generated with unacceptable parameters. This document discusses the use of DHCPv6 to assign certificates to CGA address owners. CGA 'ownership' can already be validated with the private key, so the need for a certificate is unclear. This document states: "... the generation of the Modifier field of a CGA address is computationally intensive." RFC 3972 seems indicate otherwise for most key sizes. In general, RSA key pair generation is not a big concern on modern processors. It might be a mild concern on mobile devices, but some detailed explanation is required.
I am submitting these issues as a discuss position, but please note that I expect to move from Discuss to Abstain since I have significant issues with the overall direction. My issues include one "discuss-discuss" and a number of specific issues. Discuss-discuss: The document implies that centrally managed CGAs were envisioned in the original specs ("The current CGA specifications do not mandate which device generates a CGA address.") However, I see no evidence in RFC 3972 that centrally generated CGAs were envisioned. My reading assumes locally generated CGAs. Is there any evidence that the wg really thought CGAs would be generated centrally? Specific Issues: In my opinion, this document fails to establish that a problem exists. The current DHCPv6-CGA coexistence model is dismissed without a clear explanation, and the impact of centrally generated key pairs and modifiers on the security assumptions for protocols that employ CGAs is not explored at all. [sections 1 and 2] I believe that sections 3 and 4 should be addressed in separate documents, unless the authors believe that DHCPv6 only benefits from centrally managed CGAs. Putting both concepts in one document is confusing. [global] Increasing the security of a CGA against a brute force attack while weakening the base security assumptions may not be a good compromise. [section 3, glaringly absent from section 5] The rationale for centrally generated key pairs is very weak, since a node (e.g. a cell phone) can reuse the same key pair each time it joins a subnet and generates a new CGA. [section 3] It is unclear whether the concepts proposed in Section 4 ("What CGA can do for DHCPv6") rely on centrally managed CGAs or not. From what I can tell, traditional CGAs might be very useful for DHCPv6 deployments, but I am unsure about that. The document states that when DHCPv6 is used to manage CGAs "it does not increase privacy risks". Relative to what? IMHO, centrally generated CGAs have to increase privacy risks in comparison to CGAs generated by the host itself. [section 5] As stated in the security consideration, "This work does not include a complete security analysis". In my opinion, such an analysis is crucial to determining whether this "problem" should be solved. As alluded to above, that analysis needs to review the impact on current protocols that use CGAs. If those protocols assume local generation, what is the impact of the mechanisms described here? [section 5]
What is an "unauthorized public & private key pair"? What is a "certified public & private key pair"? [section 4]
I concur with the DISCUSS position lodged by Jari Arkko, and share some of the concerns expressed by other IESG members.
This is an updated position. I believe that using CGAs with DHCP will be harmful to the Internet because it defeats one of the two primary purpose for CGAs, namely privacy. 1) When doing an analysis it's okay to state that a particular solution can be done but shouldn't be done. I think DHCPv6 combined with CGA is one of those. I share Russ' concerns and I think there are a number of other issues with the draft: 2) Sec 2: States: The public key system associated with the CGA address provides message origin validation and integrity protection without the need for negotiation and transportation of key materials. There's two problems with this statement: 1) There is no public key system with CGAs. It's just one public key, the whole point was there's no PKI (aka public key system). 2) CGAs include the public key so there is a need to transport key material. 3) Sec 2: States: The current CGA specifications do not mandate which device generates a CGA address. I thought the CGA specification was pretty clear on this: it's the address holder [RFC3972], the sender [RFC3971], or the mobile node [RFC4866]. 4) Sec 2: States: In many cases, a CGA address is generated by the associated key pair owner, which normally is also the host that will use the CGA address Actually, isn't this done in all cases except for the case suggested by this document. 5) Sec 2: States: However, in a DHCPv6-managed network, hosts should use IPv6 global addresses only from a DHCPv6 server. This is confusing to me because I'd define a DHCPv6-managed network where a clients get their addresses from DHCPv6 servers. 6) Sec 2: The last two paragraphs seem to be explaining the rationale for co- existence. I can see that DHCP might support this, but like Russ indicated I don't see the justification for this change. 7) Sec 3: States: In the current CGA specifications there is a lack of procedures to enable central management of CGA generation." Umm, isn't this one of the main points of CGAs?! 8) Sec 3: States: Administrators should be able to configure parameters used to generate CGAs... I think this statement is only true if you've bought the DHCPv6-CGA combination. 9) Sec 4: The second paragraph states: The receiver can verify both the CGA and signature, then process the payload of the DHCPv6 message only if the validation is successful. A CGA option with an address ownership proof mechanism and a signature option with a corresponding verification mechanism may be introduced into DHCPv6 protocol. Absent of some other configuration data, the receiver isn't going to know anything other than the sender owns the address. 10) Sec 5: The second paragraph compares DCHP with CGA to DHCP, but says nothing DHCP with CGA as compared to just using CGAs. There's also the throw away part about ACLs that is unexplained.
draft-davis-t-langtag-ext
These comments can be addressed during or after IESG Evaluation: 1. Please address the gen-art review comment from Vijay Gurbani: - For sake of uniformity, I would suggest wrapping the unadorned t with single quotes. For instance, in S2.1, third paragraph: s/The t extension is/The 't' extension is/ The above is the only unadorned instance I found, but there may be others that I did not check for. 2. Please expand the acronym "CLDR" on its first use. Please include the acronym "LDML" in parentheses next to the first occurrence of "Locale Data Markup Language".
Should you have a reference to 3339 for the time format? And, this shows my complete lack of understanding but do you need to say whether offsets (e.g., "Z") are allowed? I guess if it said: * it MUST only consist of a sequence of digits of the form YYYY, YYYYMM, or YYYYMMDD then that would be the same thing to say that the offset aren't supported.