IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-09-22. 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 EDT 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. RBridges: Appointed Forwarders (Proposed Standard)
    draft-ietf-trill-rbridge-af-04
    Token: Ralph Droms
    Note: Erik Nordmark (nordmark@acm.org) is the document shepherd.
    Discusses/comments (from ballot 3915):
    1. Ron Bonica: Comment [2011-09-20]:
      Please run the Nit checker over this document. Also, please make sure that the abstract and intro both reference the update correctly.
    2. Stewart Bryant: Comment [2011-09-21]:
      "If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored but any VLAN other VLAN IDs are still effective."
      I think that there are one too many "VLAN"s in the sentence.
    3. Dan Romascanu: Discuss [2011-09-22]:
      In Section 3: "It is safe to configure this inhibition time to the settling time of an attached bridged LAN. For example, if it is known that Rapid Spanning Tree Protocol (RSTP [802.1Q]) is running throughout the attached bridged LAN, it should be safe to configure this inhibition time to 4 seconds."
      Why 4 seconds? Should not this value be 3 x Hello Timer which is 6 seconds?

    Telechat:

  2. Diameter Base Protocol (Proposed Standard)
    draft-ietf-dime-rfc3588bis-29
    Token: Dan Romascanu
    Note: Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com) is the Document Shepherd
    IPR: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25
    Discusses/comments (from ballot 3557):
    1. Stephen Farrell: Discuss [2011-09-15]:
      Hopefully this is a no-brainer and just a simple clarification is needed.
      13.1 says that (D)TLS is now a MUST implement and IPsec is a MAY and using TLS is a SHOULD and using some security is a MUST, all of which is great. However, one question - when it says Diameter MUST NOT be used without "some security mechanism" does that mean one of (D)TLS or IPsec MUST be used? If so, then saying so would be good, since otherwise someone may claim to be conforming because they're using something home-grown which would not be good really. I think this can be fixed by simply changing the end of the 1st para of 13.1 to "..the Diameter protocol MUST NOT be used without one of TLS, DTLS or IPsec." If you do want to allow "some security mechanism" to mean something else then I think you need to characterise that more tightly.
    2. Stephen Farrell: Comment [2011-09-15]:
      - 5.2 says that "OIDs within...certificates" can be used to "signify Diameter Server authorization" - have those been defined since 3588? If so, then a reference here would be good. If not, that's a pity...
      - The IPR declaration confuses me. RFC 3588 is dated September 2003. The declaration says it relates to a filing from November 2003, and 3588bis doesn't seem to add anything of note other than clarifications. But I guess since its "recriprocity" that'll just have to go down as yet another wonder of the patent world ;-)
    3. Pete Resnick: Comment [2011-09-21]:
      Overall - It took quite a while (I think until I was well into section 6) for me to figure out that the document means two different things by "ABNF". There's the *real* ABNF that appears in (e.g.) section 3.2, and then there's the Command Code syntax, which you also refer to later as "ABNF". This was very confusing. Maybe this use is so entrenched now that it's not worth changing, but "CCBNF" for the latter might be nice.
      Section 3.2: "command-def = <command-name> "::=" diameter-message"
      As far as I can tell, the angle brackets around "command-name" are incorrect.
      "diameter-name = ALPHA *(ALPHA / DIGIT / "-")"
      Just confirming: You do allow "z----------" as a legal diameter-name?
      "diameter-message = header [ *fixed] [ *required] [ *optional]"
      The square brackets are superfluous. The leading asterisk already means zero or more. It also looks to me like the fixed ones always must be right after the header and the required and optional can be in any order after that. What you probably want is:
      "diameter-message = header *fixed *(required/optional)"
      That's more precise in what you want.
      Example-Request ::= < Diameter Header: 9999999, REQ, PXY > { User-Name } * { Origin-Host } * [ AVP ]
      I am confused as to what "* { Origin-Host }" could mean. How can something be both required and have a "*", which means "zero or more"? Can there actually be zero of a required AVP?
      Section 4.3.1: "FQDN = Fully Qualified Host Name"
      Here I think there you want: "FQDN = <Fully Qualified Host Name*gt;"
      Section 4.4: See comments on 3.2. Same sorts of issues.
    4. Peter Saint-Andre: Discuss [2011-09-21]:
      RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV Service of 'diameter'. 3588bis seems to add two more Proto values: 'tls' and 'dtls'. However, RFC 6335, which defines updated rules for the ports and services registry, allows only TCP, UDP, SCTP, and DCCP as transport protocols. Furthermore, this specification does not register the 'diameter' SRV Service value in accordance with RFC 6335. Because these values were not defined or registered by draft-ietf-dime-extended-naptr, I think they need to be defined here.
    5. Peter Saint-Andre: Comment [2011-09-21]:
      1. In Section 1.3.3, this specification has "[d]eprecated the exchange of CER/CEA messages in the open state" but "assume[s] that the capabilities exchange in the open state will be re-introduced in a separate specification". Do we really want to actively deprecate something that it's assumed will return in the not-too-distant future? Or do we want to change "will be re-introduced" to "might be re-introduced"?
      2. It might be helpful to explain why the End-to-End security framework has been deprecated. Did it not work properly? Did no one implement it? Were there such significant interoperability problems that it was deemed better to scrap it? And, will it be (or does it need to be) replaced by something else?
    6. Robert Sparks: Discuss [2011-09-20]:
      The document reflects the change of the name of the Well-Known IANA policy definition from "IETF Consensus" to "IETF Review", but seems to state that this is a change of policy rather than a change of the policy name (as explained in RFC5226). Specifically, it says "now only require IETF Review as opposed to an IETF Consensus". Has the working group captured what it intended?
      This sentence in section 2.1 is not clear: "For TLS [RFC5246] and DTLS [RFC4347], a Diameter node that initiate a connection prior to any message exchanges MUST run on port [TBD].:
      What was its intent? It could be misread to say that you cannot establish a connection on any other port than [TBD].
      In the new text on dynamic agent discovery, Section 5.2 part 3 - should an element that's looked up SRV records as specified in this item follow all of the requirements in RFC 2782 if multiple SRV records are returned (in particular, following the balancing algorithm over records with the same Priority)? Shouldn't this section reference RFC 2782?
      In the new text on the Election Process, "lexicographically succeeds" needs additional description.
      The note at the end of 6.1 is very ambiguous - does "this section" mean just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those subsections? Either way, it leaves the requirements language very hard to follow. Does this say certain implemenentations MAY ignore some MUSTs? If so, which ones?
    7. Robert Sparks: Comment [2011-09-20]:
      In section 1.3.1's second paragraph, starting the second sentence with "Typically," is likely to introduce confusion about the allocation policy. Why is the word needed in this sentence?
      In section 2, 2nd to last paragraph before section 2.1: This edit (moving how tranparency is described) resulted in a sentence that says Diameter Relays and redirect agents MUST support all Diameter applications. Please consider touching it again to make it clearer that those elements MUST be transparent to the applications, and as a result trivially support them.
      In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP, please consider pointing out that section 2.2 still requires _SOME_ security mechanism be used.
      The edits to the first paragraph of the description of AVP flags left the sentence "Unrecognized bits SHOULD be considered an error." unsupported. It's not clear (without looking at the diff to 3588) what bits might possibly be unrecognized.
      In section 6.1.2, can the document say why the hop-by-hop identifier SHOULD be locally unique rather than MUST be?
      NITS..
    8. Sean Turner: Discuss [2011-09-21]:
      #1) I'm confused by the following two statements:
      from abstract: "The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations."
      from s2.1: "If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port [TBD], i.e. the peer complies only with [RFC3588], then the initiator MAY revert to using TCP or SCTP and on port 3868."
      from s13: "However, all Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP and the Diameter protocol MUST NOT be used without any security mechanism."
      If all new Diameter applications support the TLS/TCP an DTLS/SCTP, how is an application not going to support accepting TLS/DTLS connections on port [TBD]? Also in s2.1 would it really be the "initiator" or would it be "peers"?
      #2) s1.1.1 and s11.2.1: This section mentions 5729 as part of the document set, but 5719 (which updates RFCC 3588) isn't mentioned. Are the contents of 5719 included in this draft? If so, shouldn't 5719 be added to the obsoletes header?
      #3) s2.2 and s13.1: I support Stephen's discuss position. I guess I'd note the same fix needs to be applied to s2.2.
      #4) s2.6 and s2.7: What's the format for the expiration time? MUST it be the format specified in 4.3.1 or is up to an implementation? If it's the former, a pointer s4.3.1 is needed.
      #5) s1.3.4, s2.4, s3, s6.11: There's no application IDs in Section 11.3. Is the section missing!? RFC 3588 had a section for Application Identifiers in the IANA section - this draft does not.
      #6) s5.2 and 11.6: This draft needs to normatively reference http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ for the S-NAPTR application service tags 'diameter.tcp', 'diameter.sctp', 'diameter.tls.tcp'. They're not defined in the this document and they don't appear to be in RFC 3588.
      #7) s6.1.2 and s3: s6.1.2 includes the following text: "The Hop-by-Hop Identifier SHOULD be set to a locally unique value."
      s3 contain the following text: "The sender MUST ensure that the Hop-by-Hop identifier in a request is unique on a given connection at any given time, and MAY attempt to ensure that the number is unique across reboots."
      don't these contradict each other? Seems like in s6.1.2 r/SHOLD/MUST ?
      #8) s11: If this document is obsoleting RFC 3588 shouldn't all the information found in RFC 3588's IANA section be included here? If not an implementer is going to need to pull out RFC 3588 + 5917, doesn't it make much more sense to have one standalone document for implementers?
      #9) s11.2: The contents of the RFC 5719 IANA considerations are mostly included but the first paragraph isn't the same - should they be the same?
      #10) s13: The peer and routing tables use expiry time. Certificates used in TLS/DTLS/IKE also contain expiry times. I think a considerations that says something about checking to make sure the peer and routing table expiry times are never beyond the expiry time in certificates. If you allow the expiry time to extend beyond the validity period in the certificate, it would be a bad thing. If the connections are very short lived then it might not be big deal, but if they're long-lived then there's more to worry about.
      #11) <process weenie> I'm hoping the answer to this is yes, but I had to ask because I didn't see it in the proto write-up:
      This document doesn't have a pre-5378 disclaimer and the author set is not the same as RFC 3588. Have Erik and Pat granted the rights to the IETF Trust to allow the document to be published without the pre-5378 disclaimer? </process weenie*gt;
    9. Sean Turner: Comment [2011-09-21]:
      (33 items)

    Telechat:

  3. ARP Mediation for IP Interworking of Layer 2 VPN (Proposed Standard)
    draft-ietf-l2vpn-arp-mediation-17
    Token: Stewart Bryant
    Note: Document Shepherd: Nabil Bitar, nabil.n.bitar@verizon.com
    Discusses/comments (from ballot 3912):
    1. Jari Arkko: Discuss [2011-09-22]:
      I am reading the ND modifications and trying very hard to convince myself that they are correct and complete. I'm not 100% sure I've managed to do that.
      I scanned the mailing list for 6man and found no discussion of this draft. Did I miss it? Shouldn't relatively complex surgery on ND require some review from the experts on ND?
      I'm also wondering if the SEND proxy specification from CSI WG would be an applicable recommendation in addition to recommending turning SEND off.
    2. Ralph Droms: Comment [2011-09-21]:
      In section 4.3.3, is "the link-layer address of the local AC" really "the link-layer address of the PE interface attached to the local AC"?
    3. Adrian Farrel: Discuss [2011-09-22]:
      I will move to a "Yes" ballot when my Discuss has been resolved.
      Why does this document include a redefinition of the Address List TLV that is already defined in RFC 5036? Although the text says that it is using the RFC 5036 definition, the text also says that the I-D defines the Address List TLV.
      Shouldn't you simply refer to 5036 and say how the fields are set for your specific use?
      Similarly the redefinition of the Notification message.
      To be clear, the main reason for objecting to the redefinition is that it opens the door to discrepencies, and makes it hard to handle future extensions. (Coders should be familiar with the practice of only defining data structures in one place :-)
      Please add some text to clarify whether the Stack Capability field in the Stack capability Interface Parameter sub-TLV is an integer or a bit-field.
      The IANA section makes it look like a bit field (which is what I would expect) but the text in the main body says... "Stack Capability = 0x0001 to indicate IPv6 stack capability" ...which makes it look like an integer
      Additionally, the text goes on to imply that the interpretation of the field is context-specific...
      "The value of Stack Capability is dependent on the PW type context. For IP Layer2 Transport type, a setting of 0x0001 indicates IPv6 stack capability."
      ...if this is the case, presumably, 0x0001 could mean something else in other circumstances. How is this tracked in the IANA registry?
    4. Adrian Farrel: Comment [2011-09-22]:
      Should the figure on page 5 include the label "AC3"?
      I agree with the other ADs who are concerned about the use or non-use of RFC 2119 language. Hopefully, this will be easy for you to clean up and will not be construed as changing the technical content of the document.
      "The "IP Layer 2 interworking circuit" pseudowire is also commonly referred to as "IP pseudowire".
      Can you insert a reference for "IP pseudowire"?
    5. Stephen Farrell: Comment [2011-09-16]:
      - 8.1 says that you "can" secure the PE-PE control plane "using MD5 authentication." Is that (still) the best that can be done? Doesn't it need a reference? Why can't something better be used, e.g. IPsec? Why no 2119 language? (This isn't a discuss because I hope that all that's in some other RFC.)
      - 8.1 says that this protocol is incompatible with SEND. I guess that's inevitable, but do you need to say more about the trade-offs concerned, e.g. would it ever be likely that a CE that depends on SEND is deployed and later on a PE doing this protocol is installed breaking the CE or changing its security properties in a bad way? (Just wondering.)
      - Frame Relay (FR) is expanded only on its 2nd use. 1st use is in 2nd para of section 1.
    6. Russ Housley: Comment [2011-09-21]:
      The Gen-ART Review by Peter McCann on 20-Sep-2011 raised a minor issue and two editorial suggestions:
      Section 5.2 says: "Since this notification does not refer to any particular message the Message ID and Message Type fields are set to 0." There does not appear to be a Message Type field in the PDU.
      Section 5: suggest replacing the idiom "chicken and egg situation" with "possible deadlock situation."
      Section 5.2: "Section 6. below." should be "Section 6 below."
    7. Pete Resnick: Comment [2011-09-21]:
      1. This entire document needs a good "MUST/SHOULD/MAY vs. must/should/may" scrubbing. Just to cite two examples:
      4.2.2: "When the PE learns the IP address of the remote CE, it should generate an Inverse ARP request."
      It "should"? Or it "SHOULD"? Or it "will"?
      4.3.2: "If a Router Discovery message contains a link layer address, then the PE MAY also use this message to discover the link layer address and IPv6 interface address."
      That MAY doesn't sound like a protocol option.
      2. Section 2: "PEs MUST support ARP mediation for IPv4 L2 Interworking circuits. PEs SHOULD support ARP mediation for IPv6 L2 interworking circuits."
      I assume this means "PEs that support ARP mediation MUST support it for IPv4 and SHOULD for IPv6". The way it is now, it sounds like ALL PEs must support this, which can't be right. That said, I see no reason for this paragraph. Mediation should be supported on both v4 and v6 circuits. I say drop the paragraph.
      3. For the record, and not something the authors need to address: I understand that the IETF doing sub-IP protocols is a ship that has sailed long before I got on the IESG. However, the mind boggles that we are deploying this particular protocol: Why can't we simply *route*?!?!? This protocol is standing on its head to allow layer 2 bridging of IP across disparate links instead of just having a routed VPN. This is goofy, it is a complete layer violation, and I don't think we should be standardizing this nonsense.
      There, I feel marginally better. :-/
    8. Peter Saint-Andre: Comment [2011-09-21]:
      This document appears to be predicated on "know[ing] that only IP traffic will be carried". How is this determined?
    9. Robert Sparks: Comment [2011-09-21]:
      Section 7.2 invokes an IANA well known policy of "IETF Consensus", referencing RFC5226, but that RFC has renamed that particular policy to "IETF Review".
    10. Sean Turner: Comment [2011-09-22]:
      I have the same question Stephen did about MD5.

    Telechat:

  4. Using the Generic Associated Channel Label for Pseudowire in MPLS-TP (Proposed Standard)
    draft-ietf-pwe3-mpls-tp-gal-in-pw-01
    Token: Stewart Bryant
    Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3913):
    1. Adrian Farrel: Comment [2011-09-22]:
      Thanks for discussing my Discuss. I am happy to move to "Yes" on this documnet, but encourage you to look at the comments.
      Section 1: "[RFC5586] defines a generalized label-based exception mechanism using the Generic Associated Channel Label (GAL) to work together with the ACH for use with LSPs but places restrictions on GAL usage with PWs.
      "This document removes the restriction imposed by [RFC5586]."
      Please clarify one or more restrictions?
      Section 3: "This indicates that the GAL can be used for MPLS-TP LSPs and Sections, but not for PWs using an MPLS-TP PSN."
      What does it mean for a PW to use an MPLS-TP PSN? Perhaps... "but not for PWs in an MPLS-TP network."
      Nits
      Title: s/Pseudowire/Pseudowires/
      Abstract: s/[RFC5586]/RFC 5586/
      Section 1: s/associated control channel/Associated Channel/ (per RFC 5085)
      Section 1: s/generalizes this for use in the/generalizes this for use as the/
      Section 3 para 1: Delete "appropriate" or fix as suggested by Stephen
    2. Stephen Farrell: Comment [2011-09-16]:
      typo: s/architectures appropriate/architectures as appropriate/ in section 3
    3. Dan Romascanu: Comment [2011-09-22]:
      OAM is defined in the terminology section but never used. I suggest to drop it.

    Telechat:

  5. Email Feedback Report Type Value : not-spam (Proposed Standard)
    draft-ietf-marf-not-spam-feedback-02
    Token: Pete Resnick
    Discusses/comments (from ballot 3920):
    1. Adrian Farrel: Comment [2011-09-22]:
      Would be nice if the Abstract gave context by mentioning "email"
      Random thought: is there also a need for an ARF to report when a message has mistakenly been reported as mistakenly reported as spam? That would be a "not-not-spam report". This would seem to be necessary as you include the possiblity of a user accidentally pressing a "not spam" button.
      "There are anti-spam systems that use "not spam" feedback today."
      Presumably, this is non-standard "not spam" feedback?
      Section 2: "In the first MIME part of the feedback report message, the end user or the email client can add information to indicate why the message is not spam -- for example, because the originator or its domain is well known."
      s/can/MAY/ ?
      Overall, I had trouble finding where in this document anything was actually defined. I don't suppose that is really a problem, but it was a bit surprising.
    2. Peter Saint-Andre: Comment [2011-09-19]:
      To avoid endless philosophical debates about what is and is not spam, I suggest changing "Indicates that a message is not spam" to "Indicates that the entity providing the report does not consider the message to be spam" (or somesuch).

    Telechat:

  6. MPLS Fault Management OAM (Proposed Standard)
    draft-ietf-mpls-tp-fault-07
    Token: Adrian Farrel
    Note: Ross Callon (rcallon@juniper.net) is the Document Shepherd.
    IPR: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mpls-tp-fault-03
    Discusses/comments (from ballot 3934):
    1. Russ Housley: Comment [2011-09-21]:
      The IPR statement from Ericsson is confusing to me. See https://datatracker.ietf.org/ipr/1460/. What does "option b) above" mean?
    2. Pete Resnick: Comment [2011-09-21]:
      Section 2.1: "The MPLS Alarm Indication Signal (AIS) message is generated in response to detecting faults in the server (sub-)layer. The AIS message SHOULD be sent as soon as the condition is detected, but MAY be delayed owing to processing in an implementation, and MAY be suppressed if protection is achieved very rapidly."
      Those "MAY"s aren't protocol options, they're exceptions to the SHOULD. How about instead, "The AIS message SHOULD be sent as soon as the condition is detected, with the obvious exceptions being delay owing to processing in an implementation or complete supression if protection is acheived rapidly."
      "The primary purpose of the AIS message is to suppress alarms in the layer network above the level at which the fault occurs. When the Link Down Indication is set, the AIS message MAY be used to trigger recovery mechanisms."
      Do you really mean "MAY" here, or rather "can"? Who are you telling that they MAY use the AIS message as the trigger, the implementer of the recovery mechanism (in which case it might be right) or others who need to be aware that recovery mechanisms might be triggered (in which case it is wrong).
      Section 2.2: Similar use of MAY as above. Please check.
    3. Dan Romascanu: Comment [2011-09-20]:
      Hopefully IANA knows what to do, but the note in Section 8.1 is not clear to me.
      "[Note: An early codepoint allocation was made: 0x0058 Fault OAM (TEMPORARY - expires 2012-07-20)]"
      Do the authors request to transform this temporary codepoint allocation to a permanent one?
      In any case the Note needs to be taken out at document publication.
    4. Peter Saint-Andre: Comment [2011-09-12]:
      Please specify whether the refresh timer can include fractional seconds.
      Please specify the byte order of the longer fields; typically this is network byte order (i.e., most significant byte first), but not always.
    5. Robert Sparks: Comment [2011-09-21]:
      Section 8.4 indicates that it will use the term "Private Use", but doesn't. It does use "Experimental Use" - should the first paragraph have called that out instead?

    Telechat:

  7. The Web Origin Concept (Proposed Standard)
    draft-ietf-websec-origin-04
    Token: Peter Saint-Andre
    Note: The Document Shepherd is Tobias Gondrom <tobias.gondrom@gondrom.org>.
    Discusses/comments (from ballot 3940):
    1. Wesley Eddy: Discuss [2011-09-13]:
      When section 4 says to return a "globally unique identifier", does it need to be generated based on the URI? From the definition in section 2.3 it seems like you're supposed to just do a gensym, so it will be different every single time the origin is computed even for the same URI going through the algorithm at different times. It wasn't clear to me if that was really the intent.
    2. Stephen Farrell: Discuss [2011-09-16]:
      (1) cleared
      (2) Just saying "return a globally unique identifier" doesn't seem enough. I think what you need is a new identifier for each run of the algorithm. Section 5 depends on this, so you should say that in section 4.
    3. Stephen Farrell: Comment [2011-09-15]:
      There are quite a few places where the language used here is difficult or problematic. I'd encourage the authors to consider including fewer words if possible - a lot of the descriptive material isn't really necessary and the document might be better without it.
      (24 items)
    4. Russ Housley: Comment [2011-09-21]:
      The Gen-ART Review by Miguel Garcia on 5-Sep-2011 raised a few minor concerns, and they were addressed by the authors. However, a new version of the document with the suggested changes gas not been posted yet.
    5. Pete Resnick: Discuss [2011-09-18]:
      Unlike other contexts, it seems to me that when it comes to matching origins, false positives are much worse than false negatives: The harm of false positives is that items will cross security contexts, hence compromising security, whereas false negatives simply mean that certain entities will not be able to request data on behalf of others. So, if two host names do not match because the hosts in question were using different versions of IDNA, or because a host name is not a valid label, better that they don't match rather than they do. So, I'm guessing you don't need to do any reference to RFC 3490 at all. Specifically:
      Section 2.3 - In the definition of idna-canonicalized, I don't think you care if the labels are in fact NR-LDH labels or A-labels. If someone presents you with an all ASCII string, you'll lowercase it and use it for comparison, and if someone presents you with a string with non-ASCII-range Unicode, you'll want to punycode it and turn it into an ASCII string, even if it isn't a valid NR-LDH. But even if you do want valid NR-LDH labels, I think it would be actively bad to allow for 3490 NFKC canonicalization, because it would allow things to compare as identical that I'm guessing you really don't want, especially in this security context. So I think the choices are:
      a) If you're willing to allow more false negatives, simply say, "If the label contains any non-ASCII-range Unicode characters, encode it with the algorithm defined in RFC 3492 section 6.3 and prepend 'xn--' to it, otherwise use the all- ASCII label." And don't call it "idna-canonicalized", but instead call it "us-ascii-encoded".
      b) If you're wanting to do some canonicalization, simply say, "If the label contains any non-ASCII-range Unicode characters, first normalize the string using NFC, and then encode it with the algorithm defined in RFC 3492 section 6.3 and prepend 'xn--' to it, otherwise use the all-ASCII label."
      I can find others to help tighten up the language if you go down this path.
      Section 6.1 - There is no "ToUnicode" algorithm RFC 5891, so at the very least the paragraph is written incorrectly. But much of the 3490 ToUnicode algorithm is validating the label. I don't think there's a need to do the validation in this document. (Remember, if there are invalid *ASCII* host name labels -- like "example_host" -- the algorithm is not going to catch those, but nobody cares because it will only match another identical invalid label.) I would simply say: "For each label in the host part of the origin triple, if the label begins with "xn--" and the remainder of the label can be successfully decoded using the algorithm defined in RFC 3492 section 6.2, append the resulting Unicode label to the results. Otherwise, append the original label (including the "xn--", if any) to the results. Separate the labels with U+002E FULL STOP code points (".").
      Section 10.1 - If the above two changes are made, this section can be eliminated.
    6. Pete Resnick: Comment [2011-09-18]:
      Section 2.3 - It seems like "globally unique identifier" and "idna-canonicalized host name" are better defined where they are used, especially since the latter is an algoritm and not really a definition of terminology.
      Section 5: "Two origins that are globally unique identifiers cannot be the same if they were created at different times, even if they were created for the same URI."
      Does "at different times" mean "in different HTML documents"? In other words, can't two identical URIs appearing in the same HTML match without worry of security problems?
    7. Sean Turner: Discuss [2011-09-22]:
      s3.1.1 points out that using RFC2617 could be problematic. Is it worth deprecating it's use? If that's a step to far adding something like "it is NOT RECOMMENDED that new protocols use concepts from [RFC2817]"?

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. (none)

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Considerations for Having a Successful "Bar BOF" Side Meeting (Informational)
    draft-eggert-successful-bar-bof-06
    Token: Russ Housley
    Discusses/comments (from ballot 3839):
    1. Jari Arkko: Discuss [2011-09-22]:
      A horrible error on your otherwise excellent draft: "Anecdotal evidence exists that at least one Area Director has not been able to set foot outside the IETF hotel for a stretch of several days during IETF-77."
      A week. A full week. I think they let me out on Thursday evening, though. And I saw the sun for the first time on Friday. And why do you pick on Anaheim?
      Seriously though I do have a more serious issue. I agree with the thrust of the draft, of course, but I think it is written from a very typical IESG perspective where we try to prevent <horrible thing> from happening. But our role is not just to prevent bad things from happening, its also make good things happen. And I would argue that the draft misses some aspects of the problem from the point of view of the bar BOF folk when it tries to focus on the location of the meeting.
      My main issue is that other than giving advice on where to meet, the draft says very little on how to go about making a successful bar BOF. The specifics of the meeting itself are just one aspect.
      1) If you are an AD, chair, or key engineer at an important company, you will have trouble even finding the other people to talk to. Part of the reason why people come to the IETF meeting is to have side meetings. We should make it easy for them, but for many people it will be difficult to get started, even if they have an issue of their own. The working group is too busy and they follow their charter, so you don't get time on the agenda. You can't broadcast your desire to talk about the topic, you won't find the additional people.
      I would like to suggest that the document be changed to recommend that its OK to broadcast in the WG meeting (if you get a slot) or on the mailing list that you are interested to talk about a particular topic, please contact such and such. And *then* you can have that bar BOF. Positive description of what the guys need to do, not just forbidding them to meet in the current way.
      2) Coming up with new ideas, finding other people to talk to are key benefits of an IETF meeting. The document should more clearly stat that this is a desirable activity. Now it comes across a bit negative. E.g.:
      "... organizers should consider the value of holding side meetings at venues where such input can be more easily gathered."
      3): "Finally, some organizers may find the process to apply for an official BOF too complex, and so decide to simply mimic one."
      But it *is* too complex, almost unbearably unlikely to result in a granted BOF. And that is not just the fault of the BOF organizers, we are to blame, too. Perhaps mostly us.
      I think the draft should honestly state something about the current BOF processing being difficult.
    2. Jari Arkko: Comment [2011-09-22]:
      (blank)
    3. Stewart Bryant: Comment [2011-09-19]:
      To comment on Stephen's comment about the use of the term "bar bof". The traditionalist in me prefers to retain that term since it goes back to the origins of the IETF. However I am conscious that the term "bar bof" may well be a cultural issue for some folks. As such it would be good to find a term that was not synonymous with alcohol, but was somewhat more colorful and descriptive than "side meeting". Unfortunately no such term springs to mind.
    4. Wesley Eddy: Comment [2011-09-11]:
      It may be worthwhile to give some tips on inviting (or not inviting) area directors to your "side meeting" / bar-BOF.
      It should say that this isn't necessary, and may not even be advisable in many cases. Some groups need time to form before they're ready with anything cohesive, and a side-meeting is a good time to establish that BEFORE approaching ADs and describing proposals.
      It should be clear that if an AD attends a side-meeting, it is not necessarily a show of support. They may simply be interested, or often may be concerned or troubled with some aspect of the potential work and relation to existing work As the side-meeting may be in early stages of developing a viable WG or BoF proposal, there are likely to be many such concerns.
    5. Adrian Farrel: Discuss [2011-09-22]:
      I wanted to ballot "Yes" and move ahead with this document as a useful piece of guidance. I certainly don't want to spend time over-polishing.
      However...
      "Thus, the fact that a Contribution is made at one of the side meetings or other "unofficial" or "semi-official" events described in this document does not change or limit the applicability of the IETF's IPR rules. If you have a question regarding the applicability of the IETF IPR rules in any specific context or to any specific activity, you should consult your attorney or make an inquiry to the IESG."
      This is not helpful. It is true that nothing changes the IETF's IPR rules. But that doesn't say whether the IETF's IPR rules apply to "side meetings".
      Where does the concept that side meetings are "semi-official" come from? I thought the whole thrust of the document was to say that side meetings are not official in any way. Indeed the Abstract says it wants to "stress the unofficial nature of these get-togethers."
      I think we can make a more significant pronouncement in this document, but if you want it to come from the IESG then I think the whole of Section 6 should be replaced with a note that the IESG are to be consulted about the applicability of the IETF's IPR rules to side meetings.
      In particular, I take objection to...
      Informally, the above makes it appropriate, in order to provide a pointer to the relevant policies, to announce the "Note Well" text [NOTEWELL] in all such meetings.
      ...because this is clearly not the case. Indeed, it is absurd that if I go to lunch with two other people during the week of the IETF meeting when we all happen to be registered for the meeting that we are covered by the Note Well. Maybe you would like this included in all menus in all restaurants within a 10 mile radius?
      And anyway, if you are defering to the IESG on this matter, it is not correct for you to make this statement.
    6. Stephen Farrell: Comment [2011-09-12]:
      1) I'm not won over to the idea of discouraging the term "bar bof" generally. I do think we should distinguish those from side-meetings held as if they were formal wg sessions though and we should discourage the holding of the latter kind of meeting. So, I'd suggest changing the last sentence of the abstract to say something like:
      "This document recommends that the community use the term "bar BoF" exclusively to refer to side meetings that are held in bars and the like and to abandon the use of the term for meetings that are held in more formal settings such as IETF meeting rooms."
      (2) The same change as (1) would be needed in the intro, 2nd last para.
      (3) I think the IETF LC discussion about IPR should result in some change to section 6, depending on where that goes. I reckon that a good outcome to that might be that the Note Well ought be popped up for side-meetings in IETF meeting rooms but not otherwise.
      (4) I think Wes' suggestion about AD attendance is worth adding.
      (5) People have been known to forget their laptops after extended bar BoF sessions in real bars. That could be added to the security considerations.
      (6) I guess the Trilogy project may be finished now, so you may want to change the tense of the ack.
    7. Dan Romascanu: Discuss [2011-09-22]:
      1. I agree with Jari's points in his DISCUSS. The current document seems to be too negative about making of the IETF meetings an opportunity to have people meet and discuss new work in the IETF. I believe that we need text that makes clear that this is not the intention.
      2. I believe that the document needs to describe in a more balanced manner the different options of meeting to discuss new work. The principal thing in my opinion is to make clear that approving a room if available for side meetings needs not be read in any way as an endoresement of the work, but this should be a valid option
      3. I find much of section 3 (where to meet) problematic. On one side the text acknowledges the problem many non-native English speakers have understanding native English speakers (and the other way actually) but encourages them to go and meet in bars and restaurants provided they are not too noisy! The point should be IMO - meet wherever and however you believe you can discuss in the best conditions, here are the options, we are here to help.
      4. I would like to raise the point made by Wesley to a DISCUSS. At least we should discuss whether text is needed saying that the participation of the ADs (and maybe also of the IAB members) in side meetings should not be read as an endorsement of any kind, and that their participation is not useful because of the positions they hold, as side meetings are not part of any formal process.
    8. Peter Saint-Andre: Comment [2011-09-12]:
      I very much like this document.
      I think it would be helpful to cite RFC 5434 as early as possible in the document. I suggest adding a parenthetical statement to Section 1:
      "New IETF work often fits into an existing working group and does not require an official "birds of a feather" (BOF) session to determine community consensus (for more detailed information about BOF sessions, see [RFC 5434])."
      In Section 3: s/much more ineffective/much less effective/
      Perhaps make this change in Section 4: s/too complex/too complex or troublesome/
      There is a typo in Section 4: s/a certain procedures/certain procedures/
    9. Robert Sparks: Discuss [2011-09-21]:
      The list conversation on the "Applicability of IPR Rules" section does not appear to have concluded. I plan to move to YES on this document once that conversation completes.
    10. Robert Sparks: Comment [2011-09-21]:
      The authors indicated they would make several changes based on last call comments (on -06), but that revision is not yet available.
    11. Sean Turner: Comment [2011-09-22]:
      1) I support Jari's comment #1. I think people ought to be able to spam the community asking if there are people interested in topic X and then from those that respond try to set up the unofficial meeting (bar BOF/side-meeting). I think that's different than spamming lists saying we're having a meeting in room z at 9pm that happens to conflict with the plenary.
      2) I'm also not entirely sold on the need to abandon the term "bar BOF".
      3) I wholly agree with Wes' comment about the AD attendance not necessarily being a good sign. It might be worth adding that folks who ask an AD if they're coming shouldn't feel bad if the AD says "no" because it's not a sign of support or disapproval. I've had to tell people that just because I wasn't going to make it that's okay to proceed because it's not an official meeting.

    Telechat:

  2. Secure Password Framework for IKEv2 (Informational)
    draft-kivinen-ipsecme-secure-password-framework-02
    Token: Sean Turner
    Note: Tero Kivinen (kivinen@iki.fi) is the document shepherd.
    Discusses/comments (from ballot 3899):
    1. Jari Arkko: Discuss [2011-09-22]:
      This is a well written document and I understand the reasons why it came to be. I do have one discuss-level issue with the description of EAP, and a comment-level opinion about this direction of the work for IPSECME.
      The discuss-level issue is that Section 1 seems to be saying that EAP is asymmetric and that it is tied to AAA:
      "... the asymmetric nature of the EAP does not matter ...
      "... The new secure password methods are meant to be used in cases where such back-end AAA-infrastructure does not exists. An example of such case could be authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either end can initiate an IKEv2 connection."
      EAP is indeed asymmetric, but so is IKEv2, even the extensions defined in this draft use different content in the messages from the initiator and the responder. There is no reason why an EAP method would have to be asymmetric; EAP-GPSK for instance could be invoked from either end, based on which direction the IKEv2 initiation went.
      Similarly, there is no requirement that AAA be used to make a remote authentication decision. Implementations can decide to execute the EAP method locally.
      I'd like to change Section 1 text a bit to make this clearer. For instance:
      "... the asymmetric nature of the EAP does not matter ...
      "... The new secure password methods are meant to be used for example with the authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either end can initiate an IKEv2 connection. Note that such model could also be supported by EAP when an EAP method that can run in symmetric fashion is in use, and the EAP method is directly implemented on both peers and no AAA is in use."
    2. Jari Arkko: Comment [2011-09-22]:
      This is a comment about the direction of the work in the IPSECME working group. I understand that I'm in the rough on this, we already debated it at the time of the charter being extended.
      But I think we chose the wrong direction, and the problem is only amplified because the working group could not agree on a single password method. We are creating new authentication method negotiation frameworks, and adding those as alternatives in the base IKEv2 exchange. I don't think this will improve interoperability in the long term. I would have chosen to specify small set of new symmetrically operable EAP methods and used the already existing exchanges. The chosen direction will cause IKEv2 implementations to become more complex, as many implementations need to support multiple use cases and therefore in practice support all the authentication frameworks. And if some day we decide to extend configuration support in devices with the new functionality so that shared secret configuration could take place centrally, we'll end up replicating AAA support in addition to the IKEv2 extensions defined here.
    3. Stephen Farrell: Comment [2011-09-22]:
      - I don't get the point about the specific methods - do they or do they not use the formats defined here? If not, why not? If so, the last sentence of the 1st para of the intro is v. confusing. Do the 3 experimental proposals actually use the values being registered here? Only one of them (draft-shin...) seems to reference this draft. Colour me confused.
      - Is it ok for an informational doc to add to these registries?
      - abstract has typos:
      s/add new one/add any new ones/
      s/in current connection/in the current connection/
      - Intro
      s/and working group/and the working group/
      s/get pick/pick/
      s/make implementation/make an implementation/
      s/a payload formats/payload formats/
      s/co-exists/co-exist/
      That's getting tedious. It badly needs an editorial pass.

    Telechat:

  3. IANA Reserved IPv4 Prefix for Shared Transition Space (Informational)
    draft-weil-shared-transition-space-request-05
    Token: Ron Bonica
    Discusses/comments (from ballot 3933):
    1. Stewart Bryant: Discuss [2011-09-21]:
      The authors state that there are no security issues because no protocol is defined. However the last para of section 4 instructs certain filtering operations and indicates that under some circumstances these filtering operations may be relaxed. That is a type of protocol action which I would have expected to be considered from a security perspective.
      I wish to discuss the following on the IESG call. At the moment there is no action for the authors.
      I share Wesley's concern that this address space will just be used as yet more generic NAT space. If the space is to be used for the IPv6 transition it would be better if it were normatively bound to a set of named transition mechanisms.
    2. Wesley Eddy: Discuss [2011-09-16]:
      I don't plan to hold this DISCUSS past the telechat.
      This document says the prefix will be used to support IPv6 transition and coexistence with IPv4.
      I think it has little or nothing to do with IPv6, at least based on the text and cited documents.
      Most (or all) of the rationale really seems to be contained in draft-bdgks-arin-shared-transition-space. Looking at that document makes it seem like the motivation really boils down to this new space supporting all sorts of IPv4-only ISP concerns without direct links to IPv6 transition (sections 3.1 through 3.5 have nothing to do with transition), but it will "free up time" for operators to think about transition (section 3.6).
      The policy statement actually makes it pretty clear that this is more about IPv4 extension than transition: "A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators."
      I suspect many people will use this prefix without spending any time thinking about IPv6 or working on transition. I suppose there's no way to tie the use of this prefix to only operators that are also running some form of IPv6 trial or operational service.
      I think the title and text using "shared transition space" terminology are misleading. It should really be called what it is: "additional NAT space", "additional IPv4 private addresses", or something similar. I feel like we're only pretending that it has something to do with IPv6 to make it more palatable.
    3. Adrian Farrel: Comment [2011-09-22]:
      I support the many Discusses raised by other ADs and do not feel the need to raise any more Discuss issues myself.
      I find myself strongly disagreeing with the statement that service providers do not have the ablity to influence the rate of replacement of deployed customer equipment. Firstly, the availability of native IPv6 services is a prerequisite for anyone bothering to upgrade - this is clearly in the hands of the service providers and remarkably little effort has been made to provide such services. Secondly, a large proportion of home routers are supplied via the service providers as part of the sign-up deal - these have become almost as replacable as moble phones. Thirdly, I would point to the transition from analogue to digital terestrial TV in some countries - a change that has been forced on the consumer in a relatively short period (albeit with regulatory backup) and which has obsoleted the installed base of far more expensive customer equipment.
      In effect, ts document would be far more likely to get a smooth passage if it did not try to give reasons or excuses, but simply said what is required and for what purpose.
    4. Stephen Farrell: Comment [2011-09-13]:
      - Wouldn't it be useful to note that this UPDATEs 1918? Just so that people going there for the bogon list get to find out about the new allocation as well?
      - What is the exception for rule that packets with these addresses as source or destination "SHOULD NOT be forwarded" across interdomain links? Clarifying that would be useful.
      - Why is filtering routing information for these addreses on ingress links not a MUST? Put another way, what's the exception to the SHOULD rule? Clarifying that would be useful.
      editorial:
      - abstract missing a "." at the end
      - expand acronyms on 1st use: CGN, CPE
      - capitalisation is inconsistent for "Infrastructure Provider" and "Shared Transition Space"
    5. Russ Housley: Discuss [2011-09-21]:
      RFC 1918 is a BCP. Should this allocation really take place without achieving a similar level of IETF consensus?
    6. Pete Resnick: Discuss [2011-09-21]:
      I agree with Wes's DISCUSS. This has nothing to do with IPv6 transition. This is a new special-use NAT address space. In particular, though I understand that much of the justification for this is in draft-bdgks-arin-shared-transition-space, I think this document at least needs to explicitly say that the requesters have actual knowledge that there are uses for this address space (e.g., using it on the "outside facing" interface of current NATs) that will fail miserably if current 1918 space (either 10/8, 172.16/12, or 192.168/16) is used. If this is simply a guess that too many things will break, I'm not as happy about going forward with the allocation. If it is actually known that things will break, the document should say that.
    7. Pete Resnick: Comment [2011-09-21]:
      I agree with Russ's DISCUSS (as does IANA apparently).
      It seems to me that the IAB should weigh in on this document.
    8. Peter Saint-Andre: Comment [2011-09-12]:
      I suggest changing "heritage" to "legacy".
    9. Robert Sparks: Comment [2011-09-21]:
      I share Russ' question about documenting the same level of consensus as 1918.
    10. Sean Turner: Discuss [2011-09-22]:
      1) I'd like to see some more text after the following sentence: "Reverse DNS queries for Shared Transition Space addresses MUST NOT be forwarded to the global DNS infrastructure."
      Maybe something like: "This is done to avoid having to set up something similar to AS112.net for RFC 1918 private address space that a host has incorrectly sent for a DNS reverse-mapping queries on the public Internet [RFC6304]."
      I'd really hate for this to lead to an expansion of that "fix" (or maybe I'm totally misunderstanding what you're asking for).
      2) The secdir review pointed out the following:
      Following up on draft-bdgks, the current document should at least advise on (and better yet, mandate solutions for) "best practices associated with the use of this space, including considerations relating to filtering, routing, etc.".
      Can something be added to address this?
    11. Sean Turner: Comment [2011-09-22]:
      1) I support Stewart's discuss.
      2) I support Russ' discuss.
      3) I support Wes' (and Pete's) discuss.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Overview of Email DNSBL Best Practise (Informational)
    draft-irtf-asrg-bcp-blacklists-10
    Token: Pete Resnick
    Discusses/comments (from ballot 3957):
    1. Stephen Farrell: Comment [2011-09-22]:
      I agree with the other discusses to date
    2. Russ Housley: Discuss [2011-09-21]:
      This document is not a BCP, yet it claim to document "best practices", Should the IESG ask the IRSG to chose a phrase that will have less likelihood of being confused with a BCP?
    3. Dan Romascanu: Comment [2011-09-22]:
      I support Russ's DISCUSS.
    4. Peter Saint-Andre: Comment [2011-09-21]:
      Overall I think this is a helpful set of guidelines. Herewith a few comments.
      1. I concur with the DISCUSS from Russ Housley. Note that Sections 1.2 and 3.6.1 include the term "BCP".
      2. The abstract states: "This document is a product of the Anti-Spam Research Group and represents the consensus of that group."
      Section 1.4 states: "NOTE: This document is a product of the Anti-Spam Research Group (ASRG) of the IRTF. As per section 3 of [RFC2014] IRTF groups do not require consensus to publish documents. Therefore readers should be aware that this document does not necessarily represent the consensus of the entire ASRG."
      Those two statements appear to be in conflict.
      3. With regard to DoS attacks, consider adding a reference to RFC 4732.
      4. The security considerations seem a bit thin to me given that DNSBLs are used in ways different from "normal" DNS servers (e.g., RFC 3833 talks about denial of service attacks on DNS servers, but not malicious use of DNS-based services to poison the behavior of email servers and the like).
      5. Please expand relevant acronyms on first use and provide appropriate citations (e.g., "IRC").

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. HIP Experiment Report (Informational)
    draft-irtf-hip-experiment-13
    Token: Russ Housley
    Note: The document shepherd is Tom Henderson (thomas.r.henderson@boeing.com)

    Telechat:

  2. Host Identity Protocol Distributed Hash Table Interface (Experimental)
    draft-irtf-hiprg-dht-04
    Token: Russ Housley
    Note: The document shepherd is Tom Henderson (thomas.r.henderson@boeing.com).

    Telechat:

1259 EDT break

1304 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Reputation Services (repute)
    Token: Pete

    Telechat:

  2. BFCPBIS (bfcpbis)
    Token: Gonzalo

    Telechat:

  3. Managed Incident Lightweight Exchange (mile)
    Token: Sean

    Telechat:

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. (none)
  2. Ballot position names for charter ballots (Robert Sparks)

    Telechat:

  3. BoF Wiki (Robert Sparks)

    Telechat:

7. Agenda Working Group News

1342 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-09-22 07:42:08 PDT)

draft-ietf-dime-rfc3588bis

  1. Stephen Farrell: Discuss [2011-09-15]:
        Hopefully this is a no-brainer and just a simple clarification is needed.
    
    13.1 says that (D)TLS is now a MUST implement and IPsec is a MAY
    and using TLS is a SHOULD and using some security is a MUST, all of
    which is great. However, one question - when it says Diameter MUST
    NOT be used without "some security mechanism" does that mean one of
    (D)TLS or IPsec MUST be used? If so, then saying so would be good,
    since otherwise someone may claim to be conforming because they're
    using something home-grown which would not be good really. I think
    this can be fixed by simply changing the end of the 1st para of 13.1
    to "..the Diameter protocol MUST NOT be used without one of TLS,
    DTLS or IPsec." If you do want to allow "some security mechanism" to
    mean something else then I think you need to characterise that more
    tightly.
     
        
  2. Stephen Farrell: Comment [2011-09-15]:
    - 5.2 says that "OIDs within...certificates" can be used to "signify
    Diameter Server authorization" - have those been defined since 3588?
    If so, then a reference here would be good. If not, that's a pity...
    
    - The IPR declaration confuses me. RFC 3588 is dated September 2003.
    The declaration says it relates to a filing from November 2003, and
    3588bis doesn't seem to add anything of note other than
    clarifications. But I guess since its "recriprocity" that'll just
    have to go down as yet another wonder of the patent world;-)
    
  3. Pete Resnick: Comment [2011-09-21]:
    Overall - It took quite a while (I think until I was well into section 6) for me
    to figure out that the document means two different things by "ABNF". There's
    the *real* ABNF that appears in (e.g.) section 3.2, and then there's the Command
    Code syntax, which you also refer to later as "ABNF". This was very confusing.
    Maybe this use is so entrenched now that it's not worth changing, but "CCBNF"
    for the latter might be nice.
    
    Section 3.2:
    
       command-def      = <command-name> "::=" diameter-message
    
    As far as I can tell, the angle brackets around "command-name" are incorrect.
    
       diameter-name    = ALPHA *(ALPHA / DIGIT / "-")
    
    Just confirming: You do allow "z----------" as a legal diameter-name?
    
       diameter-message = header  [ *fixed] [ *required] [ *optional]
    
    The square brackets are superfluous. The leading asterisk already means zero or
    more. It also looks to me like the fixed ones always must be right after the
    header and the required and optional can be in any order after that. What you
    probably want is:
    
       diameter-message = header *fixed *(required/optional)
    
    That's more precise in what you want.
    
       Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
                           { User-Name }
                         * { Origin-Host }
                         * [ AVP ]
    
    I am confused as to what "* { Origin-Host }" could mean. How can something be
    both required and have a "*", which means "zero or more"? Can there actually be
    zero of a required AVP?
    
    Section 4.3.1:
    
          FQDN               = Fully Qualified Host Name
    
    Here I think there you want:
    
          FQDN               = <Fully Qualified Host Name>
    
    Section 4.4: See comments on 3.2. Same sorts of issues.
    
  4. Peter Saint-Andre: Discuss [2011-09-21]:
        RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV Service of
    'diameter'. 3588bis seems to add two more Proto values: 'tls' and 'dtls'.
    However, RFC 6335, which defines updated rules for the ports and services
    registry, allows only TCP, UDP, SCTP, and DCCP as transport protocols.
    Furthermore, this specification does not register the 'diameter' SRV Service
    value in accordance with RFC 6335. Because these values were not defined or
    registered by draft-ietf-dime-extended-naptr, I think they need to be defined
    here. 
        
  5. Peter Saint-Andre: Comment [2011-09-21]:
    1. In Section 1.3.3, this specification has "[d]eprecated the exchange of
    CER/CEA messages in the open state" but "assume[s] that the capabilities
    exchange in the open state will be re-introduced in a separate specification".
    Do we really want to actively deprecate something that it's assumed will return
    in the not-too-distant future? Or do we want to change "will be re-introduced"
    to "might be re-introduced"?
    
    2. It might be helpful to explain why the End-to-End security framework has been
    deprecated. Did it not work properly? Did no one implement it? Were there such
    significant interoperability problems that it was deemed better to scrap it?
    And, will it be (or does it need to be) replaced by something else?
  6. Robert Sparks: Discuss [2011-09-20]:
        The document reflects the change of the name of the Well-Known
    IANA policy definition from "IETF Consensus" to "IETF Review", but
    seems to state that this is a change of policy rather than a change
    of the policy name (as explained in RFC5226).  Specifically, it says
    "now only require IETF Review as opposed to an IETF Consensus".
    Has the working group captured what it intended?
    
    This sentence in section 2.1 is not clear:
       For TLS [RFC5246] and DTLS [RFC4347], a Diameter
       node that initiate a connection prior to any message exchanges MUST
       run on port [TBD].
    What was its intent? It could be misread to say that you cannot establish
    a connection on any other port than [TBD].
    
    In the new text on dynamic agent discovery, Section 5.2 part 3 -
    should an element that's looked up SRV records as specified in this
    item follow all of the requirements in RFC 2782 if multiple SRV records
    are returned (in particular, following the balancing algorithm over
    records with the same Priority)? Shouldn't this section reference RFC 2782?
    
    In the new text on the Election Process, "lexicographically succeeds" needs
    additional description.
    
    The note at the end of 6.1 is very ambiguous - does "this section" mean
    just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
    subsections?  Either way, it leaves the requirements language very hard
    to follow.  Does this say certain implemenentations MAY ignore some MUSTs?
    If so, which ones?
     
        
  7. Robert Sparks: Comment [2011-09-20]:
    In section 1.3.1's second paragraph, starting the second sentence with
    "Typically," is likely to introduce confusion about the allocation policy.
    Why is the word needed in this sentence?
    
    In section 2, 2nd to last paragraph before section 2.1: This edit (moving
    how tranparency is described) resulted in a sentence that says Diameter Relays
    and redirect agents MUST support all Diameter applications. Please consider
    touching it again to make it clearer that those elements MUST be transparent
    to the applications, and as a result trivially support them.
    
    In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP,
    please consider pointing out that section 2.2 still requires _SOME_ security
    mechanism be used.
    
    The edits to the first paragraph of the description of AVP flags left
    the sentence "Unrecognized bits SHOULD be considered an error." unsupported.
    It's not clear (without looking at the diff to 3588) what bits might
    possibly be unrecognized.
    
    In section 6.1.2, can the document say why the hop-by-hop identifier
    SHOULD be locally unique rather than MUST be?
    
    NITS:
    In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3.
    
    Section 2.7 Realm Name: s/that is MUST/that MUST/
    
    Section 6.1.9: s/list of commonly recommended/list of common recommendations/
    
    Something is wrong with this line in section 7.2
    (The line is unchanged from 3588, but if this is a bug, it should be
    addressed at some point). 
          <answer-message> ::= < Diameter Header: code, ERR [PXY] >
    That has either one too many or one too few commas in it.
    
    The following is a pedantic nit, but please consider addressing it.
    In several places (both in text from 3588 and new text introduced as
    part of this effort), the text refers to the definitions of commands
    in the representational language defined in section 3.2 as ABNF. For
    example:
       The Grouped Data field has the following ABNF grammar:
    
             Proxy-Info ::= < AVP Header: 284 >
                            { Proxy-Host }
                            { Proxy-State }
                          * [ AVP ]
    
    That is not ABNF. Instead, it is a well formed message in a language described
    by the ABNF in section 3.2. It would be better to say something like
    "The Grouped data field has the following Command Code specification:".
    
  8. Sean Turner: Discuss [2011-09-21]:
        #1) I'm confused by the following two statements:
    
    from abstract:
    
       The Diameter base protocol as defined in this document
       obsoletes RFC 3588 and must be supported by all new Diameter
       implementations.
    
    from s2.1:
    
       If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
       connections on port [TBD], i.e. the peer complies only with
       [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
       port 3868.
    
    from s13: 
    
       However, all Diameter base protocol implementations
       MUST support the use of TLS/TCP and DTLS/SCTP and the Diameter
       protocol MUST NOT be used without any security mechanism.
    
    If all new Diameter applications support the TLS/TCP an DTLS/SCTP, how is an
    application not going to support accepting TLS/DTLS connections on port [TBD]?
    Also in s2.1 would it really be the "initiator" or would it be "peers"?
    
    #2) s1.1.1 and s11.2.1: This section mentions 5729 as part of the document set,
    but 5719 (which updates RFCC 3588) isn't mentioned.  Are the contents of 5719
    included in this draft?  If so, shouldn't 5719 be added to the obsoletes header?
    
    #3) s2.2 and s13.1: I support Stephen's discuss position.  I guess I'd note the
    same fix needs to be applied to s2.2.
    
    #4) s2.6 and s2.7: What's the format for the expiration time?  MUST it be the
    format specified in 4.3.1 or is up to an implementation?  If it's the former, a
    pointer s4.3.1 is needed.
    
    #5) s1.3.4, s2.4, s3, s6.11: There's no application IDs in Section 11.3.  Is the
    section missing!?  RFC 3588 had a section for Application Identifiers in the
    IANA section - this draft does not.
    
    #6) s5.2 and 11.6: This draft needs to normatively reference
    http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ for the S-NAPTR
    application service tags 'diameter.tcp', 'diameter.sctp', 'diameter.tls.tcp'.
    They're not defined in the this document and they don't appear to be in RFC
    3588.
    
    #7) s6.1.2 and s3: s6.1.2 includes the following text:
    
       The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
    
    s3 contain the following text
    
       The sender MUST ensure that the Hop-by-Hop identifier in a request
       is unique on a given connection at any given time, and MAY attempt
       to ensure that the number is unique across reboots.
    
    don't these contradict each other?  Seems like in s6.1.2 r/SHOLD/MUST ? 
    
    #8) s11: If this document is obsoleting RFC 3588 shouldn't all the information
    found in RFC 3588's IANA section be included here?  If not an implementer is
    going to need to pull out RFC 3588 + 5917, doesn't it make much more sense to
    have one standalone document for implementers?
    
    #9) s11.2: The contents of the RFC 5719 IANA considerations are mostly included
    but the first paragraph isn't the same - should they be the same?
    
    #10) s13: The peer and routing tables use expiry time.  Certificates used in
    TLS/DTLS/IKE also contain expiry times.  I think a considerations that says
    something about checking to make sure the peer and routing table expiry times
    are never beyond the expiry time in certificates.  If you allow the expiry time
    to extend beyond the validity period in the certificate, it would be a bad
    thing.  If the connections are very short lived then it might not be big deal,
    but if they're long-lived then there's more to worry about.
    
    #11) 
    
    <process weenie>
    
    I'm hoping the answer to this is yes, but I had to ask because I didn't see it
    in the proto write-up:
    
    This document doesn't have a pre-5378 disclaimer and the author set is not the
    same as RFC 3588.  Have Erik and Pat granted the rights to the IETF Trust to
    allow the document to be published without the pre-5378 disclaimer?
    
    </process weenie> 
        
  9. Sean Turner: Comment [2011-09-21]:
    #1) s1, p 8: The following indentation seems to be off:
    
         In addition to addressing the above requirements, Diameter also
         provides support for the following:
    
       Capability negotiation
    
    I think it ought to be:
    
       In addition to addressing the above requirements, Diameter also
       provides support for the following:
    
       Capability negotiation
    
    #2) s1.1.3: It's probably worth noting that you incorporated the errata filed on
    RFC 3588.  Also, it seems like this version deprecates use of Application ID
    
    #3) s1.3.1 and s1.3.2: Should "recommended" be "RECOMMENDED".  2119 language
    hadn't been used until 1.3.3, so maybe it should be used in 1.3.1 and 1.3.2.
    
    #4) s2.1 and/or s12: For the Tc timer should it recommended be RECOMMENDED?
    i.e.,:
    
       r/recommended value is 30 seconds/RECOMMENDED value is 30 seconds
    
    #5) s2.4: Should "mandatory" be "REQUIRED":
    
       The base protocol does not require an Application Id since its support
       is mandatory.
    
    #6) s2.5: Need a period at the end of the following sentence:
    
       Additional security information, when needed (e.g., keys,
       certificates)
    
    #7) s2.7: Need a period at the end of the following sentence:
    
       See Section 6.1.9 for relaying guidelines
    
    #8) s2.7: Server Identifier must also appear in the peer table, but there's no
    server identifier listed in s2.6.  If server=host then that'd be good to say in
    s2.7.
    
    #9) s2.8.1 and 2.8.3: Are DRL, HSM, and DRD acronyms?  Not entirely sure.
    
    #10) s3: the reference for Command Codes in 11.3 is wrong.  I think it's
    supposed to be 11.2.
    
    #11) s3: Hop-by-Hop and End-to-End identifiers paragraphs should add a pointer
    to RFC 4086 for guidelines on randomness.  You could also just put a catchall
    sentence in the security considerations (I see there's one in 6.1.9 for keys).
    
    #12) s3.2: So this is a stupid question, but does the example add spaces?
    
      Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
    
    There's no space between "<" and "Diameter Header:" in the header ABNF or
    between "Diameter Header:" and the command-id.  There are between the r-bit,
    p-it, and e-bits.  ALso are there spaces needed in the ABNF for the "< ", " >",
    "{ ", " }", "[ ", and " ]" in fixed, optional, and qual?
    
    #13) s4.1.1: r/The AVP Header contains one optional field./The AVP Header
    contains one OPTIONAL field.
    
    #14) s4.1.1, 5.3.3, 5.3.6: The IANA Enterprise Numbers registry refers to RFC
    2578 and not RFC 3232.  Shouldn't the reference in the draft match the reference
    in the registry to help people find it?  Better yet add a reference to:
    http://www.iana.org/assignments/enterprise-numbers
    
    #15) s4.3.1: what no "aaas:" example? ;)
    
    #16) s4.4: Indentation of the following is odd:
    
                               grouped-avp-def  = <name> "::=" avp
    
    #17) s4.5: Are there really still space constraints?  The current table has a
    lot less columns than RFC 3588.  Maybe just put in an RFC editor note asking
    them to put the Attribute name all on one line.
    
    #18) s5.2: Name matching has proved to be a challenge for many in the TLS/DTLS
    environment.  A pointer to RFC 6125 would be much appreciated.
    
    #19) s5.2: r/Server CA/Server Certification Authority (CA)
    
    #20) s5.2.: Contains the following:
    
       Authorization can be achieved for example, by configuration of a
       Diameter Server CA.  Alternatively this can be achieved by definition
       of OIDs within TLS/TCP and DTLS/SCTP or IKE certificates so as to
       signify Diameter Server authorization.
    
    Is configuring the CA one option - but what's the alternative?  I think you mean
    to say that that:
    
       Authorization can be achieved for example, by configuration of a
       Diameter Server CA. The Server CA issues a certificate to the
       Diameter Server, which includes an Object Identifier (OID) to indicate
       the subject is a Diameter Server in the Extended Key Usage extension
       [RFC5280].  This certificate is then used during TLS/TCP, DTLS/SCTP, or
       IKE security negotiation.
    
    So I looked in the PKIX registry are there any actually defined?  If none are
    maybe add that none are defined at this time.
    
    #21) s5.3:
    
    r/ A Diameter node MUST cache the supported applications/ A Diameter node MUST
    cache the supported Application IDs ? 
     
    r/Section 7.)/Section 7)
    
    r/Host-IP- Address/Host-IP-Address
    
    #22) s6.1.9:
     r/is distribute/is distributed
     r/a keyed message digest (e.g., HMAC-SHA1) [RFC2104].
     r/commonly recommended:/common recommendations:
    
    Also need to add reference to RFC 2104
    
    #23) s5.3.1, s5.3.2, s5.4.1, s5.4.2, s5.5.1, s5.5.2. s8.3.1, s8.3.2, s8.4.1,
    s8.4.2, s8.5.1., s8.5.2, s9.7.1, s9.7.2: After reading s6.7.2 and s6.11, I
    wonder if the sections listed should also indicate that they are "of type
    grouped"?
    
    #24) s6.10: NOT RECOMMENDED is 2119 language you just have to add it to the 2119
    section.  I think what you're trying to say here:
    
       The use of this AVP in CER and CEA messages is no
       longer recommended.
    
    is
    
       The use of this AVP in CER and CEA messages is NOT RECOMMENDED.
    
    #25) s6.10: The reference for TLS is 5246, but for DTLS it's 6083.
    
    #26) s7.1.1 and s7.1.3: Should these sections indicate that they "MUST be used
    in messages whose 'E' bit is not set"?  I know it seems obvious, but I've seen
    people implement whacky things.
    
    #27) s7.5: r/A Diameter message SHOULD/A Diameter answer message SHOULD 
    
    #28) s7.7: r/It is recommended that/It is RECOMMENDED that 
    
    #29) s8.4.1, s8.4.2, s8.5.1., s8.5.2: "Message Type" indentation is off.
    
    #30) s8.8: OLD:
    
      Session-Id is delimited by a ";" character, and MAY be any sequence
      that the client can guarantee to be eternally unique; however, the
      following format is recommended, (square brackets [] indicate an
      optional element):
    
    NEW:
    
      Session-Id is delimited by a ";" character, and MAY be any sequence
      that the client can guarantee to be eternally unique; however, the
      following format is RECOMMENDED, (square brackets [] indicate an
      OPTIONAL element):
    
    #31) s8.9: r/Authorization- Lifetime/Authorization-Lifetime
    
    #32) s9.3: not sure the last para should be indented
    
    #33) s14: To avoid being Alfreded, reorder the RFC references to go from low to
    high.

