IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

  1. Roll Call 1134 EDT Cindy:
  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. Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network (Proposed Standard)
    draft-ietf-pwe3-fat-pw-07
    Token: Adrian Farrel
    Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd
    IPR: Cisco's Statement of IPR Related to draft-ietf-pwe3-fat-pw-07
    Discusses/comments (from ballot 3696):
    1. Stephen Farrell: Comment [2011-08-22]:
      I don't get the meaning of the text below in section 12. Are yet more changes expected?
      "The congestion considerations applicable to PWs as described in [RFC3985] and any additional congestion considerations developed at the time of publication apply to this design."
    2. David Harrington: Discuss [2011-08-22]:
      Overall, this document is in good shape. A few adjustments would clarify the requirements of the proposal.
      1) the shepherding document section 1.d does not include discussion of IPR:
      2) in 1.2, "Note that this may be a departure from considerations that apply to the general MPLS case." It would be helpful to identify where the general case is defined, and to state whether this is or is not a departure, and what impact such departure might have.
      3) in 2, "it is required that the NSP in the ingress PE identify flows" and in 3 "If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label." Is this an RFC2119 REQUIRED? how does this REQUIRED/MUST language correlate with the OPTIONAL status of this feature? Are the REQUIRED/MUST only applicable to implementations that support this specification?
      4) in 5, "the default behaviour is not to include the flow label." should this be a MUST NOT?
    3. David Harrington: Comment [2011-08-22]:
      1) in 8.5, incomplete sentence at the end.
      2)in 1.2, "A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], Section 9." It would be good if there was a touch of analysis to accompany this statement. Are the two approaches able to co-exist? If the gerenal solution is approved, will this pwe-specific approach still be needed? (this is apparently provided in section 9. eirther eliminate the reference in 1.1, or provide a forward reference to section 9.
      3) a reference for the TC bits (previously known as the EXP bits)?
    4. Pete Resnick: Comment [2011-08-22]:
      I fully support David's first DISCUSSion point. The shepherding report and the document writeup are pretty content free.
      - The IPR discussion was missed.
      - I understand that the shepherding writeup was done before the assorted evaluations after -05, but it should have been updated to reflect.
      I have no objection to the document on technical grounds (it is well outside my area of expertise), but I also have no way to evaluate it on process grounds.
    5. Dan Romascanu: Comment [2011-08-22]:
      1. OAM is not expanded in any place. I think that the dedicated section should mention that the interpretation of the acronyms is conformant to RFC 6291.
      2. The text in the IANA specifications is slightly mis-leading as there is no amending of the IANA registry, just a change of reference when the RFC is published. I trust IANA knows what to do, but I think a better text would be something like:
      'IANA is requested to reserve the PW Interface Parameters Sub-TLV type Registry value 0x17 for the Flow Label indicator with the reference column refering to this RFC.'

    Telechat:

  2. A Protocol for Provisioning Resource Certificates (Proposed Standard)
    draft-ietf-sidr-rescerts-provisioning-10
    Token: Stewart Bryant
    Note: Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3776):
    1. Stephen Farrell: Comment [2011-08-20]:
      -- these were discuss points but are ok as comments following discussion Most of these are just checking if the WG thought about stuff so should be easily cleared up, except maybe the last one.
      [four item; see link]
      -- these are the original comments
      [nine items; see link]
    2. Russ Housley: Comment [2011-08-24]:
      The Gen-ART Review by Vijay Gurbani on 23-Aug-2011 includes an editorial suggestion:
      I think it will be helpful to identify either in the Abstract or in Terminology section what exactly is a "resource". I do not think you mean traditional HTTP resources like files or dynamically generated content, etc.
    3. Pete Resnick: Comment [2011-08-24]:
      There are several places throughout the draft where the word "will" gets used in a strange way. I suspect it is just a writing style the authors use, but I wanted to make sure that some of these were not protocol directives, as against simple descriptions of protocol actions:
      [several examples; see link]

    Telechat:

  3. Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths (Proposed Standard)
    draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09
    Token: Adrian Farrel
    Note: Martin Vigoureux (martin.vigoureux@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3798):
    1. Stephen Farrell: Comment [2011-08-22]:
      RRO is used a couple of times before being expanded
      The secdir reviewer asked a question [1] to which I didn't see an answer but it doesn't look like it warrants a discuss.
    2. David Harrington: Comment [2011-08-23]:
      1) The abstract contains the RFC2119 conventions text, including references. This should be in the main body of the text, not the abstract.
      2) in 2.4, I think the text could be clearer that the notify message only supplements the path error. It is not used INSTEAD of the path error message.
      3) IANA is requested to assign a new error subcode, but the text (2.4) never mentions the use of the IANA-assigned value.
    3. Sean Turner: Comment [2011-08-23]:
      [nit] The RFC editor might do this for you but I can't remember: to avoid a trivial errata (and yes we get these) please consider re-ordering the RFC references numbers to be lowest # to highest #.

    Telechat:

  4. Message Submission for Mail (Standard)
    draft-ietf-yam-rfc4409bis-02
    Token: Pete Resnick
    Note: S Moonesamy (sm+ietf@elandsys.com) is the document shepherd.
    Discusses/comments (from ballot 3860):
    1. Adrian Farrel: Comment [2011-08-23]:
      I have no objection to the publication of this document, but here are some piddle-nits you might look at in the interest of making the draft so highly polished that you can see your ^H^H^H face in it.
      [examples; see link]
    2. Stephen Farrell: Comment [2011-08-19]:
      Given that start-tls is (as stated) the most common way to secure the submission channel, perhaps the mention of IPsec in 3.3 would be better replaced with a reference to start-tls?
      typo in IANA cnosiderations? "The table in Table 1..." s/table/text/?
    3. David Harrington: Comment [2011-08-24]:
      This document seems clear and well-written. thanks.
    4. Russ Housley: Discuss [2011-08-22]:
      The specification says:
      If an incoming message includes a DKIM [DKIM], PGP [RFC4880], S/MIME [RFC5751], or other signature, sites SHOULD consider what effect message modifications will have on the validity of the signature, and MAY use the presence or absence of a signature as a criterion when deciding what, if any, modifications to make."
      This text is a warning that there are dragons here, but it does not tell the reader anything about the real consequences. I believe that the text ought to be saying that portions of the incoming message that are covered by the signature SHOULD NOT be altered. The consequences of such alteration should probably be included in the security considerations.
    5. Sean Turner: Discuss [2011-08-23]:
      The IETF LC (https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=9680&tid=1314107697) did not call out the downrefs to RFC 4954 and 5321. There is no doubt in my mind that no one will object to these downrefs, but they need to be explicitly called out in the IETF LC.
    6. Sean Turner: Comment [2011-08-23]:
      WRT to anchor36: Do we expect the RFC editor to ask the IESG before or after the telechat? I think you could delete it prior to publication.
      Appendix B: You could strike 5322 from the list because it's an informative reference.

    Telechat:

  5. An Interface ID Hello Option for PIM (Proposed Standard)
    draft-ietf-pim-hello-intid-01
    Token: Adrian Farrel
    Note: Mike McBride (mmcbride@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3870):
    1. Stephen Farrell: Comment [2011-08-19]:
      1st sentence of section 2: saying that this identifies the interface of a *neighboring* router is a tiny bit confusing, I suggest saying it identifies an interface on a router for that router's neighbors to use.
      Just checking: I'm guessing there's no need to do anything, but just in case - I imagine that ifIndex values are often sequential small integers and hence guessable and that the router identifier is often an IPv4 address for the router and hence known, so are there any possible ways to abuse the fact that anyone could easily guess an Interface ID?
    2. David Harrington: Comment [2011-08-23]:
      ifIndex can change, especially on reboot or even during a hot swap, depending on vendor and model. Implementations/uers who choose ifIndex as an identifier should be aware of this lack of stability. Since ifIndex is mentioned as one choice of identifer, the document should point out the possibility of change.
    3. Dan Romascanu: Discuss [2011-08-24]:
      1. In Section 2.1: "The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. Many systems make use of an ifIndex [RFC1213], which can be used as a Local Interface Identifier."
      I believe that the fact that ifIndex is not guaranteed to be stored and recovered at reboot must be mentioned in the text. Actually RFC 2863 defines another object which is persistent at reboot (ifAlias) which could be used, unfortunately the SYNTAX of the object is different. It could be used in cases where persistency is required by subtyping the syntax of the object, but probably this would be an overkill.
      2. In Section 2.2: "The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique."
      Is there any example of usage of globally unique identifiers? How are these supposed to be managed?
      3. also in Section 2.2: "The value 0 has a special meaning for the Router Identifier. It means that no Router Identifier is used. If a router only supports protocols that require the Interface Identifier to be unique for one router (only making use of the Local Interface Identifier), then the implementation MAY set the Router Identifier to zero."
      Why is the last recommendation only a MAY? I would have expected it to be at least a SHOULD if not a MUST.
    4. Dan Romascanu: Comment [2011-08-24]:
      1. I suggest to mention also RFC 2863 as a reference for ifIndex. Both definitions (in 1213 and 2863) are valid, but 2863 is expressed in SMIv2 and has slight changes in semantics (not relevant for this work).
      2. In Section 2.1: "The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an Interface using the Interface Identifier Hello option, and use the value of 0 to show that it is not referred to. Note that the value of 0 is not a valid ifIndex as defined in [RFC1213]."
      RFC 2863 defines the InterfaceIndexOrZero TC which allows exactly for the special semantics of value 0. One more reason to provide it as a reference.
    5. Peter Saint-Andre: Comment [2011-08-23]:
      Because the Router Identifier and Local Interface Identifier are more than 8 bits long, please specify their byte order. Although network byte order (the most significant byte first) is almost universally used, there are some exceptions, so it is important to spell this out.
    6. Sean Turner: Comment [2011-08-23]:
      [nit] I'd reorder sections 2.1 and 2.2. I would have thought you'd of talked about the higher order bits first. This is obviously non-blocking.

    Telechat:

  6. MPLS On-demand Connectivity Verification and Route Tracing (Proposed Standard)
    draft-ietf-mpls-tp-on-demand-cv-06
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.

    Discusses/comments (from ballot 3880):
    1. Adrian Farrel: Discuss [2011-08-25]:
      A number of comments were recently made on the MPLS WG mailing list and during IETF last call. I would like to see these comments discussed and resolved before the document is approved.
    2. David Harrington: Discuss [2011-08-22]:
      1) in 2.2.2, "An On-demand CV packet MUST NOT include more than 1 Source Identifier TLV." - this statement of the requirement does not seem to be conditional.
      "If more than 1 such TLV is present in an On-demand CV request packet, then an error of 1 (Malformed echo request received, Section 3.3 [RFC4379]) MUST be returned, if it is possible to unambiguously identify the source of the packet." This text is ambiguous. It is unclear what the requirement when it is NOT possible to unambiguously identify the source of the packet. I assume the purpose of this text is to say "if it is clear who originated the message, then send this error message", but "if it is unclear who originated the request, implementations MUST NOT return an error." I don't think the text succeeds at saying that. The text says an error message MUST be returned, and then details an exception; that makes it a SHOULD, not a MUST.
      In addition, by putting the conditional about identifying the source in the sentence that starts with if more than 1 source TLV is in the message, you confuse the requirements mandating only 1 src tlv per request. It is unclear which part of the complex sentence the "if" applies to.
      2) in 2.3.2, "The Source Global ID and Destination Global ID MAY be set to 0. When set to zero, either field is not applicable." is ambiguous. If Source Global ID is set to zero, does this mean the Destination Global ID is not applicable? and vice-versa?
      3) in 3.2, "The response in this case SHOULD use ACH and SHOULD be IP encapsulated." why only SHOULD? what are the expected exceptions to this SHOULD?
    3. Russ Housley: Comment [2011-08-24]:
      The Abstract ends with "... new address type and requesting an IANA registry." The IANA registration will take place before the document is published as an RFC. At this stage, the Abstract needs to be written as the final RFC, not the Internet-Draft.
      The bottom of page 6 says: "Address Type will be 5 (as shown in Section 2.1 above."
      There is a missing ')'.
    4. Dan Romascanu: Discuss [2011-08-23]:
      1. Section 2.1: "Multipath type SHOULD be set to 0 (no multipath) when using this address type."
      Why is this not a MUST? In what situations the multipath type could be set to something different than 0?
      Same question for 2.1.1 - although may be a particular case of the statement in 2.1
      2. (issue raised in the OPS-DIR review by Bert Wijnen, was not answered by the authors)
      "3.6. Management Considerations for Operation with Static MPLS-TP
      "Support for static MPLS-TP LSP, or Pseudowire, usage and on-demand CV, MAY require manageable objects to allow, for instance, configuring operating parameters such as:
      "- duration and periodicity of on-demand connectivity tests;
      "- identifiers associated with a statically configured LSP or PW.
      "The specifics of this manageability requirement are out-of-scope in this document and SHOULD be addressed in appropriate management specifications."
      Even if the manageability aspects are out-of-scope there is a need to provide some guidance as to what "duration and periodicity" values make sense with some explanation as to why those values would make sense.
    5. Dan Romascanu: Comment [2011-08-23]:
      1. in section 1.1: "LSP-Ping: refers to the mechanism - particularly as defined and used in referenced material;"
      What referenced material? need to be specific or provide at least an example
      2. In section 4.2.3: "All responses MUST always be sent on a LSP path ..."
      The word 'always' can be dropped if MUST is used in the sentence.
    6. Peter Saint-Andre: Comment [2011-08-23]:
      Please specify the byte order of the longer binary fields. Although network byte order (the most significant byte first) is almost universally used, there are some exceptions, so it is important to spell this out.
    7. Sean Turner: Comment [2011-08-24]:
      The sentence "When set to zero, the field is not applicable" occurs a couple of times in the draft. Is "not applicable" have the same meaning as "these bits are ignored"? If so, I think it'd be clearer to say "these bits are ignored."

    Telechat:

  7. The Unencrypted Form Of Kerberos 5 KRB-CRED Message (Proposed Standard)
    draft-ietf-krb-wg-clear-text-cred-02
    Token: Stephen Farrell
    Note: Sam Hartman (hartmans-ietf@mit.edu) is the document shepherd.
    Discusses/comments (from ballot 3890):
    1. Jari Arkko: Discuss [2011-08-24]:
      Maybe I'm missing something obvious, but
      "The Kerberos Encryption Type 0 is an invalid value [RFC3961].
      "The encryption type (etype) MUST be specified as 0.
      "The use of encryption type 0 in the unencrypted form of the KRB-CRED is not to specify an encryption type. In the context of the KRB-CRED it is a message specific indicator to be interpreted as ..."
      appears to me as an inconsistency. Type 0 was defined as invalid in RFC 3961, but here you define semantics for it, at least int he context of KRB-CRED? Shouldn't you say "... was defined as an invalid value in [RFC3961] but is redefined here in the context of KRB-CRED to stand for ..."?
    2. David Harrington: Discuss [2011-08-22]:
      I am uncomfortable with this proposal.
      As per RFC3365, MUST is for implementers, yet the security of this option depends on statements that the deployer MUST provide adequate protection for the credentials. I am not rasing a discuss about the possibly inappropriate use of RFC2119 language, but about the potential damage to the Internet via security vulnerabilities. This specification could create serious security holes, and the protocol cannot fulfill its purpose without security properties it does not provide.
      In the wrong hands, the vulnerability of this specific option could introduce cascading vulnerabilities. Any system that depends on the credentials exposed by inadequate protection by the deployer of this option could become vulnerable. That might presumably include network management systems, routing systems, and so on. The ramifications of network changes allowed by such a leak could "escape" local control and impact the Internet. So I'm a bit concerned that we are publishing such a standard.
      There is no language indicating that an **implementation MUST** somehow verify that it is only used with appropriate security (and I realize that coudl be a tremedously difficult engineering proposition). The protocol spec in this document does nothing to ensure the strong security required by BCP 61 (which seems to represent a solid IETF community consensus).
      If the purpose is to document existing practice, maybe this should be published as Informational rather than standards-track, with the IETF recommendation that this SHOULD NOT be used due to the high risk associated with inadequate protection. Do we really want to publish a standards-track document whose abstract says this is desirable?
      I note that Stephen Farrel balloted Yes, Sam Hartman is the document shepherd, and Jeff Hutzelman was a contributor and all presumably support this option being published. But it still makes me uncomfortable.
    3. David Harrington: Comment [2011-08-22]:
      "can been" -> "has been" or "can be"
    4. Russ Housley: Discuss [2011-08-24]:
      The security considerations say: "The transport MUST also provide confidentiality, integrity, and end to end security."
      This needs to be more clear. First, the sentences that follow seem to indicate that authentication is also required. Also, I cannot find where the ends are specified to go with this MUST statement.
    5. Russ Housley: Comment [2011-08-24]:
      Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 24-Aug-2011.
    6. Pete Resnick: Comment [2011-08-22]:
      This document does describe how to do something (albeit unsavory) in an interoperable manner, and I can imagine this document being refined with experience, so it is at least plausible to leave on the standards track. And the document does have serious admonitions about how this protocol ought to be used. I share Dave's discomfort, but I think this document has an acceptable level of warning to implementers.
    7. Dan Romascanu: Comment [2011-08-24]:
      1. I share the feeling of uneasiness expressed by DBH about putting this document on the standards track. I expect the security experts to ease my concerns.
      2. In the IANA considerations section: "The reference for Kerberos encryption type 0 should be updated to point to this document."
      It would be probably good to mention that this is the Kerberos Encryption Type Numbers in the Kerberos parameters registry. Should not it also say something like 'message not encrypted' instead of 'reserved'?
    8. Peter Saint-Andre: Comment [2011-08-23]:
      It would be nice if this document included a sentence or two about why the KRB-CRED Message was removed between RFC 1510 and RFC 4510, and why it's important to bring that feature back now. As it is, that history is hidden in the mail archive, so it appears to the naive reader that the KRB-CRED Message is a new feature.

    Telechat:

2.1.2 Returning Items

  1. Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions (Proposed Standard)
    draft-ietf-grow-geomrt-06
    Token: Ron Bonica
    Note: Christopher Morrow (christopher.morrow@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3763):
    1. Stewart Bryant: Comment [2011-05-23]:
      6. Security Considerations: "This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields that are of a descriptive nature and provide information that is useful in the analysis of routing systems. As such, the author believes that they do not constitute an additional security risk. It is recommended that the operators of the BGP collector and Peers consider their own privacy concerns before supplying geographical coordinates in MRT dumps."
      Comment: Isn't there also an enhanced threat in revealing to a physical attacker the precise geographical location of a strategic router?
    2. Ralph Droms: Comment [2011-05-26]:
      I agree with other points raised about revealing physical location, and I have a couple of additional questions:
      1. How does the BGP collector obtain the geolocation of its peers?
      2. From section 8: "It is recommended that the operators of the BGP collector and BGP peers consider their own privacy concerns before supplying geographical coordinates to BGP data collection systems."
      Depending on the answer to 1, how does the BGP peer control how its geographical coordinates are supplied to the BGP collector?
    3. Wesley Eddy: Comment [2011-05-24]:
      Support the other ADs DISCUSS positions on Informational vs. Standards Track
      Further, the security considerations should at least mention the fact that there's no way to prevent someone from lying about location data, yet would appear to have no bearing at all on BGP operation. It might totally mess up any later analysis someone is trying to use the MRT data for as they'd have little way to validate historic coordinates for a given router.
    4. Adrian Farrel: Comment [2011-08-15]:
      The final point of my Discuss is taken care of with the RFC Editor Note that rewrites the Abstract.
      Many thanks for the attention and mork
    5. Stephen Farrell: Comment [2011-05-23]:
      - MRT is not expanded.
      - Good luck with the PhD/hope it went well:-)
    6. Russ Housley: Comment [2011-08-22]:
      The Gen-ART Review by Roni Even on 20-Aug-2011 raised two editorial comments. Please consider them.

    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. Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE) (Informational)
    draft-ietf-dane-use-cases-05
    Token: Stephen Farrell
    Note: Ond?ej Sur� (ondrej.sury@nic.cz) is the Document Shepherd.
    Discusses/comments (from ballot 3881):
    1. Jari Arkko: Comment [2011-08-24]:
      I would support this document with a Yes position otherwise, but I'm a bit hesitant on the ability to *replace* (not just add to) the traditional root certificate operators by DNS operators. Its not clear that I trust the DNS operators any more than I trust the root CAs... (and besides, they are often the same guys), so this flexibility seems to add potential vulnerabilities to bid down to the least trusted DNS/CA operator.
    2. David Harrington: Comment [2011-08-24]:
      good draft. multiple typos need correcting; I assume rfc editor will fix them.
    3. Russ Housley: Comment [2011-08-24]:
      Please consider the comments from the Gen-ART Review by Alexey Melnikov on 8-Jul-2011.
    4. Pete Resnick: Comment [2011-08-24]:
      My hesitancy to put a "Yes" on this document is exactly the opposite of Jari's: I think this document bends over backwards far too much in section 3.3 to preserve traditional root CAs. Indeed, I would have much preferred if the use cases *started* with 3.3 and ended with 3.1, as I think 3.3 is the much more interesting use case. As stated in the last paragraph of 3.3, DNS ops are already trusted more than than root CAs, as a malicious DNS operator can already obtain a root CA signed cert for domains that they control, so as a domain owner I currently need to trust two entities. Better in the long run that I trust one (the DNS op), and all the better that I can be my own DNS op and be in charge of my own certs.
      I am fully in favor of this effort. I only wish this document did less kowtowing to the current CA model.
    5. Dan Romascanu: Discuss [2011-08-25]:
      Before I can add my support to this well-written document I would like the author to address the following issue raised in the DNS-DIR review by Peter Koch:
      I have a concern regarding the repeated use of the term "domain holder" throughout the document. In the introduction it says
      "With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain holder and not tampered with in transit. [...]"
      where the first conclusion simply isn't true. All that DNSSEC provides is data origin authentication with the origin being the DNS zone. DNSSEC dos not help to identify the party applying or authorizing entries into that zone. Later on, section 3.3 correctly makes that distinction:
      "By the same token, this use case puts the most power in the hands of DNS operators. Since the operator of the appropriate DNS zone has de facto control over the content and signing of the zone, he can create false DANE records that bind a malicious party's certificate to a domain. This risk is especially important to keep in mind in cases where the operator of a DNS zone is a different entity than the holder of the domain, as in DNS hosting/outsourcing arrangements, since in these cases the DNS operator might be able to make changes to a domain that are not authorized by the holder of the domain."
      However, it's not only a malicious operator that can interfere. Nowhere does it say that the operator has specific duties to verify or validate DANE information before entering data into the zone. Negligence or malice don't make a difference. The fact that the zone is DNSSEC signed does not change that since the only meaning of the RRSIGs is that the zone operator attests the data was present as signed.
      Also "domain holder" is usually understood as equivalent to a registrant, meaning someone who registered a 2nd (or 3rd, where applicable) domain name. It is not obvious how to apply this logic to nodes further down the tree.
    6. Dan Romascanu: Comment [2011-08-25]:
      Having acronyms (PKIX, AAAA, XMPP, etc. ) expanded at first occurence would increase the readability of the document
    7. Peter Saint-Andre: Comment [2011-08-22]:
      I strongly support publication of this document.
      I have one comment of substance: Section 2 states that "multiple servers ... may be co-located on a single physical host, using different ports". If I understand this statement correctly, I think the part about different ports applies to some application protocols (e.g., HTTP) but not to all application protocols. Perhaps "often using different ports" would be more accurate?
      Also, it would be good to fix the minor but annoying typographical errors that have crept into the document ("ciertificate", "case a denial of service", "Section Section", etc.).
    8. Sean Turner: Comment [2011-08-24]:
      I'm glad that Eve's and Mallory's already precarious reputations were not further denigrated by this draft.

    Telechat:

3.1.2 Returning Items

  1. Benchmarking Methodology for Link-State IGP Data Plane Route Convergence (Informational)
    draft-ietf-bmwg-igp-dataplane-conv-meth-23
    Token: Ron Bonica
    Note: Al Morton (acmorton@att.com) is the shepherd.
    Discusses/comments (from ballot 2186):
    1. Stewart Bryant: Comment [2011-08-15]:
      This is much improved since the previous version, and the RFC Editor's now addresses my remaining concerns.
    2. Adrian Farrel: Comment [2011-08-05]:
      All my issues have been addressed. Thanks. I also believe that that the Discuss points inherrited from Dave Ward are resolved.
    3. Pete Resnick: Comment [2011-08-25]:
      This document seems to be misusing RFC 2119 language. They don't seem to follow the admonition in section 6 of 2119:
      "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability."
    4. Dan Romascanu: Comment [2007-07-18]:
      1. The Abstract says 'The methodology can be applied to any link-state IGP, such as ISIS and OSPF.' Is it true that the methodology applies only to link-state IGPs? If true, I would suggest that the title is change to add 'link-state'. Else strike out 'link-state' from the Abstract.
      2. Section 3.2.2 - 'To obtain results similar to those that would be observed in an operational network, it is recommended that the number of installed routes closely approximates that the network.'
      Probably '... that of the network'
      An indication of the degree of magnitude of this number also seems to be in place here.
      3. Section 4.2 - what does 'remove layer 2 session' mean? I read layer 2 failure a failure that is detected at layer 2, but can reflect a fault that happens in the lower layer and can be as trivial as a cable failure. Am I wrong?
    5. David Ward: Discuss [2007-07-17]:
      [15 items; see link]

    Telechat:

  2. Terminology for Benchmarking Link-State IGP Data Plane Route Convergence (Informational)
    draft-ietf-bmwg-igp-dataplane-conv-term-23
    Token: Ron Bonica
    Note: Al Morton (acmorton@att.com) is the shepherd.
    Discusses/comments (from ballot 2187):
    1. Stewart Bryant: Comment [2011-08-12]:
      Thank you for addressing my concerns
    2. Ralph Droms: Comment [2010-07-01]:
      In several definitions: "Measurement Units: hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds."
      The "Measurement Units" are microseconds, while "hh:mm:ss:nnn:uuu" is a representation. Elsewhere, "Measurement Units" are defined as, e.g., "seconds"
      I don't understand the requirements language (this example from section 3.1.2):
      "Discussion: Full Convergence MUST occur after a Convergence Event."
      "MUST occur" for compliance or interoperability with what, exactly?
    3. Adrian Farrel: Comment [2010-06-30]:
      Support Stewart Bryant's Discuss
    4. Russ Housley: Comment [2007-07-14]:
      Based on Gen-ART Review by Vijay K. Gurbani.
      This draft is ready for publication as an Informational RFC. There are a few editorial changes that should be made:
      - Section 1: s/of the DUT and the/of the DUT, and the/
      - Section 3.1: DUT is expanded here; if it should be expanded anywhere, it should be in Section 1.
    5. Pete Resnick: Comment [2011-08-25]:
      Like Ralph, I am very confused by the use of 2119 language in this document. I don't understand what its necessity is or who it is aimed at.
    6. Dan Romascanu: Comment [2007-07-18]:
      In section 3.5 I do not understand why the measurment unit reads:
      'Number of N-octet offered packets that are not forwarded'
      Why not just? 'Number of packets that are not forwarded'
      If the definition is packet loss for a packet of length N, then it is the definition field that needs to be changed.
    7. David Ward: Discuss [2007-07-17]:
      [6 items; see link]

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. General Area Review Team (Gen-ART) Experiences (Informational)
    draft-doria-genart-experience-04
    Token: Russ Housley
    Discusses/comments (from ballot 3687):
    1. Stewart Bryant: Comment [2011-08-24]:
      I would like to add my thanks to the GEN-ART team for their valuable contribution to the IETF.
    2. Adrian Farrel: Comment [2011-08-22]:
      This document and the existence of the Gen-ART itself is clear proof that the General Area Review Team is nothing but a bunch of do-gooders with too much spare time on their hands.
      The output of the IETF would be considerably poorer without their input.
      Thank you.
      [nits; see link]
    3. Dan Romascanu: Comment [2011-08-23]:
      Thank you for a very useful document.
      1. It would be useful to mention in the Abstract / Introduction that the document reflects the experience accumulated in the period since GenART was started, but that the processes and mode of operation of the review team may change in time.
      2. Section 4.3: Checking the IANA considerations is usually done by IANA. Running id-nits should be performed at submission and verified by the document shepherd. I am not sure that including these on the list of items marked 'Of special interest to the General area, because it does not fall under any other area' is time best spent by GenART
      3. I would use 'keywords usage recommendations' rather than 'IETF formalities'
      4. Section 4.5: s/MIBs/MIB documents/
      5. I find the level of detail of the secretary actions described in Section 5 too detailed in some places. Some of this information would rather belong to a GenART wiki, not in an RFC. On the other hand one important detail is missing. Who nominates the GenART secretary? Is he/she a volunteer or part of the IETF Secretariat? I think that I know the answers, but for the IETF at large it would be useful to mention these.
      6. Something is broken in the sentence 'The secretary thinks that Gen-ART as an experiment that works well, but the secretary believes it is fragile. '
      7. Section 11 (IANA considerations) could be removed at document publication.
    4. Robert Sparks: Comment [2011-08-16]:
      Thanks for going through the effort to capture this history - especially the overview of comments received on the process. I expect this document to be very useful to future GenART and other review teams as well as the designers and maintainers of the tools that support them.
      A few small things to consider tweaking while editing for publication:
      1) I think it's worth acknowledging that many ADs (not just the General Area Director) take the gen-art reviews into account when preparing their evaluation.
      2) I suggest noting (prominently) that the detailed description of the mechanics involved in managing the reviews is a snapshot and that those mechanics may have changed (some minor details have already changed in the last few months, and a reader a few years from now should expect to find things have evolved even further).
      3) This sentence in 4.1 reads awkwardly: "This initially seemed to be an overloading of the process and presented some initial difficulties."
      What is it adding to the draft? I think the document would be just as effective if you deleted this sentence and the one that follows it.

    Telechat:

  2. Moving RFC 4693 to Historic (Informational)
    draft-yevstifeyev-ion-report-07
    Token: Russ Housley
    Discusses/comments (from ballot 3887):
    1. Wesley Eddy: Comment [2011-08-22]:
      idnits complains that there's no IANA considerations section
    2. Pete Resnick: Discuss [2011-08-22]:
      Process nits that are worthy of a DISCUSSion:
      1. The Last Call did not go out as stated in http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html. In particular, it did not include the words "RFC 4693 to Historic".
      2. RFC 4693 itself does not appear on the agenda. I suspect this means that this approval it will not generate the appropriate "Protocol Action" message when we approve it.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Huawei Port Range Configuration Options for PPP IPCP (Informational)
    draft-boucadair-pppext-portrange-option-07
    Token: Jari Arkko
    Note: ISE Submission
    IPR: France Telecom's Statement of IPR relating to draft-boucadair-pppext-portrange-option-00
    IPR: Nokia Corporation's Statement about IPR related to draft-boucadair-pppext-portrange-option-04
    Discusses/comments (from ballot 3879):
    1. Stewart Bryant: Comment [2011-08-24]:
      I agree with Adrian's concern.
      The draft uses the term "couple", but I think that the term "tuple" is the more conventional term.
    2. Wesley Eddy: Comment [2011-08-24]:
      In section 2.2.1 there is confusion about randomization. The ports are selected psuedo-randomly, definitely not randomly.
      The document does not mention whether the ports either being delegated or forwarded belong to particular transport protocols or all transport protocols. The authors proposed to add text saying that this applies to all transport protocols, but it should probably list them specifically by name to be clear.
      The document does not mention any changes or limitations to how applications and an OS kernel would actually interact after either being delegated ports, or having them setup for forwarding. Adding clear reference to where the usage of these ports is discussed in A+P would be useful, I think.
      The document does not mention how ports would be revoked or reaped after use. The authors proposed that reaping can only occur when the link is terminated. That may be limiting operationally, and the limitation should be understood and discussed, I believe.
    3. Adrian Farrel: Discuss [2011-08-23]:
      This Discuss is intended to be resolved in discussion with the IESG on or before 25th August. No author-action is requested.
      I agree with Jari's recommendation wrt his RFC 5742 review subject to understanding whether the PPPext working group might consider working on a standards track function to achieve the same result. If that were the case, then the existence of a non-standard, vendor-specific solution published as an RFC might be a distraction.
    4. Stephen Farrell: Comment [2011-08-23]:
      I'd share in some of the comments as to the maturity level of this spec. But that's an ISE issue I guess.
      I also don't get why it says that other functions may be "predefined (sic) in *Standards Track* documents" when its an independent submission and nothing to do with the standards track.
    5. Peter Saint-Andre: Comment [2011-08-23]:
      Seeing no RFC 5742 issues here, I am balloting "No Objection".
      However, please specify the byte order of the binary fields. Although network byte order (the most significant byte first) is almost universally used, there are some exceptions, so it is important to spell this out.
    6. Sean Turner: Comment [2011-08-24]:
      #1) This probably shows my complete lack of understanding, but I just wanted to check.
      draft-ietf-tsvwg-iana-ports-10 says: "the Dynamic Ports, also known as the Private or Ephemeral Ports, from 49152-65535 (never assigned)"
      and RFC 6056 says: "The Dynamic and/or Private Ports, 49152 through 65535
      "The dynamic port range defined by IANA consists of the 49152-65535 range, and is meant for the selection of ephemeral ports.
      If draft-boucadair-pppext-portrange-option provides another option for picking a port in the range supported by RFC 6056 why does it address ports in the range 1024-65535 and not 49152-65535?
      #2) The draft makes the following claim: "For improved security an option for delegating cryptographically random port range is defined."
      Improved over what? Nothing, the algorithms presented in RFC 6056, or something else?
      #3) This didn't make sense to me: "Other port generator functions may be predefined in Standards Track documents and allocated a not yet allocated 'function' value within the corresponding sub-option type field."
      I think you're saying that there's an option to specify another cryptographic algorithm in "function" element (e.g., "2")? I'm curious why you'd need to define them in a Standards Track document. Would that document be updating some internal Huawei registry? Based on the empty IANA considerations, I assume it's not going to be hosted at IANA.

    Telechat:

  2. How to Contribute Research Results to Internet Standardization (Informational)
    draft-weeb-research-to-internet-stds-02
    Token: Wesley Eddy
    Note: ISE Submission
    Discusses/comments (from ballot 3927):
    1. Stewart Bryant: Discuss [2011-08-24]:
      This is for discussion on the call. I will clear if the consensus is that the IETF should proceed with the document as is.
      Given that this is advice on how a community should contribute to the IETF - which is a type of process - it looks as if it should be sponsored by the General Area AD and published as an IETF rather than an Independent Document.
      Note that I see no need to change the text of the document itself.
    2. Wesley Eddy: Comment [2011-08-22]:
      It may be worth considering adding a sentence (or paragraph) to indicate the difference between a document being adopted by an IETF working group and eventually published as an RFC versus the process for a traditional academic journal or conference presentation. Specifically, it's worth warning that an RFC through an IETF WG will receive significantly more reviews than any academic journal gives (at least several WG participants, the WG chairs, and several IESG reviews are guaranteed), and that in many cases updates to the document (and perhaps even technical changes to the content and re-thinking bits of it) will be required in order to obtain consensus and move forwards. It seems like Section 4 would be a good place to store some text on this.
      It seems to me that section 3.1 (on finding the right WG) is akin to finding the right conference, workshop, or journal to submit a paper to, though perhaps *much* more crucial. However, many working groups and ADs these days are helpful in "routing" work to more appropriate groups if you choose poorly.
      In section 4.2, it strikes me that one potential difference between IETF work and common academic research is that we do a lot more "synthesis" of competing proposals, viewpoints, etc. and try to address the common use cases, requirements, etc., but in normal publications, it's more common to focus on one's own proposal only and cite "related work" in order to describe flaws or shortcomings that you improve on, even if the motivations of the work may differ a lot or the work is even misunderstood. In the IETF you're collaborating with others toward a common goal and product instead of publishing separate works in parallel tracks alongside them. It also often involves greater sensitivity about what else the IETF is doing or what *other* problems exist in the Internet today than what narrow research generally requires, since people working on these other issues can block your work if doesn't align well with theirs.
      There are some typos, but I'm sure the RFC Editor can take care of them:
      - extra space before last period in Abstract
      - double ":" at end of third paragraph in Introduction
      - inconsistent use of periods to terminate bullet points (e.g. in section 3.4)
    3. Adrian Farrel: Discuss [2011-08-23]:
      This Discuss is to provoke debate in the IESG. I intend that the issue will be resolved on or before 25th August. No Author action is required.
      I strongly support this document, however, I do not agree with the 5742 review conclusions. This document describes ways to participate in the IETF standardization process and so is clearly a matter of interest to the community for review and discussion. The document is not presented as the view of a few individuals, but reads as a definitive statement and advice about the IETF processes.
      If the document was limited to participation only in the IRTF I think it would be a poorer document, but it would then not be subject to my concern.
      I would prefer to see the document return as AD Sponsored.
    4. Stephen Farrell: Comment [2011-08-23]:
      Nice document that would have been useful for me to point at a few times, thanks.
      - I think its worth saying somewhere that research can often properly ignore some aspects that become important in the IETF (or even IRTF) such as security, performance, mgmt etc. so knowing which of those your research hasn't addressed before you start out with the IETF is useful, or even better is if you start addressing them before turning up at the IETF, or ask for IETF help in doing that. For that you could maybe add a bullet to the list on p3/4 along the lines of "- when the research hasn't focused on aspects of the technology that are important to the IETF such as security, management etc."
      - In 3.3 I think it'd be worthwhile to explicitly encourage people to actually submit an I-D and say that that's the format that IETF people are used to reading. Extracting the IETF-relevant parts of publications into an I-D is also often going to help identify parts that need more work (e.g. protocol details glossed over in simulations/PhD code) that could be done in the IETF.
      - I think a reference to IPR would be useful since a lot of researchers might not be aware of the IETF's rules on that. (I've seen some express surprise when told.) I'm sure there's a potential rathole in figuring out how to say that succintly, so I won't suggest text for that:-)
    5. Dan Romascanu: Comment [2011-08-25]:
      I have no problem with the publication of this document. I would observe that many of the recommendations about how to take new work in the IETF would be valuable for a broader audience, not only the research community. Out of the good comments that were made I support the ones made by Wesley concerning the need to take into consideration security, transport and operational aspects which are usually not that much in the focus of research projects. I would also make a crisp recommendation to submit proposals to the IETF as Internet-Drafts - this is actually the almost ubiquituous requirement made for all new contributions.
    6. Peter Saint-Andre: Comment [2011-08-22]:
      This is a helpful document. Thanks for writing it.
    7. Sean Turner: Comment [2011-08-23]:
      Thanks for this. I'd like to echo Stephen's and Wes' comments.

    Telechat:

3.3.2 Returning Items

  1. (none)

1214 EDT break

1219 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Javascript Object Signing and Encryption (jose)
    Token: Sean

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Layer 2 Virtual Private Networks (l2vpn)
    Token: Stewart

    Telechat:

  2. STORage Maintenance (storm)
    Token: David

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Discuss Criteria for Advancing Documents (Jari Arkko)

    Telechat:

  2. IAB Liaison Oversight Program (Sean Turner)

    Telechat:

  3. Standards Tree Media Type for text/mizar [IANA #480998] (Michelle Cotton)

    Telechat:

7. Agenda Working Group News

1253 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-08-25 07:28:49 PDT)

draft-ietf-pwe3-fat-pw

  1. Stephen Farrell: Comment [2011-08-22]:
    I don't get the meaning of the text below in section 12. Are
    yet more changes expected?
    
      "The congestion considerations applicable to PWs as described in
       [RFC3985] and any additional congestion considerations developed at
       the time of publication apply to this design."
    
  2. David Harrington: Discuss [2011-08-22]:
        Overall, thsi document is in good shape. A few adjustments would clarify the
    requirements of the proposal.
    
    1) the shepherding document section 1.d does not include discussion of IPR:
    "Has an IPR disclosure related to this document
    been filed? If so, please include a reference to the
    disclosure and summarize the WG discussion and conclusion on
    this issue.
    
    No specific concerns."
    
    2) in 1.2, "Note that this may be a departure from considerations that apply to
    the general MPLS case. " It would be helpful to identify where the general case
    is defined, and to state whether this is or is not a departure, and what impact
    such departure might have.
    
    3) in 2, "it is required that the NSP in the ingress PE identify flows" and in 3
    "If a flow LSE is present, it MUST be checked to determine whether it carries a
    reserved label." Is this an RFC2119 REQUIRED? how does this REQUIRED/MUST
    language correlate with the OPTIONAL status of this feature? Are the
    REQUIRED/MUST only applicable to implementations that support this
    specification?
    
    4) in 5, "the default behaviour is not to include the flow label." should this
    be a MUST NOT? 
        
  3. David Harrington: Comment [2011-08-22]:
    1) in 8.5, incomplete sentence at the end.
    2)in 1.2, "A similar design for
    general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label],
    Section 9. " It would be good if there was a touch of analysis to accompany this
    statement. Are the two approaches able to co-exist? If the gerenal solution is
    approved, will this pwe-specific approach still be needed? (this is apparently
    provided in section 9. eirther eliminate the reference in 1.1, or provide a
    forward reference to section 9.
    3) a reference for the TC bits (previously known
    as the EXP bits)?
  4. Pete Resnick: Comment [2011-08-22]:
    I fully support David's first DISCUSSion point. The shepherding report and the
    document writeup are pretty content free.
    
    - The IPR discussion was missed.
    - I understand that the shepherding writeup was
    done before the assorted evaluations after -05, but it should have been updated
    to reflect.
    
    I have no objection to the document on technical grounds (it is well outside my
    area of expertise), but I also have no way to evaluate it on process grounds.
  5. Dan Romascanu: Comment [2011-08-22]:
    1. OAM is not expanded in any place. I think that the dedicated section should
    mention that the interpretation of the acronyms is conformant to RFC 6291.
    
    2. The text in the IANA specifications is slightly mis-leading as there is no
    amending of the IANA registry, just a change of reference when the RFC is
    published. I trust IANA knows what to do, but I think a better text would be
    something like:
    
    'IANA is requested to reserve the PW Interface Parameters Sub-TLV type Registry
    value 0x17 for the Flow Label indicator with the reference column refering to
    this RFC.'

