IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-03-17. These are not an official record of the meeting.

Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)

Corrections from:

1 Administrivia

  1. Roll Call 1135 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. Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (Proposed Standard)
    draft-ietf-httpbis-content-disp-08
    Token: Alexey Melnikov
    Note: Mark Nottingham (HTTPBIS chair) is the document shepherd
    Discusses/comments (from ballot 3648):
    1. Stewart Bryant: Discuss [2011-03-14]:
      "When the value contains path separator characters ("\" or "/"), recipients SHOULD ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as "/etc/passwd")."
      ... or even intentionally over writing it - depending on your perspective.
      I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked like the last path segment. However I think that you mean that the file will be stored in "some-default-directory-but-not-slash/etc/passwd". It would be useful to clarify this in the text with an example.
      Why is this a SHOULD and not a MUST given the security implications?
      Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types.
    2. Stewart Bryant: Comment [2011-03-14]:
      "RFC 2616 defines the Content-Disposition response header field"
      I think that you need to say the Content-Disposition response header field of what. Same for Intro.
    3. Adrian Farrel: Comment [2011-03-16]:
      I have no objection to the publication of this document. There are a couple of small points that I think would benefit from attention first.
      Section 2 says that BNF from RFC 2616 is used. Section 3 metnions "ABNF". Is this the same (in which case please use consistent terminology) or different (in which case please supply a reference for ABNF).
      (See also Peter's Discuss
      Section 4.3 contains a number of bullets. The first one uses RFC 2119 language to specify behavior, but the remaining bullets use apple-pie language. Do you need to upgrade all bullets to RFC 2119?
    4. David Harrington: Discuss [2011-03-14]:
      1) is this document meant to update or obsolete 2183 (or not)? Per appendix B, this document omits parameters specified in 2183. Is this meant to obsolete those parameters?
      2) "This specification is expected to replace the definition of Content-Disposition in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis working group."
      Does this document obsolete/update the I-Ds being produced by httpbis? If so, which drafts?
      3) Does the grammar in 4.1 allow both filename and filename* to be specified?
      4) I think the statement
      "Senders MUST NOT generate Content-Disposition header fields that are invalid."
      should include a pointer to the specific rules about what is invalid.
    5. David Harrington: Comment [2011-03-14]:
      1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing.
      2) I agree with Stewart's concern about some additional security considerations that are not documented.
    6. Alexey Melnikov: Comment [2011-03-16]:
      In answer to David's DISCUSS:
      1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP.
      2) This document is not obsoleting/updating any other HTTPBIS WG I-D.
      3) Yes, both filename and filename* are allowed. That is intentional (for backward compatibility)
      4) The editor answered this, but there was a small edit in the document to add the cross reference.
    7. Dan Romascanu: Comment [2011-03-14]:
      Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and clarifies the reasons of some of the choices made by editors and the WG.
    8. Robert Sparks: Comment [2011-03-14]:
      Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at the end of Appendix D. Using a tool like purl.org helps make it easier to manage moving content around, but won't guarantee that that the content isn't a dangling reference or that it contains relative content in 20 years.
    9. Sean Turner: Discuss [2011-03-17]:
      #1) Sec 3.1 contains the following: "Recipients MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them."
      What's the default requirement? It needs to be reworded as follows: "As such, implementations SHOULD ignore invalid field by default."
      #2) Sec 4.3 contains the following: "Thus, recipients SHOULD ensure that a file extension is used that is safe, optimally matching the media type of the received payload."
      Why isn't this MUST. An implementation that doesn't do this is then vulnerable to the attacks you just described. Under what circumstances is this a good idea?
      #3) Sec 4.1 contains the following: "Header field values with multiple instances of the same parameter name are invalid."
      Is this a new requirement on HTTP headers or is this true of all HTTP headers?
      #4) Appendix D: Need normative reference for US-ASCII.
    10. Sean Turner: Comment [2011-03-17]:
      #1) Sec 4.1 contains the following phrase: "Furthermore note that the format used for ext-value allows specifying a natural language;"
      It would greatly help to include an "natural language (e.g., <insert text here>);"
      #2) Sec 4.3 contains the following phrase: "... a natural language ..."
      Could you provide and (e.g., <fill in the blank for me>). I didn't parse what this was.
      #3) Sec 8.2: Should the registration template include: "Related information: none"
      #4) App C.4 contains a table listing browsers, without version #s this table isn't of much use it - or is it all version?
      #5) App D contains the following: "[[fallbackbug: Firefox is known to pick the wrong parameter; a bug fix is scheduled for Firefox 5. --jre]]"
      Is this supposed to be removed?

    Telechat:

  2. Protocol for Access Node Control Mechanism in Broadband Networks (Proposed Standard)
    draft-ietf-ancp-protocol-15
    Token: Ralph Droms
    Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
    IPR: Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp-framework-08 and draft-ietf-ancp-protocol-05
    Discusses/comments (from ballot 3711):
    1. Adrian Farrel: Discuss [2011-03-16]:
      I have two issues related to version numbering that I would like to Discuss. Additionally, if time permits, I intend to return with a more in depth review of the protocol
      I am trying to work out how ANCP will co-exist with GSMP. It seems they both use the same port (6068) so I assume disambiguation happens on version number negotiation. But...
      A GSMP version number is an 8 bit number, with 0x03 being the current version. Since the GSMP version number is not currently tracked by IANA, there is a risk that a future version of GSMP will decide that 0x32 (i.e., version 50) will be used.
      I strongly suggest, therefore, that you need a new registry for the "GSMP and ANCP version Numbers". This will need some careful words to indicate that GSMP version 4 is allowed. You will also want to track ANCP sub-versions (but see below).
      [This point relates to part of Alexey's Discuss]
      I am really not happy about the lengths that are being gone to to support pre-standard implementations. I think this document should at least state that version 3.1 is not allowed. That is, it should not allow downward version negotiation from 3.2. Furthermore, sub-version 1 should be shown in the IANA registry as "reserved - not available for allocation".
      Furthermore, I see no reason to require the RFC Editor to make the various changes you request with respect to the version numbering. You should make these changes now.
    2. Russ Housley: Comment [2011-03-15]:
      The Gen-ART Review by Ben Campbell on 9-Mar-2011 raised a few minor points. Tom Taylor responded; he seems to agree with some of them. However, the document has not been updated yet. Please do so before approval.
    3. Alexey Melnikov: Discuss [2011-03-15]:
      [Updated: added one more issue in the DISCUSS section (look at the end of it)]
      This is a well written document and I don't have objections to its publication. However I would like to discuss the following issues before recommending its approval:
      3.1. Protocol Version: "GSMPv3 messages contain an 8-bit protocol version field. As described below, ANCP subdivides this into two 4-bit sub-fields, for version and sub-version. Implementations of this version of the ANCP specification MUST set the version sub-field to 3 and the sub-version sub-field to 1. That is, the hexadecimal representation of the value of the complete protocol version field MUST be 0x31."
      What is the meaning and semantics of version and subversion? The document is not clear on why the separation into version and subversion is needed.
      3.2. ANCP Transport: "Identifier: This 2-byte field identifies a GSMP or ANCP message. The type code for GSMP and ANCP messages is 0x880C (i.e., the same as GSMP's Ethertype)."
      Is it wise to reuse the same identifier, considering the statement elsewhere in the document that the 2 protocols are not really compatible?
      "The NAS MUST listen for incoming connections from the Access Nodes. Port 6068 is used for TCP connection."
      Does this need to be listed in the IANA Considerations section?
      4.5. Status-Info TLV: "Error Message: Human-readable string providing information about the warning or error condition. Padded with zeroes as necessary to extend to a four-byte word boundary."
      Typically human readable strings need some language tagging information. Please see <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for more details.
      8.5.1. OAM-Loopback-Test-Parameters TLV: "Byte 2: Timeout. Upper bound on the time in seconds that the NAS will wait for a response from the DSLAM. The value 0 MAY be used, but has a special meaning."
      What is the special meaning of 0?
      10. Security Considerations: "Security of the ANCP protocol is discussed in [RFC5713]. A number of security requirements on ANCP are stated in Section 8 of that document. Those applicable to ANCP itself are listed here:\..."
      This section is a bit think on TLS-specific details. In particular it doesn't describe how these requirements can be achieved with TLS (Note that TLS client authentication to the TLS server is optional, so not every ciphersuite is suitable to satisfy these requirements).
    4. Alexey Melnikov: Comment [2011-03-14]:
      5.1.1. Control Context (Informative): "Aside from its use in ANCP signalling, access line identification is also used in DHCP transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR-101] requires the AN or NAS in this role to add access line identification in Option 82 (Information) to each DHCP request it forwards to the DHCP server. It is desirable for efficiency that the identification used in this signalling should be the same as the identification used in ANCP messages."
      An informative reference to DHCP is needed here.
    5. Dan Romascanu: Discuss [2011-03-17]:
      In section 3.6.1.4: "In addition to any suggested action in the text which follows, the Code value SHOULD be logged in a MIB."
      If I was writing the MIB module and/or the instrumentation for MIB module I would not know what to do, What needs to be logged in a MIB module? (or MIB object? which of these?). The fact that the code value is supported? Each sending of a request? Each receive of a Request? Something else?
    6. Dan Romascanu: Comment [2011-03-17]:
      I support the DISCUSSes by Adrian and Alexey concerning the version number and the DISCUSS from Peter concerning the relationship with RFC 3292.
    7. Peter Saint-Andre: Discuss [2011-03-16]:
      The relationship between this specification and RFC 3292 is unclear and confusing.
      On the one hand, this document notes that modifies the GSMPv3 adjacency message format, the base GSMPv3 message format, the GSMPv3 Event message format, and the Port Management message format; therefore it appears to update RFC 3292. However, the specification does not indicate that it updates RFC 3292.
      On the other hand, this document points implementers to Sections 3.1.1, 9, and 11 of RFC 3292 for aspects of the protocol, thus introducing a normative dependency on parts of RFC 3292 while at the same time it updates other parts; why not simply copy the relevant text to this specification so that all the documentation is in one place, thus enabling us to remove the normative dependency on RFC 3292?
    8. Peter Saint-Andre: Comment [2011-03-16]:
      I concur with the DISCUSSes posted by Adrian Farrel and Alexey Melnikov.
    9. Robert Sparks: Discuss [2011-03-16]:
      Allowing ACNP agents to use any Code values from the (about to be modified) GSMPv3 Failure Response Message Name Space registry "if they appear applicable" seems underspecified. Could some guidance about when a code would NOT be applicable be added? Would an exhaustive list of applicability of the codes already registered (in the IETF Consensus ranges) be hard to produce? I take it from Tom's responses to some of the review comments that you do not expect GSMPv3 focused codes to be added to the registry, but if one ever were added (with a value below 256) that really was targeting GSMP and not ANCP, why not ask the registrant say so and capture it in the registry?
      Can the document explain when it might be reasonable to not follow the SHOULD in 3.6.1.7?
    10. Robert Sparks: Comment [2011-03-16]:
      I found the "must" convention distracting, and am skeptical of it's effectiveness as a way to communicate requirements to another SDO (which is what I understand its purpose to be based on the author's response to the genart review). If this remains in the document, please follow up and ensure it had the desired effect before trying the convention again.
      Section 3.6.1.6 speaks of incrementing transaction IDs linearly when I think it's really trying to say "by one". (If there's ever a chance of an intermediary being introduced in the path of these messages, it would help to say something now about whether recipients should care about gaps in the sequence they receive.)
    11. Sean Turner: Discuss [2011-03-17]:
      #1) DISCUSS-DISCUSS: I have to admit I'm completely out of my element here:
      If ANCP and GSMPv3 do kind of the same thing. Has there been thought to retiring GSMPv3? Are the two protocols going to gracefully co-exist?
      #2) Sec 10 includes security considerations from RFC 5713 with an informative reference. If these are the security considerations of ANCP aren't they normative? Unfortunately, RFC 5713 is informative and this would then be a DOWNREF.
    12. Sean Turner: Comment [2011-03-17]:
      #1) I support Alexey's discuss position on TLS.

    Telechat:

  3. A Profile for X.509 PKIX Resource Certificates (Proposed Standard)
    draft-ietf-sidr-res-certs-21
    Token: Stewart Bryant
    Note: Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3715):
    1. Ralph Droms: Comment [2011-03-15]:
      Minor editorial suggestion: In the Abstract, s/Resources (INRs)/Internet Number Resources (INRs)/
    2. Alexey Melnikov: Discuss [2011-03-17]:
      [Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam]
      This is a well written document and I generally support its publication.
      I was originally planning to file a DISCUSS on this issue, but though that the WG knows better. However Sam's SecDir review has changed my mind:
      Sam wrote: "I do not believe the concerns I raised in my secdir review have been addressed and I still have a deep architectural concern with the decision to prevent relying parties from accepting unknown non-critical extensions."
      There seems to be agreement with several points I raised:
      1) The profile does prohibit unknown extensions.
      2) I think there is agreement that before we can start using an error correction or new feature, we have to upgrade all software in the wild that might see the certificates.
      3) Everyone including me thinks that strong restrictions on what certificates are created is good for this profile. The question is what about restrictions on what people receive. If the IETF changes the standard in the future do we want to have to upgrade issuers and consumers or just issuers before we start using the new spec in what we issue.
      4) We may find ourself in a situation where we made a mistake or need to expand what the RPKI does.
      Adding from myself:
      I think there is no disagreement that extensions not listed in this profile SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting itself in the foot by making receivers reject certificates with unrecognized non critical extensions. A much better architectural approach would be to say that such non critical extensions "MUST be ignored". This is a pretty standard trick in the Apps Area and allows for safe extensibility.
      I also have a small list of [nearly] nit-picking items which I think need to be addressed before it is approved for publication:
      4.9.6. CRL Distribution Points: "The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this Issuer. The RPKI uses the URI form of object identification."
      This needs a Normative reference to the URI RFC.
      "The sequence of distributionPoint values MUST contain only a single DistributionPoint. The DistributionPoint MAY contain more than one URI value. An RSYNC URI [RFC5781] MUST be present in the"
      This makes the reference Normative (and it is a DownRef).
    3. Alexey Melnikov: Discuss [2011-03-12]:
      This is a well written document and I generally support its publication. I do however have a small list of [nearly] nit-picking items which I think need to be addressed before it is approved for publication:
    4. Alexey Melnikov: Comment [2011-03-12]:
      4.4. Issuer: "The value of this field is a valid X.501 distinguished name."
      A reference to the document defining DNs is needed here. (One of the LDAP documents might do.)
      "An Issuer name MUST contain one instance of the Common Name attribute and MAY contain one instance of the Serial Number attribute. If both attributes are present, it is RECOMMENDED that they appear as a set. The Common Name attribute MUST be encoded as a printable string."
      Similarly, a reference for printable string is needed.
      4.9.8.1. SIA for CA Certificates: "The ordering of URIs in this accessDescription sequence reflect the CA's relative preferences for access methods to be used by RPs, with he first"
      s/he/the
      6.2.1. CRMF Resource Certificate Request Template Fields: "version: This field SHOULD be omitted. If present, it MUST specify a request for a Version 3 Certificate. It"
      Unfinished sentence?
    5. Tim Polk: Comment [2011-03-17]:
      I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not typical for IETF publications. It would be good for the IESG to discuss the merits and drawbacks of the wg's consensus approach.
      However, I should note that I personally am comfortable with the approach based on the unique attributes of its intended deployment and application. Various aspects of this problem have been actively discussed since Stockholm.
    6. Peter Saint-Andre: Comment [2011-03-17]:
      Although I am provisionally balloting "No Objection" pending discussion within the IESG, I too am concerned about the issues raised in Alexey Melnikov's DISCUSS.
    7. Sean Turner: Comment [2011-03-10]:
      Need to add normative reference to RFC 2119 as per: http://www.rfc-editor.org/policy.html#policy.2119ref
      "Valid From" should be "Not Before" and "Valid To" should be "Not After" to match the name of fields in RFC 5280.

    Telechat:

  4. Certificate Policy (CP) for the Resource PKI (RPKI (BCP)
    draft-ietf-sidr-cp-16
    Token: Stewart Bryant
    Note: Sandra Murphy (Sandra.Murphy@cobham.com ) is the document shepherd.
    Discusses/comments (from ballot 3716):
    1. Ralph Droms: Comment [2011-03-16]:
      A few nits:
      Abstract: s/Internet resource/Internet Number Resource/
      Introduction: s/Internet number resource/Internet Number Resource/
      In section 2.4, should this text use RFC 2119 terms: "This data is supposed to be accessible to the public."
      Why are sections 5.1.*, 5.2.* listed as sections with no text?
    2. Adrian Farrel: Comment [2011-03-17]:
      I have No Objection to the publication of this document, but there are a couple of nits I hope the authors will attend to before publication.
      Missing close parenthesis in the document title.
      In the Introduction... "Note: This document is based on the template specified in the Internet Engineering Task Force (IETF) standards document RFC 3647 [RFC3647]. In the interest of keeping the document as short as reasonable, a number of sections contained in the template are omitted from this policy because they did not apply to this PKI. However, we have retained the section numbering scheme employed in the RFC to facilitate comparison with the outline in Section 6 of the RFC. Each of these omitted sections should be read as "No stipulation" in CP/CPS parlance."
      In the interests of disambiguity (for example, once this document has been published as an RFC) could you please s/the RFC/RFC 3647/ both times it shows.
      1.5.4. CP approval procedures: "The IESG MUST approve a replacement BCP that either updates or obsoletes this BCP, following the procedures of the IETF Standards Process as defined in RFC 2026 [RFC2026]."
      This is a little amusing. But I think you actually mean... "Any BCP that either updates or obsoletes this BCP, MUST be approved by the IESG following the procedures of the IETF Standards Process as defined in RFC 2026 [RFC2026].
      3.1.2. Need for names to be meaningful: "The Subject name in each certificate SHOULD NOT be "meaningful", i.e., the name is NOT intended to convey the identity of the Subject to relying parties."
      While I understnd the desire for stress, I think s/NOT/not/
      3.1.3. Anonymity or pseudonymity of subscribers: "Although Subject (and Issuer) names need not be meaningful, and may appear "random," anonymity is not a function of this PKI, and thus no explicit support for this feature is provided."
      Unless there is some special meaning of "pseudonimity" in the security community, I would suggest dropping it from the section title. The section text does not discuss the use of pseudonyms, and (to me) the use of a pseudonym is destinct from annonymity.
      3.1.5: s/Subject names/subject names/ at least twice
    3. Russ Housley: Comment [2011-03-15]:
      Please consider the minor issues raised in the Gen-ART Review by Francis Dupont on 24-Feb-2011.
    4. Alexey Melnikov: Comment [2011-03-12]:
      4.10. Certificate status services: "This PKI does not make provision for use of OCSP or SCVP, because it"
      Informative references are needed here.
    5. Peter Saint-Andre: Comment [2011-03-16]:
      Please expand "SIA" on first use and provide a reference if necessary.
      In section 4.2.1, I suggest changing "SHOULD never" to "SHOULD NOT".

    Telechat:

  5. RPKI Objects issued by IANA (Proposed Standard)
    draft-ietf-sidr-iana-objects-01
    Token: Stewart Bryant
    Note: Chris Morrow (christopher.morrow@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3727):
    1. Jari Arkko: Discuss [2011-03-17]:
      Section 8 has a MUST (see below for more details) that is not fully specified. The document should make it clear who can make exceptions on making ROAs for multicast addresses.
    2. Jari Arkko: Comment [2011-03-17]:
      What kind of change/CRL/processing load is expected from certification of unallocated space at IANA, as that space keeps changing (in the case IPv6)?
      From Ari Keränen's review:
      8. Multicast: "IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other multicast addresses unless directed."
      Directed by whom? Need to have, e.g., IESG Approval?
    3. Russ Housley: Comment [2011-03-16]:
      Please consider the comment from the Gen-ART Review by Wassim Haddad on 16-Mar-2011. I believe that improved clarity is desirable.
    4. Alexey Melnikov: Discuss [2011-03-17]:
      I am planning to ballot Yes on this document once my issues are discussed. I have a couple of discussion point for IESG which might or might result in some actions for editors.
      2) DISCUSS DISCUSS: 5. Reserved Resources: "Reserved IPv4 and IPv6 resources are held back for various reasons by IETF action. Generally such resources are not intended to be globally routed. An example of such a reservation is 127.0.0.0/8 [RFC5735]. IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed."
      Is IANA clear on where (in which RFCs) all such resources are described? The reference to [RFC5735] makes me think that it is only one example.
      "There are a small number of reserved resources which are intended to be routed, for example 192.88.99.0/24 [RFC3068]."
      As above.
    5. Alexey Melnikov: Comment [2011-03-17]:
      I feel much better about approving this document after reading draft-ietf-sidr-arch-12.txt. So I am moving my DISCUSS DISCUSS # 1 to the Comment section:
      1) DISCUSS DISCUSS: This document has lots of normative references to documents, some of which are not yet in IETF LC. I do feel that all of them actually need to be reviewed before approving this document, so I find it strange that this document is in IESG review first.
      I understand that I've done similar out-of-order IESG processing for some of my documents, so I don't claim to have a high moral ground here. However I would like to hear some explanation of why such exception is Ok in this case.
    6. Dan Romascanu: Comment [2011-03-16]:
      I support Alexey's DISCUSS and I have one supplementary question concerning the following paragraph in Section 5:
      "IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed."
      Why is this a should? Why not a MUST? If there are exceptions does IANA know and understand all cases when they apply?
    7. Robert Sparks: Comment [2011-03-15]:
      A document providing "specific direction to IANA" (and for which an interop statement is never going to make sense) would fit better as a BCP - why was PS chosen instead?

    Telechat:

  6. Logging recommendations for Internet facing servers (BCP)
    draft-ietf-intarea-server-logging-recommendations-03
    Token: Jari Arkko
    Note: Julien Laganier (julien.ietf@gmail.com) is the document shepherd
    Discusses/comments (from ballot 3736):
    1. Stewart Bryant: Comment [2011-03-15]:
      Please provide references for "NAT44, NAT64 or DS-Lite."
      If DS-Lite has a full name it should be used.
      NTP (need a ref) is not necessarily a traceable time source, it is certainly not a definitive source of time for legal purposes.
    2. Ralph Droms: Comment [2011-03-16]:
      I cleared my DISCUSS, based on e-mail from Alain Durand.
      For clarification, based on Alain's response, I suggest adding text explaining that the recommendations apply to current logging practice and port sharing does not require any changes in the way logging is performed; e.g., which packets are examined and logged.
      Editorial: I suggest the following minor change for clarity in section 2:
      OLD: "logging incoming IP addresses"
      NEW: "logging source IP addresses from inbound IP traffic"
    3. Russ Housley: Comment [2011-03-15]:
      Please consider the editorial comments from the Gen-ART Review by Francis Dupont on 5-Mar-2011.
    4. Alexey Melnikov: Comment [2011-03-07]:
      Various acronyms used need informational references, e.g. NTP.
    5. Sean Turner: Discuss [2011-03-15]:
      For the security area review:
      Please add a few other items to be considered out-of-scope or add additional security considerations. Since the document already mentions that record retention is out-of-scope, it would be useful to add that server security and transport security is important for the protection of logs for Internet facing systems. After stating that it is an important consideration, then state something to the effect of the service provider must consider the risks, including the data and services on the server to determine the appropriate measures.
      The protection of logs is critical in incident investigations. If logs are tampered with, evidence could be destroyed.

    Telechat:

  7. A Quick Crash Detection Method for IKE (Proposed Standard)
    draft-ietf-ipsecme-failure-detection-06
    Token: Sean Turner
    Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.
    Discusses/comments (from ballot 3738):
    1. Jari Arkko: Discuss [2011-03-17]:
      This is a very good specification, and I would have voted Yes if it weren't for one technical issue:
      I do not understand how Section 5.2 mechanism: "TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T)"
      works in an implementation that supports multihoming (e.g., RFC 4555). Can you clarify? I would expect that the document at least has to be clearer about this, or perhaps the Section 5.2 mechanism needs to be changed or removed to accommodate for multihoming.
    2. Adrian Farrel: Comment [2011-03-16]:
      Please expand acronyms on first use (such as "SA" in the Abstract)
    3. Dan Romascanu: Discuss [2011-03-16]:
      The DISCUSS and COMMENT is based in part on the OPS-DIR review performed by Menachem Dodge.
      This is a well written and useful document and I will support its approval after the following two issues are discussed and fixed if agreed:
      1. I would have expected that the Operational Considerations section include some information about configuration. It looks at a minimum the activation of the QCD method should be configurable, and the capability to shitch it off in networks where it involves a security risk should be provided.
      2. In Section 9.2 last paragraph, it is not completely clear as to what method should be implemented in the case of a load-sharing cluster when the load balancer cannot guarantee that all "IKE packets from the same source IP address always go to the same cluster". Should QCD Token Transmission not be implemented in such a situation?
    4. Dan Romascanu: Comment [2011-03-16]:
      1. An abbreviation sub-section would have been very useful
      2. Section 9.1 "QCD Token Generation and Handling", first paragraph, second sentence: Replace 'she' with 'they'
      OLD: "because if an attacker can guess the token associated with an IKE SA, she can tear down"
      SUGGESTED: "because if an attacker can guess the token associated with an IKE SA, they can tear down"
      3. Section 9.2 "QCD Token Transmission" 3rd paragraph last sentence: Replace 'it' with 'this'
      OLD: "One way to do it is to synchronize"
      SUGGESTED: "One way to do this is to synchronize"

    Telechat:

  8. GRE Key Extension for Mobile IPv4 (Proposed Standard)
    draft-ietf-mip4-gre-key-extension-04
    Token: Jari Arkko
    Note: Pete McCann (mccap@petoni.org) is the document shepherd.
    Discusses/comments (from ballot 3739):
    1. Stewart Bryant: Comment [2011-03-08]:
      "In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling."
      Well understated.
      FA, HA, RRP, MN, RRQ, RRP used without first expansion.
      It would be useful to the reader if the 'G' bit was called by it's proper name (GRE Encapsulation) on first used, same for the 'D' bit.
      'The FA may include a GRE key of value zero in the GRE Key Extension to signal that the HA assign GRE keys in both directions.' - Minor grammar problem.
      'Encapsulati on Unavailable' - - Minor grammar problem.
    2. Adrian Farrel: Comment [2011-03-16]:
      I have no objection to the publication of this documen, but there are a few small points that might be addressed to improve it.
      I don't think you need RFC 2119 notation in the Abstract.
      A number of acronyms are used without expansion
      Sections 4.1, 4.2, and 4.3 seem a bit confused on the use of RFC 2119 language and the cases where behavior is already defined in other specifications. Could you spend a little time to clear this up and make clear what new behavior this document is defining.
    3. Russ Housley: Comment [2011-03-16]:
      Something is wrong here:
      4.2. Home Agent Requirements for GRE Tunneling Support [RFC3344]
      The reference is misplaced. I think it belongs in the first sentence of the section.
      Please remove the extra spaces: "GRE encapsulation, it MUST send an RRP with code 'Requested Encapsulati on Unavailable (139)' [RFC3024]"
    4. Peter Saint-Andre: Comment [2011-03-16]:
      It would be nice to expand "GRE" on first use to "Generic Routing Encapsulation" and also provide a reference to RFC 2784.
    5. Sean Turner: Comment [2011-03-15]:
      1) Nits points out:
      - ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944)
      2) If you end up doing another revision, please:
      - a) expand GRE on 1st use in Abstract and Introduction.
      - b) add a period to the end of the 1st paragraph in Section 7.
      Otherwise, please consider these during AUTH48 (if the RFC editor doesn't catch them).

    Telechat:

2.1.2 Returning Items

  1. Advertising Generic Information in IS-IS (Proposed Standard)
    draft-ietf-isis-genapp-04
    Token: Stewart Bryant
    Discusses/comments (from ballot 3384):
    1. Jari Arkko: Discuss [2010-10-07]:
      I support the publication of this document and I think it is a good and proper addition to the ISIS protocol.
      However, I have a specific technical concern. Section 6 says: "The IS-IS WG of the IETF acts as the authority to determine whether information proposed to be advertised in IS-IS LSPs falls under this definition."
      But then Section 8 says: "Registration procedure is "Specification Required" as defined in [RFC5226]"
      If we are expecting to verify that the information falls under the right category, then Specification Required does not appear to be the right IANA rule. Or am I missing something?
    2. Jari Arkko: Comment [2010-10-07]:
      (blank)
    3. Ron Bonica: Comment [2011-03-16]:
      I share Lars' allergy to using routing protocols to transport generic information. Maybe we should start thinking about a generic information transport protocol.
    4. Lars Eggert: Discuss [2010-10-04]:
      I'm missing a crystal clear statement in a very visible spot that the content exchanged in GENINFO TLVs MUST NOT alter the behavior or operation of the IS-IS protocol and/or state machine. In other words, GENINFO is not a tool for a vendor to extended IS-IS in non-interoperable ways. The document does hint that this is the intent in a few places; I'm simply asking for making this very, very clear.
    5. Lars Eggert: Comment [2010-10-04]:
      (Non-actionable comment: I will likely abstain on this document even when the above change is made. The reason is that I'm allergic against the current trend of adding kitchen-sink options that turn all kinds of formerly purpose-built protocols info generic "information exchange" mechanisms.)
    6. Adrian Farrel: Comment [2010-12-12]:
      Thank you for this draft, it is a necessary addition to the IS-IS family and for your work to address my Discusses and Comments.
      I have two small, non-blocking Comments remaining that could be looked at if the authors continue to work on the document.
      I think that the RFC Editor will ask you to jiggle the content/section-headings slightly. They have a preference for seeing Section 1 named "Introduction".
      This Comment moved from the Discuss...
      I feel a bit of a lack discusion of backwards compatibility. You need to cover how a legacy implementation will react to seeing the new GENINFO TLV (a reference to an existing RFC will do), and then consider how this will apply to the utility of the extension (for example, if all speakers participating in the IS-IS instance must be upgraded - I think they will because otherwise they will not see the flags fields in the new TLV).
      It would be helpful to add a brief statement in Section 4 along the lines of: "According to the rules of [RFC4971] a legacy implementation receiving a GENINFO TLV will ..."
    7. Tim Polk: Discuss [2010-10-06]:
      The sole statement in the security considerations: "This document raises no new security issues for IS-IS."
      I don't think that is quite true, albeit in a rather cyclic manner.
      First, I believe that the use of IS-IS as a transport does have security implications that need to be considered when specifying a new geninfo application ID. It would be helpful to describe the limitations implied by this transport, and when additional security mechanisms can be employed to extend the scope. For example, the standard IS-IS cleartext password might be insufficient for some types of data, requiring deployment of RFC 5304 or 5310 authentication mechanisms.
      Second, deployment of advanced IS-IS security mechanisms (e.g., RFC 5310 authentication) is something I personally advocate. However, if an IS-IS deployment were to deploy these mechanisms solely to support advertisement of some generic information this may exacerbate any performance implications for the IS-IS deployment and could be used to launch denial of service attacks. That is, deploying IS-IS security mechanisms *because* of the generic information would be costly for the IS-IS implementation and would violate the usual precept of "security commensurate with need".
      I think a paragraph or two (total) in the security considerations that addresses both these issues would be appropriate.
    8. Tim Polk: Comment [2010-10-06]:
      I support Lars' discuss,
    9. Dan Romascanu: Comment [2011-03-15]:
      I dislike overloading protocols with exchanges of information that do not relate to the protocol functionality. However, at this phase, if the working group was chartered to do this work, I can accept such an extention as the GENINFO advertising of generic information. Separating it in a generic advertising extension rather than consuming from the expensive TLV space for each extension not related to routing is the right thing to do.
      Maybe the introduction should say something about the motivation for such a generic container within IS-IS and make possible recommendations of what future extensions using this container should include (or should not include).
    10. Peter Saint-Andre: Comment [2010-12-07]:
      (blank)
    11. Robert Sparks: Comment [2010-10-06]:
      I support Dan's discuss points.
      The document could better motivate the need for a generic container. Could it explicitly call out the existing messages that would have been candidates for the use of this mechanism if it existed at the time?
      Would it make sense to add text reinforcing that elements not understanding this TLV would ignore-but-flood?
    12. Sean Turner: Comment [2010-10-05]:
      1) Never seen 2119 language in Abstract. Is this allowed by the RFC editor?
      2) Spell out LSP on first occurrence.
      3) Sec 2: It's odd that there are requirements in the overview section. Could this be reworked?
      4) Sec 3 (and the rest of the document): RFC 5305 refers to sub-TLV not subTLV. This document should align with 5305.
      5) Sec 3.1: It would be nice if you assigned a word for the Flags: S (Scope), D (Down), I, and V. It would be nice to assign a word to for "I" and "V" too. How about Ipv4 for "I" and ipV6 for "V".
      6) Sec 3.2: RFC 5035 has to following text about ignoring unknown sub-TLVs: "Unknown sub-TLVs are to be ignored and skipped upon receipt." Does this draft want to use 2119 language to in fact require they be ignored?
      7) Sec 3.2: r/AND/and
      8) Sec 3.3: r/NOT/not
      9) Sec 7: r/IS-IS/IS-IS [RFC1195].

    Telechat:

  2. Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information (Proposed Standard)
    draft-ietf-geopriv-rfc3825bis-17
    Token: Robert Sparks
    Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).
    Discusses/comments (from ballot 3481):
    1. Jari Arkko: Comment [2010-12-02]:
      Ari Keränen reviewed this specification and he had a few comments:
      The abstract should state that this document obsoletes RFC 3825 and the intro should explain why it's done (as described in the I-D checklist).
      However, instead of obsoleting 3825, wouldn't it make more sense to have a new IPv4 DHCP option for this new version given that the new encoding is not compatible with the old one and re-using the same value seems to cause a lot of problems (as described in section 2.2.1)? Or otherwise it would be good idea to mention the reason (preserving DHCP codes?) for not doing so.
      2.3. Latitude and Longitude Fields: "Latitude values encoded by the DHCP server MUST be constrained to the range from -90 to +90 degrees. Location consumers MUST be prepared to normalize values outside this range. Values outside the range are normalized by clamping [...]"
      If the values MUST be within those boundaries, doesn't it mean that a value that is out of the range is somewhat likely completely wrong (due to a broken implementation) and thus it would make sense to ignore it rather than try to normalize the value and make it appear as if it was valid? I'm not sure if I'd like to be liberal in what I accept when it comes to information that could literally be a matter of life and death.
    2. Stewart Bryant: Comment [2010-12-01]:
      PIFF-LO term used but not defined
      GML term used but not defined
      Code: GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
      AType: Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in two places)
    3. Ralph Droms: Comment [2011-02-04]:
      I've cleared my DISCUSS. I have a remaining minor comment - In the descriptions of the options, sentences like: "When the Ver field = 1, this field represents latitude uncertainty. The contents of this field is undefined for other values of the Ver field."
      seem unnecessarily detailed. Why not simply: "This field represents latitude uncertainty."
      The descriptions of many fields say nothing about the version number.
    4. David Harrington: Comment [2010-11-30]:
      This document is well-written, with clear and unambiguous language.
      1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID with the geographic location where the identified circuit terminates (such as the location of the wall jack)."
      Would it be the job of the DHCP server to do this correlation? I would assume it was a NM application function to do such correlation.
      2) In 2.2.1.2, s/same response. This is not useful since/same response, since/
      3) When aType=2, numbering starts at ground level. How does one represent an underground parking garage level? Should 2.4.3 mention how to represent this? Should Appendix B include such an example?

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Mobile Networks Considerations for IPv6 Deployment (Informational)
    draft-ietf-v6ops-v6-in-mobile-networks-03
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3612):
    1. Ralph Droms: Comment [2011-03-16]:
      Seems like any statements like the following predicting the final allocation of IPv4 addresses are likely to be out-of-date or inaccurate. I suggest eliding text like the following from section 3.1: "The '/8' IANA blocks for Regional Internet Registries (RIRs) are projected to 'run-out' soon. Subsequently, the addressing pool available to RIRs for assignment to Internet Service Providers is anticipated to run-out in the following 2-3 years."
    2. Russ Housley: Comment [2011-03-15]:
      Following the Gen-ART Review by Kathleen Moriarty on 21-Feb-2011, several changes were agreed. However, a revised document has not been posted yet. Please make sure the revisions get included.
    3. Sean Turner: Comment [2011-03-17]:
      The tense of the 1st sentence in the abstract and intro should probably be changed because the pool is now empty.

    Telechat:

  2. IMAP4 Multimailbox SEARCH Extension (Experimental)
    draft-ietf-morg-multimailbox-search-07
    Token: Peter Saint-Andre
    Note: Timo Sirainen <tss@iki.fi> is the Document Shepherd.
    Discusses/comments (from ballot 3642):
    1. Stewart Bryant: Comment [2011-03-16]:
      ID-nits reports:
      -- The draft header indicates that this document updates RFC4466, but the abstract doesn't seem to mention this, which it should.

    Telechat:

  3. Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693 to Historic Status (Informational)
    draft-eggert-tcpm-historicize-02
    Token: David Harrington
    Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
    Discusses/comments (from ballot 3644):
    1. Adrian Farrel: Comment [2011-03-16]:
      I am ballotting "Yes" on this document, but there are a few issues I would like the author to consider before the document is passed to the RFC Editor.
      Abstract: Please change this text from a "recommendation" to an "action"
      Surely this is a Historic RFC in its own right? I.e., RFC 1072 et al are obsoleted by a Historic RFC.
      Section 2: "The RFC Editor is requested to change the status of the following RFCs to Historic [RFC2026]"
      I'm confused. Can the status of an existing RFC be changed? I thought it could only obsoleted.
      Section 3: This says IANA should mark as "obsolete". Shouldn't you use "deprecated"?
      I think you also need to tell IANA exactly what references they should place against each deprecated option.

    Telechat:

  4. Host Identity Protocol Certificates (Experimental)
    draft-ietf-hip-cert-12
    Token: Ralph Droms
    Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3698):
    1. Adrian Farrel: Comment [2011-03-01]:
      Agree with Peter's Discuss. The update to 5201 should be noted in the document header and the Abstarct.
      Section 2: "It MAY either carry SPKI certificates or X.509.v3 certificates.
      I think lower case "may" is more appropriate. Unless you mean... "It MUST carry either SPKI certificates or X.509.v3 certificates."
    2. Russ Housley: Discuss [2011-03-15]:
      This discussion on the PKIX mail list is continuing. Today the topic of unambiguous naming is still under discussion.
    3. Tim Polk: Comment [2011-03-17]:
      I support Russ's discuss position. We need to let the PKIX discussion run its course.
    4. Peter Saint-Andre: Comment [2011-03-09]:
      (blank)
    5. Sean Turner: Comment [2011-03-16]:
      (blank)

    Telechat:

  5. An Infrastructure to Support Secure Internet Routing (Informational)
    draft-ietf-sidr-arch-12
    Token: Stewart Bryant
    Note: Sandra Murphy (Sandra.Murphy@cobham.com ) is the document shepherd.
    Discusses/comments (from ballot 3717):
    1. Jari Arkko: Comment [2011-03-17]:
      From Ari Keränen's review:
      9. IANA Considerations: "This document requests that the IANA issue RPKI Certificates for the resources for which it is authoritative, i.e., reserved IPv4 addresses, IPv6 Unique Local Addresses (ULAs), and address space not yet allocated by IANA to the RIRs.
      It would be good to have explicit references to the documents where each of these "resources" are defined.
      draft-ietf-sidr-iana-objects-01 lists also AS numbers as such a resource; should that be listed here too?
    2. Adrian Farrel: Comment [2011-03-17]:
      I am balloting "Yes" for this document, but there are a few minor nits that I hope the authors will attend to before publication.
      The Introduction uses "CRL" without explanation. This does show up in the Terminology section that follows immediately, but it would be nice to clarify in the Introduction.
      CRLDP shows up in Figure 3 and nowhere else in the document. Please add a note to the text.
      Figure 1 seems to be mysteriously missing.
      Section 4.3 has a slight disconnect between the specification of access protocols and the deployment of access protocols. Thus, when you say... "each function must be implemented by at least one access protocol."
      ...I think you mean... "each function must be implemented by at least one access protocol deployed by a repository operator."
      Similarly, when you say things like... "Download: Access protocols MUST support the bulk download of "
      ...it is ambiguous whether you mean "all access protocols" or "at least one access protocol in the suite of access protocols" or "at least one access protocol deployed by the repository operator"
      Section 4.3: "To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via RSYNC (see [RFC 5781] and [RSYNC]), although other download protocols also be supported.
      s/also/may also/
      Section 5: Since according to this text a manifest is a signed object, and since the manifest is presumable issued by the authority, I would assume that a manifest includes itself in its listing. But perhaps you should clarify this one way or the other.
    3. Russ Housley: Comment [2011-03-15]:
      Please consider the comments from the Gen-ART Review by David Black on 24-Feb-2011.
    4. Alexey Melnikov: Discuss [2011-03-15]:
      This is a well written document and I support its publication. However I have a small pedantic DISCUSS which should be easy to address:
      1). 9. IANA Considerations: "This document requests that the IANA issue RPKI Certificates for the resources for which it is authoritative, i.e., reserved IPv4 addresses, IPv6 Unique Local Addresses (ULAs), and address space not yet allocated by IANA to the RIRs. IANA SHOULD make available trust anchor material in the format defined in [SIDR-TA] in support of these functions."
      Is this the right document? I thought that was already specified in draft-ietf-sidr-iana-objects.
      2). 11.2. Informative References: "[RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI Scheme", RFC 5781, February 2010."
      This reference is Normative, because of the use of a MUST.
    5. Alexey Melnikov: Comment [2011-03-15]:
      4.2. Contents and structure: "For every certificate in the PKI, there will be a corresponding file system directory in the repository that is the authoritative publication point for all objects (certificates, CRLs, ROAs and manifests) verifiable via this certificate. A certificate's Subject Information Authority (SIA) extension provides a URI that references this directory.
      An Informative reference to the URI RFC is needed here.

    Telechat:

  6. PMIPv6 Localized Routing Problem Statement (Informational)
    draft-ietf-netext-pmip6-lr-ps-06
    Token: Jari Arkko
    Note: Basavaraj Patil (basavaraj.patil@nokia.com) is the document shepherd.
    Discusses/comments (from ballot 3735):
    1. Russ Housley: Comment [2011-03-15]:
      Please consider the comments in the Gen-ART Review by Joel Halpern on 7-Mar-2011. I believe the improved clarity will be helpful.
    2. Dan Romascanu: Comment [2011-03-16]:
      The comment is based in part on the OPS-DIR review performed by Nevil Brownlee.
      1) I do not think that the document needs to be blocked for this, but I think that such document should also deal with the the Operational and Manageability considerations and include a section on this respect. At a minimum I would have expected some refering or estimation on the impact on traffic parameters in the network as local routing is designed to reduce latency and backhaul load. Also do we expect any extra extensions or attributes to be needed in the interaction between MAG and RADIUS servers?
      2) Missing also is any mention of scalability. This document describes the problem of optimising routing in a Local (i.e. single provider, or maybe 2~3 providers) setting. Scaling issues will need to be considered in an actual specification (clearly it will have to handle the maximum number of active mobile nodes).

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. A Survey of Mobility Support In the Internet (Informational)
    draft-zhu-mobility-survey-03
    Token: Jari Arkko
    Discusses/comments (from ballot 3668):
    1. Stewart Bryant: Discuss [2011-03-16]:
      ID-Nits says:
      ** The document seems to lack a Security Considerations section.
      ** The document seems to lack an IANA Considerations section. (See Section 2.2 of http://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.)
      ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references.
    2. Stewart Bryant: Comment [2011-03-16]:
      I can't check the reference so I can't figure out if there is any trade name issue with reference "Sony". Did the authors of the paper work for Sony?
    3. Adrian Farrel: Comment [2011-03-17]:
      Support Stewart's Discuss. There is no reason for I-Ds to turn up in evaluation without having run idnits
    4. Russ Housley: Discuss [2011-03-16]:
      The authors agreed to some changes based on the Gen-ART Review by Richard Barnes on 28-Feb-2011. Please make those changes.
    5. Dan Romascanu: Comment [2011-03-17]:
      I support Stewart's DISCUSS.
      I am wondering why was this document AD-sponsored and did not go on the Independent Stream. It obviously required quite a lot of efforts from the sponsoring AD (and the rest of the IESG) as there is a lot of information about more than a dozen of protocols whose accuracy needs to be verified. Then there will be some more as the document has obvious formatting and document structure issues. It is not clear to me what is the benefit.
      Also, if we already are approving such a broad protocols survey I would have expected some informations about operational and manageability considerations. There is a discussion about deployment issues (which is good) but this is not sufficient.
    6. Peter Saint-Andre: Comment [2011-03-16]:
      This is a fine document and I support its publication as an Informational RFC.
      I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track each mobile's reachability during the mobile's moving") is colloquial and potentially confusing (e.g., in "mobile replies" is the term a noun or an adjective?). Because you do not want to distinguish between mobile nodes and mobile subnets, I suggest "mobile entity".
      (There are also typographical errors, such as "Protocols like E2E, ILNP and BTMM fail into this design" instead of "fall into", but I assume that those will be fixed during the RFC Editor's review.)

    Telechat:

  2. Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax (Informational)
    draft-herzog-static-ecdh-06
    Token: Tim Polk
    Note: Jonathan Herzog (jherzog@ll.mit.edu) is the document Shepherd.
    Discusses/comments (from ballot 3684):
    1. Adrian Farrel: Comment [2011-03-16]:
      I have No objection to the publication of this document, but I have a couple of minor editorial points that could usefully be fixed to improve the document.
      The term "MACed" is used without explanation.
      Section 1: "All three of these types share the same basic structure. First, a fresh symmetric key is generated."
      There is a slight syntactic disconnect between these two sentances. Do you mean the second sentance to be a process description (in which case a paragraph break would be in order)? Or do you mean to describe the shared basic structure in some way?
      Section 1: "key transport: the symmetric key is encrypted using the public encryption key of some recipient,"
      To be very picky... Do you mean "encryption key of the intended recipient"?
      And Later... "In this case, the participants are the originator and one of the recipients."
      Again "the intended recipient" seems a better phrase.
      But I am somewhat worried that you have said "one of the recipients" given that in the case of multiple recipients (that is implied by your language) I don't see how the other recipients will be able to function as they will not have access to the necessary key.
      Section 2: "the RecipientInfo kari choice is used."
      Is "kari" an unexplained term or a typo?
      "ukm" is used without expansion
      Section 2.1 contains a number of MUST statements. Section 2.3 should give an indication of what the receiver does when one of these MUSTs is violated. This may be as simple as a reference to [CMS].

    Telechat:

  3. Multiple Attachments for EDI-INT (Informational)
    draft-meadors-multiple-attachments-ediint-11
    Token: Alexey Melnikov
    Discusses/comments (from ballot 3688):
    1. Stewart Bryant: Comment [2011-03-16]:
      There are a number of id-nits that need be fixed before the document considered ready for publication (IANA section and RFC2119 language). Also the editor should confirm that all of the lower case "should" instances are correctly set.
    2. Russ Housley: Comment [2011-03-16]:
      In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is raised. Please consider it:
      There is a space in the declaration of boundary=" INNER-BOUNDARY"; in the example in section 3. I am not sure whether this was intentional or whether it will mess up a standard MIME parser, but you may want to remove it.
    3. Alexey Melnikov: Comment [2011-03-12]:
      Should this document be published with "no IETF consensus" boilerplate?
    4. Sean Turner: Discuss [2011-03-17]:
      update based on Alexey's RFC editor note.
      #1) In Sec 2.3, need a normative reference to the canonicalization method.
      #2) In Sec 2.5, need normative references for each content types list.
    5. Sean Turner: Comment [2011-03-16]:
      Sec 2.3 says: "If the expected MIC value differs from the calculated MIC value, all attachments MUST be considered invalid and retransmitted."
      Isn't telling the initiator that they didn't match and asking for the retransmission missing?

    Telechat:

  4. IPv6-to-IPv6 Network Prefix Translation (Experimental)
    draft-mrw-nat66-12
    Token: Ron Bonica
    Discusses/comments (from ballot 3710):
    1. Stewart Bryant: Discuss [2011-03-15]:
      The purpose of this discuss is to confirm that there are no undocumented issues associated with the use prefix bits in the range 64 to 127 to fix up the checksum. These are surely real network addresses elsewhere in the net, and therefore may be destinations addresses of packets passing through the translator.
      Section 4.3 states that a node MUST support hairpinning. Does it need to say that it MUST NOT do internal route optimization?
      Does an internal router placed between a host and the translator correctly route packets in this translated range?
    2. Stewart Bryant: Comment [2011-03-15]:
      STUN, TURN, ICE should have references

    Telechat:

  5. Understanding Apple's Back to My Mac (BTMM) Service (Informational)
    draft-zhu-mobileme-doc-05
    Token: Lars Eggert
    Discusses/comments (from ballot 3718):
    1. Lars Eggert: Discuss [2011-02-18]:
      I'm holding a discuss on my own document, because the IETF last call ends one day after the telechat date.
    2. Peter Saint-Andre: Comment [2011-03-16]:
      In Section 3 we find: "BTMM uses "_udp" to tunnel packets between the two ends to achieve NAT traversal."
      I think you mean "UDP", not "_udp".
    3. Sean Turner: Comment [2011-03-16]:
      #1) In Sec 7.1, I had trouble parsing the following:
      "When the user first signs in to MobileMe on a host, it automatically receives from KDC a digital certificate and private key for "Back to My Mac Encryption Certificate"."

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. Survey of proposed use cases for the IPv6 flow label (Informational)
    draft-hu-flow-label-cases-03
    Token: Jari Arkko
    Note: ISE submission
    Discusses/comments (from ballot 3740):
    1. Stewart Bryant: Discuss [2011-03-16]:
      This is a discuss discuss that I expect to clear on the call.
      This is a fine document and I have no objection to it's publication. However I am surprised that it has not gone through a WG. Review by a WG would result in a more complete validation that all the proposals had been captured, and that the conclusion represented the wider view of the IETF.

    Telechat:

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Verification Involving PSTN Reachability (vipr)
    Token: Robert

    Telechat:

  2. Address Resolution for Massive numbers of hosts in the Data center (armd)
    Token: Ron

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Softwires (softwire)
    Token: Ralph

    Telechat:

  2. Secure Inter-Domain Routing (sidr)
    Token: Stewart

    Telechat:

  3. Layer 3 Virtual Private Networks (l3vpn)
    Token: Stewart

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IESG statement on MIME type registrations from other SDOs in the standards tree with no drafts (Alexey Melnikov)

    Telechat:

  2. text/n3 and text/turtle Media Type registrations from W3C (Alexey Melnikov)

    Telechat:

  3. Using "Updates" to update IANA procedure (Alexey Melnikov)

    Telechat:

  4. Ports & Services BCP: final RFC Editor note about use of multiple ports for related protocols (Alexey Melnikov)

    Telechat:

7. Agenda Working Group News

1411 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-03-17 07:28:35 PDT)

draft-ietf-httpbis-content-disp

  1. Stewart Bryant: Discuss [2011-03-14]:
        When the value contains path separator characters ("\" or "/"),
          recipients SHOULD ignore all but the last path segment.  This
          prevents unintentional overwriting of well-known file system
          locations (such as "/etc/passwd").
    
        
  2. ... or even intentionally over writing it - depending on your perspective. I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked like the last path segment. However I think that you mean that the file will be stored in "some-default-directory-but-not-slash/etc/passwd". It would be useful to clarify this in the text with an example. Why is this a SHOULD and not a MUST given the security implications. ==== Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types.
  3. Stewart Bryant: Comment [2011-03-14]:
    "RFC 2616 defines the Content-Disposition response header field"
    
    I think that you need to say the  Content-Disposition response header field of
    what. Same for Intro.
    
    
  4. Adrian Farrel: Comment [2011-03-16]:
    I have no objection to the publication of this document. There are a couple f
    small points that I think would benefit from attention first.
    
    ---
    
    Section 2 says that BNF from RFC 2616 is used.
    Section 3 metnions "ABNF". Is this the same (in which case please use
    consistent terminology) or different (in which case please supply a
    reference for ABNF).
    
    (See also Peter's Discuss
    
    ---
    
    Section 4.3 contains a number of bullets. The first one uses RFC 2119
    language to specify behavior, but the remaining bullets use apple-pie
    language. Do you need to upgrade all bullets to RFC 2119?
    
  5. David Harrington: Discuss [2011-03-14]:
        1) is this document meant to update or obsolete 2183 (or not)? Per appendix B,
    this document omits parameters specified in 2183. Is this meant to obsolete
    those parameters?
    
    2) "This specification is expected to replace the definition of Content-
    Disposition in the HTTP/1.1 specification, as currently revised by
       the IETF
    HTTPbis working group."
    Does this document obsolete/update the I-Ds being
    produced by httpbis? If so, which drafts?
    
    3) Does the grammar in 4.1 allow both filename and filename*  to be specified?
    
    4) I think the statement "   Senders MUST NOT generate Content-Disposition
    header fields that are
       invalid." should include a pointer to the specific
    rules about what is invalid. 
        
  6. David Harrington: Comment [2011-03-14]:
    1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of
    the filename to be confusing.
    
    2) I agree with Stewart's concern about some additional security considerations
    that are not documented.
  7. Alexey Melnikov: Comment [2011-03-16]:
    In answer to David's DISCUSS:
    
    1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183
    specifies Content-Disposition header field for email only. This draft is a
    standalone version for HTTP.
    
    2) This document is not obsoleting/updating any other HTTPBIS WG I-D.
    
    3) Yes, both filename and filename*  are allowed. That is intentional (for
    backward compatibility)
    
    4) The editor answered this, but there was a small edit in the document to add
    the cross reference.
  8. Dan Romascanu: Comment [2011-03-14]:
    Why would Appendix C4 be removed at publication? I believe that it actually
    includes important information about the status of the implementations, and
    clarifies the reasons of some of the choices made by editors and the WG.
  9. Robert Sparks: Comment [2011-03-14]:
    Consider adding "At the time of publication of this document, " to the front of
    the sentence starting with the purl.org URL at the end of Appendix D. Using a
    tool like purl.org helps make it easier to manage moving content around, but
    won't guarantee that that the content isn't a dangling reference or that it
    contains relative content in 20 years.
  10. Sean Turner: Discuss [2011-03-17]:
        (updated based on exchanges with author)
    
    #1) Sec 3.1 contains the following:
    
      Recipients MAY take steps to recover a usable field-value from an
      invalid header field, but SHOULD NOT reject the message outright,
      unless this is explicitly desirable behaviour (e.g., the
      implementation is a validator).  As such, the default handling of
      invalid fields is to ignore them.
    
    What's the default requirement?  It needs to be reworded as follows:
    
      As such, implementations SHOULD ignore invalid field by default.
    
    #2) Sec 4.3 contains the following:
    
      Thus, recipients SHOULD ensure
      that a file extension is used that is safe, optimally matching the
      media type of the received payload.
    
    Why isn't this MUST.  An implementation that doesn't do this is then vulnerable
    to the attacks you just described.  Under what circumstances is this a good
    idea?
    
    #3) Sec 4.1 contains the following:
    
       Header field values with multiple instances of the same parameter
       name are invalid.
    
    Is this a new requirement on HTTP headers or is this true of all HTTP headers? 
        
  11. Sean Turner: Comment [2011-03-17]:
    #1) Sec 4.1 contains the following phrase:
    
       Furthermore note that the format used for ext-value allows specifying
       a natural language;
    
    It would greatly help to include an "natural language (e.g., <insert text
    here>);"
    
    #3) Sec 8.2: Should the registration template include:
    
       Related information: none
    
    #5) App D contains the following:
    
         [[fallbackbug: Firefox is known to
          pick the wrong parameter; a bug fix is scheduled for Firefox 5.
          --jre]]
    
    Is this supposed to be removed?