draft-ietf-l2vpn-arp-mediation

  1. Jari Arkko: Discuss [2011-09-22]:
        I am reading the ND modifications and trying very hard to convince myself that
    they are correct and complete. I'm not 100% sure I've managed to do that.
    
    I scanned the mailing list for 6man and found no discussion of this draft. Did I
    miss it? Shouldn't relatively complex surgery on ND require some review from the
    experts on ND?
    
    I'm also wondering if the SEND proxy specification from CSI WG would be an
    applicable recommendation in addition to recommending turning SEND off. 
        
  2. Ralph Droms: Comment [2011-09-21]:
    In section 4.3.3, is "the link-layer address of the
    local AC" really "the link-layer address of the PE
    interface attached to the local AC"?
  3. Adrian Farrel: Discuss [2011-09-22]:
        I will move to a "Yes" ballot when my Discuss has been resolved.
    
    Why does this document include a redefinition of the Address List TLV
    that is already defined in RFC 5036? Although the text says that it is
    using the RFC 5036 definition, the text also says that the I-D defines
    the Address List TLV.
    
    Shouldn't you simply refer to 5036 and say how the fields are set for
    your specific use?
    
    Similarly the redefinition of the Notification message.
    
    To be clear, the main reason for objecting to the redefinition is that
    it opens the door to discrepencies, and makes it hard to handle
    future extensions. (Coders should be familiar with the practice of
    only defining data structures in one place :-)
    
    ---
    
    Please add some text to clarify whether the Stack Capability field   
    in the Stack capability Interface Parameter sub-TLV is an integer or
    a bit-field.
    
    The IANA section makes it look like a bit field (which is what I 
    would expect) but the text in the main body says...
    
         Stack Capability = 0x0001 to indicate IPv6 stack capability 
    
        
  4. ...which makes it look like an integer Additionally, the text goes on to imply that the interpretation of the field is context-specific... The value of Stack Capability is dependent on the PW type context. For IP Layer2 Transport type, a setting of 0x0001 indicates IPv6 stack capability.
  5. ...if this is the case, presumably, 0x0001 could mean something else in other circumstances. How is this tracked in the IANA registry?
  6. Adrian Farrel: Comment [2011-09-22]:
    Should the figure on page 5 include the label "AC3"?
                
    ---
    
    I agree with the other ADs who are concerned about the use or non-use
    of RFC 2119 language. Hopefully, this will be easy for you to clean up
    and will not be construed as changing the technical content of the
    document.
    
    ---
    
         The "IP Layer 2 interworking circuit" 
         pseudowire is also commonly referred to as "IP pseudowire". 
    
    Can you insert a reference for "IP pseudowire"?
  7. Stephen Farrell: Comment [2011-09-16]:
    - 8.1 says that you "can" secure the PE-PE control plane "using MD5
    authentication." Is that (still) the best that can be done? Doesn't
    it need a reference? Why can't something better be used, e.g. IPsec?
    Why no 2119 language? (This isn't a discuss because I hope that
    all that's in some other RFC.)
    
    - 8.1 says that this protocol is incompatible with SEND. I
    guess that's inevitable, but do you need to say more about
    the trade-offs concerned, e.g. would it ever be likely that
    a CE that depends on SEND is deployed and later on a PE doing
    this protocol is installed breaking the CE or changing its
    security properties in a bad way? (Just wondering.)
    
    - Frame Relay (FR) is expanded only on its 2nd use. 1st
    use is in 2nd para of section 1.
  8. Russ Housley: Comment [2011-09-21]:
      The Gen-ART Review by Peter McCann on 20-Sep-2011 raised a minor
      issue and two editorial suggestions:
      
      Section 5.2 says: "Since this notification does not refer to any
      particular message the Message ID and Message Type fields are set
      to 0."  There does not appear to be a Message Type field in the PDU.
    
      Section 5: suggest replacing the idiom "chicken and egg situation"
      with "possible deadlock situation."
    
      Section 5.2: "Section 6. below." should be "Section 6 below."
  9. Pete Resnick: Comment [2011-09-21]:
    1. This entire document needs a good "MUST/SHOULD/MAY vs. must/should/may"
    scrubbing. Just to cite two examples:
    
    4.2.2:
             
         When the PE learns the IP address of the remote CE, it should 
         generate an Inverse ARP request.
    
    It "should"? Or it "SHOULD"? Or it "will"?
    
    4.3.2:
    
         If a Router Discovery message contains a link layer 
         address, then the PE MAY also use this message to discover the 
         link layer address and IPv6 interface address.
    
    That MAY doesn't sound like a protocol option.
    
    2. Section 2:
    
         PEs MUST support ARP mediation for IPv4 L2 Interworking 
         circuits. PEs SHOULD support ARP mediation for IPv6 L2 
         interworking circuits.
    
    I assume this means "PEs that support ARP mediation MUST support it for IPv4 and
    SHOULD for IPv6". The way it is now, it sounds like ALL PEs must support this,
    which can't be right. That said, I see no reason for this paragraph. Mediation
    should be supported on both v4 and v6 circuits. I say drop the paragraph.
    
    3. For the record, and not something the authors need to address:
    
    I understand that the IETF doing sub-IP protocols is a ship that has sailed long
    before I got on the IESG. However, the mind boggles that we are deploying this
    particular protocol: Why can't we simply *route*?!?!? This protocol is standing
    on its head to allow layer 2 bridging of IP across disparate links instead of
    just having a routed VPN. This is goofy, it is a complete layer violation, and I
    don't think we should be standardizing this nonsense.
    
    There, I feel marginally better. :-/
  10. Peter Saint-Andre: Comment [2011-09-21]:
    This document appears to be predicated on "know[ing] that only IP traffic will
    be carried". How is this determined?
  11. Robert Sparks: Comment [2011-09-21]:
    Section 7.2 invokes an IANA well known policy of "IETF Consensus", referencing
    RFC5226, but that RFC has renamed that particular policy to "IETF Review".
  12. Sean Turner: Comment [2011-09-22]:
    I have the same question Stephen did about MD5.

draft-ietf-pwe3-mpls-tp-gal-in-pw

  1. Adrian Farrel: Comment [2011-09-22]:
    Thanks for discussing my Discuss.
    I am happy to move to "Yes" on this documnet,
    but encourage you to look at the comments.
    
    ---
    
    Section 1
    
       [RFC5586] defines a generalized label-based exception mechanism using 
       the Generic Associated Channel Label (GAL) to work together with the 
       ACH for use with LSPs but places restrictions on GAL usage with PWs.  
    
       This document removes the restriction imposed by [RFC5586]. 
    
    Please clarify one or more restrictions?
    
    ---
    
    Section 3
    
       This indicates that the GAL can be used for MPLS-TP LSPs and Sections, 
       but not for PWs using an MPLS-TP PSN. 
    
    What does it mean for a PW to use an MPLS-TP PSN?
    Perhaps...
    
       but not for PWs in an MPLS-TP network.
    
    ---
    
    Nits
    
    Title
    s/Pseudowire/Pseudowires/
    
    ---
    
    Abstract
    s/[RFC5586]/RFC 5586/
    
    ---
    
    Section 1
    s/associated control channel/Associated Channel/  (per RFC 5085)
    
    ---
    
    Section 1
    s/generalizes this for use in the/generalizes this for use as the/
    
    ---
    
    Section 3 para 1
    
    Delete "appropriate" or fix as suggested by Stephen
  2. Stephen Farrell: Comment [2011-09-16]:
    typo: s/architectures appropriate/architectures as appropriate/
    in section 3
  3. Dan Romascanu: Comment [2011-09-22]:
    OAM is defined in the terminology section but never used. I suggest to drop it. 

draft-ietf-trill-rbridge-af

  1. Ron Bonica: Comment [2011-09-20]:
    Please run the Nit checker over this document. Also, please make sure that the
    abstract and intro both reference the update correctly.
  2. Stewart Bryant: Comment [2011-09-21]:
    "If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored
    but any VLAN other VLAN IDs are still effective."
    
    I think that there are one too many "VLAN"s in the sentence.
  3. Dan Romascanu: Discuss [2011-09-22]:
        In Section 3: 
    
    >       It is safe to
             configure this inhibition time to the settling time of an
             attached bridged LAN. For example, if it is known that Rapid
             Spanning Tree Protocol (RSTP [802.1Q]) is running throughout
             the attached bridged LAN, it should be safe to configure this
             inhibition time to 4 seconds. 
    
    Why 4 seconds? Should not this value be 3 x Hello Timer which is 6 seconds?  
        

draft-ietf-marf-not-spam-feedback

  1. Adrian Farrel: Comment [2011-09-22]:
    Would be nice if the Abstract gave context by mentioning "email"
    
    ---
    
    Random thought: is there also a need for an ARF to report when a
    message has mistakenly been reported as mistakenly reported as spam?
    That would be a "not-not-spam report". This would seem to be necessary
    as you include the possiblity of a user accidentally pressing a "not
    spam" button.
    
    ---
    
       There are anti-spam systems that use "not spam" feedback today.
    
    Presumably, this is non-standard "not spam" feedback?
    
    ---
    
    Section 2
    
       In the first MIME part of the feedback report message, the end user
       or the email client can add information to indicate why the message
       is not spam -- for example, because the originator or its domain is
       well known.
    
    s/can/MAY/ ?
    
    ---
    
    Overall, I had trouble finding where in this document anything was 
    actually defined. I don't suppose that is really a problem, but it
    was a bit surprising.
  2. Peter Saint-Andre: Comment [2011-09-19]:
    To avoid endless philosophical debates about what is and is not spam, I suggest
    changing "Indicates that a message is not spam" to "Indicates that the entity
    providing the report does not consider the message to be spam" (or somesuch).

draft-ietf-mpls-tp-fault

  1. Russ Housley: Comment [2011-09-21]:
      The IPR statement from Ericsson is confusing to me.  See
      https://datatracker.ietf.org/ipr/1460/.  What does "option b)
      above" mean?
  2. Pete Resnick: Comment [2011-09-21]:
    Section 2.1:
    
       The MPLS Alarm Indication Signal (AIS) message is generated in
       response to detecting faults in the server (sub-)layer.  The AIS
       message SHOULD be sent as soon as the condition is detected, but MAY
       be delayed owing to processing in an implementation, and MAY be
       suppressed if protection is achieved very rapidly.
    
    Those "MAY"s aren't protocol options, they're exceptions to the SHOULD. How
    about instead, "The AIS message SHOULD be sent as soon as the condition is
    detected, with the obvious exceptions being delay owing to processing in an
    implementation or complete supression if protection is acheived rapidly."
    
       The primary purpose of the AIS message is to suppress alarms in the
       layer network above the level at which the fault occurs.  When the
       Link Down Indication is set, the AIS message MAY be used to trigger
       recovery mechanisms.
    
    Do you really mean "MAY" here, or rather "can"? Who are you telling that they
    MAY use the AIS message as the trigger, the implementer of the recovery
    mechanism (in which case it might be right) or others who need to be aware that
    recovery mechanisms might be triggered (in which case it is wrong).
    
    Section 2.2: Similar use of MAY as above. Please check.
    
  3. Dan Romascanu: Comment [2011-09-20]:
    Hopefully IANA knows what to do, but the note in Section 8.1 is not clear to me.
    
    >    [Note: An early codepoint allocation was made: 0x0058 Fault OAM
       (TEMPORARY - expires 2012-07-20)]
    
    Do the authors request to transform this temporary codepoint allocation to a
    permanent one?
    
    In any case the  Note needs to be taken out at document publication. 
  4. Peter Saint-Andre: Comment [2011-09-12]:
    Please specify whether the refresh timer can include fractional seconds.
    
    Please specify the byte order of the longer fields; typically this is network
    byte order (i.e., most significant byte first), but not always.
  5. Robert Sparks: Comment [2011-09-21]:
    Section 8.4 indicates that it will use the term "Private Use", but doesn't. It
    does use "Experimental Use" - should the first paragraph have called that out
    instead?

draft-ietf-websec-origin

  1. Wesley Eddy: Discuss [2011-09-13]:
        When section 4 says to return a "globally unique identifier", does it need to be
    generated based on the URI?  From the definition in section 2.3 it seems like
    you're supposed to just do a gensym, so it will be different every single time
    the origin is computed even for the same URI going through the algorithm at
    different times.  It wasn't clear to me if that was really the intent. 
        
  2. Stephen Farrell: Discuss [2011-09-16]:
        (1) cleared
    
    (2) Just saying "return a globally unique identifier" doesn't seem
    enough. I think what you need is a new identifier for each run of
    the algorithm. Section 5 depends on this, so you should say that in
    section 4. 
        
  3. Stephen Farrell: Comment [2011-09-15]:
    There are quite a few places where the language used here is
    difficult or problematic. I'd encourage the authors to consider
    including fewer words if possible - a lot of the descriptive
    material isn't really necessary and the document might be better
    without it. 
    
    - 2.2: "OWS SHOULD either not be produced or be produced as a single
    SP character." is a bit unclear. Why not say that user agents MUST
    be able to handle OWS as input, but SHOULD just produce a single SP
    on output?
    
    - 2.3: The definition of "globally unique identifier" is odd if you
    don't have some kind of hierarchy/registration scheme. I think all
    you need here is a low probability of collision and it'd be better
    to be explicit about that so that implementations don't choose
    over-short identifiers (not everyone understands the birthday
    paradox).
    
    - 2.3: a couple of examples of idna-canonicalized host names would
    help here if you have them. People might easily go wrong in the
    conversion otherwise given how many RFCs are referenced in the
    definition.
    
    - Section 3: I think it'd be good to point out here that there have
    been variations in what is called a "same origin policy" - referring
    to "*the* same origin policy" hides that issue.
    
    - 3.1: "Trust" is a horrible term when not qualified and tends to be
    interpreted differently by different people.  I think this'd be
    better if the term wasn't used at all.  Perhaps you could recast
    this section as "things for which URIs are used by UAs" and get rid
    of the word "trust" entirely, e.g. in the 1st example, the document
    author is assuming that the right content will be fetched when the
    script URI is de-referenced etc. 
    
    - 3.1: "execute the script with the privileges of the document"
    seems wrong - the document doesn't have privileges associated with
    it, rather the context in which the document is being rendered in
    the UA has associated privileges, granted by the user, UA and client
    OS. The term used could mislead someone into thinking that the
    document will always have the same privileges regardless of UA
    which'd be wrong.
    
    - 3.1: Saying "the document exports *its* secret data..." seems
    wrong - it's the user's secret, not the document's.  Saying the
    "document...trusts the confidentiality of information sent" also
    seems wrong.  
    
    - 3.1.1: What if relative URIs are used? Are you saying not to do
    that? Can't that be a (worse) pitfall?
    
    - 3.2: example.edu is not one of the example domains afaik.  (Maybe
    it ought be, but I don't think it is.)
    
    - 3.3: The term authority is being defined here with a novel
    meaning. I think you need to call that out in section 2.3. I also
    wonder at the definition. Saying that an image is passive seems
    wrong (.wmf, .tiff etc have all seen vulnerability reports) and
    it seems to wrongly conflate the media type with the privileges with
    which the UA renders the content. Section 3.4.2 also seems to argue
    against associating privileges with media types and says that one
    should associate them with origins. This is fairly confused stuff.
    
    - 3.5: You could/should drop the word "trust" as per the comment
    above.
    
    - section 4: typos: "Other user agent use a globally unique
    identifier each file URI, which is the most secure option." above
    IMO." s/agent/agents/ & s/each file/for each file/
    
    - 3.3: typo "User agent determine" s/agent/agents/
    
    - section 4, last para: I see no point in saying "Implementations
    MAY define other types of origins" without saying what those might
    be in sufficient detail that two implementations (of this spec)
    would do the same thing. Suggest getting rid of the paragraph.
    
    - section 4: It seems to me that you don't actually need global
    uniqueness at all but rather just local uniqueness in the scope of a
    single "run" of the UA. I don't object to being OTT in this respect
    but it'd be better if you made it clear that even though you only
    need local uniqueness right now, you're asking for more than that,
    just in case.
    
    - 7.1: I don't get why you have section 6 define how to serialise
    but then don't use that in the syntax here.  That is, the "://"
    catentation is re-done in 7.1.
    
    - 7.2: Why say "might wish to" and not MAY here? If >1 origin is
    involved and a UA is going to send out an Origin header, then I
    don't get why there isn't a MUST for including all origins.
    
    - section 8: references for taint-tracking and exfiltration would be
    good - those are not common terms.
    
    - 8.2: "NOT RECOMMENDED" is missing from 2119 unfortunately.
    
    - 8.2: typo s/domain a function/domain is a function/
    
    - 8.2 - what URI scheme uses public keys for naming authorities?
    Giving an example of a registered scheme that does that would 
    be good.
    
    - 8.2 - typo: s/at worse/at worst/
    
    - 8.3: "objects which the content is able to designate" is hard to
    understand or meaningless. I'm not quite sure what you do mean
    exactly though. The entire section is hard to understand actually.
    
    - Section 10: the section header could be deleted since only 10.1
    has content.
  4. Russ Housley: Comment [2011-09-21]:
      The Gen-ART Review by Miguel Garcia on 5-Sep-2011 raised a few minor
      concerns, and they were addressed by the authors.  However, a new
      version of the document with the suggested changes gas not been 
      posted yet.
  5. Pete Resnick: Discuss [2011-09-18]:
        Unlike other contexts, it seems to me that when it comes to matching origins,
    false positives are much worse than false negatives: The harm of false positives
    is that items will cross security contexts, hence compromising security, whereas
    false negatives simply mean that certain entities will not be able to request
    data on behalf of others. So, if two host names do not match because the hosts
    in question were using different versions of IDNA, or because a host name is not
    a valid label, better that they don't match rather than they do. So, I'm
    guessing you don't need to do any reference to RFC 3490 at all. Specifically:
    
    Section 2.3 - In the definition of idna-canonicalized, I don't think you care if
    the labels are in fact NR-LDH labels or A-labels. If someone presents you with
    an all ASCII string, you'll lowercase it and use it for comparison, and if
    someone presents you with a string with non-ASCII-range Unicode, you'll want to
    punycode it and turn it into an ASCII string, even if it isn't a valid NR-LDH.
    But even if you do want valid NR-LDH labels, I think it would be actively bad to
    allow for 3490 NFKC canonicalization, because it would allow things to compare
    as identical that I'm guessing you really don't want, especially in this
    security context. So I think the choices are:
    
    a) If you're willing to allow more false negatives, simply say, "If the label
    contains any non-ASCII-range Unicode characters, encode it with the algorithm
    defined in RFC 3492 section 6.3 and prepend 'xn--' to it, otherwise use the all-
    ASCII label." And don't call it "idna-canonicalized", but instead call it "us-
    ascii-encoded".
    
    b) If you're wanting to do some canonicalization, simply say, "If the label
    contains any non-ASCII-range Unicode characters, first normalize the string
    using NFC, and then encode it with the algorithm defined in RFC 3492 section 6.3
    and prepend 'xn--' to it, otherwise use the all-ASCII label."
    
    I can find others to help tighten up the language if you go down this path.
    
    Section 6.1 - There is no "ToUnicode" algorithm RFC 5891, so at the very least
    the paragraph is written incorrectly. But much of the 3490 ToUnicode algorithm
    is validating the label. I don't think there's a need to do the validation in
    this document. (Remember, if there are invalid *ASCII* host name labels -- like
    "example_host" -- the algorithm is not going to catch those, but nobody cares
    because it will only match another identical invalid label.) I would simply say:
    "For each label in the host part of the origin triple, if the label begins with
    "xn--" and the remainder of the label can be successfully decoded using the
    algorithm defined in RFC 3492 section 6.2, append the resulting Unicode label to
    the results. Otherwise, append the original label (including the "xn--", if any)
    to the results. Separate the labels with U+002E FULL STOP code points (".").
    
    Section 10.1 - If the above two changes are made, this section can be
    eliminated. 
        
  6. Pete Resnick: Comment [2011-09-18]:
    Section 2.3 - It seems like "globally unique identifier" and "idna-canonicalized
    host name" are better defined where they are used, especially since the latter
    is an algoritm and not really a definition of terminology.
    
    Section 5 - 
    
       o  Two origins that are globally unique identifiers cannot be the
          same if they were created at different times, even if they were
          created for the same URI.
    
    Does "at different times" mean "in different HTML documents"? In other words,
    can't two identical URIs appearing in the same HTML match without worry of
    security problems?
  7. Sean Turner: Discuss [2011-09-22]:
        s3.1.1 points out that using RFC2617 could be problematic.  Is it worth
    deprecating it's use?  If that's a step to far adding something like "it is NOT
    RECOMMENDED that new protocols use concepts from [RFC2817]"? 
        

