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

  1. Roll Call 1134 EST Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Media Resource Control Protocol Version 2 (MRCPv2) (Proposed Standard)
    draft-ietf-speechsc-mrcpv2-27
    Token: Robert Sparks
    Note: Eric Burger (eburger@standardstrack.com) is the document shepherd.
    Discusses/comments (from ballot 3123):
    1. Jari Arkko: Discuss [2011-12-01]:
      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.
    2. Ralph Droms: Discuss [2011-11-29]:
      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?
    3. Ralph Droms: Comment [2011-11-29]:
      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.
    4. Stephen Farrell: Discuss [2011-11-25]:
      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.
    5. Stephen Farrell: Comment [2011-11-25]:
      (10 items)
    6. Pete Resnick: Discuss [2011-12-01]:
      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.
    7. Pete Resnick: Comment [2011-12-01]:
      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?
    8. Dan Romascanu: Discuss [2011-12-01]:
      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?
    9. Dan Romascanu: Comment [2011-12-01]:
      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.
    10. Robert Sparks: Discuss [2011-11-30]:
      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
    11. Sean Turner: Discuss [2011-11-30]:
      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.
    12. Sean Turner: Comment [2011-11-30]:
      (11 items)

    Telechat:

  2. An IPv6 Routing Header for Source Routes with RPL (Proposed Standard)
    draft-ietf-6man-rpl-routing-header-05
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.
    Discusses/comments (from ballot 3769):
    1. Ralph Droms: Discuss [2011-11-29]:
      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.
    2. Ralph Droms: Comment [2011-11-30]:
      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.
    3. Adrian Farrel: Comment [2011-11-30]:
      (8 items)
    4. Stephen Farrell: Discuss [2011-11-28]:
      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?
    5. Stephen Farrell: Comment [2011-11-28]:
      (4 items)
    6. Robert Sparks: Comment [2011-11-29]:
      (blank)
    7. Sean Turner: Discuss [2011-11-30]:
      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."
      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.

    Telechat:

  3. RPL Option for Carrying RPL Information in Data-Plane Datagrams (Proposed Standard)
    draft-ietf-6man-rpl-option-05
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.
    Discusses/comments (from ballot 3770):
    1. Ralph Droms: Discuss [2011-11-29]:
      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.
    2. Adrian Farrel: Comment [2011-11-30]:
      (5 items)
    3. Stephen Farrell: Discuss [2011-11-28]:
      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?
    4. Stephen Farrell: Comment [2011-11-28]:
      (5 items)
    5. Russ Housley: Comment [2011-11-28]:
      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."
    6. Robert Sparks: Comment [2011-11-29]:
      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?
    7. Sean Turner: Comment [2011-11-30]:
      I support Stephen's discuss.

    Telechat:

  4. Diameter Priority Attribute Value Pairs (Proposed Standard)
    draft-ietf-dime-priority-avps-05
    Token: Dan Romascanu
    Note: Lionel Morand (lionel.morand@orange-ftgroup.com) is the document shepherd
    Discusses/comments (from ballot 3774):
    1. Stephen Farrell: Comment [2011-11-11]:
      - 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.
    2. David Harrington: Discuss [2011-11-30]:
      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?
    3. David Harrington: Comment [2011-11-30]:
      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 ..." I think this is an incorrect usage for MUST; MUST is for implementers. (Since an operator might choose to NOT consider the issues and security of Diameter base, this document should warn users what vulnerabilities might exist in their network if another operator ignores these issues.)
      3) In acknowledgements, you credit a number of people with resolving the "problems", but don't mention what problems those were.
    4. Robert Sparks: Discuss [2011-11-30]:
      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"?
    5. Sean Turner: Comment [2011-11-29]:
      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?

    Telechat:

  5. Definitions of Managed Objects for RBridges (Proposed Standard)
    draft-ietf-trill-rbridge-mib-04
    Token: Ralph Droms
    Note: Donald Eastlake (d3e3e3@gmail.com) is the Document Shepherd.
    Discusses/comments (from ballot 3885):
    1. Adrian Farrel: Discuss [2011-12-01]:
      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?
    2. Adrian Farrel: Comment [2011-12-01]:
      (6 items)
    3. Stephen Farrell: Comment [2011-11-11]:
      - What does "TBD for this section" mean in 5.1? I assume that was meant to be deleted but that got missed?
    4. Russ Housley: Discuss [2011-11-29]:
      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.
    5. Peter Saint-Andre: Comment [2011-11-30]:
      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."
    6. Sean Turner: Comment [2011-11-29]:
      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.

    Telechat:

  6. A SASL & GSS-API Mechanism for OpenID (Proposed Standard)
    draft-ietf-kitten-sasl-openid-07
    Token: Stephen Farrell
    Discusses/comments (from ballot 3893):
    1. Russ Housley: Comment [2011-11-29]:
      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.
    2. Peter Saint-Andre: Discuss [2011-11-30]:
      [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)?
    3. Peter Saint-Andre: Comment [2011-11-30]:
      There are several instances of "URL" instead of "URI"; is the difference meant to be significant?
    4. Sean Turner: Discuss [2011-11-28]:
      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?
    5. Sean Turner: Comment [2011-11-28]:
      (4 items)

    Telechat:

  7. Kerberos Version 5 GSS-API Channel Binding Hash Agility (Proposed Standard)
    draft-ietf-krb-wg-gss-cb-hash-agility-08
    Token: Stephen Farrell
    Note: Sam Hartman (hartmans-ietf@mit.edu) is the document shepherd.
    Discusses/comments (from ballot 3901):
    1. Jari Arkko: Discuss [2011-12-01]:
      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?
    2. Jari Arkko: Comment [2011-12-01]:
      Ari Keränen's review: (see link)
    3. Russ Housley: Comment [2011-11-29]:
      Please consider the editorial comments in the Gen-ART Review from Francis Dupont on 5-Nov-2011.
    4. Sean Turner: Comment [2011-11-28]:
      An informative reference to RFC 6151 might be good in the 1st sentence of the introduction.

    Telechat:

  8. Sieve Extension for Converting Messages Before Delivery (Proposed Standard)
    draft-ietf-sieve-convert-05
    Token: Pete Resnick
    Discusses/comments (from ballot 3925):
    1. Adrian Farrel: Comment [2011-12-01]:
      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.
    2. Stephen Farrell: Comment [2011-11-26]:
      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.
    3. Peter Saint-Andre: Comment [2011-11-28]:
      In Section 2.1, it might be helpful to cite RFC 5228 on the definition of "implicit keep".

    Telechat:

  9. Loss Episode Metrics for IPPM (Proposed Standard)
    draft-ietf-ippm-loss-episode-metrics-03
    Token: Wesley Eddy
    Note: Henk Uijterwaal (henk@uijterwaal.nl) is the document shepherd.
    IPR: AT&T Intellectual Property I, LP's Statement about IPR related to draft-ietf-ippm-loss-episode-metrics-00
    Discusses/comments (from ballot 3984):
    1. Adrian Farrel: Comment [2011-12-01]:
      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."
    2. Stephen Farrell: Comment [2011-11-28]:
      - 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.
    3. Russ Housley: Comment [2011-11-30]:
      The Gen-ART Review by Peter McCann on 19-Nov-2011 raised several editorial suggestions. Please consider them.
    4. Dan Romascanu: Comment [2011-12-01]:
      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./

    Telechat:

  10. Stream Control Transmission Protocol (SCTP) Stream Reconfiguration (Proposed Standard)
    draft-ietf-tsvwg-sctp-strrst-12
    Token: Wesley Eddy
    Note: James Polk (jmpolk@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 4010):
    1. Stephen Farrell: Comment [2011-11-28]:
      - 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?
    2. Russ Housley: Discuss [2011-11-30]:
      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 response. Also, please consider the editorial comments.
    3. Dan Romascanu: Comment [2011-12-01]:
      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.
    4. Peter Saint-Andre: Comment [2011-11-30]:
      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?
    5. Sean Turner: Comment [2011-11-30]:
      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"

    Telechat:

  11. Network Configuration Protocol (NETCONF) Base Notifications (Proposed Standard)
    draft-ietf-netconf-system-notifications-06
    Token: Dan Romascanu
    Note: Mehmet Ersue (mehmet.ersue@nsn.com) is the Document Shepherd for this document.
    Discusses/comments (from ballot 4025):
    1. David Harrington: Comment [2011-11-30]:
      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.
    2. Russ Housley: Comment [2011-11-29]:
      idnits 2.12.12 reported: "Unused Reference: 'RFC6021' is defined on line 623, but no explicit reference was found in the text"
    3. Peter Saint-Andre: Comment [2011-11-29]:
      [comment redacted]
    4. Sean Turner: Comment [2011-11-28]:
      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 ;.

    Telechat:

  12. Network Configuration Protocol (NETCONF) Access Control Model (Proposed Standard)
    draft-ietf-netconf-access-control-06
    Token: Dan Romascanu
    Note: Bert Wijnen (bertietf@bwijnen.net) is the document shepherd.
    Discusses/comments (from ballot 4026):
    1. Stephen Farrell: Comment [2011-11-28]:
      - 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,/
    2. Peter Saint-Andre: Comment [2011-11-29]:
      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.
    3. Sean Turner: Comment [2011-11-30]:
      #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.

    Telechat:

2.1.2 Returning Items

  1. Overview and Framework for Internationalized Email (Proposed Standard)
    draft-ietf-eai-frmwrk-4952bis-12
    Token: Pete Resnick
    Discusses/comments (from ballot 3546):
    1. Ralph Droms: Comment [2010-09-21]:
      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"?
    2. Tim Polk: Comment [2010-09-23]:
      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."
    3. Dan Romascanu: Comment [2010-09-23]:
      p21: s/Expecting and most/Expecting most/
    4. Peter Saint-Andre: Comment [2010-09-22]:
      (6 items)

    Telechat:

  2. The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (Standard)
    draft-ietf-appsawg-rfc3462bis-04
    Token: Pete Resnick
    Discusses/comments (from ballot 3946):
    1. Ron Bonica: Comment [2011-10-19]:
      Concur with Russ' discuss.
    2. Adrian Farrel: Comment [2011-10-18]:
      Cleared my Discuss after discussion
    3. Stephen Farrell: Comment [2011-11-26]:
      typo:
      Missing a word in the intro: "message is overly and"
    4. Peter Saint-Andre: Comment [2011-11-28]:
      Please retain the part of Appendix B that lists the changes from RFC3462 to this memo.
    5. Robert Sparks: Comment [2011-11-29]:
      (blank)
    6. Sean Turner: Comment [2011-11-29]:
      (blank)

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. IANA Reserved IPv4 Prefix for Shared CGN Space (BCP)
    draft-weil-shared-transition-space-request-10
    Token: Ron Bonica
    Discusses/comments (from ballot 3933):
    1. Ron Bonica: Discuss [2011-11-29]:
      I will change this ballot to "YES" when a /10 has been allocated for this space.
    2. Stewart Bryant: Discuss [2011-11-29]:
      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.
    3. Ralph Droms: Discuss [2011-11-30]:
      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?
    4. Wesley Eddy: Comment [2011-11-30]:
      I agree with the comments and discuss positions from others that say there is not IETF consensus on this document.
    5. Adrian Farrel: Comment [2011-11-30]:
      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.
    6. Stephen Farrell: Comment [2011-12-01]:
      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.
    7. David Harrington: Discuss [2011-12-01]:
      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.
    8. Dan Romascanu: Discuss [2011-12-01]:
      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.
    9. Peter Saint-Andre: Discuss [2011-11-30]:
      I concur with the DISCUSS position lodged by Stewart Bryant.

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. LISP Alternative Topology (LISP+ALT) (Experimental)
    draft-ietf-lisp-alt-09
    Token: Jari Arkko
    Note: Terry Manderson (terry.manderson@icann.org) is the document shepherd.
    Discusses/comments (from ballot 3905):
    1. Ron Bonica: Discuss [2011-11-30]:
      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.
    2. Stewart Bryant: Comment [2011-12-01]:
      "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 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 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. There also needs to be text discussion the impact of the cache system on connectionless flows.
      SB> There does not seem to be a definition of "PI"
    3. Ralph Droms: Discuss [2011-11-30]:
      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?
    4. Ralph Droms: Comment [2011-11-30]:
      (3 items)
    5. Adrian Farrel: Discuss [2011-12-01]:
      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.
    6. Adrian Farrel: Comment [2011-12-01]:
      I picked out the same sentence as several others...
      "EID-prefixes are expected to be allocated to a LISP site by Internet Registries."
      ...but I wondered whether you were saying something less alarming than they interpretted (for example, that the addresses are not from a private space). In any case, clarification will surely help.
    7. Robert Sparks: Discuss [2011-11-29]:
      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 .murphy-bgp-secr). Are there plans to update and eventually publish this draft? If not, is there something more recent that could be used instead?
      (Sorry, hit the send button too soon) -
      Also, what are the plans for [I-D.white-sobgparchitecture]?
    8. Sean Turner: Discuss [2011-12-01]:
      #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.
    9. Sean Turner: Comment [2011-12-01]:
      #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.

    Telechat:

  2. Locator/ID Separation Protocol (LISP) (Experimental)
    draft-ietf-lisp-16
    Token: Jari Arkko
    Note: Joel Halpern (jmh@joelhalpern.com) is the document shepherd.
    Discusses/comments (from ballot 3906):
    1. Ron Bonica: Discuss [2011-11-30]:
      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.
    2. Stewart Bryant: Discuss [2011-12-01]:
      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 the state lifetime, and the issue of holding a stale 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.
    3. Stewart Bryant: Comment [2011-12-01]:
      (9 items)
    4. Ralph Droms: Discuss [2011-11-30]:
      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?
    5. Ralph Droms: Comment [2011-11-30]:
      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.
      (et cetera, see link)
    6. Wesley Eddy: Discuss [2011-11-29]:
      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.
    7. Wesley Eddy: Comment [2011-11-29]:
      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"?
    8. Adrian Farrel: Discuss [2011-11-30]:
      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."
    9. Adrian Farrel: Comment [2011-11-30]:
      (8 items)
    10. Stephen Farrell: Discuss [2011-12-01]:
      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.
    11. Stephen Farrell: Comment [2011-12-01]:
      (33 items)
    12. Russ Housley: Comment [2011-11-29]:
      This is going for experimental, and I think it clears the bar for experimental. However, I think Section 6 could be much more clear.
    13. Pete Resnick: Comment [2011-11-29]:
      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.
    14. Dan Romascanu: Comment [2011-11-30]:
      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
    15. Peter Saint-Andre: Comment [2011-11-30]:
      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).
    16. Robert Sparks: Discuss [2011-11-29]:
      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?
    17. Robert Sparks: Comment [2011-11-29]:
      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.
    18. Sean Turner: Discuss [2011-12-01]:
      #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?
    19. Sean Turner: Comment [2011-12-01]:
      (4 items)

    Telechat:

  3. Guidelines for the Codec Development Within the IETF (Informational)
    draft-ietf-codec-guidelines-06
    Token: Robert Sparks
    Note: Jonathan Rosenberg (jdrosen@jdrosen.net) is the Document Shepherd
    Discusses/comments (from ballot 3937):
    1. Jari Arkko: Comment [2011-12-01]:
      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.
    2. Stewart Bryant: Comment [2011-11-28]:
      Nit
    3. Adrian Farrel: Comment [2011-12-01]:
      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.
    4. Stephen Farrell: Comment [2011-11-28]:
      - 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.
    5. Russ Housley: Comment [2011-11-29]:
      Please consider the comments in the Gen-ART Review by Martin Thomson on 11-Oct-2011.
    6. Pete Resnick: Comment [2011-11-29]:
      - 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".
    7. Peter Saint-Andre: Comment [2011-11-28]:
      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.
    8. Sean Turner: Comment [2011-11-29]:
      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.

    Telechat:

  4. Handover Keying (HOKEY) Architecture Design (Informational)
    draft-ietf-hokey-arch-design-10
    Token: Stephen Farrell
    Note: Tiny Tsou is the draft shepherd
    Discusses/comments (from ballot 4011):
    1. Jari Arkko: Comment [2011-12-01]:
      "inter-authenticator handovers.However, it is currently unclear how"
      s/[.]/. /
    2. Russ Housley: Discuss [2011-11-29]:
      The Gen-ART Review by Richard Barnes on 23-Nov-2011 raise some questions that deserve a response.

    Telechat:

3.1.2 Returning Items

  1. DHCPv6 and CGA Interaction: Problem Statement (Informational)
    draft-ietf-csi-dhcpv6-cga-ps-07
    Token: Ralph Droms
    Note: Document shepherd: Marcelo Bagnulo (marcelo@it.uc3m.es)
    Discusses/comments (from ballot 3561):
    1. Jari Arkko: Discuss [2010-10-20]:
      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.
    2. Jari Arkko: Comment [2010-10-20]:
      (blank)
    3. Ron Bonica: Discuss [2010-10-21]:
      Support DISCUSS positions from security ADs
    4. Ron Bonica: Comment [2010-10-21]:
      (blank)
    5. Stephen Farrell: Discuss [2011-11-28]:
      - 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?
    6. David Harrington: Discuss [2010-10-20]:
      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 external 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?
    7. David Harrington: Comment [2010-10-20]:
      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.
    8. Russ Housley: Discuss [2010-10-03]:
      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.
    9. Tim Polk: Discuss [2010-10-20]:
      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]
    10. Tim Polk: Comment [2010-10-20]:
      What is an "unauthorized public & private key pair"? What is a "certified public & private key pair"? [section 4]
    11. Peter Saint-Andre: Comment [2011-11-30]:
      I concur with the DISCUSS position lodged by Jari Arkko, and share some of the concerns expressed by other IESG members.
    12. Sean Turner: Discuss [2010-10-21]:
      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.
    13. Sean Turner: Comment [2010-10-21]:
      (blank)

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. BCP 47 Extension T - Transformed Content (Informational)
    draft-davis-t-langtag-ext-06
    Token: Pete Resnick
    Discusses/comments (from ballot 3874):
    1. Pete Resnick: Comment [2011-11-29]:
      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".
    2. Sean Turner: Comment [2011-11-29]:
      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.

    Telechat:

  2. Recommendations for the Remediation of Bots in ISP Networks (Informational)
    draft-oreirdan-mody-bot-remediation-18
    Token: Stephen Farrell
    Discusses/comments (from ballot 3939):
    1. Stewart Bryant: Comment [2011-11-28]:
      There is the outstanding issue of verifying that the IPR issues noted by the Shepherd have been fully resolved. I am sure that Stephen will verify the resolution before issuing a publication request, and thus am highlighting this issue as a comment.
      "An ISP may use Netflow [RFC3954]"
      I would think that the the standards based solution IPFIX [RFC5101] would be a better reference.
    2. Wesley Eddy: Comment [2011-11-29]:
      This is a good document. I am not at all an expert in this area, but my only comment is that it seems like there may be some liability to the ISP in attempting to detect bot infections because they may then need to bear the burden to report criminal activity that they witness. I'm sure commercial ISPs have considered this in their policies, but I didn't notice it clearly mentioned in the document.
    3. Peter Saint-Andre: Comment [2011-11-29]:
      Overall this is a helpful document. I have a few comments and suggestions.
      In Section 1.2:
      OLD: "The detection and destruction of bots is an ongoing issue and also a constant battle between the Internet security community, network security engineers and bot developers."
      NEW: "The detection and destruction of bots is an ongoing issue and also a constant battle between the Internet security community and network security engineers on the one hand and bot developers on the other."
      P2P is not a communication protocol, it is an architectural approach.
      It is a bit odd to speak of the "introduction" of HTTP, given that HTTP was invented over 20 years ago.
      The document sometimes conflates bots and botnets. For example:
      "As a consequence, botnets that are initially detected and classified by the ISP as one particular type of bot need to be continuously monitored and tracked in order to identify correctly the threat the botnet poses at any particular point in time."
      Although a botnet consists of bots, not all bots are part of a botnet (and we certainly can't say that a botnet can be classified as a type of bot, as in the quoted paragraph).

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Expert for DHCPv6 Option Codes [IANA #502340] (Michelle Cotton)

    Telechat:

  2. add document shepherds to distribution list of DISCUSS and COMMENTS (Dan Romascanu)

    Telechat:

  3. Data Center (Stewart Bryant/Ron Bonica)

    Telechat:

  4. Expert for RFC2506 (Robert Sparks)

    Telechat:

  5. Designated Expert for RFC3798 (Pete Resnick)

    Telechat:

7. Agenda Working Group News

1410 EST Executive Session


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-12-01 07:30:03 PST)

draft-ietf-speechsc-mrcpv2

  1. Jari Arkko: Discuss [2011-12-01]:
        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. 
        
  2. Ralph Droms: Discuss [2011-11-29]:
        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? 
        
  3. Ralph Droms: Comment [2011-11-29]:
    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.
    
  4. Stephen Farrell: Discuss [2011-11-25]:
        
    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.
     
        
  5. Stephen Farrell: Comment [2011-11-25]:
    - 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?
    
  6. Pete Resnick: Discuss [2011-12-01]:
        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. 
        
  7. Pete Resnick: Comment [2011-12-01]:
    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?
  8. Dan Romascanu: Discuss [2011-12-01]:
        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? 
        
  9. Dan Romascanu: Comment [2011-12-01]:
    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.
  10. Robert Sparks: Discuss [2011-11-30]:
        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  
        
  11. Sean Turner: Discuss [2011-11-30]:
        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. 
        
  12. Sean Turner: Comment [2011-11-30]:
    #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

  1. Ralph Droms: Discuss [2011-11-29]:
        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. 
        
  2. Ralph Droms: Comment [2011-11-30]:
    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.
  3. Adrian Farrel: Comment [2011-11-30]:
    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.
    
  4. Stephen Farrell: Discuss [2011-11-28]:
        
    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? 
     
        
  5. Stephen Farrell: Comment [2011-11-28]:
    - 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.
  6. Robert Sparks: Comment [2011-11-29]:
    
        
  7. Sean Turner: Discuss [2011-11-30]:
        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. Ralph Droms: Discuss [2011-11-29]:
        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.
     
        
  2. Adrian Farrel: Comment [2011-11-30]:
    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.
    
  3. Stephen Farrell: Discuss [2011-11-28]:
        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? 
     
        
  4. Stephen Farrell: Comment [2011-11-28]:
    - 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.
  5. Russ Housley: Comment [2011-11-28]:
      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.
  6. Robert Sparks: Comment [2011-11-29]:
    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?
  7. Sean Turner: Comment [2011-11-30]:
    I support Stephen's discuss.

draft-ietf-dime-priority-avps

  1. Stephen Farrell: Comment [2011-11-11]:
    - 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.
    
  2. David Harrington: Discuss [2011-11-30]:
        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? 
        
  3. David Harrington: Comment [2011-11-30]:
    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
        
  4. ..." I think this is an incorrect usage for MUST; MUST is for implementers. (Since an operator might choose to NOT consider the issues and security of Diameter base, this document should warn users what vulnerabilities might exist in their network if another operator ignores these issues.) 3) In acknowledgements, you credit a number of people with resolving the "problems", but don't mention what problems those were.
  5. Robert Sparks: Discuss [2011-11-30]:
        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"? 
        
  6. Sean Turner: Comment [2011-11-29]:
    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

  1. Adrian Farrel: Discuss [2011-12-01]:
        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? 
        
  2. Adrian Farrel: Comment [2011-12-01]:
    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
        
  3. ... that are conformant to this MIB module Or are you making a wider statement about Rbridges? --- The DESCRIPTION clause of rbridgeSnoopingPortAddr should indicate the (obvious) fact that the object is interpretted in the context of rbridgeSnoopingPortAddrType. --- rbridgeDtreeActiveTrees OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of trees being computed by all Rbridges campus." Missing some text in the DESCRIPTION clause?
  4. Stephen Farrell: Comment [2011-11-11]:
    - What does "TBD for this section" mean in 5.1?
    I assume that was meant to be deleted but that
    got missed?
    
  5. Russ Housley: Discuss [2011-11-29]:
        
      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. 
        
  6. Peter Saint-Andre: Comment [2011-11-30]:
    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."
  7. Sean Turner: Comment [2011-11-29]:
    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

  1. Russ Housley: Comment [2011-11-29]:
      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.
  2. Peter Saint-Andre: Discuss [2011-11-30]:
        [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)? 
        
  3. Peter Saint-Andre: Comment [2011-11-30]:
    There are several instances of "URL" instead of "URI"; is the difference meant
    to be significant?
  4. Sean Turner: Discuss [2011-11-28]:
        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? 
        
  5. Sean Turner: Comment [2011-11-28]:
    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

  1. Jari Arkko: Discuss [2011-12-01]:
        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? 
        
  2. Jari Arkko: Comment [2011-12-01]:
    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):
    
        
  3. ..if that's what was meant. 5. IANA Considerations 0x00000000 - 0x000003FF IETF Consensus In RFC5226 this is "IETF Review" instead of "IETF Consensus".
  4. Russ Housley: Comment [2011-11-29]:
      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
  5. Sean Turner: Comment [2011-11-28]:
    An informative reference to RFC 6151 might be good in the 1st
    sentence of the introduction.

