IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2010-08-12. These are not an official record of the meeting.

Narrative scribe: Susan Hares (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. Spatial Composition of Metrics (Proposed Standard)
    draft-ietf-ippm-spatial-composition-15
    Token: Lars Eggert
    Note: Henk Uijterwaal (henk@ripe.net) is the document shepherd.
    Discusses/comments (from ballot 2131):
    1. Ron Bonica: Discuss [2010-08-09]:
      two downrefs
    2. Stewart Bryant: Discuss [2010-08-09]:
      The term "Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i]" is very confusing.
      Similarly the term Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream metric is confusing.
      The term FiniteDelay is not defined in this doc and I could nor see it in RFC2679
      Similarly I do not see definitions for MeanDelay or CompMeanDelay or MinDelay*
      I cannot parse the ASCII maths that is used to calculate Type-P-Composite-One-way-pdv-refmin-quantile-a
    3. Stewart Bryant: Comment [2010-08-09]:
      I found this draft very difficult to read. In part this is the authors terse style and in part this is because of the constraints placed on the authors by the use of ASCII text to express mathematical concepts.
      "Type-P-Finite--Composite-One-way-Delay-Minimum," looks like a typo "--"
      The term "ground truth" is used, but I could not see a definition or a reference.
      A reference should be provided for the derivation of the measurement of "Type-P-One-way-pdv-refmin-Skewness"
    4. Dan Romascanu: Discuss [2010-08-09]:
      id-nits complains about RFC 2330 and RFC 5835 being downrefs. The PROTO write-up mentions something about the framework document (actually they are two) being rather Normative References, and I am OK with this line, but the IETF Last Call did not explicitely call the downrefs.
    5. Dan Romascanu: Comment [2010-08-09]:
      The OPS-DIR review by Benoit Claise made a number of useful editorial comments which I suggest to be considered.
    6. Sean Turner: Comment [2010-08-11]:
      Should the must in the following be MUST? "Passive measurement must restrict attention to the headers of interest."

    Telechat:

  2. Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (Proposed Standard)
    draft-ietf-manet-nhdp-14
    Token: Stewart Bryant
    Note: Ian Chakeres (ian.chakeres@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3360):
    1. Ralph Droms: Comment [2010-08-11]:
      In section 2, I don't understand the definition of "interface". Why not use the definition from RFC 2460?
      Section 4.1: what is "an address represented by a network address"? I don't understand the uniqueness properties defined in the first bullet.
      Section 4.2: would it be more correct to write that the Information Bases "describe the state of the protocol in a node"?
      In section 10.1, I don't understand "A HELLO message which is transmitted periodically SHOULD contain, and otherwise MAY contain [...]"; does it mean that a HELLO message that is not transmitted periodically "MAY contain"?
      Section 18: s/repository/registry/ ?
    2. Sean Turner: Discuss [2010-08-11]:
      The proto write-up did not identify the DOWNREF to RFC 5148 in 1.h/8. A second IETF LC is necessary to call this DOWNREF out.

    Telechat:

  3. DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers (Proposed Standard)
    draft-ietf-behave-dns64-10
    Token: David Harrington
    Discusses/comments (from ballot 3379):
    1. Tim Polk: Discuss [2010-08-12]:
      I have some concerns regarding the impact on DNSSEC aware clients. Is expecting these systems to be translation-aware practical? I noticed the writeup mentioned the need for the DNS directorate review, but my review of the dns-dir archives did not turn up a review. If the DNS directorate has reviewed this document and supports publication I will clear.
    2. Sean Turner: Comment [2010-08-11]:
      Some minor nits

    Telechat:

  4. Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (Proposed Standard)
    draft-ietf-behave-v6v4-xlate-stateful-12
    Token: David Harrington
    Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd.
    Discusses/comments (from ballot 3381):
    1. Alexey Melnikov: Comment [2010-08-11]:
      3.4. Determining the Incoming tuple
      "The NAT64 MUST handle fragments. In particular, NAT64 MUST handle fragments arriving out-of-order , conditioned on the following:"
      "* The NAT64 MUST limit the amount of resources devoted to the storage of fragmented packets in order to protect from DoS attacks."
      I think these 2 requirements are slightly in conflict, as an implementation claiming compliance can claim to never have resources, which means that support for fragments is truly optional.
      3.5.1.1. Rules for Allocation of IPv4 Transport Addresses for UDP
      "In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but MAY be in use in"
      MAY here is not an implementation choice, so the use of MAY is not appropriate. I suggest changing this to "can".
      "the other BIB (referring to the UDP and TCP BIBs)."
      s/UDP/ICMP ?
    2. Peter Saint-Andre: Comment [2010-08-11]:
      1. Please provide an informational reference to RFC 5245 for ICE, and expand the term on first use.
      2. Please provide an informational reference to RFC 5389 for STUN, and expand the term on first use.
      3. Among the contributors, Simon Parreault's last name is in fact Perreault.

    Telechat:

  5. IPv6 Addressing of IPv4/IPv6 Translators (Proposed Standard)
    draft-ietf-behave-address-format-09
    Token: David Harrington
    Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd.
    Discusses/comments (from ballot 3382):
    1. Ralph Droms: Comment [2010-08-11]:
      Minor comment ... the name "Well Known Prefix" seems underspecified;
    2. Alexey Melnikov: Discuss [2010-08-07]:
      DISCUSS DISCUSS: I want to make sure that this document is consistent with [approved for publication] draft-ietf-6man-text-addr-representation.
      Also, should the document be updated to use lowercased hex digits (as per Section 4.3 of draft-ietf-6man-text-addr-representation) in example addresses?
    3. Tim Polk: Comment [2010-08-11]:
      The PL row in Figure 1 includes superfluous lengths 112 and 120 bits.

    Telechat:

  6. IPv6 Traffic Engineering in IS-IS (Proposed Standard)
    draft-ietf-isis-ipv6-te-07
    Token: Stewart Bryant
    Discusses/comments (from ballot 3383):
    1. Stewart Bryant: Comment [2010-08-11]:
      The following comments were made during Routing Directorate review. The authors have agreed text with the reviewer that addresses these issues.
    2. Adrian Farrel: Discuss [2010-08-11]:
      Please make the changes agreed after Routing Directorate review by Tomonori Takeda, expecially the change wrt the deprecation of site-local addresses.
    3. Adrian Farrel: Comment [2010-08-11]:
      A number of acronyms are used without expansion.
      It would probably be proper for Section 5 to include a pointer to RFC 5304 for general security considerations for IS-IS.
      Are you sure the authors don't want to change their affiliation?
    4. David Harrington: Discuss [2010-08-10]:
      1) there are numerous places where "this TLV" is used, and sometimes the reference is ambiguous. I recommend spelling out the TLVs by name.
      2) 3.2.3 says a new TLV is needed to build a Neighbor Address TLV, but never says WHY another TLV is needed. As far as I can tell, there needs to be a mapping between a link-local address and a "global" address, but I don't know why from this text.
      3) The second paragraph in 3.2.3 has lots of ambiguity and really needs to be tightened up. I don't know what "get hold of" means from a technical point of view. I don't know what "build" a sub-TLV means from a technical point of view...
      4) The IPv6 Global Interface Address TLV can carry either a global or a site-local address. Well, when it is carrying a site-local address, isn't this poorly named? and since, according to section 2, IS-IS doesn't differentiate between global and site-local, making it sound like it is "global" is misleading. Would this be better called something like IPv6 Remote Interface Address or IPv6 Peer Interface Address?
      5) in 3.2.5, "the SRLG TLV defined in [GMPLS] identifies the corresponding link". Actually, RFC5307 never mentions the word "corresponding". and the text doesn't explain "corresponding to what". The langauge should be made more consistent with RFC 5307.
      6) in 3.2.5, I am not quite sure what "either of these means" refers to.
      ... There is an assertion that there is no backward-compatible way to encode an IPv6 address into a SLRG TLV. It seems unfortunate that RFC5307 was also written rather loosely, and apparently all the reserved bits of the Flags field that "should be set to zero" could actually be set to anything because there is no text specifying what should happen if the bits are not set to zero. Otherwise, we might have been able to use a flag bit to specify support for IPv6 addressing, and provided a list of 4 4-octet values to carry an IPv6 address.
      7) in 4.1, we seem to be EXTREMELY loose with compliance requirements. If you do not implement traffic engineering, you MAY include or omit this TLV. This TLV is designed to do traffic engineering; why would anybody include it if they don't do traffic engineering? What should a receiving entity do if this IS included when traffic engineering is not supported?
      ... This TLV MUST NOT be included more than once [but if you do then] all except the first must be ignored. If this is a MUST NOT, why not return an error or throw the thing away if the implementer is not compliant to the MUST NOT?
      8) in 4.1, If "injecting" a /128 prefix into routing table is a really bad thing to do, is this something that an implementation of the TLV should detect and prevent?
      9) in 4.2, what is the (main) TLV? why not use the approrpiate name for the TLV?
      10) in 4.4, the flags handling has been tightened - good. Instead of saying it must be 0 or 1 or discard the TLV, you might want to say if a bit is non-zero that the receiver does not understand then discard the TLV.
      11) in 4.4, What should a receiver do if the IPv6 SRLG (139) is used when an IPv4 SRLG (138) could have been used?
    5. David Harrington: Comment [2010-08-10]:
      1) acronyms should be expanded on first use. CSPF, SPF,
      2) section 3 is very lightweight; mainly it is pointers to sub-sections in section 4 that correspond to IPv4 TLVs.
      3) in 4.5, you should have a referendce for the Hello.
    6. Peter Saint-Andre: Comment [2010-08-10]:
      Several acronyms are not expanded on first use (e.g., TLV, LSP, IIH, PDU).

    Telechat:

  7. IP/ICMP Translation Algorithm (Proposed Standard)
    draft-ietf-behave-v6v4-xlate-20
    Token: David Harrington
    Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd.
    Discusses/comments (from ballot 3385):
    1. Jari Arkko: Discuss [2010-08-12]:
      I would like to discuss on issue. The document explains:
      "Also, when the IPv4 sender does not set the DF bit the translator MUST always include an IPv6 fragment header to indicate that the sender allows fragmentation."
      "In addition, the rules in section 3.1 use the presence of an IPv6 fragment header to indicate that the sender might not be using path MTU discovery (i.e., the packet should not have the DF flag set should it later be translated back to IPv4)."
      "If the DF bit is set and the packet is not a fragment (i.e., the MF flag is not set and the Fragment Offset is equal to zero) then the translator SHOULD NOT add a Fragment header to the resulting packet."
      "If there is a need to add a Fragment header (the DF bit is not set or the packet is a fragment) the header fields are set as above with the following exceptions:"
      In other words, DF=0 implies a fragment header in IPv6. This has been shown to cause operational difficulties in practice, as even traffic that in no way needed fragmentation will have a fragmentation header, which may result in difficulties due to limited firewall fragmentation support in IPv6, and so on.
      Perhaps the spec is right in recommending this, but I would like to understand exactly why it says what it says, and what the downside of a more relaxed recommendation might be. (FWIW, I'm sending this message behind a NAT64 device that uses a relaxed recommendation.)
    2. Stewart Bryant: Discuss [2010-08-11]:
      "When a translator receives an unfragmented UDP IPv4 packet and the checksum field is zero, the translator SHOULD compute the missing UDP checksum as part of translating the packet."
      There needs to be text explaining how the translator know whether or not to add the missing checksum.
      My reading of this specification is that in the reverse direction (IPv6 to IPv4), when a non checksum neutral address is used a check sum will be added to the UDP header carried by the IPv4 packet, and yet I see no discussion of whether this can be turned off, or of the implications for the IPv4 host (which conceivably may not be able to operate with UDP checksum)
    3. Alexey Melnikov: Discuss [2010-08-09]:
      As per ID nits <http://www.ietf.org/id-info/checklist.html>, section 1 D, any -bis document that obsoletes another document needs to list changes since the previous version. (No need to list every comma, just major changes).
    4. Alexey Melnikov: Comment [2010-08-09]:
      3. Translating from IPv4 to IPv6:
      "Path MTU discovery is mandatory in IPv6 but it is optional in IPv4. IPv6 routers never fragment a packet - only the sender can do fragmentation."
      "However, when the IPv4 sender does not set the Don't Fragment (DF) bit, the translator MUST ensure that the packet does not exceed the path MTU on the IPv6 side. This is done by fragmenting the IPv4 packet so that it fits in 1280-byte IPv6 packets, since that is the minimum IPv6 MTU. Also, when the IPv4 sender does not set the DF bit the translator MUST always include an IPv6 fragment header to indicate that the sender allows fragmentation."
      Are these 2 paragraphs in conflict?
    5. Tim Polk: Discuss [2010-08-11]:
      Tero Kvinen's security directorate review indicated that the security considerations are incomplete with respect to the impact of IPsec's AH and ESP on translation. I have not seen a response to this message...
    6. Sean Turner: Comment [2010-08-11]:
      I support Tim's DISCUSS position.

    Telechat:

  8. TWAMP Reflect Octets and Symmetrical Size Features (Proposed Standard)
    draft-ietf-ippm-twamp-reflect-octets-07
    Token: Lars Eggert
    Note: Henk Uijterwaal (henk@ripe.net) is the document shepherd.
    Discusses/comments (from ballot 3489):
    1. Ron Bonica: Comment [2010-08-09]:
      Unused Reference: 'RFC5226' is defined on line 738, but no explicit reference was found in the text
    2. Stewart Bryant: Comment [2010-08-09]:
      Unused Reference: 'RFC5226' is defined on line 738, but no explicit reference was found in the text
    3. Adrian Farrel: Comment [2010-08-11]:
      Section 4.2.1: There is a bit of a 2119 mess as follows...
      "When simultaneously using the RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357] AND Reflect octets mode, the Session-Reflector MUST reflect the designated octets from the Session-Sender's test packet in the "Packet Padding (from Session-Sender)" Field, and MAY re-use additional Packet Padding from the Session-Sender."
      I think "AND" is not a 2119 term, and "RECOMMENDED" is used here simply to report on what RFC 5357 says.
      The problem with the use of "RECOMMENDED" shows up in a number of other places. It also seems to encourage the use of other non-2119 words (such as "IF" in Section 3.3).
    4. David Harrington: Comment [2010-08-11]:
      1) It would be helpful to include a little explanation as to why the symmetric-size option is needed, probably in paragraph 4 of section 1.
      2) I'm not sure what RFC???? refers to; it this an internet-draft?
    5. Alexey Melnikov: Comment [2010-08-07]:
      "This field communicates the length of the padding in the TWAMP-Test Packet that the Session-Sender expects to be reflected, and the length of octets that the Session-Reflector SHALL return in include in its TWAMP-Test"
      This doesn't read well. I think you should either delete "return in" or "include in".
      3.4. Additional considerations:
      "A Control-Client conforming to this extension of [RFC5357] MAY ignore the values in the higher bits of the Modes Field, or it MAY support other features that are communicated in those bit positions. The other bits are available for future protocol extensions."
      Is it Ok for this document to define this? I think this is already defined in the base spec.
      6.2. Registry Contents: "TWAMP Modes Registry is recommended to be augmented as follows:..."
      Please don't repeat existing registry entries in the IANA Considerations section. The current list is maintained by IANA and any list specified in an RFC can quickly get out of date.
    6. Peter Saint-Andre: Discuss [2010-08-10]:
      This specification states that "the Reflect octets mode re-designates the original TWAMP-Test (and OWAMP-Test) Packet Padding Field (see section 4.1.2 of [RFC4656])". Therefore it appears that this specification formally updates RFC 4656. However, the document header notes only that it updates RFC 5357.
    7. Peter Saint-Andre: Comment [2010-08-10]:
      1. There are numerous instances of the text "the RECOMMENDED truncation process in TWAMP section 4.2.1 [RFC5357]"; there is no need for the word "recommended" to be all-caps here, because the normative language already exists in RFC 5357.
      2. Some of the typography is non-standard, such as "*continues*" and "IF" and "AND" and "BOTH"; it's better to provide emphasis using normal English words

    Telechat:

  9. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual- Stack Lite (Proposed Standard)
    draft-ietf-softwire-ds-lite-tunnel-option-03
    Token: Ralph Droms
    Note: Dave Ward (dward@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3496):
    1. Jari Arkko: Discuss [2010-08-12]:
      We have been pushing back in other cases when people defined both FQDN and IP address information for the same configuration item in DHCP. Why are two options and configuration mechanisms absolutely necessary in this case? Wouldn't IP-address based configuration suffice?
    2. Adrian Farrel: Comment [2010-08-11]:
      Section 4 carries a couple of "MUST NOT" with respect to the DS-Lite Name option. It would be well to describe what a receiver is supposed to do in the event of a breach.
    3. David Harrington: Discuss [2010-08-10]:
      1) in section 5,
      "The server MUST provide a way to configure the OPTION_DS_LITE_ADDR, and SHOULD allow the operator to enter a Fully Qualified Domain Name, upon which the server performs DNS Resolution to assemble its OPTION_DS_LITE_ADDR contents." does the server really perform DNS resolution when an FQDN is entered?
      what if the client and server have access to different DNS servers? Couldn't you run into a situation where the server cannot resolve the FQDN but the client could? or vice-versa?
      2) in a related question,
      "If the server is configured with an FQDN as the tunnel endpoint locator, the configured FQDN value MUST contain a resolvable Fully Qualified Domain Name, having appropriate delegations from the root, and having a AAAA record locating the Softwire Concentrator."
      what happens if the client and server have different capabilities to get a AAAA record, maybe because of a NAT at IPvX boundaries?
      3) in section 6, "A client that supports B4 functionality of DS-Lite (defined in [I-D.softwire-ds-lite-04]) MUST include OPTION_DS_LITE_ADDR on its OPTION_ORO, and MAY include OPTION_DS_LITE_NAME at its option and ability."
      Is this a new compliance requirement for B4s that could render existing compliant B4 implementations non-compliant?
    4. David Harrington: Comment [2010-08-10]:
      1) in the INtroduction, the first mention of AFTR should be spelled out and given a reference.
      2) it would be good to identify the specific registry in the IANA registries (e.g., by URL), and to provide the added values formatted to match the existing registry.
    5. Alexey Melnikov: Discuss [2010-08-07]:
      DISCUSS DISCUSS:
      3. The Dual-Stack Lite Address DHCPv6 Option:
      "The client validates the DS-Lite Address option by confirming the option is of 16 octets in length or greater. The client MUST ignore any tunnel-endpoint-addr shorter than 16 octets. In the event the option is greater than 16 octets in length, only the first 16 octets are interpreted."
      Is there any good reason to tolerate any value of this option with length != 16?
    6. Alexey Melnikov: Comment [2010-08-07]:
      Should the document be clear that non-ASCII (IDN) FQDN are not allowed, i.e. that any such name must be punycode-encoded?
    7. Peter Saint-Andre: Discuss [2010-08-10]:
      The meaning of "FQDN" seems to be underspecified. Is this limited to a "traditional domain name", i.e., a fully qualified domain name all of whose labels are "LDH labels" (as defined in RFC 5890)? Or can the HostName type be an "internationalized domain name", i.e., a DNS domain name at least one of whose labels is a "U-label" or "A-label" (as defined in RFC 5890)? If this document inherits its definition of FQDN from Section 8 of RFC 3315, then it would be good to make that clear and specify that internationalized labels from IDNs need to be represented as A-labels.

    Telechat:

2.1.2 Returning Items

  1. Transport Layer Security (TLS) Extensions: Extension Definitions (Proposed Standard)
    draft-ietf-tls-rfc4366-bis-10
    Token: Sean Turner
    Note: Document shepherd is Joe Salowey <jsalowey@cisco.com>
    Discusses/comments (from ballot 3195):
    1. Ron Bonica: Comment [2010-08-09]:
      three Obsolete informational references
    2. Adrian Farrel: Discuss [2010-08-11]:
      I don't think it is right that Section 10.1 includes the text "Published specification: [RFC4366], and [RFC5280]." yet this document claims to obsolete RFC 4366.
    3. Adrian Farrel: Comment [2010-08-11]:
      The RFC Editor will require that you remove the citation from the Abstract. This is usually done by replacing it with the document name and RFC number.
    4. Alexey Melnikov: Discuss [2010-08-11]:
      1) 3. Server Name Indication:
      struct {...} ServerName;
      enum {...} NameType;
      opaque HostName<1..2^16-1>;
      struct { } ServerNameList;
      [...]
      "However, for backward compatibility, all future NameTypes MUST begin with a 16-bit length field."
      Can you please clarify what this means? I am looking at both ServerName and NameType definitions and I don't see what you are talking about.
      2) 5. Client Certificate URLs: "The TLS server is not required to follow HTTP redirects when retrieving the certificates or certificate chain."
      This is not strong enough for interoperability. Either redirects MUST be followed, or they MUST NOT be followed. Alternatively there need to be some explanation of why SHOULD (or even MAY) is appropriate here.
      3) 5. Client Certificate URLs: "If a server encounters an unreasonable delay in obtaining"
      This is not very specific. Can a minimal value be recommended here?
      "certificates in a given CertificateURL, it SHOULD time out and signal a certificate_unobtainable(111) error alert."
      What are possible alternatives to the SHOULD?
    5. Alexey Melnikov: Comment [2010-08-11]:
      I am agreeing with Peter's DISCUSS.
      Additionally, I have the following comments:
      10.1 pkipath MIME Type Registration: The "Encoding Considerations" section should say that the data is binary.
      Person & email address to contact for further information: Magnus Nystrom <magnus@rsasecurity.com>
      I vaguely remember that Magnus has changed jobs since, so this email address is no longer valid.
    6. Dan Romascanu: Discuss [2010-08-12]:
      DISCUSS-DISCUSS: This document obsoletes RFC 4366 (if approved) which seems to be correct. However, 4366 is already obsoleted by 5246 which may not be accurate. Actually can we have one RFC obsoleted by more that one newer RFC?
    7. Dan Romascanu: Comment [2010-08-12]:
      ...
    8. Peter Saint-Andre: Discuss [2010-08-09]:
      The "HostName" type seems to be underspecified. Is this limited to a "traditional domain name", i.e., a fully qualified domain name all of whose labels are "LDH labels" (as defined in RFC 5890)? Or can the HostName type be an "internationalized domain name"...

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Network News Transfer Protocol (NNTP) Additions to LIST Command (Proposed Standard)
    draft-elie-nntp-list-additions-04
    Token: Alexey Melnikov
    Discusses/comments (from ballot 3412):
    1. Adrian Farrel: Comment [2010-08-11]:
      It seems to me that [RFC2980] might usefully be a normative reference since this document purports to update it.
    2. Alexey Melnikov: Discuss [2010-08-12]:
      Holding a temporary DISCUSS for IANA, to let IANA verify that the new IANA Considerations section is Ok
    3. Peter Saint-Andre: Comment [2010-08-10]:
      1. In Section 2.3.2, the phrase "at least all" is awkward -- I suggest changing it to "all".
      2. In Section 2.4.2, the text "although these situations SHOULD NOT occur if the news server is an injecting agent that carries moderated newsgroups" is merely informative, so it would be good to change "SHOULD NOT occur" to "should not occur" or "are unexpected" or something else non-normative.
      3. In Section 2.5.2, change "date of last modification date" to "date of last modification" or "last modification date".
      4. In Section 7, the definition does not include a descriptive name for the extension. However, perhaps the descriptive name is "LIST"?
      5. In Section 7, the "Contact for Further Information" is "Author of this document", but no contact information is provided (e.g., an email address).
    4. Sean Turner: Comment [2010-08-11]:
      1) Sec 2: should "optional" be "OPTIONAL"?

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (Informational)
    draft-ietf-ipsecme-roadmap-09
    Token: Sean Turner
    Note: Paul Hoffman (paul.hoffman@vpnc.org) the document shepherd for this document.
    Discusses/comments (from ballot 3344):
    1. Adrian Farrel: Comment [2010-08-11]:
      Thanks for what must have been a pretty painful task. I think this makes a useful document.
    2. Tim Polk: Comment [2010-08-12]:
      (1) I understand that this is a forklift upgrade for RFC 2411, so the usual "Changes Since ..." section would not be helpful. However, this document has a very similar title and does obsolete 2411 if approved. Perhaps a few sentences in the intro to describe that relationship would be useful!
      (2) RFC 5282 should be added to the list of base documents in section 4.1.2, IKEv2. As noted in section 5.4, 5282 added the capability to negotiate combined mode algorithms to IKEv2.
      (3) Section 5.4.3 is misplaced. GMAC is an Integrity protection algorithm and should appear in section 5.3. This will necessitate forward pointers to section 5.4, since it is based on a combined mode algorithm, but it does not fit with the other algorithms in 5.4 which are providing both encryption and integrity-protection.
      (4) In section 5.2.1, last sentence of the first paragraph: "This number (the value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 and IKEv2, but it is not mentioned in this RFC."
      "this RFC" is ambiguous - I gather the authors meant RFC 2410 (since the value is clearly mentioned in *this* RFC).

    Telechat:

  2. Framework for IPv4/IPv6 Translation (Informational)
    draft-ietf-behave-v6v4-framework-09
    Token: David Harrington
    Note: Dan Wing (dwing@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3378):
    1. Gonzalo Camarillo: Comment [2010-08-04]:
      The taxonomy of applications in Section 1.3 seems useful. However, the definition of P2P applications can be confusing. For example, SIP is classified as a P2P application and not as a client/server application. However, entities in SIP are called user agent clients, user agent servers, proxy servers, redirect servers, etc. Using a different term instead of P2P to classify those types of applications would make that section clearer. However, since this is not substantial to the draft, I leave it up to the authors whether or not to make this change.
    2. Dan Romascanu: Comment [2010-08-10]:
      1. It would be useful to expand acronyms at first ocurence - e.g. NAT-PT, AAAA record, A record, MTA, SIIT, etc.
      2. It would be useful to add the network management protocols (SNMP, NETCONF) and the AAA protocols (Diameter, RADIUS) in the examples of client-server protocols in section 1.3. Deployment of these protocols is one of the issues network operators encounter in the transition scenarios.
      3. At the begining of section 2 - s/translation solution/translation solutions/

    Telechat:

  3. ForCES Applicability Statement (Informational)
    draft-ietf-forces-applicability-09
    Token: Adrian Farrel
    Note: The Document Shepherd is Jamal Hadi Salim (hadi@mojatatu.com).
    Discusses/comments (from ballot 3445):
    1. (none)

    Telechat:

  4. Implementation Report for ForCES (Informational)
    draft-ietf-forces-implementation-report-02
    Token: Adrian Farrel
    Note: Joel Halpern (jmh@joelhalpern.com) is the Document Shepherd.
    Discusses/comments (from ballot 3455):
    1. Tim Polk: Comment [2010-08-11]:
      I support Dan's discuss. To my reading, two interoperable implementations of the security features are needed to fully satisfy the requirements for Draft Standard specified in 2026.
    2. Dan Romascanu: Discuss [2010-08-10]:
      The following issue is based on an observation made by Pekka Savola in his OPS-DIR report.
      In Section 3 (Summary) the following statement is being made: "The authors attest that the ForCES Protocol, Model and SCTP-TML meet the requirements for Draft Standard."
      However, Sections 5, 6.1.3.3 and 9 indicate that the (mandatory) SCTP-TML IPsec security framework was not implemented by any of the tested implementations and thus not tested for interoperability. I believe that the text in the Summary section needs to reflect this situation.
    3. Peter Saint-Andre: Comment [2010-08-10]:
      One nit: several acronyms are not expanded on first use (e.g., "PL" and "XML").

    Telechat:

  5. Basic Requirements for IPv6 Customer Edge Routers (Informational)
    draft-ietf-v6ops-ipv6-cpe-router-07
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3475):
    1. Stewart Bryant: Comment [2010-08-09]:
      MLD not expanded on first use

    Telechat:

  6. Emerging Service Provider Scenarios for IPv6 Deployment (Informational)
    draft-ietf-v6ops-isp-scenarios-00
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3501):
    1. (none)

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Deprecating Unicode Language Tag Characters: RFC 2482 is Historic (Informational)
    draft-presuhn-rfc2482-historic-02
    Token: Alexey Melnikov
    Note: Strong support from the Apps Area people.
    Discusses/comments (from ballot 3478):
    1. (none)

    Telechat:

  2. BCP 47 Extension U (Informational)
    draft-davis-u-langtag-ext-03
    Token: Alexey Melnikov
    Note: Martin J. Duerst <duerst@it.aoyama.ac.jp> is the document shepherd
    Discusses/comments (from ballot 3484):
    1. Peter Saint-Andre: Comment [2010-08-10]:
      1. Section 2.1 has the text "(for details see Section 3)" but that is a reference to Section 3 of UTS35, not to Section 3 of the RFC-to-be.
      2. There is a typo in "the first occurrence of an attributes or key conveys meaning"; it seems that "attributes" should be "attribute".
      3. In the text "[w]ith successive versions of [UTS35], additional attributes, keys, and types MAY be defined", I think "might" is better than "MAY" since there is no normative force to those words and therefore conformance terms don't apply.
      4. The information about accessing machine-readable files is helpful to developers, but might quickly become dated; I suggest providing a pointer to the CLDR project
    2. Sean Turner: Comment [2010-08-11]:
      I suspect the RFC editor will complain about the compound reference for [UTS35]. Are references to the specific sections needed?
      Is the [US-ASCII] reference the same as: "American National Standards Institute, "Coded Character Sets - 7-Bit American Standard Code for Information Interchange (7-Bit ASCII), ANSI X3.4", 1986. for ASCII.

    Telechat:

  3. IPv4 and IPv6 Greynets (Informational)
    draft-baker-v6ops-greynet-04
    Token: Ron Bonica
    Note: Tim Chown (tjc@ecs.soton.ac.uk) is the document shepherd.
    Discusses/comments (from ballot 3492):
    1. Ralph Droms: Comment [2010-08-12]:
      Question based on this statement:
      "It has been observed [RFC5157] that address scanning is less effective in IPv6 [RFC2460] networks, as there are more addresses to scan. The observation is of limited value, in that there are other approaches to identifying IPv6 systems, such as reading the 'Received:' lines in SMTP envelopes. Such attacks can be limited by the use of Privacy Addresses [RFC4941], which periodically change, rendering such historical information less useful, but the fact is that such analytic methods exist. Greynets are a tool that can be used to isolate and analyze them."
      Is there any deployment experience that indicates greynets provide useful information in IPv6, where the traffic to be captured by the greynet may come from seeding information about "lit" IPv6 addresses rather than address or prefix scanning?

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions Via RFC Editor