draft-eggert-successful-bar-bof

  1. Jari Arkko: Discuss [2011-09-22]:
        A horrible error on your otherwise excellent draft:
    
    > Anecdotal evidence exists that at least one Area Director has not
    > been able to set foot outside the IETF hotel for a stretch of several
    > days during IETF-77.
    
    A week. A full week. I think they let me out on Thursday evening, though. And I
    saw the sun for the first time on Friday. And why do you pick on Anaheim?
    
    Seriously though I do have a more serious issue. I agree with the thrust of the
    draft, of course, but I think it is written from a very typical IESG perspective
    where we try to prevent <horrible thing> from happening. But our role is not
    just to prevent bad things from happening, its also make good things happen. And
    I would argue that the draft misses some aspects of the problem from the point
    of view of the bar BOF folk when it tries to focus on the location of the
    meeting.
    
    My main issue is that other than giving advice on where to meet, the draft says
    very little on how to go about making a successful bar BOF. The specifics of the
    meeting itself are just one aspect.
    
    1) If you are an AD, chair, or key engineer at an important company, you will
    have trouble even finding the other people to talk to. Part of the reason why
    people come to the IETF meeting is to have side meetings. We should make it easy
    for them, but for many people it will be difficult to get started, even if they
    have an issue of their own. The working group is too busy and they follow their
    charter, so you don't get time on the agenda. You can't broadcast your desire to
    talk about the topic, you won't find the additional people.
    
    I would like to suggest that the document be changed to recommend that its OK to
    broadcast in the WG meeting (if you get a slot) or on the mailing list that you
    are interested to talk about a particular topic, please contact such and such.
    And *then* you can have that bar BOF. Positive description of what the guys need
    to do, not just forbidding them to meet in the current way.
    
    2) Coming up with new ideas, finding other people to talk to are key benefits of
    an IETF meeting. The document should more clearly stat that this is a desirable
    activity. Now it comes across a bit negative. E.g.:
    
       "... organizers
       should consider the value of holding side meetings at venues where
       such input can be more easily gathered."
    
    3) 
    
    > Finally, some organizers may find
    > the process to apply for an official BOF too complex, and so decide
    > to simply mimic one.
    
    But it *is* too complex, almost unbearably unlikely to result in a granted BOF.
    And that is not just the fault of the BOF organizers, we are to blame, too.
    Perhaps mostly us.
    
    I think the draft should honestly state something about the current BOF
    processing being difficult. 
        
  2. Jari Arkko: Comment [2011-09-22]:
    
        
  3. Stewart Bryant: Comment [2011-09-19]:
    To comment on Stephen's comment about the use of the term "bar bof". The
    traditionalist in me prefers to retain that term since it goes back to the
    origins of the IETF. However I am conscious that the term "bar bof" may well be
    a cultural issue for some folks. As such it would be good to find a term that
    was not synonymous with alcohol, but was somewhat more colorful and descriptive
    than "side meeting". Unfortunately no such term springs to mind.
  4. Wesley Eddy: Comment [2011-09-11]:
    It may be worthwhile to give some tips on inviting (or not inviting) area
    directors to your "side meeting" / bar-BOF.
    
    It should say that this isn't necessary, and may not even be advisable in many
    cases.  Some groups need time to form before they're ready with anything
    cohesive, and a side-meeting is a good time to establish that BEFORE approaching
    ADs and describing proposals.
    
    It should be clear that if an AD attends a side-meeting, it is not necessarily a
    show of support.  They may simply be interested, or often may be concerned or
    troubled with some aspect of the potential work and relation to existing work
    As the side-meeting may be in early stages of developing a viable WG or BoF
    proposal, there are likely to be many such concerns.
        
  5. .
  6. Adrian Farrel: Discuss [2011-09-22]:
        I wanted to ballot "Yes" and move ahead with this document as a useful
    piece of guidance. I certainly don't want to spend time over-polishing.
    
    However...
    
       Thus, the fact that a Contribution is made at one of the side
       meetings or other "unofficial" or "semi-official" events described in
       this document does not change or limit the applicability of the
       IETF's IPR rules.  If you have a question regarding the applicability
       of the IETF IPR rules in any specific context or to any specific
       activity, you should consult your attorney or make an inquiry to the
       IESG.
    
    This is not helpful. It is true that nothing changes the IETF's IPR
    rules. But that doesn't say whether the IETF's IPR rules apply to 
    "side meetings".
    
    Where does the concept that side meetings are "semi-official" come from?
    I thought the whole thrust of the document was to say that side meetings
    are not official in any way. Indeed the Abstract says it wants to 
    "stress the unofficial nature of these get-togethers."
    
    I think we can make a more significant pronouncement in this document,
    but if you want it to come from the IESG then I think the whole of 
    Section 6 should be replaced with a note that the IESG are to be
    consulted about the applicability of the IETF's IPR rules to side
    meetings.
    
    In particular, I take objection to...
    
       Informally, the above makes it appropriate, in order to provide a
       pointer to the relevant policies, to announce the "Note Well" text
       [NOTEWELL] in all such meetings.
    
        
  7. ...because this is clearly not the case. Indeed, it is absurd that if I go to lunch with two other people during the week of the IETF meeting when we all happen to be registered for the meeting that we are covered by the Note Well. Maybe you would like this included in all menus in all restaurants within a 10 mile radius? And anyway, if you are defering to the IESG on this matter, it is not correct for you to make this statement.
  8. Stephen Farrell: Comment [2011-09-12]:
    1) I'm not won over to the idea of discouraging the term "bar bof"
    generally. I do think we should distinguish those from side-meetings
    held as if they were formal wg sessions though and we should discourage
    the holding of the latter kind of meeting. So, I'd suggest changing
    the last sentence of the abstract to say something like:
    
      "This document recommends that the community use
       the term "bar BoF" exclusively to refer to side
       meetings that are held in bars and the like and
       to abandon the use of the term for meetings that
       are held in more formal settings such as IETF 
       meeting rooms."
    
    (2) The same change as (1) would be needed in the intro, 2nd
    last para.
    
    (3) I think the IETF LC discussion about IPR should result in
    some change to section 6, depending on where that goes. I 
    reckon that a good outcome to that might be that the Note Well
    ought be popped up for side-meetings in IETF meeting rooms
    but not otherwise.
    
    (4) I think Wes' suggestion about AD attendance is worth
    adding.
    
    (5) People have been known to forget their laptops after
    extended bar BoF sessions in real bars. That could be added
    to the security considerations.
    
    (6) I guess the Trilogy project may be finished now, so you
    may want to change the tense of the ack.
    
  9. Dan Romascanu: Discuss [2011-09-22]:
        1. I agree with Jari's points in his DISCUSS. The current document seems to be
    too negative about making of the IETF meetings an opportunity to have people
    meet and discuss new work in the IETF. I believe that we need text that makes
    clear that this is not the intention.
    
    2. I believe that the document needs to describe in a more balanced manner the
    different options of meeting to discuss new work. The principal thing in my
    opinion is to make clear that approving a room if available for side meetings
    needs not be read in any way as an endoresement of the work, but this should be
    a valid option
    
    3. I find much of section 3 (where to meet) problematic. On one side the text
    acknowledges the problem many non-native English speakers have understanding
    native English speakers (and the other way actually) but encourages them to go
    and meet in bars and restaurants provided they are not too noisy! The point
    should be IMO - meet wherever and however you believe you can discuss in the
    best conditions, here are the options, we are here to help.
    
    4. I would like to raise the point made by Wesley to a DISCUSS. At least we
    should discuss whether text is needed saying that the participation of the ADs
    (and maybe also of the IAB members) in side meetings should not be read as an
    endorsement of any kind, and that their participation is not useful because of
    the positions they hold, as side meetings are not part of any formal process. 
        
  10. Peter Saint-Andre: Comment [2011-09-12]:
    I very much like this document.
    
    I think it would be helpful to cite RFC 5434 as early as possible in the
    document. I suggest adding a parenthetical statement to Section 1:
    
       New IETF work often fits into an existing working group
       and does not require an official "birds of a feather" (BOF) session
       to determine community consensus (for more detailed information
       about BOF sessions, see [RFC 5434]).
    
    In Section 3:
    
    s/much more ineffective/much less effective/
    
    Perhaps make this change in Section 4:
    
    s/too complex/too complex or troublesome/
    
    There is a typo in Section 4:
    
    s/a certain procedures/certain procedures/
    
  11. Robert Sparks: Discuss [2011-09-21]:
        The list conversation on the "Applicability of IPR Rules" section does not
    appear to have concluded. I plan to move to YES on this document once that
    conversation completes. 
        
  12. Robert Sparks: Comment [2011-09-21]:
    The authors indicated they would make several changes based on last call
    comments (on -06), but that revision is not yet available.
  13. Sean Turner: Comment [2011-09-22]:
    1) I support Jari's comment #1.  I think people ought to be able to spam the
    community asking if there are people interested in topic X and then from those
    that respond try to set up the unofficial meeting (bar BOF/side-meeting).  I
    think that's different than spamming lists saying we're having a meeting in room
    z at 9pm that happens to conflict with the plenary.
    
    2) I'm also not entirely sold on the need to abandon the term "bar BOF".
    
    3) I wholly agree with Wes' comment about the AD attendance not necessarily
    being a good sign.  It might be worth adding that folks who ask an AD if they're
    coming shouldn't feel bad if the AD says "no" because it's not a sign of support
    or disapproval.  I've had to tell people that just because I wasn't going to
    make it that's okay to proceed because it's not an official meeting.