draft-ietf-sieve-convert

  1. Adrian Farrel: Comment [2011-12-01]:
    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.
    
  2. Stephen Farrell: Comment [2011-11-26]:
    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.
    
  3. Peter Saint-Andre: Comment [2011-11-28]:
    In Section 2.1, it might be helpful to cite RFC 5228 on the definition of
    "implicit keep".

draft-ietf-ippm-loss-episode-metrics

  1. Adrian Farrel: Comment [2011-12-01]:
    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."
    
  2. Stephen Farrell: Comment [2011-11-28]:
    - 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.
  3. Russ Housley: Comment [2011-11-30]:
      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
  4. Dan Romascanu: Comment [2011-12-01]:
    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

  1. Stephen Farrell: Comment [2011-11-28]:
    - 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?
    
  2. Russ Housley: Discuss [2011-11-30]:
        
      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 
        
  3. Dan Romascanu: Comment [2011-12-01]:
    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.
  4. Peter Saint-Andre: Comment [2011-11-30]:
    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?
  5. Sean Turner: Comment [2011-11-30]:
    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

  1. David Harrington: Comment [2011-11-30]:
    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.
  2. Russ Housley: Comment [2011-11-29]:
      idnits 2.12.12 reported:
    
        Unused Reference: 'RFC6021' is defined on line 623, but no explicit
        reference was found in the text
  3. Peter Saint-Andre: Comment [2011-11-29]:
    [comment redacted]
  4. Sean Turner: Comment [2011-11-28]:
    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

  1. Stephen Farrell: Comment [2011-11-28]:
    - 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,/
    
  2. Peter Saint-Andre: Comment [2011-11-29]:
    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.
  3. Sean Turner: Comment [2011-11-30]:
    #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

  1. Ralph Droms: Comment [2010-09-21]:
    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"? 
  2. Tim Polk: Comment [2010-09-23]:
    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.
    
  3. Dan Romascanu: Comment [2010-09-23]:
     p21: s/Expecting and most/Expecting most/
    
  4. Peter Saint-Andre: Comment [2010-09-22]:
    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

  1. Ron Bonica: Comment [2011-10-19]:
    Concur with Russ' discuss.
  2. Adrian Farrel: Comment [2011-10-18]:
    Cleared my Discuss after discussion
  3. Stephen Farrell: Comment [2011-11-26]:
    typo:
    
    Missing a word in the intro: "message is overly and"
  4. Peter Saint-Andre: Comment [2011-11-28]:
    Please retain the part of Appendix B that lists the changes from RFC3462 to this
    memo.
  5. Robert Sparks: Comment [2011-11-29]:
    
        
  6. Sean Turner: Comment [2011-11-29]:
    
      