draft-ietf-ancp-protocol

  1. Adrian Farrel: Discuss [2011-03-16]:
        I have two issues related to version numbering that I would like to
    Discuss. Additionally, if time permits, I intend to return with a more
    in depth review of the protocol
    
    ---
    
    I am trying to work out how ANCP will co-exist with GSMP. It seems they
    both use the same port (6068) so I assume disambiguation happens on
    version number negotiation. But...
    
    A GSMP version number is an 8 bit number, with 0x03 being the current 
    version. Since the GSMP version number is not currently tracked by IANA,
    there is a risk that a future version of GSMP will decide that 0x32
    (i.e., version 50) will be used.
    
    I strongly suggest, therefore, that you need a new registry for the 
    "GSMP and ANCP version Numbers". This will need some careful words to
    indicate that GSMP version 4 is allowed. You will also want to track
    ANCP sub-versions (but see below).
    
    [This point relates to part of Alexey's Discuss]
    
    ---
    
    I am really not happy about the lengths that are being gone to to 
    support pre-standard implementations. I think this document should at
    least state that version 3.1 is not allowed. That is, it should not 
    allow downward version negotiation from 3.2. Furthermore, sub-version
    1 should be shown in the IANA registry as "reserved - not available for
    allocation".
    
    Furthermore, I see no reason to require the RFC Editor to make the
    various changes you request with respect to the version numbering. You
    should make these changes now.
     
        
  2. Russ Housley: Comment [2011-03-15]:
      The Gen-ART Review by Ben Campbell on 9-Mar-2011 raised a few minor
      points.  Tom Taylor responded; he seems to agree with some of them.  
      However, the document has not been updated yet.  Please do so before
      approval.
  3. Alexey Melnikov: Discuss [2011-03-15]:
        [Updated: added one more issue in the DISCUSS section (look at the end of it)]
    
    This is a well written document and I don't have objections to its publication.
    However I would like to discuss the following issues before recommending its
    approval:
    
    3.1.  Protocol Version
    
       GSMPv3 messages contain an 8-bit protocol version field.  As
       described below, ANCP subdivides this into two 4-bit sub-fields, for
       version and sub-version.  Implementations of this version of the ANCP
       specification MUST set the version sub-field to 3 and the sub-version
       sub-field to 1.  That is, the hexadecimal representation of the value
       of the complete protocol version field MUST be 0x31.
    
    What is the meaning and semantics of version and subversion? The document is not
    clear on why the separation into version and subversion is needed.
    
    3.2.  ANCP Transport
    
       Identifier:  This 2-byte field identifies a GSMP or ANCP message.
          The type code for GSMP and ANCP messages is 0x880C (i.e., the same
          as GSMP's Ethertype).
    
    Is it wise to reuse the same identifier, considering the statement elsewhere
    in the document that the 2 protocols are not really compatible?
    
       The NAS MUST listen for incoming connections from the Access Nodes.
       Port 6068 is used for TCP connection.
    
    Does this need to be listed in the IANA Considerations section?
    
    4.5.  Status-Info TLV
    
          Error Message:  Human-readable string providing information about
             the warning or error condition.  Padded with zeroes as
             necessary to extend to a four-byte word boundary.
    
    Typically human readable strings need some language tagging information.
    Please
    see <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for
    more details.
    
    8.5.1.  OAM-Loopback-Test-Parameters TLV
    
             Byte 2: Timeout.  Upper bound on the time in seconds that the
             NAS will wait for a response from the DSLAM.  The value 0 MAY
             be used, but has a special meaning.
    
    What is the special meaning of 0?
    
    10.  Security Considerations
    
       Security of the ANCP protocol is discussed in [RFC5713].  A number of
       security requirements on ANCP are stated in Section 8 of that
       document.  Those applicable to ANCP itself are listed here:
    
       o  The protocol solution MUST offer authentication of the AN to the
          NAS.
    
       o  The protocol solution MUST offer authentication of the NAS to the
          AN.
    
    This section is a bit think on TLS-specific details. In particular it doesn't
    describe how these requirements can be achieved with TLS (Note that TLS client
    authentication to the TLS server is optional, so not every ciphersuite is
    suitable to satisfy these requirements). 
        
  4. Alexey Melnikov: Comment [2011-03-14]:
    5.1.1.  Control Context (Informative)
    
       Aside from its use in ANCP signalling, access line identification is
       also used in DHCP transactions involving hosts served by DSL.  Either
       the AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
       the AN or NAS in this role to add access line identification in
       Option 82 (Information) to each DHCP request it forwards to the DHCP
       server.  It is desirable for efficiency that the identification used
       in this signalling should be the same as the identification used in
       ANCP messages.
    
    An informative reference to DHCP is needed here.
    
  5. Dan Romascanu: Discuss [2011-03-17]:
        In section 3.6.1.4: 
    
    > In addition to any suggested action in the text which follows, the
       Code value SHOULD be logged in a MIB.  
    
    If I was writing the MIB module and/or the instrumentation for MIB module I
    would not know what to do, What needs to be logged in a MIB module? (or MIB
    object? which of these?). The fact that the code value is supported? Each
    sending of a request? Each receive of a Request? Something else? 
        
  6. Dan Romascanu: Comment [2011-03-17]:
    I support the DISCUSSes by Adrian and Alexey concerning the version number and
    the DISCUSS from Peter concerning the relationship with RFC 3292.
  7. Peter Saint-Andre: Discuss [2011-03-16]:
        The relationship between this specification and RFC 3292 is unclear and
    confusing.
    
    On the one hand, this document notes that modifies the GSMPv3 adjacency message
    format, the base GSMPv3 message format, the GSMPv3 Event message format, and the
    Port Management message format; therefore it appears to update RFC 3292.
    However, the specification does not indicate that it updates RFC 3292.
    
    On the other hand, this document points implementers to Sections 3.1.1, 9, and
    11 of RFC 3292 for aspects of the protocol, thus introducing a normative
    dependency on parts of RFC 3292 while at the same time it updates other parts;
    why not simply copy the relevant text to this specification so that all the
    documentation is in one place, thus enabling us to remove the normative
    dependency on RFC 3292? 
        
  8. Peter Saint-Andre: Comment [2011-03-16]:
    I concur with the DISCUSSes posted by Adrian Farrel and Alexey Melnikov.
  9. Robert Sparks: Discuss [2011-03-16]:
        Allowing ACNP agents to use any Code values from the (about to be modified)
    GSMPv3 Failure Response Message Name Space registry "if they appear applicable"
    seems underspecified. Could some guidance about when a code would NOT be
    applicable be added? Would an exhaustive list of applicability of the codes
    already registered (in the IETF Consensus ranges) be hard to produce?  I take it
    from Tom's responses to some of the review comments that you do not expect
    GSMPv3 focused codes to be added to the registry, but if one ever were added
    (with a value below 256) that really was targeting GSMP and not ANCP, why not
    ask the registrant say so and capture it in the registry?
    
    Can the document explain when it might be reasonable to not follow the SHOULD in
    3.6.1.7? 
        
  10. Robert Sparks: Comment [2011-03-16]:
    I found the "must" convention distracting, and am skeptical of it's
    effectiveness as a way to communicate requirements to another SDO (which is what
    I understand its purpose to be based on the author's response to the genart
    review). If this remains in the document, please follow up and ensure it had the
    desired effect before trying the convention again.
    
    Section 3.6.1.6 speaks of incrementing transaction IDs linearly when I think
    it's really trying to say "by one". (If there's ever a chance of an intermediary
    being introduced in the path of these messages, it would help to say something
    now about whether recipients should care about gaps in the sequence they
    receive.)
  11. Sean Turner: Discuss [2011-03-17]:
        #1) DISCUSS-DISCUSS
    
    I have to admint I'm completely out of my element here:
    
    If ANCP and GSMPv3 do kind of the same thing. Has there been thought to retiring
    GSMPv3?  Are the two protocols going to gracefully co-exist?
    
    #2) Sec 10 includes security considerations from RFC 5713 with an informative
    reference.  If these are the security considerations of ANCP aren't they
    normative?  Unfortunately, RFC 5713 is informative and this would then be a
    DOWNREF. 
        
  12. Sean Turner: Comment [2011-03-17]:
    #1) I support Alexey's discuss position on TLS.

draft-ietf-sidr-res-certs

  1. Ralph Droms: Comment [2011-03-15]:
    Minor editorial suggestion: In the Abstract,
    s/Resources (INRs)/Internet Number Resources (INRs)/
  2. Alexey Melnikov: Discuss [2011-03-17]:
        [Updated as per Sam Hartman's SecDir review discussion and a further discussion
    with Sam]
    
    This is a well written document and I generally support its publication. 
    
    I was originally planning to file a DISCUSS on this issue, but though that the
    WG knows better. However Sam's SecDir review has changed my mind:
    
    Sam wrote:
    
    I do not believe the concerns I raised in my secdir review have been
    addressed and I still have a deep architectural concern with the
    decision to prevent relying parties from accepting unknown non-critical
    extensions.
    
    There seems to be agreement with several points I raised:
    
    1) The profile does prohibit unknown extensions.
    
    2) I think there is agreement that before we can start using an error
    correction or new feature, we have to upgrade all software in the wild
    that might see the certificates.
    
    3) Everyone including me thinks that strong restrictions  on what
    certificates are created is good for this profile. The question is what
    about restrictions on what people receive. If the IETF changes the
    standard in the future do we want to have to upgrade issuers and
    consumers or just issuers before we start using the new spec in what we
    issue.
    
    4) We may find ourself in a situation where we made a mistake or need to
    expand what the RPKI does.
    
    Adding from myself:
    
    I think there is no disagreement that extensions not listed in this profile
    SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting
    itself in the foot by making receivers reject certificates with unrecognized non
    critical extensions. A much better architectural approach would be to say that
    such non critical extensions "MUST be ignored". This is a pretty standard trick
    in the Apps Area and allows for safe extensibility.
    
    I also have a small list of [nearly] nit-picking items which I think need to be
    addressed before it is approved for publication:
    
    4.9.6.  CRL Distribution Points
    
       The CRL Distribution Points (CRLDP) extension identifies the
       location(s) of the CRL(s) associated with certificates issued by this
       Issuer.  The RPKI uses the URI form of object identification.
    
    This needs a Normative reference to the URI RFC.
    
       The sequence of distributionPoint values MUST contain only a single
       DistributionPoint.  The DistributionPoint MAY contain more than one
       URI value.  An RSYNC URI [RFC5781] MUST be present in the
    
    This makes the reference Normative (and it is a DownRef).
    
       DistributionPoint, and reference the most recent instance of this
       Issuer's CRL.  Other access form URIs MAY be used in addition to the
       RSYNC URI, representing alternate access mechanisms for this CRL.
     
        
  3. Alexey Melnikov: Comment [2011-03-12]:
    4.4.  Issuer
    
       The value of this field is a valid X.501 distinguished name.
    
    A reference to the document defining DNs is needed here. (One of the LDAP
    documents might do.)
    
       An Issuer name MUST contain one instance of the Common Name attribute
       and MAY contain one instance of the Serial Number attribute.  If both
       attributes are present, it is RECOMMENDED that they appear as a set.
       The Common Name attribute MUST be encoded as a printable string.
    
    Similarly, a reference for printable string is needed.
    
       Issuer names are not intended to be descriptive of the identity of
       Issuer.
    
    4.9.8.1.  SIA for CA Certificates
    
       The ordering of URIs
       in this accessDescription sequence reflect the CA's relative
       preferences for access methods to be used by RPs, with he first
    
    s/he/the
    
       element of the sequence being the most preferred by the CA.
    
    6.2.1.  CRMF Resource Certificate Request Template Fields
    
          version
             This field SHOULD be omitted.  If present, it MUST specify a
             request for a Version 3 Certificate.  It
    
    Unfinished sentence?
    
  4. Tim Polk: Comment [2011-03-17]:
    I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not
    typical for IETF publications.  It would be good for the IESG to discuss the
    merits and drawbacks of the wg's consensus approach.
    
    However, I should note that I personally am comfortable with the approach based
    on the unique attributes of its intended deployment and application.  Various
    aspects of this problem have been actively discussed since Stockholm.
  5. Peter Saint-Andre: Comment [2011-03-17]:
    Although I am provisionally balloting "No Objection" pending discussion within
    the IESG, I too am concerned about the issues raised in Alexey Melnikov's
    DISCUSS.
  6. Sean Turner: Comment [2011-03-10]:
    Need to add normative reference to RFC 2119 as per: http://www.rfc-
    editor.org/policy.html#policy.2119ref
    
    "Valid From" should be "Not Before" and "Valid To" should be "Not After" to
    match the name of fields in RFC 5280.

