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

Valid HTML 4.01 Strict

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