draft-ietf-sidr-rescerts-provisioning

  1. Stephen Farrell: Comment [2011-08-20]:
    -- these were discuss points but are ok as comments following discussion
    Most of these are just checking if the WG thought about stuff so 
    should be easily cleared up, except maybe the last one.
    
    (1) In 3.1.1.4 the verifier is expected to be able to find CA certs
    that aren't supplied. I'm not trying to insist on any particular thing 
    here, but the more you specify for this the easier it is to get interop 
    so did the WG consider e.g. insisting that if any CA certs are supplied
    then there must be a complete path in some specific order or
    something like that? The same thing applies for crls - if its
    possible to be more specific then that's better. If the WG thought
    about this, and the use cases are such that you can't really say
    more here, then that's ok but I wanted to check.
    
    (2) 3.1.1.5 says the crls field MUST be present. That would
    preclude a signer that never sees CRLs that might include their
    cert. Is that intentional? Is it a good idea? (I'll clear if you say
    yes to both but wanted to check.) 
    
    (3) In 3.1.2 you say again that the crls field has to be there, but
    you never say that it has to contain a reasonable CRL - would it be
    ok if I added some random CRL to this field that has nothing to do
    with my signer cert? (Assuming the verifier finds the right CRLs
    somehow.)
    
    (4) You don't say that the [Binary]SigningTime has to be within the
    EE cert validity, nor that it can be outside the EE cert validity.
    I don't mind which you want, but saying what's allowed there would 
    be good. If anything is allowed, then saying that would
    be good too. Without having checked, I think I recall some other PKI
    implementations that have been over strict or overly loose in this
    respect in the past which led to some interop glitches.
    
    -- these are the original comments
    
    1) This has a relatively baroque layering, with HTTP carrying CMS
    containing XML possibly containing pkcs#10 etc. I guess that design
    is driven by the availability of tools and libraries for those. If
    so, it'd be good to say that (and maybe even hint where to get such
    tools, not sure) so the reader gets the right impression. If not,
    then I'm left wondering why a new protocol doing all that with one
    encoding scheme (ASN.1 or XML or whatever) wouldn't have been 
    a good bit simpler.
    
    (2) The abstract just talks about "resources" but for sidr those are
    just routing and addressing information (or however you like to put
    it) and not e.g. web resources. It'd be better maybe to make that
    clear in the abstract in case someone picks up this RFC and thinks
    they can use it for other things. (I know its clear when you get
    to section 2, but it'd be nice to save people having to read that
    far if they're not going to be able to use this.)
    
    (3) In 3.1.1.4 you say that certificates MUST contain the signer
    cert but you don't say it can't contain two certs for
    the signer. Later in 3.1.1.6.2 you do say the sid MUST have the
    skid from "the" EE cert and in 3.1.2 you say there has to be just
    one, but saying so would be nice in 3.1.1.4 as well.
    
    (4) You say that SigningTime and BinarySigningTime have to represent
    the same time. I didn't check the references to be sure but do e.g.
    the equivalents for "20110819"  and "201108191614" represent the
    same time or not? If both have to be at 1-second granularity or
    something then just saying that here would be good.
    
    (5) What is an "operator alert error"? (in 3.2) Maybe just "error"
    is enough or it ought be defined?
    
    (6) Checks 1, 4, 5 and 6 from 3.2 (p15) replicate stuff from 3.1
    which seem unnecessary.
    
    (7) In 3.2, check 3 you say "this server's" which seems wrong for
    the case where the client is checking a response.
    
    (8) The end of p22 is the first place it says that you can't use the
    same key pair for >1 resource. Could you could add a reference to
    some other sidr document that describes this in more detail? It
    might also be useful to state this rule earlier.
    
    (9) 3.3 could really do with some overview text saying briefly who
    sends what to whom and why. For example, in 3.3.2 it is not clear
    whether the client is asking the server for a list belonging to
    the client or to the server, at least not until I parsed the fairly
    hard-to-get text at the end of p17;-) That overview text might 
    all be in some other sidr document, but having it here would 
    be good.
    
  2. Russ Housley: Comment [2011-08-24]:
      The Gen-ART Review by Vijay Gurbani on 23-Aug-2011 includes an
      editorial suggestion:
    
      I think it will be helpful to identify either in the Abstract or in
      Terminology section what exactly is a "resource".  I do not think you
      mean traditional HTTP resources like files or dynamically generated
      content, etc.
  3. Pete Resnick: Comment [2011-08-24]:
    There are several places throughout the draft where the word "will" gets used in
    a strange way. I suspect it is just a writing style the authors use, but I
    wanted to make sure that some of these were not protocol directives, as against
    simple descriptions of protocol actions:
    
    - Section 3 (note my *hilighting*):
    
       [...]  The server's response *will* similarly be the body
       of the response with a content type of "application/rpki-updown".
    
       The content of the POST, and the server's response, *will* be a "well-
       formed" CMS [RFC5652] object, encoded using the Distinguished
       Encoding Rules for ASN.1 (DER) [X.509-88], formatted in accordance
       with the CMS profile specified in the following section. [...]
    
       The protocol's request / response interaction is assumed to be
       reliable,
    in that all requests *will* generate a matching response.
     
    For example, in the
    first, do you simply mean, "The server's response is the body of the response",
    or do you rather mean, "The server's response MUST be the body of the response"?
    In other words, are you giving directions to generating implementations here, or
    simply describing behavior that receiving implementations can expect?
    
    I found similar examples in 3.3.2 (the two paragraphs after the payload
    definition and the last sentences of the descriptions of resource_set_as,
    resource_set_ipv4, resource_set_ipv6, [issuer's certificate]), 3.4.1 ("will
    (re)set the issuer's local record"), 3.6 ("will make a best effort" -- which
    sounds like a SHOULD -- and "The en-US description will always be included").

draft-ietf-mpls-rsvp-te-no-php-oob-mapping

  1. Stephen Farrell: Comment [2011-08-22]:
    RRO is used a couple of times before being expanded
    
    The secdir reviewer asked a question [1] to which I didn't
    see an answer but it doesn't look like it warrants a
    discuss. 
    
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02855.html
  2. David Harrington: Comment [2011-08-23]:
    1) The abstract contains the RFC2119 conventions text, including references.
    This should be in the main body of the text, not the abstract.
    
    2) in 2.4, I think the text could be clearer that the notify message only
    supplements the path error. It is not used INSTEAD of the path error message.
    
    3) IANA is requested to assign a new error subcode, but the text (2.4) never
    mentions the use of the IANA-assigned value.
  3. Sean Turner: Comment [2011-08-23]:
    <an absolute nit>
    
    The RFC editor might do this for you but I can't remember: to avoid a trivial
    errata (and yes we get these) please consider re-ordering the RFC references
    numbers to be lowest # to highest #.
    
    </an absolute nit>

draft-ietf-yam-rfc4409bis

  1. Adrian Farrel: Comment [2011-08-23]:
    I have no objection to the publication of this document, but here are some
    piddle-nits you might look at in the interest of making the draft so highly
    polished that you can see your ^H^H^H face in it.
    
    ---
    
    idnits says...
      -- The draft header indicates that this document obsoletes RFC4409, but the
         abstract doesn't seem to mention this, which it should.
    
    ---
    
    I think you are not supposed to include citations in the Abstract.
    On the other hand, it might be nice to include the reference to 
    [SMTP-MTA] in the first paragraph of Section 1.
    
    ---
    
    Maybe the Abstract should mention what type of messages (i.e. mail) the
    document handles?
    
    ---
    
    Section 2.2 does not need to include
       In examples, "C:" is used to indicate lines sent by the client, and
       "S:" indicates those sent by the server.  Line breaks within a
       command example are for editorial purposes only.
    
    ---
    
    Section 3
    
    In the last paragraph of the section there are some lower-case "must".
    Please be sure that you don't mean upper case.
    
    Similarly section 8 paragraph 3
  2. Stephen Farrell: Comment [2011-08-19]:
    Given that start-tls is (as stated) the most common
    way to secure the submission channel, perhaps the
    mention of IPsec in 3.3 would be better replaced
    with a reference to start-tls?
    
    typo in IANA cnosiderations? "The table in Table 1..."
    s/table/text/?
    
  3. David Harrington: Comment [2011-08-24]:
    This document seems clear and well-written.
    thanks.
  4. Russ Housley: Discuss [2011-08-22]:
        
      The specification says:
    
        If an incoming message includes a DKIM [DKIM], PGP [RFC4880],
        S/MIME [RFC5751], or other signature, sites SHOULD consider what
        effect message modifications will have on the validity of the
        signature, and MAY use the presence or absence of a signature as
        a criterion when deciding what, if any, modifications to make.
    
      This text is a warning that there are dragons here, but it does not
      tell the reader anything about the real consequences.  I believe
      that the text ought to be saying that portions of the incoming
      message that are covered by the signature SHOULD NOT be altered.
      The consequences of such alteration should probably be included in
      the security considerations. 
        
  5. Sean Turner: Discuss [2011-08-23]:
        <process weenie>
    
    The IETF LC
    (https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=9680&tid=1314107697)
    did not call out the downrefs to RFC 4954 and 5321.  There is no doubt in my
    mind that no one will object to these downrefs, but they need to be explicitly
    called out in the IETF LC.
    
    </process weenie> 
        
  6. Sean Turner: Comment [2011-08-23]:
    WRT to anchor36: Do we expect the RFC editor to ask the IESG before or after the
    telechat?  I think you could delete it prior to publication.
    
    Appendix B: You could strike 5322 from the list because it's an informative
    reference.

draft-ietf-pim-hello-intid

  1. Stephen Farrell: Comment [2011-08-19]:
    1st sentence of section 2: saying that this identifies
    the interface of a *neighboring* router is a tiny bit
    confusing, I suggest saying it identifies an interface
    on a router for that router's neighbors to use.
    
    Just checking: I'm guessing there's no need to do 
    anything, but just in case - I imagine that ifIndex
    values are often sequential small integers
    and hence guessable and that the router identifier
    is often an IPv4 address for the router and hence
    known, so are there any possible ways to abuse the
    fact that anyone could easily guess an Interface ID?
    
  2. David Harrington: Comment [2011-08-23]:
    ifIndex can change, especially on reboot or even during a hot swap, depending on
    vendor and model.
    Implementations/uers who choose ifIndex as an identifier
    should be aware of this lack of stability.
    Since ifIndex is mentioned as one
    choice of identifer, the document should point out the possibility of change.
  3. Dan Romascanu: Discuss [2011-08-24]:
        1. In Section 2.1: 
    
       The 32 bit Local Interface Identifier is selected such that it is
       unique among the router's PIM enabled interfaces.  That is, there
       MUST NOT be two PIM interfaces with the same Local Interface
       Identifier.  While an interface is up, the Identifier MUST always be
       the same once it has been allocated.  If an interface goes down and
       comes up, the router SHOULD use the same Identifier.  Many systems
       make use of an ifIndex [RFC1213], which can be used as a Local
       Interface Identifier.
    
    I believe that the fact that ifIndex is not guaranteed to be stored and
    recovered at reboot must be mentioned in the text. Actually RFC 2863 defines
    another object which is persistent at reboot (ifAlias) which could be used,
    unfortunately the SYNTAX of the object is different. It could be used in cases
    where persistency is required by subtyping the syntax of the object, but
    probably this would be an overkill.
    
    2. In Section 2.2: 
    
       The 32 bit Router Identifier may be used to uniquely identify the
       router.  It may be selected to be unique within some administrative
       domain, or possibly globally unique.  
    
    Is there any example of usage of globally unique identifiers? How are these
    supposed to be managed?
    
    3. also in Section 2.2: 
    
       The value 0 has a special meaning for the Router Identifier.  It
       means that no Router Identifier is used.  If a router only supports
       protocols that require the Interface Identifier to be unique for one
       router (only making use of the Local Interface Identifier), then the
       implementation MAY set the Router Identifier to zero.
    
    Why is the last recommendation only a MAY? I would have expected it to be at
    least a SHOULD if not a MUST. 
        
  4. Dan Romascanu: Comment [2011-08-24]:
    1. I suggest to mention also RFC 2863 as a reference for ifIndex. Both
    definitions (in 1213 and 2863) are valid, but 2863 is expressed in SMIv2 and has
    slight changes in semantics (not relevant for this work).
    
    2. In Section 2.1
    
       The Local Interface Identifier MUST be non-zero.  The reason for
       this, is that some protocols may want to only optionally refer to an
       Interface using the Interface Identifier Hello option, and use the
       value of 0 to show that it is not referred to.  Note that the value
       of 0 is not a valid ifIndex as defined in [RFC1213].
    
    RFC 2863 defines the InterfaceIndexOrZero TC which allows exactly for the
    special semantics of value 0. One more reason to provide it as a reference.
  5. Peter Saint-Andre: Comment [2011-08-23]:
    Because the Router Identifier and Local Interface Identifier are more than 8
    bits long, please specify their byte order. Although network byte order (the
    most significant byte first) is almost universally used, there are some
    exceptions, so it is important to spell this out.
  6. Sean Turner: Comment [2011-08-23]:
    <a complete and utter nit>
    
    I'd reorder sections 2.1 and 2.2.  I would have thought you'd of talked about
    the higher order bits first.  This is obviously non-blocking.
    
    </a complete and utter nit>