draft-ietf-sidr-cp

  1. Ralph Droms: Comment [2011-03-16]:
    A few nits:
    
    Abstract: s/Internet resource/Internet Number Resource/
    
    Introduction: s/Internet number resource/Internet Number Resource/
    
    In section 2.4, should this text use RFC 2119 terms:
    
       This data is supposed to be accessible to the public.
    
    Why are sections 5.1.*, 5.2.* listed as sections with no text?
  2. Adrian Farrel: Comment [2011-03-17]:
    I have No Objection to the publication of this document, but there are
    a couple of nits I hope the authors will attend to before publication.
    
    ---
    
    Missing close parenthesis in the document title.
    
    ---
    
    In the Introduction...
    
       Note: This document is based on the template specified in the
       Internet Engineering Task Force (IETF) standards document RFC 3647
       [RFC3647].  In the interest of keeping the document as short as
       reasonable, a number of sections contained in the template are
       omitted from this policy because they did not apply to this PKI.
       However, we have retained the section numbering scheme employed in
       the RFC to facilitate comparison with the outline in Section 6 of
       the RFC. Each of these omitted sections should be read as "No
       stipulation" in CP/CPS parlance.
    
    In the interestes of disambiguity (for example, once this document
    has been published as an RFC) could you please
    s/the RFC/RFC 3647/
    both times it shows.
    
    ---
    
    1.5.4. CP approval procedures
    
       The IESG MUST approve a replacement BCP that either updates or
       obsoletes this BCP, following the procedures of the IETF Standards
       Process as defined in RFC 2026 [RFC2026].
    
    This is a little amusing. But I think you actually mean...
    
       Any BCP that either updates or obsoletes this BCP, MUST be approved
       by the IESG following the procedures of the IETF Standards Process as
       defined in RFC 2026 [RFC2026].
    
    ---
    
    3.1.2. Need for names to be meaningful
    
       The Subject name in each certificate SHOULD NOT be "meaningful",
       i.e., the name is NOT intended to convey the identity of the Subject
       to relying parties.
    
    While I understnd the desire for stress, I think s/NOT/not/
    
    ---
    
    3.1.3. Anonymity or pseudonymity of subscribers
    
       Although Subject (and Issuer) names need not be meaningful, and may
       appear "random," anonymity is not a function of this PKI, and thus
       no explicit support for this feature is provided.
    
    Unless there is some special meaning of "pseudonimity" in the security
    community, I would suggest dropping it from the section title. The 
    section text does not discuss the use of pseudonyms, and (to me) the
    use of a pseudonym is destinct from annonymity.
    
    ---
    
    3.1.5
    
    s/Subject names/subject names/ at least twice
    
  3. Russ Housley: Comment [2011-03-15]:
      Please consider the minor issues raised in the Gen-ART Review by
      Francis Dupont on 24-Feb-2011.
  4. Alexey Melnikov: Comment [2011-03-12]:
    4.10. Certificate status services
    
       This PKI does not make provision for use of OCSP or SCVP, because it
    
    Informative references are needed here.
    
       is anticipated that the primary RPs (ISPs) will acquire and validate
       certificates for all participating resource holders.
  5. Peter Saint-Andre: Comment [2011-03-16]:
    Please expand "SIA" on first use and provide a reference if necessary.
    
    In section 4.2.1, I suggest changing "SHOULD never" to "SHOULD NOT".