3.3.1 New Items

  1. A Childless Initiation of the IKE SA (Experimental)
    draft-nir-ipsecme-childless-06
    Token: Sean Turner
    Discusses/comments (from ballot 3495):
    1. Adrian Farrel: Comment [2010-08-11]:
      The acronym "SA" is used in the Title, Abstract, and body without expansion. Other acronyms are also used in the body without expansion.

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. Media Description for IKE in the Session Description Protocol (SDP) (Informational)
    draft-saito-mmusic-sdp-ike-07
    Token: Russ Housley

    Telechat:

1223 EDT break

1231 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Port Control Protocol (pcp)
    Token: Jari

    Telechat:

  2. Authority-to-Citizen Alert (atoca)
    Token: Robert

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Mobility EXTensions for IPv6 (mext)
    Token: Jari

    Telechat:

  2. Behavior Engineering for Hindrance Avoidance (behave)
    Token: David

    Telechat:

4.2.2 Proposed for Approval

  1. Transparent Interconnection of Lots of Links (trill)
    Token: Ralph

    Telechat:

5. IAB News We can use

  1. Amy: no representatives here

6. Management Issues

  1. Expert for draft-ietf-idnabis-tables [IANA #378056] (Michelle Cotton)

    Telechat:

  2. draft-ietf-6man-text-addr-representation AUTH48 change (Jari Arkko)

    Telechat:

7. Agenda Working Group News

Glenn: winding up transitional phase; about 30 meetings in Maastricht, plus meetings with IESG members since. I am winding up the transitional RFC Editor document. I would be glad to share results with you prior to the Draft. If you're interested in how things are shaping up, email me (glenn@RiverOnce.com).

1328 EDT Adjourned



Appendix: Snapshot of discusses/comments

(at 2010-08-12 08:29:26 PDT)

draft-ietf-ippm-spatial-composition

  1. Ron Bonica: Discuss [2010-08-09]:
        Nits:
    
      == Unused Reference: 'RFC5644' is defined on line 1246, but no explicit
         reference was found in the text
    
      ** Downref: Normative reference to an Informational RFC: RFC 2330
    
      ** Downref: Normative reference to an Informational RFC: RFC 5835 
        
  2. Ron Bonica: Comment [2010-08-09]:
    
        
  3. Stewart Bryant: Discuss [2010-08-09]:
        
    The term 
    
    Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i]
    
    is very confusing.
    
    Similarly the term Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream metric is
    confusing.
    
    I think that the authors are trying to use the same text to describe both
    metrics, but it is not clear that they are not presenting a math expression.
    
    The term FiniteDelay is not defined in this doc and I could nor see it in
    RFC2679
    
    Similarly I do not see definitions for MeanDelay or CompMeanDelay or MinDelay*
    
    In each case they seem to be an intermediate variable, but I can't find text
    explaining why this is done.
    
    * - there is a definition of MinDelay in a much later section, but it's not
    clear that this is a general definition, nor is there a forward reference to it.
    
    ========
    
    I cannot parse the ASCII maths that is used to calculate
    
     Type-P-Composite-One-way-pdv-refmin-quantile-a
     
        
  4. Stewart Bryant: Comment [2010-08-09]:
    I found this draft very difficult to read. In part this is the authors terse
    style and in part this is because of the constraints placed on the authors by
    the use of ASCII text to express mathematical concepts. In respect of the latter
    we may wish to encourage the authors to submit a a pdf version of this document
    using standard math notation.
    
    ============
    
    Type-P-Finite--Composite-One-way-Delay-Minimum,
    
    looks like a typo "--"
    
    ==========
    
    The term "ground truth" is used, but I could not see a definition or a
    reference. Google seems to indicate that it is a technical term in sensing, thus
    a reference or definition would be useful to the reader.
    
    ========
    
    A reference should be provided for the derivation of the measurement of
    
    Type-P-One-way-pdv-refmin-Skewness
  5. Dan Romascanu: Discuss [2010-08-09]:
        id-nits complains about RFC 2330 and RFC 5835 being downrefs. The PROTO write-up
    mentions something about the framework document (actually they are two) being
    rather Normative References, and I am OK with this line, but the IETF Last Call
    did not explicitely call the downrefs. 
        
  6. Dan Romascanu: Comment [2010-08-09]:
    The OPS-DIR review by Benoit Claise made a number of useful editorial comments
    which I suggest to be considered.
  7. Sean Turner: Comment [2010-08-11]:
    I almost made this a discuss, but thought better of it:
    
    Should the must in the following be MUST?
    
    Passive measurement must restrict attention to the headers of interest.
    
    You later mention precautions MUST be taken to keep user information safe and
    confidential.  Seems like the above would fall in to the same kind of MUST?