draft-ietf-mpls-tp-on-demand-cv

  1. Adrian Farrel: Discuss [2011-08-25]:
        A number of comments were recently made on the MPLS WG mailing list and during
    IETF last call.
    I would like to see these comments discussed and resolved before
    the document is approved. 
        
  2. David Harrington: Discuss [2011-08-22]:
        1) in 2.2.2, "An On-demand CV packet MUST NOT include more than 1 Source
    Identifier TLV." - this statement of the requirement does not seem to be
    conditional. 
    "If more than 1 such TLV is present in an On-demand CV request
    packet, then an error of 1 (Malformed echo request received, Section 3.3
    [RFC4379]) MUST be returned, if it is possible to unambiguously identify the
    source of the packet." This text is ambiguous. It is unclear what the
    requirement when it is NOT possible to unambiguously identify the source of the
    packet.
    I assume the purpose of this text is to say "if it is clear who
    originated the message, then send this error message", but "if it  is unclear
    who originated  the request, implementations MUST NOT return an error." I don't
    think the text succeeds at saying that.
    The text says an error message MUST be
    returned, and then details an exception; that makes it a SHOULD, not a MUST. 
    In
    additioin, by putting the conditional about identifying the source in the
    setence that starts with if more than 1 source TLV is in the message, you
    confuse the requirements mandating only 1 src tlv per request. It is unclear
    which part of the complex sentence the "if" applies to.
    
    2) in 2.3.2, "The Source Global ID and Destination Global ID MAY be set to 0.
    When set to zero, either field is not applicable." is ambiguous. If Source
    Global ID is set to zero, does this mean the Destination Global ID is not
    applicable? and vice-versa?
    
    3) in 3.2, "The response in this case SHOULD use ACH and SHOULD be IP
    encapsulated. " why only SHOULD? what are the expected exceptions to this
    SHOULD? 
        
  3. Russ Housley: Comment [2011-08-24]:
      The Abstract ends with "... new address type and requesting an IANA
      registry."  The IANA registration will take place before the document
      is published as an RFC.  At this stage, the Abstract needs to be
      written as the final RFC, not the Internet-Draft.
    
      The bottom of page 6 says:
      >
      > Address Type will be 5 (as shown in Section 2.1 above.
      >
      There is a missing ')'.
  4. Dan Romascanu: Discuss [2011-08-23]:
        1. Section 2.1: 
    
       Multipath type SHOULD be set to 0 (no multipath) when using this
       address type.
    
    Why is this not a MUST? In what situations the multipath type could be set to
    something different than 0?
    
    Same question for 2.1.1 - although may be a particular case of the statement in
    2.1
    
    2. (issue raised in the OPS-DIR review by Bert Wijnen, was not answered by the
    authors)
    
        3.6.  Management Considerations for Operation with Static MPLS-TP
    
        Support for static MPLS-TP LSP, or Pseudowire, usage and on-demand
        CV, MAY require manageable objects to allow, for instance,
        configuring operating parameters such as:
    
        o  duration and periodicity of on-demand connectivity tests;
        o  identifiers associated with a statically configured LSP or PW.
    
        The specifics of this manageability requirement are out-of-scope in
        this document and SHOULD be addressed in appropriate management
        specifications.
    
    Even if the manageability aspects are out-of-scope there is a need to provide
    some guidance as to what " duration and periodicity " values make sense with
    some explanation as to why those values would make sense. 
        
  5. Dan Romascanu: Comment [2011-08-23]:
    1. in section 1.1: 
    
       o  LSP-Ping: refers to the mechanism - particularly as defined and
          used in referenced material;
    
    What referenced material? need to be specific or provide at least an example
    
    2. In section 4.2.3: 
    
    All responses MUST always be sent on a LSP path  ...
    
    The word 'always' can be dropped if MUST is used in the sentence. 
  6. Peter Saint-Andre: Comment [2011-08-23]:
    Please specify the byte order of the longer binary fields. Although network byte
    order (the most significant byte first) is almost universally used, there are
    some exceptions, so it is important to spell this out.
  7. Sean Turner: Comment [2011-08-24]:
    The sentence "When set to zero, the field is not applicable" occurs a couple of
    times in the draft.  Is "not applicable" have the same meaning as "these bits
    are ignored"?  If so, I think it'd be clearer to say "these bits are ignored."

draft-ietf-krb-wg-clear-text-cred

  1. Jari Arkko: Discuss [2011-08-24]:
        Maybe I'm missing something obvious, but 
    
       The Kerberos Encryption Type 0 is an invalid value [RFC3961]. 
       ...
       The encryption type (etype) MUST be specified as 0.
       ....
       The use of encryption type 0 in the
       unencrypted form of the KRB-CRED is not to specify an encryption
       type.  In the context of the KRB-CRED it is a message specific
       indicator to be interpreted as ...
    
    appears to me as an inconsistency. Type 0 was defined as invalid in RFC 3961,
    but here you define semantics for it, at least int he context of KRB-CRED?
    Shouldn't you say "... was defined as an invalid value in [RFC3961] but is
    redefined here in the context of KRB-CRED to stand for ..."? 
        
  2. David Harrington: Discuss [2011-08-22]:
        I am uncomfortable with this proposal.
    
    As per RFC3365, MUST is for implementers, yet the security of this option
    depends on statements that the deployer MUST provide adequate protection for the
    credentials.
    I am not rasing a discuss about the possibly inappropriate use of
    RFC2119 language, but about the potential damage to the Internet via security
    vulnerabilities.
    This specification could create serious security holes, and the
    protocol cannot fulfill its purpose without security properties it does not
    provide.
    
    In the wrong hands, the vulnerability of this specific option could introduce
    cascading vulnerabilities. Any system that depends on the credentials exposed by
    inadequate protection by the deployer of this option could become vulnerable.
    That might presumably include network management systems, routing systems, and
    so on. 
    The ramifications of network changes allowed by such a leak could
    "escape" local control and impact the Internet.
    So I'm a bit concerned that we
    are publishing such a standard.
    
    There is no language indicating that an **implementation MUST** somehow verify
    that it is only used with appropriate security (and I realize that coudl be a
    termedously difficult engineering proposition). The protocol spec in this
    document does nothing to ensure the strong security required by BCP 61 (which
    seems to represent a solid IETF community consensus).
    
    If the purpose is to document existing practice, maybe this should be published
    as Informational rather than standards-track, with the IETF recommendation that
    this SHOULD NOT be used due to the high risk associated with inadequate
    protection. Do we really want to publish a standards-track document whose
    abstract says this is desirable?
    
    I note that Stephen Farrel balloted Yes, Sam Hartman is the document shepherd,
    and Jeff Hutzelman was a contributor and all presumably support this option
    being published. But it still makes me uncomfortable. 
        
  3. David Harrington: Comment [2011-08-22]:
    "can been" -> "has been" or "can be"
    
  4. Russ Housley: Discuss [2011-08-24]:
        
      The security considerations say:
      >
      > The transport MUST also provide confidentiality, integrity, and
      > end to end security.
      >
      This needs to be more clear.  First, the sentences that follow seem
      to indicate that authentication is also required.  Also, I cannot
      find where the ends are specified to go with this MUST statement. 
        
  5. Russ Housley: Comment [2011-08-24]:
      Please consider the editorial comments in the Gen-ART Review by
      Kathleen Moriarty on 24-Aug-2011.
  6. Pete Resnick: Comment [2011-08-22]:
    This document does describe how to do something (albeit unsavory) in an
    interoperable manner, and I can imagine this document being refined with
    experience, so it is at least plausible to leave on the standards track. And the
    document does have serious admonitions about how this protocol ought to be used.
    I share Dave's discomfort, but I think this document has an acceptable level of
    warning to implementers.
  7. Dan Romascanu: Comment [2011-08-24]:
    1. I share the feeling of uneasiness expressed by DBH about putting this
    document on the standards track. I expect the security experts to ease my
    concerns.
    
    2. In the IANA considerations section: 
    
     The reference for Kerberos encryption type 0 should be updated to
       point to this document.
    
    It would be probably good to mention that this is the Kerberos Encryption Type
    Numbers in the Kerberos parameters registry. Should not it also say something
    like 'message not encrypted' instead of 'reserved'?
  8. Peter Saint-Andre: Comment [2011-08-23]:
    It would be nice if this document included a sentence or two about why the KRB-
    CRED Message was removed between RFC 1510 and RFC 4510, and why it's important
    to bring that feature back now. As it is, that history is hidden in the mail
    archive, so it appears to the naive reader that the KRB-CRED Message is a new
    feature.

draft-ietf-grow-geomrt

  1. Stewart Bryant: Comment [2011-05-23]:
    6.  Security Considerations
    
       This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields
       that are of a descriptive nature and provide information that is
       useful in the analysis of routing systems.  As such, the author
       believes that they do not constitute an additional security risk.  It
       is recommended that the operators of the BGP collector and Peers
       consider their own privacy concerns before supplying geographical
       coordinates in MRT dumps.
    
    Comment:
    
    Isn't there also an enhanced threat in revealing to a physical attacker the
    precise geographical location of a strategic router?
  2. Ralph Droms: Comment [2011-05-26]:
    I agree with other points raised about revealing physical location,
    and I have a couple of additional questions: 
    
    1. How does the BGP collector obtain the geolocation of its peers?
    
    2. From section 8:
    
       It
       is recommended that the operators of the BGP collector and BGP peers
       consider their own privacy concerns before supplying geographical
       coordinates to BGP data collection systems.
    
    Depending on the answer to 1, how does the BGP peer control how its
    geographical coordinates are supplied to the BGP collector?
    
  3. Wesley Eddy: Comment [2011-05-24]:
    Support the other ADs DISCUSS positions on Informational vs. Standards Track
    
    Further, the security considerations should at least mention the fact that
    there's no way to prevent someone from lying about location data, yet would
    appear to have no bearing at all on BGP operation.  It might totally mess up any
    later analysis someone is trying to use the MRT data for as they'd have little
    way to validate historic coordinates for a given router.
  4. Adrian Farrel: Comment [2011-08-15]:
    The final point of my Discuss is taken care of with the RFC Editor Note that
    rewrites the Abstract.
    
    Many thanks for the attention and mork
  5. Stephen Farrell: Comment [2011-05-23]:
    - MRT is not expanded.
    - Good luck with the PhD/hope it went well:-)
  6. Russ Housley: Comment [2011-08-22]:
      The Gen-ART Review by Roni Even on 20-Aug-2011 raised two editorial
      comments.  Please consider them.
    
      1.  Section 5 "This section is to aide" should be "aid"
    
      2.  Section 6 "does not support the the" delete the second "the"