draft-ietf-sidr-iana-objects

  1. Jari Arkko: Discuss [2011-03-17]:
        Section 8 has a MUST (see below for more details) that is not fully specified.
    The document should make it clear who can make exceptions on making ROAs for
    multicast addresses. 
        
  2. Jari Arkko: Comment [2011-03-17]:
    What kind of change/CRL/processing load is expected from certification of
    unallocated space at IANA, as that space keeps changing (in the case IPv6)?
    
    From Ari Keränen's review: 
    
    8.  Multicast
    
       IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other
       multicast addresses unless directed.
    
    Directed by whom? Need to have, e.g., IESG Approval?
    
  3. Russ Housley: Comment [2011-03-16]:
      Please consider the comment from the Gen-ART Review by
      Wassim Haddad on 16-Mar-2011.  I believe that improved clarity
      is desirable.
  4. Alexey Melnikov: Discuss [2011-03-17]:
        I am planning to ballot Yes on this document once my issues are discussed.
    
    I have a couple of discussion point for IESG which might or might result in some
    actions for editors.
    
    2) DISCUSS DISCUSS
    
    5.  Reserved Resources
    
       Reserved IPv4 and IPv6 resources are held back for various reasons by
       IETF action.  Generally such resources are not intended to be
       globally routed.  An example of such a reservation is 127.0.0.0/8
       [RFC5735].
    
       IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
       not intended to be routed.
    
    Is IANA clear on where (in which RFCs) all such resources are described?
    The reference to [RFC5735] makes me think that it is only one example.
    
       There are a small number of reserved resources which are intended to
       be routed, for example 192.88.99.0/24 [RFC3068].
    
    As above.
    
       IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
       resources that are expected to be globally routed.
     
        
  5. Alexey Melnikov: Comment [2011-03-17]:
    I feel much better about approving this document after reading draft-ietf-sidr-
    arch-12.txt. So I am moving my DISCUSS DISCUSS # 1 to the Comment section:
    
    1) DISCUSS DISCUSS:
    
    This document has lots of normative references to documents, some of which are
    not yet in IETF LC. I do feel that all of them actually need to be reviewed
    before approving this document, so I find it strange that this document is in
    IESG review first.
    
    I understand that I've done similar out-of-order IESG processing for some of my
    documents, so I don't claim to have a high moral ground here. However I would
    like to hear some explanation of why such exception is Ok in this case.
  6. Dan Romascanu: Comment [2011-03-16]:
    I support Alexey's DISCUSS and I have one supplementary question concerning the
    following paragraph in Section 5:
    
    >    IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
       not intended to be routed.
    
    Why is this a should? Why not a MUST? If there are exceptions does IANA know and
    understand all cases when they apply?
  7. Robert Sparks: Comment [2011-03-15]:
    A document providing "specific direction to IANA" (and for which an interop
    statement is never going to make sense) would fit better as a BCP - why was PS
    chosen instead?