draft-ietf-manet-nhdp

  1. Ralph Droms: Comment [2010-08-11]:
    In general, I think this document is well-written and clear.  However, I do have
    a few specific comments.
    
    In section 2, I don't understand the definition of "interface".  Why not use the
    definition from RFC 2460?
    
    Section 4.1: what is "an address represented by a network address"?  I don't
    understand the uniqueness properties defined in the first bullet.
    
    Section 4.2: would it be more correct to write that the Information Bases
    "describe the state of the protocol in a node"?  Do I understand correctly that
    the first paragraph of 4.2 states that the Information Bases are abstractions
    and need not be explicitly implemented as described in the doc?  It might be
    helpful to give a forward reference to Tuples as they are defined later in the
    document.  Similarly, in section 4.2.1, it might be helpful to give forward
    references to the definitions of Local Interface Tuples, Removed Interface
    Address Tuples and 2-hop Tuples.
    
    In section 10.1, I don't understand "A HELLO message which is transmitted
    periodically SHOULD contain, and otherwise MAY contain [...]"; does it mean that
    a HELLO message that is not transmitted periodically "MAY contain"?
    
    Section 18: s/repository/registry/ ?
  2. Sean Turner: Discuss [2010-08-11]:
        1) The proto write-up did not identify the DOWNREF to RFC 5148 in 1.h/8.   A
    second IETF LC is necessary to call this DOWNREF out. 
        