draft-ietf-dane-use-cases

  1. Jari Arkko: Comment [2011-08-24]:
    I would support this document with a Yes position otherwise, but I'm a bit
    hesitant on the ability to *replace* (not just add to) the traditional root
    certificate operators by DNS operators. Its not clear that I trust the DNS
    operators any more than I trust the root CAs... (and besides, they are often the
    same guys), so this flexibility seems to add potential vulnerabilities to bid
    down to the least trusted DNS/CA operator.
    
    
  2. David Harrington: Comment [2011-08-24]:
    good draft.
    multiple typos need correcting; I assume rfc editor will fix them.
  3. Russ Housley: Comment [2011-08-24]:
      Please consider the comments from the Gen-ART Review by
      Alexey Melnikov on 8-Jul-2011.
  4. Pete Resnick: Comment [2011-08-24]:
    My hesitancy to put a "Yes" on this document is exactly the opposite of Jari's:
    I think this document bends over backwards far too much in section 3.3 to
    preserve traditional root CAs. Indeed, I would have much preferred if the use
    cases *started* with 3.3 and ended with 3.1, as I think 3.3 is the much more
    interesting use case. As stated in the last paragraph of 3.3, DNS ops are
    already trusted more than than root CAs, as a malicious DNS operator can already
    obtain a root CA signed cert for domains that they control, so as a domain owner
    I currently need to trust two entities. Better in the long run that I trust one
    (the DNS op), and all the better that I can be my own DNS op and be in charge of
    my own certs.
    
    I am fully in favor of this effort. I only wish this document did less kowtowing
    to the current CA model.
  5. Dan Romascanu: Discuss [2011-08-25]:
        Before I can add my support to this well-written document I would like the
    author to address the following issue raised in the DNS-DIR review by Peter
    Koch:
    
    I have a concern regarding the repeated use of the term "domain holder"
    throughout the document. In the introduction it says
    
       With the advent of DNSSEC [RFC4033], it is now possible for DNS name
       resolution to provide its information securely, in the sense that
       clients can verify that DNS information was provided by the domain
       holder and not tampered with in transit. [...]
    
    where the first conclusion simply isn't true.  All that DNSSEC provides is data
    origin authentication with the origin being the DNS zone. DNSSEC dos not help to
    identify the party applying or authorizing entries into that zone.  Later on,
    section 3.3 correctly makes that distinction:
    
       By the same token, this use case puts the most power in the hands of
       DNS operators.  Since the operator of the appropriate DNS zone has de
       facto control over the content and signing of the zone, he can create
       false DANE records that bind a malicious party's certificate to a
       domain.  This risk is especially important to keep in mind in cases
       where the operator of a DNS zone is a different entity than the
       holder of the domain, as in DNS hosting/outsourcing arrangements,
       since in these cases the DNS operator might be able to make changes
       to a domain that are not authorized by the holder of the domain.
    
    However, it's not only a malicious operator that can interfere. Nowhere does it
    say that the operator has specific duties to verify or validate DANE information
    before entering data into the zone. Negligence or malice don't make a
    difference.   The fact that the zone is DNSSEC signed does not change that since
    the only meaning of the RRSIGs is that the zone operator attests the data was
    present as signed.
    
    Also "domain holder" is usually understood as equivalent to a registrant,
    meaning someone who registered a 2nd (or 3rd, where applicable) domain name.  It
    is not obvious how to apply this logic to nodes further down the tree. 
        
  6. Dan Romascanu: Comment [2011-08-25]:
    Having acronyms (PKIX, AAAA, XMPP, etc. ) expanded at first occurence would
    increase the readability of the document
  7. Peter Saint-Andre: Comment [2011-08-22]:
    I strongly support publication of this document.
    
    I have one comment of substance: Section 2 states that "multiple servers ... may
    be co-located on a single physical host, using different ports". If I understand
    this statement correctly, I think the part about different ports applies to some
    application protocols (e.g., HTTP) but not to all application protocols. Perhaps
    "often using different ports" would be more accurate?
    
    Also, it would be good to fix the minor but annoying typographical errors that
    have crept into the document ("ciertificate", "case a denial of service",
    "Section Section", etc.).
  8. Sean Turner: Comment [2011-08-24]:
    I'm glad that Eve's and Mallory's already precarious reputations were not
    further denigrated by this draft.

draft-ietf-bmwg-igp-dataplane-conv-meth

  1. Stewart Bryant: Comment [2011-08-15]:
    This is much improved since the previous version, and the RFC Editor's now
    addresses my remaining concerns.
  2. Adrian Farrel: Comment [2011-08-05]:
    All my issues have been addressed. Thanks.
    I also believe that that the Discuss
    points inherrited from Dave Ward are resolved.
  3. Pete Resnick: Comment [2011-08-25]:
    This document seems to be misusing RFC 2119 language. They don't seem to follow
    the admonition in section 6 of 2119:
    
       Imperatives of the type defined in this memo must be used with care
       and sparingly.  In particular, they MUST only be used where it is
       actually required for interoperation or to limit behavior which has
       potential for causing harm (e.g., limiting retransmisssions)  For
       example, they must not be used to try to impose a particular method
       on implementors where the method is not required for
       interoperability.
    
  4. Dan Romascanu: Comment [2007-07-18]:
    1. The Abstract says 'The methodology can be applied to any link-state IGP, such
    as ISIS and OSPF.' Is it true that the methodology applies only to link-state
    IGPs? If true, I would suggest that the title is change to add 'link-state'.
    Else strike out 'link-state' from the Abstract.
    
    2. Section 3.2.2 - 'To obtain results similar to those that would be 
       observed in an operational network, it is recommended that the 
       number of installed routes closely approximates that the network.' 
    
    Probably '... that of the network'  
    
    An indication of the deegree of magnitude of this number also seems to be in
    place here.
    
    3. Section 4.2 - what does 'remove layer 2 session' mean? I read layer 2 failure
    a failure that is detected at layer 2, but can reflect a fault that happens in
    the lower layer and can be as trivial as a cable failure. Am I wrong?
  5. David Ward: Discuss [2007-07-17]:
        A few comments on this draft:
    
    0) it is unclear why RIP isn't covered 
    
    1) it is unclear why the recommended timer values in 3.2.4 do not correspond to
    typical values configured in the network but, the route scaling numbers do
    
    2) the packet sampling time in 3.2.5 seems out of date. IGPs converge faster
    than the packet sample time today.
    
    3) it is recommended that the results are in usecs only
    
    4) it is unclear if there are packet order test requirements for ECMP paths.
    Since the many ECMP tests are called out is there any 'correct' test or outcome
    that is desired for selection of ECMP path?
    
    5) On bcast interfaces it is unclear if both p2p/nbma and bcast needs to be
    configured
    
    6) why don't the tests include generation of LSA/LSP as well as change in data
    plane. IOW, what is SUT/DUT in Fig2 as well as 4.1.3.
    
    7) The results from the remote failure case 4.1.3 aren't quite correct:
    
    "The additional
       convergence time contributed by LSP Propagation can be
       obtained by subtracting the Rate-Derived Convergence Time
       measured in 4.1.2 (Convergence Due to Neighbor Interface 
       Failure) from the Rate-Derived Convergence Time measured in 
       this test case."
    
    Though the point is mostly academic, it isn't technically correct.
    
    8) why don't we include fiber pull test and/or enable disable interface
    
    9) Do we want to specify tests for "link up" vs just "link down?" Link up is a
    critical event in the network and frequently causes loops/microloops.
    
    10) In the "metric change" test in 4.5 since traffic is moving from one intf to
    another there should be an observable convergence event unlike what is stated in
    expected results:
    
    "There should be no externally observable IGP Route Convergence ..."
    
    11) In general the results section of each tests should state what should be
    observed during the test, packet loss, packets tx/rx between any SUT and
    required systems, etc. Right now, there is a very brief description of the
    influencing variables of the test. It would not be possible to verify a true
    positive on a test w/ current text.
    
    12) There needs to be a notion and testing of specific prefixes:
    
    first, last and then a median and mean
    
    13) There needs to be a notion of important prefixes or those that are biased
    for prioritized convergence. E.g. BGP Nexthops.
    
    14) There should be a measure of any microloops formed and duration of any
    loops|microloops
    
    15) Is graceful restart and time to restore FIB considered a convergence event?
    If not, why? 
        

draft-ietf-bmwg-igp-dataplane-conv-term

  1. Stewart Bryant: Comment [2011-08-12]:
    Thank you for addressing my concerns
  2. Ralph Droms: Comment [2010-07-01]:
    In several definitions:
    
       Measurement Units:
    
       hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
       microseconds.
    
    The "Measurement Units" are microseconds, while "hh:mm:ss:nnn:uuu" is a
    representation.  Elsewhere, "Measurement Units" are defined as, e.g., "seconds"
    
    I don't understand the requirements language (this example from section 3.1.2):
    
       Discussion:
    
       Full Convergence MUST occur after a Convergence Event.
    
    "MUST occur" for compliance or interoperability with what, exactly?
  3. Adrian Farrel: Comment [2010-06-30]:
    Support Stewart Bryant's Discuss
  4. Russ Housley: Comment [2007-07-14]:
      Based on Gen-ART Review by Vijay K. Gurbani.
    
      This draft is ready for publication as an Informational RFC.
      There are a few editorial changes that should be made:
    
      - Section 1: s/of the DUT and the/of the DUT, and the/
    
      - Section 3.1: DUT is expanded here; if it should be expanded
         anywhere, it should be in Section 1.
  5. Pete Resnick: Comment [2011-08-25]:
    Like Ralph, I am very confused by the use of 2119 language in this document. I
    don't understand what its necessity is or who it is aimed at.
  6. Dan Romascanu: Comment [2007-07-18]:
    In section 3.5 I do not understand why the measurment unit reads: 
    
    'Number of N-octet offered packets that are not forwarded'
    
    Why not just? 
    
    'Number of packets that are not forwarded'
    
    If the definition is packet loss for a packet of length N, then it is the
    definition field that needs to be changed.
  7. David Ward: Discuss [2007-07-17]:
        A few items:
    
    0) we need to have a definition of remote vs local failure
    
    1) Why isn't a convergence event defined as any local or remote trigger that
    causes a route recalculation vs one in which fwding is effected. If convergence
    is only to be defined by a change in forwarding what is the term that the
    authors recommend for an event in which a route calculation has to be made but,
    in fact forwarding is not changed? To the control plane of the router, the work
    is the same and given a catastrophic network event; a "queue" of calculations
    that cause no forwarding change in front of a calculation that would cause a
    forwarding plane change is critical to define, understand and place as a
    variable in the convergence equation.
    
    2) There should be a definition of prioritized convergence in which "important
    prefixes" (e.g. loopbacks that are BGP NHs) are measured vs "unimportant
    prefixes." In addition, the important prefixes should
    
    3) There have been alternative definitions and terminology for convergence that
    the authors should cite and rectify. Many of these docs have been discussed in
    rtgwg.
    
    4) loops and microloops should be defined
    
    5) units of measurement are wrong order of magnitude
    
    6) Restoration Convergence time is unclear. The IGP sees only individual
    convergence events. 
        