draft-ietf-intarea-server-logging-recommendations

  1. Stewart Bryant: Comment [2011-03-15]:
    Please provide references for  "NAT44, NAT64 or DS-Lite."
    
    If DS-Lite has a full name it should be used.
    
    NTP (need a ref)  is not necessarily a traceable time source, it is certainly
    not a definitive source of time for legal purposes.
  2. Ralph Droms: Comment [2011-03-16]:
    I cleared my DISCUSS, based on e-mail from Alain Durand.
    
    For clarification, based on Alain's response, I suggest adding
    text explaining that the recommendations apply to current
    logging practice and port sharing does not require any changes
    in the way logging is performed; e.g., which packets are
    examined and logged.
    
    Editorial: I suggest the following minor change for clarity in section 2:
    
    OLD:
    
       logging incoming IP addresses
    
    NEW:
    
       logging source IP addresses from inbound IP traffic
  3. Russ Housley: Comment [2011-03-15]:
      Please consider the editorial comments from the Gen-ART Review by
      Francis Dupont on 5-Mar-2011.
  4. Alexey Melnikov: Comment [2011-03-07]:
    Various acronyms used need informational references, e.g. NTP.
    
  5. Sean Turner: Discuss [2011-03-15]:
        For the security area review:
    
    Please add a few other items to be considered out-of-scope or add additional
    security considerations.  Since the document already mentions that record
    retention is out-of-scope, it would be useful to add that server security and
    transport security is important for the protection of logs for Internet facing
    systems.    After stating that it is an important consideration, then state
    something to the effect of the service provider must consider the risks,
    including the data and services on the server to determine the appropriate
    measures.
    
    The protection of logs is critical in incident investigations.  If logs are
    tampered with, evidence could be destroyed. 
        