draft-ietf-behave-dns64

  1. Tim Polk: Discuss [2010-08-12]:
        I have some concerns regarding the impact on DNSSEC aware clients.  Is expecting
    these systems to be
    translation-aware practical?  I noticed the writeup
    mentioned the need for the DNS directorate review, but my
    review of the dns-dir
    archives did not turn up a review.  If the DNS directorate has reviewed  this
    document and
    supports publication I will clear. 
        
  2. Sean Turner: Comment [2010-08-11]:
    Some minor nits:
    
    #1) Sec 2: r/mode" ./mode".
    #2) Sec 5.1.3: r/. ./.
    #3) Sec 5.1.7: 
     3a) r/from the A record/from the A record.
     3b) r/28 (AAAA)/28 (AAAA).
     3c) r/to 16/to 16.
     3d) r/([RFC2308]/([RFC2308]).
    #4) Sec 7.1 & 7.2: r/h2.example.com/h2.example.com.
    #5) Sec 7.1: r/is 64:FF9B::192.0.2.1/is 64:FF9B::192.0.2.1.

draft-ietf-behave-v6v4-xlate-stateful

  1. Alexey Melnikov: Comment [2010-08-11]:
    3.4.  Determining the Incoming tuple
    
          The NAT64 MUST handle fragments.  In particular, NAT64 MUST handle
          fragments arriving out-of-order , conditioned on the following:
    
          *  The NAT64 MUST limit the amount of resources devoted to the
             storage of fragmented packets in order to protect from DoS
             attacks.
    
    I think these 2 requirements are slightly in conflict, as an implementation
    claiming compliance can claim to never have resources, which means that support
    for fragments is truly optional.
    
    3.5.1.1.  Rules for Allocation of IPv4 Transport Addresses for UDP
    
          In all cases, the allocated IPv4 transport address (T,t) MUST NOT
          be in use in another entry in the same BIB, but MAY be in use in
    
    MAY here is not an implementation choice, so the use of MAY is not appropriate.
    I suggest changing this to "can".
    
          the other BIB (referring to the UDP and TCP BIBs).
    
    s/UDP/ICMP ?
    (Similar text in Section 3.5.2.3).
  2. Peter Saint-Andre: Comment [2010-08-11]:
    1. Please provide an informational reference to RFC 5245 for ICE, and expand the
    term on first use.
    
    2. Please provide an informational reference to RFC 5389 for STUN, and expand
    the term on first use.
    
    3. Among the contributors, Simon Parreault's last name is in fact Perreault.

draft-ietf-behave-address-format

  1. Ralph Droms: Comment [2010-08-11]:
    Minor comment ... the name "Well Known Prefix" seems underspecified; however, I
    can't suggest something terse that seems better.  Maybe "Well Known 64xlate
    Prefix"?
  2. Adrian Farrel:
  3. Alexey Melnikov: Discuss [2010-08-07]:
        This is a DISCUSS DISCUSS:
    
    I want to make sure that this document is consistent with [approved for
    publication] draft-ietf-6man-text-addr-representation.
    Also, should the document
    be updated to use lowercased hex digits (as per Section 4.3 of draft-ietf-6man-
    text-addr-representation) in example addresses? 
        
  4. Tim Polk: Comment [2010-08-11]:
    The PL row in Figure 1 includes superfluous lengths 112 and 120 bits.   I would
    suggest:
    
    OLD
        +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
        |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
        +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    
    NEW
        +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
        |PL| 0-------------32--40--48--56--64--72--80--88--96--104----------|
        +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    
    (2)
    In the paragraph following figure 1:
    
    s/prefic is 96 bits/prefix is 96 bits/

draft-ietf-isis-ipv6-te

  1. Stewart Bryant: Comment [2010-08-11]:
    The following comments were made during Routing Directorate review.
    
    The authors have agreed text with the reviewer that addresses these issues.
    
    ======
    Summary:
    This document is basically ready for publication, but has some minor
    issues to be considered before publication.
    
    Comments:
    This document is well written and easy to read. I have several nits and
    one minor question.
    
    Major Issues:
    No major issues found.
    
    Minor Issues:
    
    Section 3.1.1:
    Global, site-local and link-local addresses are mentioned. Have you
    considered that site-local addresses have been deprecated by RFC 3879?
    Have you considered unique local addresses in RFC 4139?
    
    Nits:
    
    - I would suggest to add RFC 2119 to normative references.
    
    - Usually, the main body starts with Introduction section, followed by
    Requirement Words. I would suggest that Section 2 (Overview) is moved up
    to Section 1, followed by Requirement Words (or Requirement Words can be
    a separate section).
    
    ======
  2. Adrian Farrel: Discuss [2010-08-11]:
        Please make the changes agreed after Routing Directorate review by 
    Tomonori Takeda, expecially the change wrt the deprecation of site-local
    addresses.
    
    ---
    
    In Section 4.4
       The flag octet indicates whether the IPv6 neighbor address is
       included (set to 1), or not included (set to 0).  Other values for
       the flags field are reserved - an implementation receiving a value
       for the flags field other than 0 or 1 SHOULD discard the TLV.
    
       Note that this rule for processing the flags octet allows for future
       extensibility of the IPv6 SRLG TLV.  In particular, it allows
       alternative means of identifying the corresponding link to be added
       in the future.  An implementation that does not understand such an
       extension will simply discard the TLV, rather than attempting to
       interpret the TLV incorrectly.
    
    Surely this field contains bit flags and should not be treated as an
    integer.
    
    But anyway, what you have seems to break future extensibility rather
    than facilitate it as you claim. Are you really saying that if a future
    use of the flags is found, this TLV should not be propagated by legacy 
    routers? Are you also saying that such legacy routers should entirely 
    ignore all information in the TLV?
    
    If this is what you are saying, you are really using the flags field as
    a TLV sub-type value not as flags at all.
    
    ---
    
    In Section 4.4
    
       To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP
       from contradicting each other, the following rules are applied.
    
    I don't think a contradiction would be implied by breaking the rules
    since one could infer an additive rule. So perhaps...
    s/contradicting each other/causing confusion of interpretation/
    
    ---
    
    A normative reference to RFC 2119 is missing.
    
    ---
    
    [GMPLS] appears to be a normative reference from 3.2
    
    ---
    
    [GMPLS-ROUTING] appears to be a normative reference from 4.4 
        
  3. Adrian Farrel: Comment [2010-08-11]:
    A number of acronyms are used without expansion.
    
    ---
    
    It would probably be proper for Section 5 to include a pointer to RFC
    5304 for general security considerations for IS-IS.
    
    ---
    
    Are you sure the authors don't want to change their affiliation?
  4. David Harrington: Discuss [2010-08-10]:
        There are sections of this document that should be made more clear and
    unambiguous before being advanced to standards-track.
    
    1) there are numerous places where "this TLV" is used, and sometimes the
    reference is ambiguous. I recommend spelling out the TLVs by name.
    
    2) 3.2.3 says a new TLV is needed to build a Neighbor Address TLV, but never
    says WHY another TLV is needed. As far as I can tell, there needs to be a
    mapping between a link-local address and a "global" address, but I don't know
    why from this text.
    
    3) The second paragraph in 3.2.3 has lots of ambiguity and really needs to be
    tightened up. 
    I don't know what "get hold of" means from a technical point of
    view.
    I don't know what "build" a sub-TLV means from a technical point of view.
    "To achieve this" - from the context, "this" seems to refer to "getting hold of
    a global or site-local address"
    "To achieve this, [a TLV] is defined in 4.5",
    but 4.5 doesn't talk at all about how to "get hold of" an address.
    The next to
    last sentence talks about using the new TLV in the IIH. Then the last sentence
    talks about two TLVs - "The TLV" used with an [IPv6] TLV, which, when used in
    the IIH carries a link-local address. Does this mean that "The TLV" (the new
    one), when used in the IIH, carries a link-local address, or does this mean the
    [IPv6] TLV, when carried in the IIH, carries a link-local address?
    
    4) The IPv6 Global Interface Address TLV can carry either a global or a site-
    local address. Well, when it is carrying a site-local address, isn't this poorly
    named? and since, according to section 2, IS-IS doesn't differentiate between
    global and site-local, making it sound like it is "global" is misleading. Would
    this be better called something like IPv6 Remote Interface Address or IPv6 Peer
    Interface Address?
    
    5) in 3.2.5, "the SRLG TLV defined in [GMPLS] identifies the corresponding
    link". Actually, RFC5307 never mentions the word "corresponding". and the text
    doesn't explain "corresponding to what". The langauge should be made more
    consistent with RFC 5307.
    
    6) in 3.2.5, I am not quite sure what "either of these means" refers to. Is the
    flag one of these means? or is the flag irrelevant, and the "means of
    identification" the contents of the SRLG TLV? This is a NIT, but it reflects the
    looseness of the text in this document.
    
    There is an assertion that there is no backward-compatible way to encode an IPv6
    address into a SLRG TLV. It seems unfortunate that RFC5307 was also written
    rather loosely, and apparently all the reserved bits of the Flags field that
    "should be set to zero" could actually be set to anything because there is no
    text specifying what should happen if the bits are not set to zero. Otherwise,
    we might have been able to use a flag bit to specify support for IPv6
    addressing, and provided a list of 4 4-octet values to carry an IPv6 address.
    
    7) in 4.1, we seem to be EXTREMELY loose with compliance requirements. 
    
    If you do not implement traffic engineering, you MAY include or omit this TLV.
    This TLV is designed to do traffic engineering; why would anybody include it if
    they don't do traffic engineering? What should a receiving entity do if this IS
    included whenn  traffic engineering is not supported? ignore it? What this does
    from an engineering perspective is invite implmenters to overload this TLV for
    purposes for which it is not being designed. and that can lead to problems down
    the road. I think this should be a MUST NOT.
    
    A stable, global or site-local address SHOULD be used; so what are the
    exceptions that justify a SHOULD? When exactly does it make sense to use an
    unstable address or a link-local address in this TLV? Why is this not a MUST?
    
    Let me point out that section 3.2.1 says the IPv4 Router ID TLV contains a
    stable address, not that it SHOULD contain a stable address. RFC 5305 says
    The router ID is useful for traffic engineering purposes because it
       describes
    a single address that can always be used to reference a
       particular router.
    I
    interpret that "always" as meaning it MUST be a stable address.
    
    This TLV MUST NOT be included more than once [but if you do then] all except the
    first must be ignored. If this is a MUST NOT, why not return an error or throw
    the thing away if the implementer is not compliant to the MUST NOT? What is the
    benefit to allowing an implementer to send multiple TLVs if all but the first
    will be ignored? So what are the security risks of allowing a sender (or a man-
    in-the-middle) to send extra TLVs that will be ignored? Could I maybe use this
    unchecked space in IS-IS messages to transport malware? The security
    considerations sections doesn't mention anything about this.
    
    8) in 4.1, If "injecting" a /128 prefix into routing table is a really bad thing
    to do, is this something that an implementation of the TLV should detect and
    prevent? I am not quite sure which actor should take which action here. What
    values should a TLV sender not send? How should a receiver act if they get such
    a bad value?
    
    9) in 4.2, what is the (main) TLV? why not use the approrpiate name for the TLV?
    
    10) in 4.4, the flags handling has been tightened - good. Instead of saying it
    must be 0 or 1 or discard the TLV, you might want to say if a bit is non-zero
    that the receiver does not understand then discard the TLV. This way, you could
    add new functionality identified by flags not defined in this document. If you
    do this, you should create a registry for the flags to control and coordinate
    flag bit semantics.
    
    Have you considered duplicating the functionality of type 138 in type 139 with
    an eye to replacing 138 with a more extensible type? The existing flag usage
    from type 138 could be preserved; additional Flag bits could be used to specify
    whether the interface and neighbor addresses are IPv4 or IPv6. While you can not
    achieve backwards compatibility, you can achieve forward compatibility to a more
    extensible replacement type, and deprecate 138 usage.
    
    11) in 4.4, What should a receiver do if the IPv6 SRLG (139) is used when an
    IPv4 SRLG (138) could have been used? Is the MUST enforceable? Is this
    detectable? Is this an error? should the TLV be discarded?
    
    If the problem is possible contradiction, why not specify that if both are
    received, then the receiver MUST ignore the IPv6 SRLG and apply the IPv4 SRLG?
    (although since IPv6 use is expected to grow while IPv4 use lessens, and you've
    made the IPv6 SRLG TLV extensible, and an extended IPv6 SRLG TLV might be more
    useful than the legacy limited-extensibility IPv4 SRLG, favoring the IPv6 SRLG
    might make more sense). 
        
  5. David Harrington: Comment [2010-08-10]:
    1) acronyms should be expanded on first use. CSPF, SPF, 
    2) section 3 is very
    lightweight; mainly it is pointers to sub-sections in section 4 that correspond
    to IPv4 TLVs. I think section 3.2 could be eliminated by simply moving the
    reference to the IPv4 TLVs into each section 4 sub-section. (or even just
    providing a table of corresponding TLVs)
    3) in 4.5, you should have a referendce
    for the Hello.
  6. Peter Saint-Andre: Comment [2010-08-10]:
    Several acronyms are not expanded on first use (e.g., TLV, LSP, IIH, PDU). The
    RFC Editor will ask that you expand them, so you might as well start working on
    that task now. :)