draft-kivinen-ipsecme-secure-password-framework

  1. Jari Arkko: Discuss [2011-09-22]:
        This is a well written document and I understand the reasons why it came to be.
    I do have one discuss-level issue with the description of EAP, and a comment-
    level opinion about this direction of the work for IPSECME.
    
    The discuss-level issue is that Section 1 seems to be saying that EAP is
    asymmetric and that it is tied to AAA:
    
       ...
       the asymmetric nature of the EAP does not matter
       ...
    
       ...
       The new secure password methods are meant to be used in cases where
       such back-end AAA-infrastructure does not exists.  An example of such
       case could be authentication between two servers or routers.  These
       scenarios are usually symmetric: both peers know the shared secret,
       no back-end authentication servers are involved, and either end can
       initiate an IKEv2 connection.
       ...
    
    EAP is indeed asymmetric, but so is IKEv2, even the extensions defined in this
    draft use different content in the messages from the initiator and the
    responder.
    There is no reason why an EAP method would have to be asymmetric;
    EAP-GPSK
    for instance could be invoked from either end, based on which direction
    the IKEv2
    initiation went.
    
    Similarly, there is no requirement that AAA be used to make a remote
    authentication
    decision. Implementations can decide to execute the EAP method
    locally.
    
    I'd like to change Section 1 text a bit to make this clearer. For instance:
    
       ...
       the asymmetric nature of the EAP does not matter
       ...
    
       ...
       The new secure password methods are meant to be used for example
       with the authentication between two servers or routers.  These
       scenarios are usually symmetric: both peers know the shared secret,
       no back-end authentication servers are involved, and either end can
       initiate an IKEv2 connection. Note that such model could also be
       supported by EAP when an EAP method that can run in symmetric
       fashion is in use, and the EAP method is directly implemented on both
       peers and no AAA is in use.
       ... 
        
  2. Jari Arkko: Comment [2011-09-22]:
    This is a comment about the direction of the work in the IPSECME working group.
    I understand that I'm in the rough on this, we already debated it at the time of
    the charter being extended.
    
    But I think we chose the wrong direction ,and the problem is only amplified
    because the working group could not agree on a single password method. We are
    creating new authentication method negotiation frameworks, and adding those as
    alternatives in the base IKEv2 exchange. I don't think this will improve
    interoperability in the long term. I would have chosen to specify small set of
    new symmetrically operable EAP methods and used the already existing exchanges.
    The chosen direction will cause IKEv2 implementations to become more complex, as
    many implementations need to support multiple use cases and therefore in
    practice support all the authentication frameworks. And if some day we decide to
    extend configuration support in devices with the new functionality so that
    shared secret configuration could take place centrally, we'll end up replicating
    AAA support in addition to the IKEv2 extensions defined here.
  3. Stephen Farrell: Comment [2011-09-22]:
    - I don't get the point about the specific methods - do they or do
    they not use the formats defined here? If not, why not? If so, the
    last sentence of the 1st para of the intro is v. confusing.
    Do the 3 experimental proposals actually use the values being
    registered here? Only one of them (draft-shin...) seems to
    reference this draft. Colour me confused.
    
    - Is it ok for an informational doc to add to these registries?
    
    - abstract has typos: 
    	s/add new one/add any new ones/
    	s/in current connection/in the current connection/
    
    - Intro
    	s/and working group/and the working group/
    	s/get pick/pick/
    	s/make implementation/make an implementation/
    	s/a payload formats/payload formats/
    	s/co-exists/co-exist/
    
    That's getting tedious. It badly needs an editorial pass.
    