draft-ietf-ipsecme-failure-detection

  1. Jari Arkko: Discuss [2011-03-17]:
        This is a very good specification, and I would have voted Yes if it weren't for
    one technical issue:
    
    I do not understand how Section 5.2 mechanism:
    
             TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T)
    
    works in an implementation that supports multihoming (e.g., RFC 4555). Can you
    clarify?
    I would expect that the document at least has to be clearer about this,
    or perhaps the
    Section 5.2 mechanism needs to be changed or removed to
    accommodate for 
    multihoming. 
        
  2. Adrian Farrel: Comment [2011-03-16]:
    Please expand acronyms on first use (such as "SA" in the Abstract)
  3. Dan Romascanu: Discuss [2011-03-16]:
        The DISCUSS and COMMENT is based in part on the OPS-DIR review performed by
    Menachem Dodge.
    
    This is a well written and useful document and I will support its approval after
    the following two issues are discussed and fixed if agreed:
    
    1. I would have expected that the Operational Considerations section include
    some information about configuration. It looks at a minimum the activation of
    the QCD method should be configurable, and the capability to shitch it off in
    networks where it involves a security risk should be provided.
    
    2. In Section 9.2 last paragraph, it is not completely clear as to what method
    should be implemented in the case of a load-sharing cluster when the load
    balancer cannot guarantee that all "IKE packets from the same source IP address
    always go to the same cluster". Should QCD Token Transmission not be implemented
    in such a situation? 
        
  4. Dan Romascanu: Comment [2011-03-16]:
    1. An abbreviation sub-section would have been very useful
    
    2.   Section 9.1 "QCD Token Generation and Handling", first paragraph, second
    sentence:
    
    Replace 'she' with 'they'
    
    OLD                  
    
    because if an attacker can guess the token associated with an IKE SA, she can
    tear down
    
    SUGGESTED 
    
    because if an attacker can guess the token associated with an IKE SA, they can
    tear down
    
    3. Section 9.2 "QCD Token Transmission" 3rd paragraph last sentence:
    
    Replace 'it' with 'this'
    
    OLD                 
    
    One way to do it is to synchronize
    
    SUGGESTED   
    
    One way to do this is to synchronize
    
     