draft-ietf-behave-v6v4-xlate

  1. Jari Arkko: Discuss [2010-08-12]:
        This document is in very good shape (as is the entire document set
    on NAT64) and should move forward. However, before recommending that
    this particular document gets final approval, I would like to discuss
    on issue. The document explains:
    
       Also, when the IPv4 sender does not set the DF bit
       the translator MUST always include an IPv6 fragment header to
       indicate that the sender allows fragmentation.
       ...
       In addition, the rules in section 3.1 use
       the presence of an IPv6 fragment header to indicate that the sender
       might not be using path MTU discovery (i.e., the packet should not
       have the DF flag set should it later be translated back to IPv4). 
       ....
       If the DF bit is set and the packet is not a fragment (i.e., the MF
       flag is not set and the Fragment Offset is equal to zero) then the
       translator SHOULD NOT add a Fragment header to the resulting packet.
       ...
       If there is a need to add a Fragment header (the DF bit is not set or
       the packet is a fragment) the header fields are set as above with the
       following exceptions:
    
    In other words, DF=0 implies a fragment header in IPv6. This has been
    shown to cause operational difficulties in practice, as even traffic
    that in no way needed fragmentation will have a fragmentation header,
    which may result in difficulties due to limited firewall fragmentation
    support in IPv6, and so on.
    
    Perhaps the spec is right in recommending this, but I would like to
    understand exactly why it says what it says, and what the downside
    of a more relaxed recommendation might be. (FWIW, I'm sending this
    message behind a NAT64 device that uses a relaxed recommendation.) 
        
  2. Jari Arkko: Comment [2010-08-12]:
    
        
  3. Stewart Bryant: Discuss [2010-08-11]:
        When a translator receives an unfragmented UDP IPv4 packet and the
    checksum field is zero, the translator SHOULD compute the missing UDP
    checksum as part of translating the packet.  
    
    There needs to be text explaining how the translator know whether or not to add
    the missing checksum. I understand that this is now a more complex decision than
    it used to be as a result of proposals to relax the requirement to include a UDP
    checksum for IPv6 depending on the application requirement.
    
    My reading of this specification is that in the reverse direction (IPv6 to
    IPv4), when a non checksum neutral address is used a check sum will be added to
    the UDP header carried by the IPv4 packet, and yet I see no discussion of
    whether this can be turned off, or of the implications for the IPv4 host (which
    conceivably may not be able to operate with UDP checksum) 
        
  4. Alexey Melnikov: Discuss [2010-08-09]:
        [Updated]
    
    Modulo the issues listed below I have No Objections to the publication of this
    document:
    
    As per ID nits <http://www.ietf.org/id-info/checklist.html>, section 1 D, any
    -bis document that obsoletes another document needs to list changes since the
    previous version. (No need to list every comma, just major changes).
    
    ID-nits tool report for this document:
    
     Checking references for intended status: Proposed Standard
      ----------------------------------------------------------------------------
    
     [...]
    
      ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460)
    
    Is use of RFC 1883 intentional?
    
     [...]
    
      -- Obsolete informational reference (is this intentional?): RFC 2766
         (Obsoleted by RFC 4966)
    
    What is the relationship between this document and RFC 4966? 
        
  5. Alexey Melnikov: Comment [2010-08-09]:
    3.  Translating from IPv4 to IPv6
    
       Path MTU discovery is mandatory in IPv6 but it is optional in IPv4.
       IPv6 routers never fragment a packet - only the sender can do
       fragmentation.
    
     [...]
    
       However, when the IPv4 sender does not set the Don't Fragment (DF)
       bit, the translator MUST ensure that the packet does not exceed the
       path MTU on the IPv6 side.  This is done by fragmenting the IPv4
       packet so that it fits in 1280-byte IPv6 packets, since that is the
       minimum IPv6 MTU.  Also, when the IPv4 sender does not set the DF bit
       the translator MUST always include an IPv6 fragment header to
       indicate that the sender allows fragmentation.
    
    Are these 2 paragraphs in conflict?
  6. Tim Polk: Discuss [2010-08-11]:
        Tero Kvinen's security directorate review indicated that the security
    considerations are incomplete with respect to the impact of IPsec's AH and ESP
    on translation.  I have not seen a response to this message (and there have been
    no
    updates to the document), and personally believe these issues should be
    addressed.  That is, I consider these issues
    blocking.  Please work with Tero to
    scrub the text!
    
    The full message is available at:
                      http://www.ietf.org/mail-
    archive/web/secdir/current/msg01762.html 
        
  7. Sean Turner: Comment [2010-08-11]:
    I support Tim's DISCUSS position.

draft-ietf-ippm-twamp-reflect-octets

  1. Ron Bonica: Comment [2010-08-09]:
      == Unused Reference: 'RFC5226' is defined on line 738, but no explicit
         reference was found in the text
  2. Stewart Bryant: Comment [2010-08-09]:
     Nits says:
    
     Unused Reference: 'RFC5226' is defined on line 738, but no explicit
         reference was found in the text
    
  3. Adrian Farrel: Comment [2010-08-11]:
    [See also Peter's Comment]
    
    Section 4.2.1
    
    There is a bit of a 2119 mess as follows...
    
       When simultaneously using the RECOMMENDED truncation process in TWAMP
       section 4.2.1 [RFC5357] AND Reflect octets mode, the Session-
       Reflector MUST reflect the designated octets from the Session-
       Sender's test packet in the "Packet Padding (from Session-Sender)"
       Field, and MAY re-use additional Packet Padding from the Session-
       Sender.
    
    I think "AND" is not a 2119 term, and "RECOMMENDED" is used here simply
    to report on what RFC 5357 says. How about...
    
       Section 4.2.1 of [RFC5356] recommends a truncation process for use in
       TWAMP. When that process is used in conjunction with the Reflect 
       octets mode, the Session-Reflector MUST reflect the designated octets
       from the Session-Sender's test packet in the "Packet Padding (from
       Session-Sender)" Field, and MAY re-use additional Packet Padding from
       the Session-Sender.
    
    The problem with the use of "RECOMMENDED" shows up in a number of other
    places. It also seems to encourage the use of other non-2119 words (such
    as "IF" in Section 3.3).
  4. David Harrington: Comment [2010-08-11]:
    1) It would be helpful to include a little explanation as to why the symmetric-
    size option is needed, probably in paragraph 4 of section 1.
    2) I'm not sure
    what RFC???? refers to; it this an internet-draft?
  5. Alexey Melnikov: Comment [2010-08-07]:
       This field communicates the length of the padding in the TWAMP-Test Packet
    that
       the Session-Sender expects to be reflected, and the length of octets
    that the Session-Reflector SHALL return in include in its TWAMP-Test
    
    This doesn't read well. I think you should either delete "return in" or "include
    in".
    
       packet format (see section 4.2).
    
    3.4.  Additional considerations
    
       A Control-Client conforming to
       this extension of [RFC5357] MAY ignore the values in the higher bits
       of the Modes Field, or it MAY support other features that are
       communicated in those bit positions.  The other bits are available
       for future protocol extensions.
    
    Is it Ok for this document to define this? I think this is already defined in
    the base spec.
    
    6.2.  Registry Contents
    
       TWAMP Modes Registry is recommended to be augmented as follows:
    
       Value  Description             Semantics Definition
       0      Reserved
    
       1      Unauthenticated         RFC4656, Section 3.1
    
       2      Authenticated           RFC4656, Section 3.1
    
       4      Encrypted               RFC4656, Section 3.1
    
       8      Unauth. TEST protocol,  RFC5618, Section 3.1 (3)
              Auth. CONTROL
       16     Individual Session      RFC????, Section 3.1
              Control                 bit position (4)
    
    Please don't repeat existing registry entries in the IANA Considerations
    section. The current list is maintained by IANA and any list specified in an RFC
    can quickly get out of date.
  6. Peter Saint-Andre: Discuss [2010-08-10]:
        This specification states that "the Reflect octets mode re-designates the
    original TWAMP-Test (and OWAMP-Test) Packet Padding Field (see section 4.1.2 of
    [RFC4656])".  Therefore it appears that this specification formally updates RFC
    4656. However, the document header notes only that it updates RFC 5357. 
        
  7. Peter Saint-Andre: Comment [2010-08-10]:
    1. There are numerous instances of the text "the RECOMMENDED truncation process
    in TWAMP section 4.2.1 [RFC5357]"; there is no need for the word "recommended"
    to be all-caps here, because the normative language already exists in RFC 5357.
    
    2. Some of the typography is non-standard, such as "*continues*" and "IF" and
    "AND" and "BOTH"; it's better to provide emphasis using normal English words,
    such as "it is important to note that X continues" and "if and only if".