draft-weil-shared-transition-space-request

  1. Stewart Bryant: Discuss [2011-09-21]:
        The authors state that there are no security issues because no protocol is
    defined. However the last para of section4
    instructs certain filtering
    operations and indicates that under some circumstances these filtering
    operations may be relaxed. That is a type of protocol action which I would have
    expected to be considered from a security perspective.
    
    I wish to discuss the following on the IESG call. At the moment there is no
    action for the authors.
    
    I share Wesley's concern that this address space will just be used as yet more
    generic NAT space. If the space is to be used for the IPv6 transition it would
    be better if it were normatively bound to a set of named transition mechanisms. 
        
  2. Wesley Eddy: Discuss [2011-09-16]:
        I don't plan to hold this DISCUSS past the telechat.
    
    This document says the prefix will be used to support IPv6 transition and
    coexistence with IPv4.
    
    I think it has little or nothing to do with IPv6, at least based on the text and
    cited documents.
    
    Most (or all) of the rationale really seems to be contained in draft-bdgks-arin-
    shared-transition-space.  Looking at that document makes it seem like the
    motivation really boils down to this new space supporting all sorts of IPv4-only
    ISP concerns without direct links to IPv6 transition (sections 3.1 through 3.5
    have nothing to do with transition), but it will "free up time" for operators to
    think about transition (section 3.6).
    
    The policy statement actually makes it pretty clear that this is more about IPv4
    extension than transition:
       A second contiguous /10 IPv4 block will be
    reserved to facilitate
       IPv4 address extension.  This block will not be
    allocated or assigned
       to any single organization, but is to be shared by
    Service Providers
       for internal use for IPv4 address extension deployments
    until
       connected networks fully support IPv6.  Examples of such needs
    include: IPv4 addresses between home gateways and NAT444 translators.
    
    I suspect many people will use this prefix without spending any time thinking
    about IPv6 or working on transition.  I suppose there's no way to tie the use of
    this prefix to only operators that are also running some form of IPv6 trial or
    operational service.
    
    I think the title and text using "shared transition space" terminology are
    misleading.  It should really be called what it is: "additional NAT space",
    "additional IPv4 private addresses", or something similar.  I feel like we're
    only pretending that it has something to do with IPv6 to make it more palatable. 
        
  3. Adrian Farrel: Comment [2011-09-22]:
    I support the many Discusses raised by other ADs and do not feel the
    need to raise any more Discuss issues myself.
    
    I find myself strongly disagreeing with the statement that service
    providers do not have the ablity to influence the rate of replacement
    of deployed customer equipment. Firstly, the availability of native
    IPv6 services is a prerequisite for anyone bothering to upgrade - this
    is clearly in the hands of the service providers and remarkably little
    effort has been made to provide such services. Secondly, a large 
    proportion of home routrs are supplied via the service providers as
    part of the sign-up deal - these have become almost as replacable as
    moble phones. Thirdly, I would point to the tansition from analogue to
    digital terestrial TV in some countries - a change that has been forced
    on the consumer in a relatively short period (albeit with regulatory
    backup) and which has obsoleted the installed base of far more expensive
    customer equipment.
    
    In effect, ts document would be far more likely to get a smooth passage
    if it did not try to give reasons or excuses, but simply said what is
    required and for what purpose.
  4. Stephen Farrell: Comment [2011-09-13]:
    - Wouldn't it be useful to note that this UPDATEs 1918?  Just so that
    people going there for the bogon list get to find out about the new
    allocation as well?
    
    - What is the exception for rule that packets with these addresses as
    source or destination  "SHOULD NOT be forwarded" across interdomain
    links? Clarifying that would be useful.
    
    - Why is filtering routing information for these addreses on ingress
    links not a MUST? Put another way, what's the exception to the
    SHOULD rule? Clarifying that would be useful.
    
    editorial:
    - abstract missing a "." at the end
    - expand acronyms on 1st use: CGN, CPE
    - capitalisation is inconsistent for "Infrastructure Provider" and
    "Shared Transition Space"
    
  5. Russ Housley: Discuss [2011-09-21]:
          RFC 1918 is a BCP.  Should this allocation really take place without
      achieving a similar level of IETF consensus? 
        
  6. Pete Resnick: Discuss [2011-09-21]:
        I agree with Wes's DISCUSS. This has nothing to do with IPv6 transition. This is
    a new special-use NAT address space. In particular, though I understand that
    much of the justification for this is in draft-bdgks-arin-shared-transition-
    space, I think this document at least needs to explicitly say that the
    requesters have actual knowledge that there are uses for this address space
    (e.g., using it on the "outside facing" interface of current NATs) that will
    fail miserably if current 1918 space (either 10/8, 172.16/12, or 192.168/16) is
    used. If this is simply a guess that too many things will break, I'm not as
    happy about going forward with the allocation. If it is actually known that
    things will break, the document should say that. 
        
  7. Pete Resnick: Comment [2011-09-21]:
    I agree with Russ's DISCUSS (as does IANA apparently).
    
    It seems to me that the IAB should weigh in on this document.
  8. Peter Saint-Andre: Comment [2011-09-12]:
    I suggest changing "heritage" to "legacy".
  9. Robert Sparks: Comment [2011-09-21]:
    I share Russ' question about documenting the same level of consensus as 1918.
  10. Sean Turner: Discuss [2011-09-22]:
        1) I'd like to see some more text after the following sentence:
    
       Reverse DNS queries for
       Shared Transition Space addresses MUST NOT be forwarded to the global
       DNS infrastructure.
    
    Maybe something like:
    
      This is done to avoid having to set up something similar to AS112.net for
       RFC 1918 private address space that a host has incorrectly sent for a
       DNS reverse-mapping queries on the public Internet [RFC6304].
    
    I'd really hate for this to lead to an expansion of that "fix" (or maybe I'm
    totally misunderstanding what you're asking for).
    
    2) The secdir review pointed out the following:
    
      Following up on draft-bdgks, the current document should at least
      advise on (and better yet, mandate solutions for) "best practices
      associated with the use of this space, including considerations
      relating to filtering, routing, etc.".
    
    Can something be added to address this?
     
        
  11. Sean Turner: Comment [2011-09-22]:
    1) I support Stewart's discuss.
    
    2) I support Russ' discuss.
    
    3) I support Wes' (and Pete's) discuss.

