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