draft-ietf-softwire-ds-lite-tunnel-option

  1. Jari Arkko: Discuss [2010-08-12]:
        This document is ready to move forward. However, there is one issue
    that i would like to briefly discuss before recommending the final
    approval of the RFC.
    
    We have been pushing back in other cases when people defined both
    FQDN and IP address information for the same configuration item in
    DHCP. Why are two options and configuration mechanisms absolutely 
    necessary in this case? Wouldn't IP-address based configuration
    suffice? 
        
  2. Jari Arkko: Comment [2010-08-12]:
    
        
  3. Adrian Farrel: Comment [2010-08-11]:
    Section 4 carries a couple of "MUST NOT" with respect to the DS-Lite
    Name option. It would be well to describe what a receiver is supposed
    to do in the event of a breach.
  4. David Harrington: Discuss [2010-08-10]:
        This document appears to be in good shape. I have a few clarifying questions 
    
    1) in section 5, 
    The server MUST provide a way to configure the OPTION_DS_LITE_ADDR,
       and SHOULD allow the operator to enter a Fully Qualified Domain Name,
       upon which the server performs DNS Resolution to assemble its
       OPTION_DS_LITE_ADDR contents.
    does the server really perform DNS resolution when an FQDN is entered? 
    
    what if the client and server have access to different DNS servers?
    Couldn't you
    run into a situation where the server cannot resolve the FQDN but the client
    could?
    or vice-versa?
    
    I see there is a DNS_SERVERS option, but this would presumably be configured
    from the DHCP server perspective.
    Could the client have difficulty reaching the
    specified DNS servers, due to firewalls, NATs, or routing? 
    The text doesn't say
    the DNS_SERVERS option must contain servers reachable by both server and client,
    and I don't know whether it is reasonabe to require that knowledge at time of
    configuration, and for it to be true at time of use.
    
    2) in a related question, 
    If the server is configured with an FQDN as the
    tunnel endpoint
       locator, the configured FQDN value MUST contain a resolvable
    Fully
       Qualified Domain Name, having appropriate delegations from the root,
    and having a AAAA record locating the Softwire Concentrator.
    what happens if the
    client and server have different capabilities to get a AAAA record,
    maybe
    because of a NAT at IPvX boundaries?
    
    3) in section 6,
       A client that supports B4 functionality of DS-Lite (defined in
       [I-D.softwire-ds-lite-04]) MUST include OPTION_DS_LITE_ADDR on its
       OPTION_ORO, and MAY include OPTION_DS_LITE_NAME at its option and
       ability.
    
    Is this a new compliance requirement for B4s that could render existing
    compliant B4 implementations non-compliant? 
        
  5. David Harrington: Comment [2010-08-10]:
    1) in the INtroduction, the first mention of AFTR should be spelled out and
    given a reference.
    (I am aware it is spelled out in the Abstract, but I think ti
    should also be spelled out here.
    
    2) it would be good to identify the specific registry in the IANA registries
    (e.g., by URL), and to provide the added values formatted to match the existing
    registry.
    
    
  6. Alexey Melnikov: Discuss [2010-08-07]:
        This is a DISCUSS DISCUSS:
    
    3.  The Dual-Stack Lite Address DHCPv6 Option
    
       The client validates the DS-Lite Address option by confirming the
       option is of 16 octets in length or greater.  The client MUST ignore
       any tunnel-endpoint-addr shorter than 16 octets.  In the event the
       option is greater than 16 octets in length, only the first 16 octets
       are interpreted.
    
    Is there any good reason to tolerate any value of this option with length != 16?
     
        
  7. Alexey Melnikov: Comment [2010-08-07]:
    Should the document be clear that non-ASCII (IDN) FQDN are not allowed, i.e.
    that any such name must be punycode-encoded?
  8. Peter Saint-Andre: Discuss [2010-08-10]:
        The meaning of "FQDN" seems to be underspecified. Is this limited to a
    "traditional domain name", i.e., a fully qualified domain name all of whose
    labels are "LDH labels" (as defined in RFC 5890)? Or can the HostName type be an
    "internationalized domain name", i.e., a DNS domain name at least one of whose
    labels is a "U-label" or "A-label" (as defined in RFC 5890)? If this document
    inherits its definition of FQDN from Section 8 of RFC 3315, then it would be
    good to make that clear and specify that internationalized labels from IDNs need
    to be represented as A-labels. 
        

draft-ietf-tls-rfc4366-bis

  1. Ron Bonica: Comment [2010-08-09]:
      == Unused Reference: 'RFC2119' is defined on line 1027, but no explicit
         reference was found in the text
    
      -- Obsolete informational reference (is this intentional?): RFC 2246
         (Obsoleted by RFC 4346)
    
      -- Obsolete informational reference (is this intentional?): RFC 4346
         (Obsoleted by RFC 5246)
    
      -- Obsolete informational reference (is this intentional?): RFC 4366
         (Obsoleted by RFC 5246)
  2. Pasi Eronen: Comment [2009-11-02]:
    
        
  3. Adrian Farrel: Discuss [2010-08-11]:
        I don't think it is right that Section 10.1 includes the text
    
       Published specification: [RFC4366], and [RFC5280].
    
    yet this document claims to obsolete RFC 4366. 
        
  4. Adrian Farrel: Comment [2010-08-11]:
    The RFC Editor will require that you remove the citation from the 
    Abstract. This is usually done by replacing it with the document
    name and RFC number.
  5. Alexey Melnikov: Discuss [2010-08-11]:
        This is an important document and I support its publication. However I would
    like to discuss a few things before recommending its approval:
    
    1)
    3. Server Name Indication
    
          struct {
              NameType name_type;
              select (name_type) {
                  case host_name: HostName;
              } name;
          } ServerName;
    
          enum {
              host_name(0), (255)
          } NameType;
    
          opaque HostName<1..2^16-1>;
    
          struct {
              ServerName server_name_list<1..2^16-1>
          } ServerNameList;
    
     [...]
    
       However, for backward compatibility, all future NameTypes
       MUST begin with a 16-bit length field.
    
    Can you please clarify what this means?
    I am looking at both ServerName and
    NameType definitions and I don't see what you are talking about.
    
    2)
    5. Client Certificate URLs
    
       The TLS server is not required to follow HTTP redirects when
       retrieving the certificates or certificate chain.
    
    This is not strong enough for interoperability. Either redirects MUST be
    followed, or they MUST NOT be followed. Alternatively there need to be some
    explanation of why SHOULD (or even MAY) is appropriate here.
    
       The URLs used in
       this extension SHOULD therefore be chosen not to depend on such
       redirects.
    
    3)
    5. Client Certificate URLs
    
       If a server encounters an unreasonable delay in obtaining
    
    This is not very specific. Can a minimal value be recommended here?
    
       certificates in a given CertificateURL, it SHOULD time out and signal
       a certificate_unobtainable(111) error alert.
    
    What are possible alternatives to the SHOULD?
    
       This alert MAY be fatal;
       for example, if client authentication is required by the server for
       the handshake to continue. 
        
  6. Alexey Melnikov: Comment [2010-08-11]:
    I am agreeing with Peter's DISCUSS.
    
    Additionally, I have the following comments:
    
    10.1 pkipath MIME Type Registration
    
    The "Encoding Considerations" section should say that the data is binary.
    
      Person & email address to contact for further information:
          Magnus Nystrom <magnus@rsasecurity.com>
    
    I vaguely remember that Magnus has changed jobs since, so this email address is
    no longer valid.
  7. Dan Romascanu: Discuss [2010-08-12]:
        This is a DISCUSS-DISCUSS that I expect to clear during of after the telechat.
    This document obsoletes RFC 4366 (if approved) which seems to be correct.
    However, 4366 is already obsoleted by 5246 which may not be accurate. Actually
    can we have one RFC obsoleted by more that one newer RFC? 
        
  8. Dan Romascanu: Comment [2010-08-12]:
    
        
  9. Peter Saint-Andre: Discuss [2010-08-09]:
        The "HostName" type seems to be underspecified. Is this limited to a
    "traditional domain name", i.e., a fully qualified domain name all of whose
    labels are "LDH labels" (as defined in RFC 5890)? Or can the HostName type be an
    "internationalized domain name", i.e., a DNS domain name at least one of whose
    labels is a "U-label" or "A-label" (as defined in RFC 5890)? As far as I can
    see, the description "represented as a byte string using ASCII encoding without
    a trailing dot" does not exclude IDNs containing A-labels. If the intent is to
    support IDNs, then it would be good to note that fact, because otherwise
    eliminating the UTF-8 representation of the HostName type might be considered a
    step backward (unless there are plans to define a new i18nHostName type). 
        