draft-ietf-mip4-gre-key-extension

  1. Stewart Bryant: Comment [2011-03-08]:
    "In the absence of this key identifier, the data streams cannot be distinguished
    from each other, a significant
     drawback when using IP-in-IP tunneling."
    
    Well understated.
    
    FA, HA, RRP, MN, RRQ, RRP used without first expansion.
    
    It would be useful to the reader if the 'G' bit was called by it's proper name
    (GRE Encapsulation) on first used, same for the 'D' bit.
    
    'The FA may include a GRE key of value zero in the GRE Key Extension to signal
    that the HA assign GRE keys in both directions.' - Minor grammar problem.
    
    'Encapsulati on Unavailable' - - Minor grammar problem.
  2. Adrian Farrel: Comment [2011-03-16]:
    I have no objection to the publication of this documen, but there are a few
    small points that might be addressed to improve it.
    
    ---
    
    I don't think you need RFC 2119 notation in the Abstract.
    
    ---
    
    A number of acronyms are used without expansion
    
    ---
    
    Sections 4.1, 4.2, and 4.3 seem a bit confused on the use of RFC 2119 
    language and the cases where behavior is already defined in other 
    specifications. Could you spend a little time to clear this up and make
    clear what new behavior this document is defining.
    
  3. Russ Housley: Comment [2011-03-16]:
      Something is wrong here:
      >
      > 4.2.  Home Agent Requirements for GRE Tunneling Support
      >    [RFC3344]
      >
      The reference is misplaced.  I think it belongs in the first
      sentence of the section.
    
      Please remove the extra spaces:
      >
      >    GRE encapsulation, it MUST send an RRP with code 'Requested
      >    Encapsulati on Unavailable (139)' [RFC3024] .
  4. Peter Saint-Andre: Comment [2011-03-16]:
    It would be nice to expand "GRE" on first use to "Generic Routing Encapsulation"
    and also provide a reference to RFC 2784.
  5. Sean Turner: Comment [2011-03-15]:
    1) Nits points out:
    
     -  ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944)
    
    2) If you end up doing another revision, please:
    
    a) expand GRE on 1st use in Abstract and Introduction.
    
    b) add a period to the end of the 1st paragraph in Section 7.
    
    Otherwise, please consider these during AUTH48 (if the RFC editor doesn't catch
    them).

draft-ietf-isis-genapp

  1. Jari Arkko: Discuss [2010-10-07]:
        I support the publication of this document and I think it is a good
    and proper addition to the ISIS protocol.
    
    However, I have a specific technical concern. Section 6 says:
    
       The IS-IS WG of the IETF acts as the authority to determine whether
       information proposed to be advertised in IS-IS LSPs falls under this
       definition.
    
    But then Section 8 says:
    
       Registration procedure is "Specification Required" as defined
       in [RFC5226]
    
    If we are expecting to verify that the information falls under the
    right category, then Specification Required does not appear to be
    the right IANA rule. Or am I missing something? 
        
  2. Jari Arkko: Comment [2010-10-07]:
    
        
  3. Ron Bonica: Comment [2011-03-16]:
    I share Lars' allergy to using routing protocols to transport generic
    information. Maybe we should start thinking about a generic information
    transport protocol.
  4. Lars Eggert: Discuss [2010-10-04]:
        I'm missing a crystal clear statement in a very visible spot that the content
    exchanged in GENINFO TLVs MUST NOT alter the behavior or operation of the IS-IS
    protocol and/or state machine. In other words, GENINFO is not a tool for a
    vendor to extended IS-IS in non-interoperable ways. The document does hint that
    this is the intent in a few places; I'm simply asking for making this very, very
    clear. 
        
  5. Lars Eggert: Comment [2010-10-04]:
    (Non-actionable comment: I will likely abstain on this document even when the
    above change is made. The reason is that I'm allergic against the current trend
    of adding kitchen-sink options that turn all kinds of formerly purpose-built
    protocols info generic "information exchange" mechanisms.)
  6. Adrian Farrel: Comment [2010-12-12]:
    Thank you for this draft, it is a necessary addition to the IS-IS family and for
    your work to address my Discusses and Comments.
    
    I have two small, non-blocking Comments remaining that could be looked at if the
    authors continue to work on the document.
    
    I think that the RFC Editor will ask you to jiggle the content/section-
    headings slightly. They have a preference for seeing Section 1 named
    "Introduction".
    
    ---
    
    This Comment moved from the Discuss...
    
    I feel a bit of a lack discusion of backwards compatibility.
    You need to cover how a legacy implementation will react to seeing the
    new GENINFO TLV (a reference to an existing RFC will do), and then 
    consider how this will apply to the utility of the extension (for 
    example, if all speakers participating in the IS-IS instance must be
    upgraded - I think they will because otherwise they will not see the
    flags fields in the new TLV).
    
    It would be helpful to add a brief statement in Section 4 along the lines of:
    
    "According to the rules of [RFC4971] a legacy implementation receiving a GENINFO
    TLV will ..."
  7. Tim Polk: Discuss [2010-10-06]:
        The sole statement in the security considerations:
    
      This document raises no new security issues for IS-IS.
    
    I don't think that is quite true, albeit in a rather cyclic manner.
    
    First, I believe that the use of IS-IS as a transport does have security
    implications that need to be considered
    when specifying a new geninfo
    application ID. It would be helpful to describe the limitations implied by this
    transport,
    and when additional security mechanisms can be employed to extend the
    scope.  For example, the standard IS-IS
    cleartext password  might be
    insufficient for some types of data, requiring deployment of RFC 5304 or 5310
    authentication mechanisms.
    
    Second, deployment of advanced IS-IS security mechanisms (e.g., RFC 5310
    authentication) is something I
    personally advocate.   However, if an IS-IS
    deployment were to deploy these mechanisms solely to support
    advertisement of
    some generic information this may exacerbate any performance implications for
    the IS-IS
    deployment and could be used to launch denial of service attacks.
    That is, deploying IS-IS security mechanisms
    *because* of the generic
    information would be costly for the IS-IS implementation and would violate the
    usual 
    precept of "security commensurate with need".
    
    I think a paragraph or two (total) in the security considerations that addresses
    both these issues would be appropriate. 
        
  8. Tim Polk: Comment [2010-10-06]:
    I support Lars' discuss,
  9. Dan Romascanu: Comment [2011-03-15]:
    I dislike overloading protocols with exchanges of information that do not relate
    to the protocol functionality. However, at this phase, if the working group was
    chartered to do this work, I can accept such an extention as the GENINFO
    advertising of generic information. Separating it in a generic advertising
    extension rather than consuming from the expensive TLV space for each extension
    not related to routing is the right thing to do.
    
    Maybe the introduction should say something about the motivation for such a
    generic container within IS-IS and make possible recommendations of what future
    extensions using this container should include (or should not include).
  10. Peter Saint-Andre: Comment [2010-12-07]:
    
        
  11. Robert Sparks: Comment [2010-10-06]:
    I support Dan's discuss points. 
    
    The document could better motivate the need for a generic container. Could it
    explicitly call out the existing messages that would have been candidates for
    the use of this mechanism if it existed at the time?
    
    Would it make sense to add text reinforcing that elements not understanding this
    TLV would ignore-but-flood?
  12. Sean Turner: Comment [2010-10-05]:
    1) Never seen 2119 language in Abstract.  Is this allowed by the RFC editor?
    
    2) Spell out LSP on first occurrence.
    
    3) Sec 2: It's odd that there are requirements in the overview section.  Could
    this be reworked?
    
    4) Sec 3 (and the rest of the document): RFC 5305 refers to sub-TLV not subTLV.
    This document should align with 5305.
    
    5) Sec 3.1: It would be nice if you assigned a word for the Flags: S (Scope), D
    (Down), I, and V.  It would be nice to assign a word to for "I" and "V" too.
    How about Ipv4 for "I" and ipV6 for "V".
    
    6) Sec 3.2: RFC 5035 has to following text about ignoring unknown sub-TLVs:
    "Unknown sub-TLVs are to be ignored and skipped upon receipt."  Does this draft
    want to use 2119 language to in fact require they be ignored?
    
    7) Sec 3.2: r/AND/and
    
    8) Sec 3.3: r/NOT/not
    
    9) Sec 7: r/IS-IS/IS-IS [RFC1195].
    

draft-ietf-geopriv-rfc3825bis

  1. Jari Arkko: Comment [2010-12-02]:
    Ari Keränen reviewed this specification and he had a few comments:
    
    The abstract should state that this document obsoletes RFC 3825 and the 
    intro should explain why it's done (as described in the I-D checklist).
    
    However, instead of obsoleting 3825, wouldn't it make more sense to have 
    a new IPv4 DHCP option for this new version given that the new encoding 
    is not compatible with the old one and re-using the same value seems to 
    cause a lot of problems (as described in section 2.2.1)? Or otherwise it 
    would be good idea to mention the reason (preserving DHCP codes?) for 
    not doing so.
    
    2.3.  Latitude and Longitude Fields
    
        Latitude values encoded by the DHCP server MUST be constrained to the
        range from -90 to +90 degrees.  Location consumers MUST be prepared
        to normalize values outside this range.  Values outside the range are
        normalized by clamping [...]
    
    If the values MUST be within those boundaries, doesn't it mean that a 
    value that is out of the range is somewhat likely completely wrong (due 
    to a broken implementation) and thus it would make sense to ignore it 
    rather than try to normalize the value and make it appear as if it was 
    valid? I'm not sure if I'd like to be liberal in what I accept when it 
    comes to information that could literally be a matter of life and death.
  2. Stewart Bryant: Comment [2010-12-01]:
    PIFF-LO term used but not defined
    GML term used but not defined
    Code:
    GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
    AType:
    Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in
    two places)
    
    
  3. Ralph Droms: Comment [2011-02-04]:
    I've cleared my DISCUSS.  I have a remaining minor
    comment - In the descriptions of the options, sentences like:
    
                  When the Ver field = 1, this field represents
                  latitude uncertainty.  The contents of this field is
                  undefined for other values of the Ver field.
    
    seem unnecessarily detailed.  Why not simply:
    
                  This field represents
                  latitude uncertainty.
    
    The descriptions of many fields say nothing about the version number.
  4. David Harrington: Comment [2010-11-30]:
    This document is well-written, with clear and unambiguous language. 
    
    1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID
    with the geographic location where the
       identified circuit terminates (such as
    the location of the wall jack)." Would it be the job of the DHCP server to do
    this correlation? I would assume it was a NM application function to do such
    correlation. 
    2) In 2.2.1.2, s/same response. This is not useful since/same
    response, since/
    3) When aType=2, numbering starts at ground level. How does one
    represent an underground parking garage level?
    Should 2.4.3 mention how to
    represent this? Should Appendix B include such an example?

draft-ietf-v6ops-v6-in-mobile-networks

  1. Ralph Droms: Comment [2011-03-16]:
    Seems like any statements like the following predicting the final
    allocation of IPv4 addresses are likely to be out-of-date or
    inaccurate.  I suggest eliding text like the following from section 3.1:
    
       The '/8' IANA blocks for Regional Internet
       Registries (RIRs) are projected to 'run-out' soon.  Subsequently, the
       addressing pool available to RIRs for assignment to Internet Service
       Providers is anticipated to run-out in the following 2-3 years.
  2. Russ Housley: Comment [2011-03-15]:
      Following the Gen-ART Review by Kathleen Moriarty on 21-Feb-2011,
      several changes were agreed.  However, a revised document has not
      been posted yet.  Please make sure the revisions get included.
  3. Sean Turner: Comment [2011-03-17]:
    The tense of the 1st sentence in the abstract and intro should probably be
    changed because the pool is now empty.