draft-doria-genart-experience

  1. Stewart Bryant: Comment [2011-08-24]:
    I would like to add my thanks to the GEN-ART team for their valuable
    contribution to the IETF.
  2. Adrian Farrel: Comment [2011-08-22]:
    This document and the existence of the Gen-ART itself is clear proof that the
    General Area Review Team is nothing but a bunch of do-gooders with too much
    spare time on their hands.
    
    The output of the IETF would be considerably poorer without their input.
    
    Thank you.
    
    ---
    
    Nits:
    
    One of my favorite deviations is "PIN number".
    Could you repair "Gen-ART team" and "Gen-ART review team"
    Oh, and "General Area AD" is a bit dodgy.
    
    s/gen-art/Gen-ART/  throughout
    
    ---
    
    Section 3
    
       The original and continuing goal of the Gen-ART team was, and is, to
       offload some of the burden from the General Area AD of IESG reviews.
                 
    Tautology?
    "original and continuing" "was, and is,"  
    
    ---
    
    Section 3
    
       The load for the bi-weekly IESG reviews is often quite large;
       occasionally there are more than 20 I-Ds scheduled for discussion in
       a single telechat. Thus, ADs also have less than a week's notice for
       many of the I-Ds on the telechat agenda.
    
    "Thus"? Apropos of what?
    
    ---
    
    Section 3
    
    I found the tense somewhat fluid as the original aims and the current 
    aims are mixed. I don't think any inaccuracy was introduced, but it is
    odd to read.
    
    ---
    
    Section 3
    s/provides a reasonable basis/provide a reasonable basis/
    
    ---
    
    Would it be helpful to include the current review email template?
    
    ---
    
    Section 5.4
    
       1.  Currently, a volunteer is assisting the secretary in caching the
           email reviews as they arrive.
    
    Makes it sound like the secretary is a paid staff member or a conscript
    
    ---
    
    I was rather disappointed by Section 6. I know I have Asperger's and
    love statistics, but given 20 I-Ds every two weeks for 7 years, this
    section is very short of information.
    
    What does "ready" mean? Even the authors sometimes use quote marks.
    
    ---
    
    I would have been interested to know the impression of Gen-ART reviews
    from the persepctive of the victims^H^H^H^H^H^H^H authors of the drafts
    that are reviewed.
    
    ---
    
    Section 7.2
    
    s/Area Directors'/Area Directors/
  3. Dan Romascanu: Comment [2011-08-23]:
    Thank you for a very useful document. 
    
    1. It would be useful to mention in the Abstract / Introduction that the
    document reflects the experience accumulated in the period since GenART was
    started, but that the processes and mode of operation of the review team may
    change in time.
    
    2. Section 4.3: Checking the IANA considerations is usually done by IANA.
    Running id-nits should be performed at submission and verified by the document
    shepherd. I am not sure that including these on the list of items marked 'Of
    special interest to the General area, because it does not fall under any other
    area' is time best spent by GenART
    
    3. I would use 'keywords usage recommendations' rather than 'IETF formalities'
    
    4. Section 4.5: s/MIBs/MIB documents/
    
    5. I find the level of detail of the secretary actions described in Section 5
    too detailed in some places. Some of this information would rather belong to a
    GenART wiki, not in an RFC. On the other hand one important detail is missing.
    Who nominates the GenART secretary? Is he/she a volunteer or part of the IETF
    Secretariat? I think that I know the answers, but for the IETF at large it would
    be useful to mention these.
    
    6. Something is broken in the sentence 'The secretary thinks that Gen-ART as an
    experiment that works well,
       but the secretary believes it is fragile. '
    
    7. Section 11 (IANA considerations) could be removed at document publication. 
  4. Robert Sparks: Comment [2011-08-16]:
    Thanks for going through the effort to capture this history - especially the
    overview of comments received on the process. 
    I expect this document to be very
    useful to future GenART and other review teams as well as the designers and
    maintainers of the tools that support them.
    
    A few small things to consider tweaking while editing for publication:
    
    1) I think it's worth acknowledging that many ADs (not just the General Area
    Director) take the gen-art reviews into
    account when preparing their evaluation.
    
    2) I suggest noting (prominently) that the detailed description of the mechanics
    involved in managing the reviews is a snapshot and that those mechanics may have
    changed (some minor details have already changed in the last few months, and a
    reader a few years from now should expect to find things have evolved even
    further).
    
    3) This sentence in 4.1 reads awkwardly:
    
            This initially seemed to be an overloading of the process and presented
    some initial difficulties.
    
         What is it adding to the draft? I think the document would be just as
    effective if you deleted this sentence
         and the one that follows it.

draft-yevstifeyev-ion-report

  1. Wesley Eddy: Comment [2011-08-22]:
    idnits complains that there's no IANA considerations section
  2. Pete Resnick: Discuss [2011-08-22]:
        Process nits that are worthy of a DISCUSSion:
    
    1. The Last Call did not go out as stated in http://www.ietf.org/iesg/statement
    /designating-rfcs-as-historic.html . In particular, it did not include the words
    "RFC 4693 to Historic".
    
    2. RFC 4693 itself does not appear on the agenda. I suspect this means that this
    approval it will not generate the appropriate "Protocol Action" message when we
    approve it. 
        

draft-boucadair-pppext-portrange-option

  1. Stewart Bryant: Comment [2011-08-24]:
    I agree with Adrian's concern.
    
    The draft uses the term "couple", but I think that the term "tuple" is the more
    conventional term.
    
    
  2. Wesley Eddy: Comment [2011-08-24]:
    In section 2.2.1 there is confusion about randomization.  The ports are selected
    psuedo-randomly, definitely not randomly.
    
    The document does not mention whether the ports either being delegated or
    forwarded belong to particular transport protocols or all transport protocols.
    The authors proposed to add text saying that this applies to all transport
    protocols, but it should probably list them specifically by name to be clear.
    
    The document does not mention any changes or limitations to how applications and
    an OS kernel would actually interact after either being delegated ports, or
    having them setup for forwarding.  Adding clear reference to where the usage of
    these ports is discussed in A+P would be useful, I think.
    
    The document does not mention how ports would be revoked or reaped after use.
    The authors proposed that reaping can only occur when the link is terminated.
    That may be limiting operationally, and the limitation should be understood and
    discussed, I believe.
  3. Adrian Farrel: Discuss [2011-08-23]:
        This Discuss is intended to be resolved in discussion with the IESG on or before
    25th August.
    
    No author-action is requested.
    
    I agree with Jari's recommendation wrt his RFC 5742 review subject to
    understanding whether the PPPext working group might consider working on a
    standards track function to achieve the same result. If that were the case, then
    the existence of a non-standard, vendor-specific solution published as an RFC
    might be a distraction. 
        
  4. Stephen Farrell: Comment [2011-08-23]:
    I'd share in some of the comments as to the maturity level of
    this spec. But that's an ISE issue I guess.
    
    I also don't get why it says that other functions may be
    "predefined (sic) in *Standards Track* documents" when
    its an independent submission and nothing to do with
    the standards track.
    
  5. Peter Saint-Andre: Comment [2011-08-23]:
    Seeing no RFC 5742 issues here, I am balloting "No Objection".
    
    However, please specify the byte order of the binary fields. Although network
    byte order (the most significant byte first) is almost universally used, there
    are some exceptions, so it is important to spell this out.
  6. Sean Turner: Comment [2011-08-24]:
    #1) This probably shows my complete lack of understanding, but I just wanted to
    check.
    
    draft-ietf-tsvwg-iana-ports-10 says:
    
       o  the Dynamic Ports, also known as the Private or Ephemeral Ports,
          from 49152-65535 (never assigned)
    
    and RFC 6056 says:
    
      o  The Dynamic and/or Private Ports, 49152 through 65535
    
       The dynamic port range defined by IANA consists of the 49152-65535
       range, and is meant for the selection of ephemeral ports.
    
    If draft-boucadair-pppext-portrange-option provides another option for picking a
    port in the range supported by RFC 6056 why does it address ports in the range
    1024-65535 and not 49152-65535?
    
    #2) The draft makes the following claim:
    
       For improved security an option for delegating cryptographically
       random port range is defined.
    
    Improved over what?  Nothing, the algorithms presented in RFC 6056, or something
    else?
    
    #3) This didn't make sense to me:
    
       Other port generator functions may be predefined in Standards Track
       documents and allocated a not yet allocated 'function' value within
       the corresponding sub-option type field.
    
    I think you're saying that there's an option to specify another cryptographic
    algorithm in "function" element (e.g., "2")?  I'm curious why you'd need to
    define them in a Standards Track document.  Would that document be updating some
    internal Huawei registry?  Based on the empty IANA considerations, I assume it's
    not going to be hosted at IANA.

draft-weeb-research-to-internet-stds

  1. Stewart Bryant: Discuss [2011-08-24]:
        This is for discussion on the call. I will clear if the consensus is that the
    IETF should proceed with the document as is.
    
    Given that this is advice on how a community should contribute to the IETF -
    which is a type of process -  it looks as if it should be sponsored by the
    General Area AD and published as an IETF rather than an Independent Document.
    
    Note that I see no need to change the text of the document itself. 
        
  2. Wesley Eddy: Comment [2011-08-22]:
    It may be worth considering adding a sentence (or paragraph) to indicate the
    difference between a document being adopted by an IETF working group and
    eventually published as an RFC versus the process for a traditional academic
    journal or conference presentation.  Specifically, it's worth warning that an
    RFC through an IETF WG will receive significantly more reviews than any academic
    journal gives (at least several WG participants, the WG chairs, and several IESG
    reviews are guaranteed), and that in many cases updates to the document (and
    perhaps even technical changes to the content and re-thinking bits of it) will
    be required in order to obtain consensus and move forwards.  It seems like
    Section 4 would be a good place to store some text on this.
    
    It seems to me that section 3.1 (on finding the right WG) is akin to finding
    the right conference, workshop, or journal to submit a paper to, though perhaps
    *much* more crucial.  However, many working groups and ADs these days are
    helpful in "routing" work to more appropriate groups if you choose poorly.
    
    In section 4.2, it strikes me that one potential difference between IETF work
    and common academic research is that we do a lot more "synthesis" of competing
    proposals, viewpoints, etc. and try to address the common use cases,
    requirements, etc., but in normal publications, it's more common to focus on
    one's own proposal only and cite "related work" in order to describe flaws or
    shortcomings that you improve on, even if the motivations of the work may differ
    a lot or the work is even misunderstood.  In the IETF you're collaborating with
    others toward a common goal and product instead of publishing separate works in
    parallel tracks alongside them.  It also often involves greater sensitivity
    about what else the IETF is doing or what *other* problems exist in the Internet
    today than what narrow research generally requires, since people working on
    these other issues can block your work if doesn't align well with theirs.
    
    There are some typos, but I'm sure the RFC Editor can take care of them:
    
    - extra space before last period in Abstract
    
    - double ":" at end of third paragraph in Introduction
    
    - inconsistent use of periods to terminate bullet points (e.g. in section 3.4)
  3. Adrian Farrel: Discuss [2011-08-23]:
        This Discuss is to provoke debate in the IESG. I intend that the 
    issue will be resolved on or before 25th August.
    
    No Author action is required.
    
    I strongly support this document, however, I do not agree with the 
    5742 review conclusions. This document describes ways to participate
    in the IETF standardization process and so is clearly a matter of
    interest to the community for review and discussion. The document is
    not presented as the view of a few individuals, but reads as a 
    definitive statement and advice about the IETF processes.
    
    If the document was limited to participation only in the IRTF I think
    it would be a poorer document, but it would then not be subject to my
    concern.
    
    I would prefer to see the document return as AD Sponsored. 
        
  4. Stephen Farrell: Comment [2011-08-23]:
    Nice document that would have been useful for me to point at a few
    times, thanks.
    
    - I think its worth saying somewhere that research can often 
    properly ignore some aspects that become important in the IETF (or
    even IRTF) such as security, performance, mgmt etc. so knowing
    which of those your research hasn't addressed before you start out
    with the IETF is useful, or even better is if you start addressing
    them before turning up at the IETF, or ask for IETF help in doing
    that. For that you could maybe add a bullet to the list on p3/4
    along the lines of "- when the research hasn't focused on aspects
    of the technology that are important to the IETF such as security,
    management etc."
    
    - In 3.3 I think it'd be worthwhile to explicitly encourage people
    to actually submit an I-D and say that that's the format that IETF
    people are used to reading. Extracting the IETF-relevant parts of
    publications into an I-D is also often going to help identify
    parts that need more work (e.g. protocol details glossed over
    in simulations/PhD code) that could be done in the IETF.
    
    - I think a reference to IPR would be useful since a lot of
    researchers might not be aware of the IETF's rules on that.  (I've
    seen some express surprise when told.) I'm sure there's a
    potential rathole in figuring out how to say that succintly, so I
    won't suggest text for that:-)
    
  5. Dan Romascanu: Comment [2011-08-25]:
    I have no problem with the publication of this document. I would observe that
    many of the recommendations about how to take new work in the IETF would be
    valuable for a broader audience, not only the research community. Out of the
    good comments that were made I support the ones made by Wesley concerning the
    need to take into consideration security, transport and operational aspects
    which are usually not that much in the focus of research projects. I would also
    make a crisp recommendation to submit proposals to the IETF as Internet-Drafts -
    this is actually the almost ubiquituous requirement made for all new
    contributions.
  6. Peter Saint-Andre: Comment [2011-08-22]:
    This is a helpful document. Thanks for writing it.
  7. Sean Turner: Comment [2011-08-23]:
    Thanks for this.  I'd like to echo Stephen's and Wes' comments.
    
    spt