draft-elie-nntp-list-additions

  1. Adrian Farrel: Comment [2010-08-11]:
    It seems to me that [RFC2980] might usefully be a normative reference 
    since this document purports to update it.
  2. Alexey Melnikov: Discuss [2010-08-12]:
        Holding a temporary DISCUSS for IANA, to let IANA verify that the new IANA
    Considerations section is Ok 
        
  3. Peter Saint-Andre: Comment [2010-08-10]:
    This specification is clear, complete, and well-written. Here are a few small
    items to consider.
    
    1. In Section 2.3.2, the phrase "at least all" is awkward -- I suggest changing
    it to "all".
    
    2. In Section 2.4.2, the text "although these situations SHOULD NOT occur if the
    news server is an injecting agent that carries moderated newsgroups" is merely
    informative, so it would be good to change "SHOULD NOT occur" to "should not
    occur" or "are unexpected" or something else non-normative.
    
    3. In Section 2.5.2, change "date of last modification date" to "date of last
    modification" or "last modification date".
    
    4. In Section 7, the definition does not include a descriptive name for the
    extension. However, perhaps the descriptive name is "LIST"?
    
    5. In Section 7, the "Contact for Further Information" is "Author of this
    document", but no contact information is provided (e.g., an email address).
  4. Sean Turner: Comment [2010-08-11]:
    #1) Sec 2: should "optional" be "OPTIONAL"?

draft-ietf-ipsecme-roadmap

  1. Adrian Farrel: Comment [2010-08-11]:
    Thanks for what must have been a pretty painful task. I think this makes a
    useful document.
  2. Tim Polk: Comment [2010-08-12]:
    (1) I understand that this is a forklift upgrade for RFC 2411, so the usual
    "Changes Since ..." section would not be
    helpful.  However, this document has a
    very similar title and does obsolete 2411 if approved.  Perhaps a few
    sentences
    in the intro to describe that relationship would be useful!
    
    (2) RFC 5282 should be added to the list of base documents in section 4.1.2,
    IKEv2.  As noted in section 5.4, 5282
    added the capability to negotiate combined
    mode algorithms to IKEv2.
    
    (3) Section 5.4.3 is misplaced.  GMAC is an Integrity protection algorithm and
    should appear in section 5.3. This 
    will necessitate forward pointers to section
    5.4, since it is based on a combined mode algorithm, but it does not fit
    with
    the other algorithms in 5.4 which are providing both encryption and integrity-
    protection.
    
    (4) In section 5.2.1, last sentence of the first paragraph:
    
    This number (the
       value 11 for ESP_NULL) is found on the IANA registries for
    both IKEv1
       and IKEv2, but it is not mentioned in this RFC.
    
    "this RFC" is ambiguous - I gather the authors meant RFC 2410 (since the
    value is clearly mentioned in *this* RFC).  I suggest:
    
    s/this RFC/[RFC2410]/

draft-ietf-behave-v6v4-framework

  1. Gonzalo Camarillo: Comment [2010-08-04]:
    The taxonomy of applications in Section 1.3 seems useful. However, the
    definition of P2P applications can be confusing. For example, SIP is classified
    as a P2P application and not as a client/server application . However, entities
    in SIP are called user agent clients, user agent servers, proxy servers,
    redirect servers, etc. Using a different term instead of P2P to classify those
    types of applications would make that section clearer. However, since this is
    not substantial to the draft, I leave it up to the authors whether or not to
    make this change.
  2. Dan Romascanu: Comment [2010-08-10]:
    This is a well-written, clear document, useful reading to understand the other
    documents in the bucket.
    
    A few non-blocking comments: 
    
    1. It would be useful to expand acronyms at first ocurence - e.g. NAT-PT, AAAA
    record, A record, MTA, SIIT, etc.
    
    2. It would be useful to add the network management protocols (SNMP, NETCONF)
    and the AAA protocols (Diameter, RADIUS) in the examples of client-server
    protocols in section 1.3. Deployment of these protocols is one of the issues
    network operators encounter in the transition scenarios.
    
    3. At the begining of section 2 - s/translation solution/translation solutions/

draft-ietf-forces-applicability

  1. (none)

draft-ietf-forces-implementation-report

  1. Tim Polk: Comment [2010-08-11]:
    I support Dan's discuss.  To my reading, two interoperable implementations of
    the security features are needed
    to fully satisfy the requirements for Draft
    Standard specified in 2026.  The requirements were loosened in 5652
    (see section
    6.2) but I do not think there would be IETF consensus to support an exception
    case for *all* the
    security features.
    
    At a minimum, I know one Security AD that would object... :)  
    
    The simplest solution would be to remove the first sentence in section 3.
    Creating and demonstrating the
    interoperability of two implementations of the
    security features would more difficult but more rewarding.
  2. Dan Romascanu: Discuss [2010-08-10]:
        The following issue is based on an observation made by Pekka Savola in his OPS-
    DIR report.
    
    In Section 3 (Summary) the following statement is being made: 
    
    >  The authors attest that the ForCES Protocol, Model and SCTP-TML meet
       the requirements for Draft Standard.
    
    However, Sections 5, 6.1.3.3 and 9 indicate that the (mandatory) SCTP-TML IPsec
    security framework was not implemented by any of the tested implementations and
    thus not tested for interoperability. I believe that the text in the Summary
    section needs to reflect this situation. 
        
  3. Dan Romascanu: Comment [2010-08-10]:
    
        
  4. Peter Saint-Andre: Comment [2010-08-10]:
    This is a fine document. Thank you for completing interoperability testing and
    for documenting the results!
    
    One nit: several acronyms are not expanded on first use (e.g., "PL" and "XML").

draft-ietf-v6ops-ipv6-cpe-router

  1. Stewart Bryant: Comment [2010-08-09]:
    For IPv6 multicast traffic the IPv6 CE router may act as an MLD proxy
       [RFC4605] and may support a dynamic multicast routing protocol.
    
    >> MLD not expanded on first use

draft-ietf-v6ops-isp-scenarios

  1. (none)

draft-presuhn-rfc2482-historic

  1. (none)

draft-davis-u-langtag-ext

  1. Peter Saint-Andre: Comment [2010-08-10]:
    This is a fine specification. Here are a few nits.
    
    1. Section 2.1 has the text "(for details see Section 3)" but that is a
    reference to Section 3 of UTS35, not to Section 3 of the RFC-to-be. Please
    either remove the parenthetical clause or state clearly "(for details see
    Section 3 of [UTS35])".
    
    2. There is a typo in "the first occurrence of an attributes or key conveys
    meaning"; it seems that "attributes" should be "attribute".
    
    3. In the text "[w]ith successive versions of [UTS35], additional attributes,
    keys, and types MAY be defined", I think "might" is better than "MAY" since
    there is no normative force to those words and therefore conformance terms don't
    apply.
    
    4. The information about accessing machine-readable files is helpful to
    developers, but might quickly become dated; I suggest providing a pointer to the
    CLDR project, such as "For information about retrieving machine-readable files
    listing the valid attributes, keys, and types associated with each successive
    version of [UTS35], visit <http://cldr.unicode.org>."
  2. Sean Turner: Comment [2010-08-11]:
    I suspect the RFC editor will complain about the compound reference for [UTS35].
    Are references to the specific sections needed?  If you want to keep them, then
    in the past the way I've seen it done (see RFC 5751) is to renumber 6.1 and 6.2
    to 6.2 and 6.3.  Add a new section 6.1 that addresses says [UTS35] refers to the
    three new reference tags.  In the new section 6.2, make up some reference tags
    like: [UTS35-All], [UTS-Sec3], [UTS-Sec5].  It might be easier to just remove
    them.
    
    Is the [US-ASCII] reference the same as:
    
        American National Standards Institute,
        "Coded Character Sets - 7-Bit American
        Standard Code for Information
        Interchange (7-Bit ASCII), ANSI X3.4",
        1986.
    
    I ask because this was the reference recently suggested to me for ASCII.

draft-baker-v6ops-greynet

  1. Ralph Droms: Comment [2010-08-12]:
    Question based on this statement:
    
       It has been observed [RFC5157] that address scanning is less
       effective in IPv6 [RFC2460] networks, as there are more addresses to
       scan.  The observation is of limited value, in that there are other
       approaches to identifying IPv6 systems, such as reading the
       'Received:' lines in SMTP envelopes.  Such attacks can be limited by
       the use of Privacy Addresses [RFC4941], which periodically change,
       rendering such historical information less useful, but the fact is
       that such analytic methods exist.  Greynets are a tool that can be
       used to isolate and analyze them.
    
    Is there any deployment experience that indicates greynets provide useful
    information in IPv6, where the traffic to be captured by the greynet may come
    from seeding information about "lit" IPv6 addresses rather than address or
    prefix scanning?

draft-nir-ipsecme-childless

  1. Adrian Farrel: Comment [2010-08-11]:
    The acronym "SA" is used in the Title, Abstract, and body without
    expansion.
    
    Other acronyms are also used in the body without expansion.

draft-saito-mmusic-sdp-ike