draft-ietf-morg-multimailbox-search

  1. Stewart Bryant: Comment [2011-03-16]:
    ID-nits reports:
      -- The draft header indicates that this document updates RFC4466, but the
         abstract doesn't seem to mention this, which it should.
    

draft-eggert-tcpm-historicize

  1. Adrian Farrel: Comment [2011-03-16]:
    I am ballotting "Yes" on this document, but there are a few issues I
    would like the author to consider before the document is passed to 
    the RFC Editor.
    
    ---
    
    Abstract
    
    Please change this text from a "recommendation" to an "action"
    
    ---
    
    Surely this is a Historic RFC in its own right? I.e., RFC 1072 et al
    are obsoleted by a Historic RFC.
    
    ---
    
    Section 2
    
       The RFC Editor is requested to change the status of the following
       RFCs to Historic [RFC2026]:
    
    I'm confused. Can the status of an existing RFC be changed? I thought
    it could only obsoleted.
    
    ---
    
    Section 3
    
    This says IANA should mark as "obsolete". Shouldn't you use 
    "deprecated"?
    
    I think you also need to tell IANA exactly what references they should
    place against each deprecated option.
    

draft-ietf-hip-cert

  1. Adrian Farrel: Comment [2011-03-01]:
    Agree with Peter's Discuss. The update to 5201 should be noted in the document
    header and the Abstarct.
    
    ---
    
    Section 2
    
       It MAY either carry SPKI certificates or X.509.v3
       certificates.
    
    I think lower case "may" is more appropriate. Unless you mean...
    
       It MUST carry either SPKI certificates or X.509.v3
       certificates.
    
  2. Russ Housley: Discuss [2011-03-15]:
        
      This discussion on the PKIX mail list is continuing.  Today the topic
      of unambiguous naming is still under discussion. 
        
  3. Tim Polk: Comment [2011-03-17]:
    I support Russ's discuss position.  We need to let the PKIX discussion run its
    course.
  4. Peter Saint-Andre: Comment [2011-03-09]:
    
        
  5. Sean Turner: Comment [2011-03-16]:
    
      

draft-ietf-sidr-arch

  1. Jari Arkko: Comment [2011-03-17]:
    From Ari Keränen's review:
    
    9. IANA Considerations
    
       This document requests that the IANA issue RPKI Certificates for the
       resources for which it is authoritative, i.e., reserved IPv4
       addresses, IPv6 Unique Local Addresses (ULAs), and address space not
       yet allocated by IANA to the RIRs. 
    
    It would be good to have explicit references to the documents where each of
    these "resources" are defined.
    
    draft-ietf-sidr-iana-objects-01 lists also AS numbers as such a resource; should
    that be listed here too?
  2. Adrian Farrel: Comment [2011-03-17]:
    I am balloting "Yes" for this document, but there are a few minor nits
    that I hope the authors will attend to before publication.
    
    ---
    
    The Introduction uses "CRL" without explanation. This does show up in
    the Terminology section that follows immediately, but it would be nice
    to clarify in the Introduction.
    
    ---
    
    CRLDP shows up in Figure 3 and nowhere else in the document.
    Please add a note to the text.
    
    ---
    
    Figure 1 seems to be mysteriously missing.
    
    ---
    
    Section 4.3 has a slight disconnect between the specification of access
    protocols and the deployment of access protocols. Thus, when you say...
    
       each function must be implemented by at least one access protocol.
    
        
  3. ...I think you mean... each function must be implemented by at least one access protocol deployed by a repository operator. Similarly, when you say things like... Download: Access protocols MUST support the bulk download of
  4. ...it is ambiguous whether you mean "all access protocols" or "at least one access protocol in the suite of access protocols" or "at least one access protocol deployed by the repository operator" --- Section 4.3 To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via RSYNC (see [RFC 5781] and [RSYNC]), although other download protocols also be supported. s/also/may also/ --- Section 5 Since according to this text a manifest is a signed object, and since the manifest is presumable issued by the authority, I would assume that a manifest includes itself in its listing. But perhaps you should clarify this one way or the other.
  5. Russ Housley: Comment [2011-03-15]:
      Please consider the comments from the Gen-ART Review by
      David Black on 24-Feb-2011.
  6. Alexey Melnikov: Discuss [2011-03-15]:
        This is a well written document and I support its publication. However I have a
    small pedantic DISCUSS which should be easy to address:
    
    1). 
    9. IANA Considerations 
    
       This document requests that the IANA issue RPKI Certificates for the 
       resources for which it is authoritative, i.e., reserved IPv4 
       addresses, IPv6 Unique Local Addresses (ULAs), and address space not 
       yet allocated by IANA to the RIRs. IANA SHOULD make available trust 
       anchor material in the format defined in [SIDR-TA] in support of 
       these functions. 
    
    Is this the right document? I thought that was already specified in draft-ietf-
    sidr-iana-objects.
    
    2).
    11.2. Informative References 
    
       [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI 
                  Scheme", RFC 5781, February 2010. 
    
    This reference is Normative, because of the use of a MUST. 
        
  7. Alexey Melnikov: Comment [2011-03-15]:
    4.2. Contents and structure 
    
       For every certificate in the PKI, there will be a corresponding file 
       system directory in the repository that is the authoritative 
       publication point for all objects (certificates, CRLs, ROAs and 
       manifests) verifiable via this certificate. A certificate's Subject 
       Information Authority (SIA) extension provides a URI that references 
       this directory.
    
    An Informative reference to the URI RFC is needed here.

draft-ietf-netext-pmip6-lr-ps

  1. Russ Housley: Comment [2011-03-15]:
      Please consider the comments in the Gen-ART Review by Joel Halpern
      on 7-Mar-2011.  I believe the improved clarity will be helpful.
  2. Dan Romascanu: Comment [2011-03-16]:
    The comment is based in part on the OPS-DIR review performed by Nevil Brownlee. 
    
    1) I do not think that the document needs to be blocked for this, but I think
    that such document should also deal with the the Operational and Manageability
    considerations and include a section on this respect. At a minimum I would have
    expected some refering or estimation on the impact on traffic parameters in the
    network as local routing is designed to reduce latency and backhaul load. Also
    do we expect any extra extensions or attributes to be needed in the interaction
    between MAG and RADIUS servers?
    
    2)  Missing also is any mention of scalability. This document describes the
    problem of optimising routing in a Local (i.e. single provider, or maybe 2~3
    providers) setting. Scaling issues will need to be considered in an actual
    specification (clearly it will have to handle the maximum number of active
    mobile nodes).

draft-zhu-mobility-survey

  1. Stewart Bryant: Discuss [2011-03-16]:
        ID-Nits says: 
    
     ** The document seems to lack a Security Considerations section.
    
      ** The document seems to lack an IANA Considerations section.  (See Section
         2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
         when there are no actions for IANA.)
    
      ** The document seems to lack separate sections for Informative/Normative
         References.  All references will be assumed normative when checking for
         downward references.
    
        
  2. Stewart Bryant: Comment [2011-03-16]:
    I can't check the reference so I can't figure out if there is any trade name
    issue with reference "Sony". Did the authors of the paper work for Sony?
  3. Adrian Farrel: Comment [2011-03-17]:
    Support Stewart's Discuss. There is no reason for I-Ds to turn up in evaluation
    without having run idnits
  4. Russ Housley: Discuss [2011-03-16]:
        
      The authors agreed to some changes based on the Gen-ART Review by
      Richard Barnes on 28-Feb-2011.  Please make those changes. 
        
  5. Dan Romascanu: Comment [2011-03-17]:
    I support Stewart's DISCUSS. 
    
    I am wondering why was this document AD-sponsored and did not go on the
    Independent Stream. It obviously required quite a lot of efforts from the
    sponsoring AD (and the rest of the IESG) as there is a lot of information about
    more than a dozen of protocols whose accuracy needs to be verified. Then there
    will be some more as the document has obvious formatting and document structure
    issues. It is not clear to me what is the benefit.
    
    Also, if we already are approving such a broad protocols survey I would have
    expected some informations about operational and manageability considerations.
    There is a discussion about deployment issues (which is good) but this is not
    sufficient.
  6. Peter Saint-Andre: Comment [2011-03-16]:
    This is a fine document and I support its publication as an Informational RFC. 
    
    I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track
    each mobile's reachability during the mobile's moving") is colloquial and
    potentially confusing (e.g., in "mobile replies" is the term a noun or an
    adjective?). Because you do not want to distinguish between mobile nodes and
    mobile subnets, I suggest "mobile entity".
    
    (There are also typographical errors, such as "Protocols like E2E, ILNP and BTMM
    fail into this design" instead of "fall into", but I assume that those will be
    fixed during the RFC Editor's review.)

draft-herzog-static-ecdh

  1. Adrian Farrel: Comment [2011-03-16]:
    I have No objection to the publication of this document, but I have a
    couple of minor editorial points that could usefully be fixed to
    improve the document.
    
    ---
    
    The term "MACed" is used without explanation.
    
    ---
    
    Section 1
    
       All three of these types share the same basic structure.  First, a
       fresh symmetric key is generated.
    
    There is a slight syntactic disconnect between these two sentances. Do
    you mean the second sentance to be a process description (in which case
    a paragraph break would be in order)? Or do you mean to describe the
    shared basic structure in some way?
    
    ---
    
    Section 1
    
       o  key transport: the symmetric key is encrypted using the public
          encryption key of some recipient,
    
    To be very picky...
    Do you mean "encryption key of the intended recipient"?
    
    And Later...
    
       In this case, the participants are the originator and
       one of the recipients.
    
    Again "the intended recipient" seems a better phrase.
    
    ButI am somewhat worried that you have said "one of the recipients" 
    given tat in the case of multiple recipients (that is implied by your
    language) I don't see how the other recipients will be able to function
    as they will not have access to the necessary key.
    
    ---
    
    Section 2
    
       the RecipientInfo kari choice is used.
    
    Is "kari" an unexplained term or a typo?
    
    ---
    
    "ukm" is used without expansion
    
    ---
    
    Section 2.1 contains a number of MUST statements. Section 2.3 should 
    give an indication of what the receiver does when one of these MUSTs
    is violated. This may be as simple as a reference to [CMS].
    

draft-meadors-multiple-attachments-ediint

  1. Stewart Bryant: Comment [2011-03-16]:
    There are a number of id-nits that need be fixed before the document considered
    ready for publication (IANA section and RFC2119 language). Also the editor
    should confirm that all of the lower case "should" instances are correctly set.
  2. Russ Housley: Comment [2011-03-16]:
      In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is
      raised.  Please consider it:
    
      There is a space in the declaration of boundary=" INNER-BOUNDARY";
      in the example in section 3.  I am not sure whether this was
      intentional or whether it will mess up a standard MIME parser, but
      you may want to remove it.
  3. Alexey Melnikov: Comment [2011-03-12]:
    Should this document be published with "no IETF consensus" boilerplate?
    
  4. Sean Turner: Discuss [2011-03-17]:
        update based on Alexey's RFC editor note.
    
    #1) In Sec 2.3, need a normative reference to the canonicalization method.
    
    #2) In Sec 2.5, need normative references for each content types list.
     
        
  5. Sean Turner: Comment [2011-03-16]:
    Sec 2.3 says: 
    
       If the expected MIC value differs from the calculated MIC value, all
       attachments MUST be considered invalid and retransmitted.
    
    Isn't telling the initiator that they didn't match and asking for the
    retransmission missing?

draft-mrw-nat66

  1. Stewart Bryant: Discuss [2011-03-15]:
        The purpose of this discuss is to confirm that there are no undocumented issues
    associated with the use prefix bits in the range 64 to 127 to fix up the
    checksum. These are surely real network addresses elsewhere in the net, and
    therefore may be destinations addresses of packets passing through the
    translator.
    
    Section 4.3 states that a node MUST support hairpinning. Does it need to say
    that it MUST NOT do internal route optimization?
    
    Does an internal router placed between a host and the translator correctly route
    packets in this translated range?
    
        
  2. Stewart Bryant: Comment [2011-03-15]:
    STUN, TURN, ICE should have references

draft-zhu-mobileme-doc

  1. Lars Eggert: Discuss [2011-02-18]:
        I'm holding a discuss on my own document, because the IETF last call ends one
    day after the telechat date. 
        
  2. Peter Saint-Andre: Comment [2011-03-16]:
    In Section 3 we find:
    
       BTMM uses "_udp" to tunnel packets between the
       two ends to achieve NAT traversal.
    
    I think you mean "UDP", not "_udp".
    
  3. Sean Turner: Comment [2011-03-16]:
    #1) In Sec 7.1, I had trouble parsing the following:
    
       When the user first signs in to MobileMe on a host, it automatically
       receives from KDC a digital certificate and private key for "Back to
       My Mac Encryption Certificate".

draft-hu-flow-label-cases

  1. Stewart Bryant: Discuss [2011-03-16]:
        This is a discuss discuss that I expect to clear on the call.
    
    This is a fine document and I have no objection to it's publication. However I
    am surprised  that it has not gone through a WG. Review by a WG would result in
    a more complete validation that all the proposals had been captured, and that
    the conclusion represented the wider view of the IETF.