draft-weil-shared-transition-space-request

  1. Ron Bonica: Discuss [2011-11-29]:
        I will change this ballot to "YES" when a /10 has been allocated for this space. 
        
  2. Stewart Bryant: Discuss [2011-11-29]:
        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. 
        
  3. Ralph Droms: Discuss [2011-11-30]:
        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? 
        
  4. Wesley Eddy: Comment [2011-11-30]:
    I agree with the comments and discuss positions from others that say there is
    not IETF consensus on this document.
  5. Adrian Farrel: Comment [2011-11-30]:
    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.
  6. Stephen Farrell: Comment [2011-12-01]:
    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.
    
  7. David Harrington: Discuss [2011-12-01]:
        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. 
        
  8. Dan Romascanu: Discuss [2011-12-01]:
        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. 
        
  9. Peter Saint-Andre: Discuss [2011-11-30]:
        I concur with the DISCUSS position lodged by Stewart Bryant. 
        

draft-ietf-lisp-alt

  1. Ron Bonica: Discuss [2011-11-30]:
        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. 
        
  2. Stewart Bryant: Comment [2011-12-01]:
    =====
       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" 
  3. Ralph Droms: Discuss [2011-11-30]:
        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? 
        
  4. Ralph Droms: Comment [2011-11-30]:
    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?
    
  5. Adrian Farrel: Discuss [2011-12-01]:
        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. 
        
  6. Adrian Farrel: Comment [2011-12-01]:
    I picked out the same sentence as several others...
    
       EID-prefixes are expected to be allocated to a LISP site by Internet
       Registries.
    
        
  7. ...but I wondered whether you were saying something less alarming than they interpretted (for example, that the addresses are not from a private space). In any case, clarification will surely help.
  8. Robert Sparks: Discuss [2011-11-29]:
        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
        
  9. .murphy-bgp-secr). Are there plans to update and eventually publish this draft? If not, is there something more recent that could be used instead? (Sorry, hit the send button too soon) - Also, what are the plans for [I-D.white-sobgparchitecture]?
  10. Sean Turner: Discuss [2011-12-01]:
        #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. 
        
  11. Sean Turner: Comment [2011-12-01]:
    #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

  1. Ron Bonica: Discuss [2011-11-30]:
        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. 
        
  2. Stewart Bryant: Discuss [2011-12-01]:
        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. 
        
  3. Stewart Bryant: Comment [2011-12-01]:
       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?
  4. Ralph Droms: Discuss [2011-11-30]:
        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? 
        
  5. Ralph Droms: Comment [2011-11-30]:
    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/
  6. Wesley Eddy: Discuss [2011-11-29]:
        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. 
        
  7. Wesley Eddy: Comment [2011-11-29]:
    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"?
  8. Adrian Farrel: Discuss [2011-11-30]:
        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. 
        
  9. Adrian Farrel: Comment [2011-11-30]:
    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.
    
  10. Stephen Farrell: Discuss [2011-12-01]:
        
    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.
     
        
  11. Stephen Farrell: Comment [2011-12-01]:
    - 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.
    
  12. Russ Housley: Comment [2011-11-29]:
      This is going for experimental, and I think it clears the bar for
      experimental.  However, I think Section 6 could be much more clear.
  13. Pete Resnick: Comment [2011-11-29]:
    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.
  14. Dan Romascanu: Comment [2011-11-30]:
    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
  15. Peter Saint-Andre: Comment [2011-11-30]:
    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).
  16. Robert Sparks: Discuss [2011-11-29]:
        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? 
        
  17. Robert Sparks: Comment [2011-11-29]:
    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.
  18. Sean Turner: Discuss [2011-12-01]:
        #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? 
        
  19. Sean Turner: Comment [2011-12-01]:
    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

  1. Jari Arkko: Comment [2011-12-01]:
    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.
  2. Stewart Bryant: Comment [2011-11-28]:
    Nit
    
    S/agains them/against them/
  3. Adrian Farrel: Comment [2011-12-01]:
    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.
  4. Stephen Farrell: Comment [2011-11-28]:
    - 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.
    
  5. Russ Housley: Comment [2011-11-29]:
      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
  6. Pete Resnick: Comment [2011-11-29]:
    - 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".
  7. Peter Saint-Andre: Comment [2011-11-28]:
    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.
  8. Sean Turner: Comment [2011-11-29]:
    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

  1. Jari Arkko: Comment [2011-12-01]:
    >   inter-authenticator handovers.However, it is currently unclear how
    
    s/[.]/. /
    
  2. Russ Housley: Discuss [2011-11-29]:
        
      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

  1. Jari Arkko: Discuss [2010-10-20]:
        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. 
        
  2. Jari Arkko: Comment [2010-10-20]:
    
        
  3. Ron Bonica: Discuss [2010-10-21]:
        Support DISCUSS positions from security ADs 
        
  4. Ron Bonica: Comment [2010-10-21]:
    
        
  5. Stephen Farrell: Discuss [2011-11-28]:
        - 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?
    
        
  6. David Harrington: Discuss [2010-10-20]:
        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? 
        
  7. David Harrington: Comment [2010-10-20]:
    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.
  8. Russ Housley: Discuss [2010-10-03]:
        
      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. 
        
  9. Tim Polk: Discuss [2010-10-20]:
        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] 
        
  10. Tim Polk: Comment [2010-10-20]:
    What is an "unauthorized public & private key pair"?  What is a "certified
    public & private key pair"? [section 4]
  11. Peter Saint-Andre: Comment [2011-11-30]:
    I concur with the DISCUSS position lodged by Jari Arkko, and share some of the
    concerns expressed by other IESG members.
  12. Sean Turner: Discuss [2010-10-21]:
        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. 
        
  13. Sean Turner: Comment [2010-10-21]:
    
      

draft-davis-t-langtag-ext

  1. Pete Resnick: Comment [2011-11-29]:
    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".
  2. Sean Turner: Comment [2011-11-29]:
    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.