draft-irtf-asrg-bcp-blacklists

  1. Stephen Farrell: Comment [2011-09-22]:
    I agree with the other discusses to date
  2. Russ Housley: Discuss [2011-09-21]:
        
      This document is not a BCP, yet it claim to document "best practices",
      Should the IESG ask the IRSG to chose a phrase that will have less
      likelihood of being confused with a BCP? 
        
  3. Dan Romascanu: Comment [2011-09-22]:
    I support Russ's DISCUSS. 
  4. Peter Saint-Andre: Comment [2011-09-21]:
    Overall I think this is a helpful set of guidelines. Herewith a few comments.
    
    1. I concur with the DISCUSS from Russ Housley. Note that Sections 1.2 
    and 3.6.1 include the term "BCP".
    
    2. The abstract states:
    
       This document is a product of the Anti-Spam Research Group and
       represents the consensus of that group.
    
    Section 1.4 states:
    
       NOTE:  This document is a product of the Anti-Spam Research Group
          (ASRG) of the IRTF.  As per section 3 of [RFC2014] IRTF groups do
          not require consensus to publish documents.  Therefore readers
          should be aware that this document does not necessarily represent
          the consensus of the entire ASRG.
    
    Those two statements appear to be in conflict.
    
    3. With regard to DoS attacks, consider adding a reference to RFC 4732.
    
    4. The security considerations seem a bit thin to me given that DNSBLs 
    are used in ways different from "normal" DNS servers (e.g., RFC 3833 talks
    about denial of service attacks on DNS servers, but not malicious use of
    DNS-based services to poison the behavior of email servers and the like).
    
    5. Please expand relevant acronyms on first use and provide appropriate 
    citations (e.g., "IRC").

draft-irtf-hip-experiment

draft-irtf-hiprg-dht