IESG Narrative Minutes

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

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

Corrections from: (none)

1 Administrivia

  1. Roll Call 1134 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Sieve Extension: Externally Stored Lists (Proposed Standard)
    draft-ietf-sieve-external-lists-10
    Token: Pete Resnick
    Discusses/comments (from ballot 3524):
    1. Adrian Farrel: Comment [2011-06-09]:
      Just a couple of WIBNIs
      The first sentence of the Abstract could usefully mention email. The Introduction might benefit similarly.
      Would be nice if section 1.1 said "ABNF" when pointing to 5234.
    2. Stephen Farrell: Comment [2011-06-02]:
      "Implementations MAY support other tests but MUST raise an error (which SHOULD be a compile-time error, but MAY be a runtime error) when a script uses ":list" with a test for which it is not supported."
      That's a bit unclear - what's the last "it"? Maybe s/for which it/that/

    Telechat:

  2. The Unicode code points and IDNA - Unicode 6.0 (Proposed Standard)
    draft-faltstrom-5892bis-04
    Token: Pete Resnick
    Note: Jiankang Yao is the document shepherd.
    Discusses/comments (from ballot 3744):
    1. Ron Bonica: Comment [2011-06-08]:
      Unicode 6.0 is mentioned in the text body and included in the reference section, but there are no formal references to the document. (Run the nit-checker and you will see what I mean).
    2. Wesley Eddy: Comment [2011-06-03]:
      typo in section 1: "that where allocated" -> "that were allocated"?
    3. Adrian Farrel: Comment [2011-06-07]:
      Abstract: I don't know what it means to "specify consensus". Suggest...
      OLD: This document specifies IETF consensus
      NEW: This memo documents IETF consensus
    4. Stephen Farrell: Comment [2011-06-02]:
      s/This imply/This implies/

    Telechat:

  3. Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry (Proposed Standard)
    draft-ietf-dnsext-dnssec-registry-fixes-08
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@shinkuro.com) is the document shepherd.
    Discusses/comments (from ballot 3796):
    1. Stewart Bryant: Comment [2011-06-01]:
      I believe that it is useful to the reader if the updating text is included in the documnet abstract.
      Perhaps I should clarify that, I mean the list of updated documents.
    2. Stephen Farrell: Comment [2011-06-08]:
      I support Robert's discuss and his proposed solution looks to me like it'd work if the WG has not got a reason why its a bad plan.
    3. Russ Housley: Discuss [2011-06-07]:
      The Gen-ART Review by Alexey Melnikov on 5-June-2011 raised some points that deserve a response. I have not seen a response yet.
      Feel free to respond to all of the points raised by Alexey. I have constructed these questions based on Alexey's review:
      (1) Looking at the difference between this document and the IANA registry <http://www.iana.org/assignments/dns-sec-alg-numbers/ dns-sec-alg-numbers.xml>, I can see that they have different list of RFC numbers in the right column. Is this intentional? Is the list in this document correct?
      (2) As somebody else already pointed out during the IETF Last Call the range 123-251 is Reserved by RFC 6014, but this reservation is not mentioned in this document. Why not?
      (3) Section 2.3 requires the replacement of the whole table. It seems like overkill to replace the whole table every time a change to a single algorithm implementation status is needed. This practice could result in mistakes and lead to exactly the kind of trouble that this document demonstrates. Why is this the best approach for this IANA table?
    4. Pete Resnick: Discuss [2011-06-05]:
      I think the mechanism specified for registry update in section 2.3 is so far out of the norm that it should be reconsidered. In particular, the idea of rewriting the entire registry every time a change to a single entry in the registry occurs seems inappropriate. I fear that, for example, if an entry moves from RECOMMENDED TO IMPLEMENT to MUST IMPLEMENT, the history of how it got to that state will be lost. Futher, I think the RFC that made the algorithm RECOMMENDED TO IMPLEMENT, or MUST IMPLEMENT, or MUST NOT IMPLEMENT should be in the Reference column of the registry. Finally, I think referring to "Compliance" in the registry is wildly outside of IETF norms. Suggested changes:
      a) Define the registry such that "Standards Action" (or maybe "IETF Review", i.e., IESG or WG document) is required for changes to the registry.
      b) The "Reference" column in the registry must be to a document that defines the requirements level for DNSSec (MUST IMPLEMENT, MUST NOT IMPLEMENT, etc.) in addition to a definition of the algorithm. (They can be the same document, or more than one.)
      c) Change the "Compliance to RFC TBD1" column to "Requirements level", which should reflect the contents of the document pointed to in (b).
      Then all of this nonsense about rewriting the registry every time can be removed.
    5. Pete Resnick: Comment [2011-06-05]:
      Comments I made to the WG regarding the references to "Reserved until 2020" and the correction to the unassigned code points the WG has agreed to fix.
    6. Peter Saint-Andre: Discuss [2011-06-07]:
      I concur with the concerns raised by Pete Resnick and consider the solution proposed by Robert Sparks to be a reasonable path forward. I would go farther and suggest that there is no need at all for an IANA registry, simply an RFC that lists the most up-to-date recommendations. Obsolete it when the recommendations change and it will be clear to those who implement and deploy DNSSEC which algorithms are appropriate at any given time.
    7. Robert Sparks: Discuss [2011-06-07]:
      Would the following approach achieve the goals the working group desires with this document?
      Instead of keeping the Compliance information in the IANA registry as a new column, keep it entirely within this RFC. Add a sentence to the registry that says "See RFCXXXX for the IETF Consensus on which subset of these algorithms are required or recommended to implement or avoid."
      The RFC could then say that any changes to the RFC affecting that column should be done through obsoleting the RFC, replacing it with a new one. That way, you would have a single document to refer to for conformance purposes, and a clear history of what changes were made. This would avoid Pete's concerns with the potential unintended consequences of the new proposed mechanics for maintaining the registry. It would also avoid an issue I have with the sentence that tries to constrain any updates to this RFC to _only_ use the obsoletes mechanism. It allows the working group to maintain any changes by only using a series of obsoletes, and guides future maintainers should the working group go away. As long as the consensus was to only use obsoletes, that's exactly what will happen. If IETF consensus changes in the future, it would override any attempt to constrain the document maintenance anyway.
      If a path like this was considered and rejected, documenting what it wouldn't achieve would help motivate the current proposal.

    Telechat:

  4. Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) (Proposed Standard)
    draft-ietf-ccamp-gmpls-vcat-lcas-13
    Token: Adrian Farrel
    Note: Deborah Brungard (dbrungard@att.com) is the document shepherd.
    Discusses/comments (from ballot 3807):
    1. Stephen Farrell: Comment [2011-06-07]:
      (blank)
    2. Russ Housley: Comment [2011-06-08]:
      The Gen-ART Review by Kathleen Moriarty on 7-Jun-2011 includes several editorial improvements. Please consider them.

    Telechat:

  5. Relay-Supplied DHCP Options (Proposed Standard)
    draft-ietf-dhc-dhcpv6-relay-supplied-options-06
    Token: Ralph Droms
    Note: John Brzozowski <John_Brzozowski@Cable.Comcast.com> is the document shepherd.
    Discusses/comments (from ballot 3818):
    1. Jari Arkko: Comment [2011-06-09]:
      The document says: "DHCP server implementations SHOULD have a user-configurable list of RSOO-enabled options, so that new RSOO-enabled options do not require software to be updated."
      I think you mean "... administrator-configurable list ..." (the real end user should not be the one dictating what RSOO options are acceptable)
    2. Ralph Droms: Discuss [2011-06-08]:
      The second paragraph of section 8 should be edited to meet the guidelines for IANA Registry creation in RFC 5226. It would be preferable to choose one of the well-known policies from section 4.1 of RFC 5226 for the new registry.
    3. Stephen Farrell: Comment [2011-06-04]:
      I added an RFC editor note for the hokey LDN draft as agreed with its authors. That's at: https://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/writeup/
    4. Russ Housley: Comment [2011-06-06]:
      The Gen-ART Review by Vijay Gurbani on 2-June-2011 includes two editorial improvements. Please consider them.
    5. Pete Resnick: Comment [2011-06-06]:
      These two paragraphs from section 5:
      "DHCP relay agents that implement this specification MUST be configurable not to send the Relay-Supplied Options option."
      "Relay agents implementing this specification SHOULD have a configuration parameter that determines whether or not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Supplied Options option."
      and this sentence from section 6:
      "DHCP server implementations SHOULD have a user-configurable list of RSOO-enabled options, so that new RSOO-enabled options do not require software to be updated."
      seem like implementation advice, not protocol interoperability statements, and therefore are not appropriate for 2119 language. They should be re-worded.
    6. Sean Turner: Discuss [2011-06-09]:
      #1) Section 5 includes: "Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Relay agents MUST NOT modify the contents of any message before forwarding it to the DHCP client."
      but RFC 3315 says: "Clients MUST discard any received Relay-forward messages."
      so should DHCP client be replaced with DHCP server? If not then I'm really confused because I thought this message was only to be sent by the Relay Agent to the Server (i.e., never to the client).
      If the last sentence is not specific to the RSSO option, then isn't it an update to RFC 3315 (at least I couldn't find it in 3315)?
      #2) The security considerations had me scratching my head. It talks about DHCP relay agents being untrusted but 3315 includes the following:
      "If a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships."
    7. Sean Turner: Comment [2011-06-09]:
      In Section 4: r/option should appear in an RSOO/option SHOULD appear in an RSOO ?

    Telechat:

  6. Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID) (Proposed Standard)
    draft-ietf-dhc-duid-uuid-03
    Token: Ralph Droms
    Note: Ted Lemon (mellon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot 3821):
    1. Stephen Farrell: Comment [2011-06-03]:
      "That embeds a [UUID]." - embeds a UUID in what? I guess client or server identifier - might be no harm to clarify if you want.
    2. Russ Housley: Comment [2011-06-08]:
      The Gen-ART Review by Wassim Haddad on 8-June-2011 includes one editorial improvement. Please consider it.
    3. Peter Saint-Andre: Comment [2011-06-07]:
      Please make it clear whether a DUID contains a straight UUID (e.g., "f81d4fae-7dec-11d0-a765-00a0c91e6bf6") or the URN representation (e.g., "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6").

    Telechat:

  7. Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) (Proposed Standard)
    draft-ietf-l3vpn-ibgp-07
    Token: Stewart Bryant
    Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the document shepherd.
    Discusses/comments (from ballot 3823):
    1. Adrian Farrel: Comment [2011-06-07]:
      A rather well written document. Thank you.
    2. Stephen Farrell: Discuss [2011-06-08]:
      I think this should be an easy one.
      Can an ATTR_SET include an ATTR_SET? Currently, that appears to be allowed. I've no idea if that's intended or not. Maybe clarify? If allowed, would that complicate the stack push/pop model in the text?
    3. Stephen Farrell: Comment [2011-06-08]:
      (1) Some acronyms aren't expanded - VRF was the one that got me as well as ASBR. I guess implementers of this would know but just in case.
      (2) The diagram at the start of section 4 could be clearer. I found it confusing anyway.
      (3) last line of p8 - is that "should" or "SHOULD"? When would it be ok to not contain the ASN of the customer?
      (4) s/VPN network/VPN/ (Sorry, pet peeve of mine:-)
      (5) When is it ok to include the NEXT_HOP attribute in an ATTR_SET? Text says SHOULD NOT which implies there are cases when its the right thing to do - documenting (some of) those would be better.
    4. Russ Housley: Comment [2011-06-08]:
      The Gen-ART Review by Suresh Krishnan on 7-Jun-2011 includes two suggestions for improvement.
      (1) The authors readily accepted the first suggestion. Please make sure the changes related to the first one make it into the document prior to publication.
      (2) The authors questioned the value of the second suggestion. My personal preference would be to include a very general statement the need for protection against memory exhaustion attacks in the security considerations section, but I will not demand one.
    5. Sean Turner: Comment [2011-06-09]:
      These ought to be pretty easy to fix up. Most are about 2119 language usage.
      #1) elide the reference from the abstract
      #2) Section 4 contains the following: "When a PE received route is imported into a VRF, its IGP metric, as far as BGP path selection is concerned, should be the metric to the remote PE address, expressed in terms of the service provider metric domain."
      r/should/SHOULD?
      #3) r/ATTR_SET is an optional transitive/ATTR_SET is an OPTIONAL transitive
      #4) Section 5 contains the following: "It should contain the autonomous-system number of the customer network that originates the given set of attributes."
      r/should/SHOULD?
      #5) Section 5 contains the following: "BGP speakers that support the extensions defined in this document must also support RFC4893 [RFC4893]."
      r/must/MUST?
      #6) Section 5 contains the following: "When present it should be ignored by the receiving PE."
      r/should/SHOULD?
      #7) Section 7 contains the following: "Otherwise, in the case of an autonomous-system number mismatch, the set of attributes to be associated with the route shall be constructed as follows:"
      and: "When advertising the VRF route to an Exterior BGP peer, a PE router shall apply steps 1 to 4 defined above and subsequently prepend its own autonomous-system number to the AS_PATH attribute."
      r/shall/SHALL ?
      #8) Section 8 contains the following: "It is recommend that different VRFs of the same VPN (i.e. in different PE routers) which are configured with iBGP PE-CE peering sessions use different Route Distinguisher values."
      r/recommended/RECOMMENDED ?
      also r/Route Distinguisher values/Route Distinguisher (RD) values
      #9) In Section 8, expand NLRI

    Telechat:

  8. PPP TRILL Protocol Control Protocol (Proposed Standard)
    draft-ietf-pppext-trill-protocol-07
    Token: Jari Arkko
    Note: James Carlson (carlsonj@workingcode.com) is the document shepherd.
    Discusses/comments (from ballot 3834):
    1. Stewart Bryant: Comment [2011-06-03]:
      Thank you for addressing my concerns.
    2. Ralph Droms: Comment [2011-06-03]:
      I think the IANA considerations section needs more information for the creation of the "TNCP Configuration Options" registry; e.g., what is the format of the registry, what information needs to be provided for new registrations?
    3. Adrian Farrel: Comment [2011-06-09]:
      I agree with Ralph, the IANA section does not make it easy for IANA to get this right without having to ask questions.
      Please name the registry (not the protocol field). I assume you are using the "PPP DLL Protocol Numbers" registry.
      Please make it clear whether you expect all values of "XX" to be the same or not.
    4. Stephen Farrell: Discuss [2011-06-03]:
      The security considerations section of this doesn't appear to specify any mandatory to implement (MTI) security mechanism. It does say that there are lots of possible choices and perhaps one of the referenced specifications does have some MTI security mechanism that's inherited but that's not clear to me, and nor, I guess would it be clear to a developer. Can you pick one of the various security mechanisms and nominate that as MTI or highlight that something inherited is MTI?
    5. Pete Resnick: Discuss [2011-06-05]:
      I have real process concerns with this document.
      The PPPEXT charter says, "The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required."
      No charter changes occurred during the relevant timeframe. (Imagine the worst case scenario: Nobody expects PPPEXT to be producing new standards track documents without a re-charter, so nobody gave any attention to this document because there was no recharter announcement. For context, PPPEXT has not published a document since 2006, and hasn't published a standards track document since 2004.) So this document is, at the very least, outside of the scope of the charter for the WG. That's a straight up process violation.
      The IESG writeup says that there is no document shepherd because the (only) WG chair is the author of the document. That's not itself a process violation, but it is a concern. So I went to review the mailing list to see the history. This causes me concern also:
      Oct 2009: Chair submits -00, I-D which he authored. Asks for acceptance by WG. Silence. Put on WG page anyway.
      May/June 2010: Chair/author submits -01 I-D. One editorial comment.
      June 2010: Chair asks if anyone else has read the document. Silence.
      Jan 2011: Chair/author submits -02 I-D. Silence for 10 days, at which point chair makes a WGLC. Flurry of messages from 2 participants, 2 other messages, mostly about IS-IS.
      February 2011: One message about the draft, unreplied to until mid-March.
      March 2011: A few messages from the same two participants as January.
      March/April 2011: Chair/author submits -03 I-D. A few messages from the same two participants.
      May 2011: Chair/author submits -04 I-D. Three "looks OK to me" comments, one "agree to disagree" comment. Chair/author submits -05 I-D to fix nits. AD does review.
      May/June 2011: Chair/author submits -06 I-D to address AD comments. IETF LC. RTG Area review. Another flurry of IS-IS discussion.
      June 2011: Chair/author submits -07 I-D removing references to IS-IS including a complete change in a normative requirement in section 2 without any discussion I can find on the mailing list. Document goes to IESG Review.
      All of this seems problematic. I would prefer to see this document re-submitted as an individual submission through the AD and not as the product of this WG, mostly due to the charter violation, but also because (a) the chair as author makes this tricky and (b) it did not get significantly more review than it would have as an individual submission anyway. Maybe this is just process twiddling, but the above all looks very bad from a process perspective.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. IANA Rules for MIKEY (Multimedia Internet KEYing) (Proposed Standard)
    draft-arkko-mikey-iana-01
    Token: Sean Turner
    Note: Ari Keranen (ari.keranen@ericsson.com) is the document shepherd
    Discusses/comments (from ballot 3766):
    1. Russ Housley: Comment [2011-06-06]:
      IDnits reports:
      ** Downref: Normative reference to an Informational RFC: RFC 5410
      ** Downref: Normative reference to an Informational RFC: RFC 6043
    2. Robert Sparks: Comment [2011-06-07]:
      Consider text encouraging future registrants/area directors to seek IETF review instead of starting at IESG approval if there's any doubt about the need for that review.

    Telechat:

  2. Reducing the Standards Track to Two Maturity Levels (BCP)
    draft-housley-two-maturity-levels-06
    Token: Jari Arkko
    Note: Russ Housley (housley@vigilsec.com) is the document shepherd.
    Discusses/comments (from ballot 3804):
    1. Ralph Droms: Discuss [2011-06-08]:
      I support the intention and the specifics in this document, and intend to vote "yes" after we have discussed a couple of points. In general, based on personal experience and observation, I believe that the changes to the standards track will improve those processes. Perhaps now we can advance RFCs 2131, 2132 and 3315 to Internet Standard...
      However, I am not prepared to accept section 2.1 without further discussion. My concern with section 2.1 is that there is no explicit explanation of the ways in which "publishing a Proposed Standard [is] much harder than the stated requirements in RFC 2026" and how "to restore practice to the requirements for Proposed Standard from RFC 2026"." For example, is the intention of this document for the IESG to self-regulate its review of specifications to return to the "stated requirements in RFC 2026?"
      In section 2.2, the specific mechanics for advancing to Internet Standard need to be clarified:
      OLD: The criteria for advancing from Proposed Standard to Internet Standard are confirmed by the IESG in an IETF-wide Last Call of at least two weeks:
      NEW: A specification must satisfy the following criteria before advancing to Internet Standard:
      [...]
      The IESG confirms that the specification meets the criteria. The IESG uses an IETF-wide Last Call of at least two seeks to gather comments from the IETF community about advancement of the specification.
    2. Stephen Farrell: Comment [2011-06-08]:
      (1) "limited to the changes" - might be good to make it clear that all text changes are up for checking. Otherwise someone will make an argument that "I only changed informative text, the protocol's the same" and that the IESG therefore should shut up and go away.
      (2) I don't see that this document changes anything at all in terms of the difficulty of getting a 1st PS. That's ok, but the text is a bit misleading on this I think. In particular, I'd delete "The intention of the two-tier maturity ladder is to restore practice to the requirements for Proposed Standard from RFC 2026, and stop performing more scrutiny than intended in IETF working groups and the IESG." That may be the authors' intention and it might be good or bad, but this document does nothing about it.
      (3) I don't know from reading this if STD numbers will be allocated for "Internet Standard" RFCs. (It says that STD numbers are allocated to "full Standard maturity level" documents, and that existing practice will remain, but after this BCP there will be no more "full Standard" documents, so its not clear.)
    3. Pete Resnick: Discuss [2011-06-08]:
      I agree fully with Peter's DISCUSS. He summarized much better than I could have.
      I do believe that there probably *is* agreement on the requirement changes to move from Proposed to whatever is the next level and that these changes do address a problem by lowering the burden of moving out of Proposed. I would like to see those adopted, independent of agreement on the other two portions (i.e., returning to a lower bar for Proposed, or removing one level of the standards track).
    4. Peter Saint-Andre: Discuss [2011-06-08]:
      I would love to ballot "Yes" on this document. However, having reviewed the feedback provided during IETF Last Call, I am not comfortable with saying that we have rough consensus to proceed with publication. I hope this DISCUSS will provide some helpful input to a conversation about the path forward.
      My reading of the Last Call feedback is that there is quite a bit of confusion about what problem(s) we need to solve in this space. Some of the possibilities are:
      1. Make it easier to advance to Proposed Standard, e.g., by returning to the RFC 2026 philosophy of what "Proposed" means.
      2. Simplify and clarify the process of progressing from Proposed Standard to Draft Standard, e.g. by telling folks that implementation reports don't need to be a huge undertaking.
      3. Advance more specifications to Full Standard, e.g. by removing obstacles or providing incentives for advancement.
      4. Improve our "branding" and better satisfy our "customers", e.g. by removing stages in the standards process that few people have used.
      5. Align our documentation with the reality of the processes that we actually follow.
      6. Start measuring the right things, e.g. by getting rid of interoperability reports and instead gauging widespread deployment.
      7. Encourage working groups and document editors to incorporate implementation and deployment feedback into their specs throughout the process, e.g. by making it easier to iterate at Proposed Standard.
      It seems that until we have clarity in the community about which problem(s) we're trying to solve, we'll never reach consensus about which solutions we need. My reluctant conclusion is that another round of problem-defining is required before we proceed to problem-solving.
    5. Sean Turner: Comment [2011-06-07]:
      Section 2 contains the following:
      "Experience with a Proposed Standard often leads to revisions that clarify, modify, enhance, or remove features. Review of revisions to a Proposed Standard that is submitted for publication at the same maturity level is generally limited to the changes."
      Perhaps r/the changes/these types of changes ?
      RFC 5967 already updates RFC 2026, but a reference to RFC 2026 in Section 2.2 would be helpful to those writing implementation reports.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol (Historic)
    draft-ietf-mpls-mp-ldp-reqs-08
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    Discusses/comments (from ballot 3806):
    1. Stephen Farrell: Comment [2011-05-30]:
      TCP MD5: yuk but, I guess, ok for an historic document
    2. Pete Resnick: Discuss [2011-06-05]:
      The only indication *in the document* of why this thing is being put forward as "Historic" is because it is "documenting the work done". But normally if that were the case, the document would be published as Informational. Historic documents are supposed to be "superseded by a more recent specification or is for any other reason considered to be obsolete", and nowhere in this document does it indicate any newer specification that supersedes it nor any reason it is obsolete. In fact, it reads as if it *is* a set of requirements, and uses lots of RFC 2119 language to do so. That sounds to me like it is trying to be standards track.
      However, when I go to the IESG Writeup, there is an indication that it is being published Historic because there is a specification that "already exists and there are deployed implementations" and that somehow this document might "conflict" with those. That reads to me like "the WG came up with this set of requirements for LDP extensions, but we didn't follow them". If *that's* true, then I want to hear about why these requirements weren't followed and why they shouldn't be. But when I try to figure out how the WG made the decision to go forward with this document, all I get in the writeup is:
      "Working Group Summary: This document is an output from the MPLS working group and we have good support for it."
      :Document Quality: The document is well reviewed."
      I'm sorry, but that writeup is utterly content-free. I have no idea why the MPLS WG would have *any* support for this document, and the above does nothing to explain it. I want a real IESG writeup of this document before I can even attempt to understand what the WG thought it was doing with this document.
    3. Peter Saint-Andre: Discuss [2011-06-07]:
      I don't intend to hold up publication over the matter, but I'd like to have a conversation about why this document is Historic, not Informational. RFC 2026 states:
      "A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level."
      As far as I can see, this document has not been superseded and is not to be considered obsolete.

    Telechat:

3.1.2 Returning Items

  1. Clarification of sender behavior in persist condition. (Informational)
    draft-ietf-tcpm-persist-04
    Token: Wesley Eddy
    Note: Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3812):
    1. Stewart Bryant: Comment [2011-05-23]:
      "Systems that adhere too strictly to the above verbiage of"
      Comment: In English English I would not consider "verbiage" to be polite to the author of RFC1122.
    2. Ralph Droms: Comment [2011-06-07]:
      Are the phrases "Zero-Window Probe (ZWP)", 'persist condition', "ZWP state" and "ZWP or persist condition" all equivalent? If so, for consistency, choose one and use it throughout.
      At the end of section 3, for clarity, I suggest changing:
      OLD: to persist legitimate connections
      NEW: to maintain legitimate connections in persist condition
    3. Adrian Farrel: Comment [2011-06-09]:
      Support David and Pete's Discusses
    4. David Harrington: Discuss [2011-06-01]:
      1) persist is Informational, but you are using RFC2119 language.
      2) does this document update rfc1122? the header doesn't say so, nor does the abstract or intro sections.
    5. Russ Housley: Discuss [2011-06-08]:
      The Gen-ART Review by Brian Carpenter on 5-Jun-2011 started quite a discussion. That discussion does not seem to have reached closure. I find myself siding with the argument presented by David Borman for publication of this document as an Informational RFC, but this discussion needs to come to closure for a reasonable consensus call on this point.
    6. Pete Resnick: Discuss [2011-06-05]:
      In the introduction: "This guidance is not intended to preclude resource management by the operating system or application, which may request connections to be aborted regardless of them being in the persist condition, and the TCP implementation should, of course, comply by aborting such connections."
      And in section 5: "...a TCP implementation MUST allow connections in the ZWP or persist condition to be closed or aborted by their applications or other resource management routines in the operating system."
      It's likely that these statements are either superfluous or incorrect. The 1122 instructions say that "TCP MUST allow the connection to stay open." It doesn't put any requirement on operating systems or applications which might purposefully abort connections for any purpose, including the DoS attack identified in this document, or because of user-cancel operations, or system shutdowns, or any number of other reasons, and I have no indication (at least it is nowhere cited in this document) that anybody has taken the guidance to TCP to mean that such aborts should not be honored. So in that sense, I think the statement doesn't add much to the interpretation of TCP.
      However, insofar as this statement intends that operating systems or applications ought to be allowed to *blindly* abort connections in persist condition, I think it is flat wrong. That is to say, if the operating system has some reason to believe that the connection is actually dead, or an attack, of course an abort is justified.
      As the document says in section 4: "A clever application might detect such attacks with connections that are not making progress, and could close these connections."
      And indeed, this should be recommended behavior in the face of the attack.
      However, the next sentence reveals what is actually going on here: "...However, some applications might have transferred all the data to the TCP socket and subsequently closed the socket leaving the connection with no controlling process, hereby referred to as orphaned connections."
      It is socket implementations, not TCP, that are the real problem here. Many of these APIs that allow applications to exit without gracefully closing TCP connections are what is causing the problem, not the protocol design of TCP or the implementation requirements in 1122.
      If the WG (and the IETF) really think that this has something to do with the requirements of 1122, then this document needs to be standards track, not informational, and should explain why this is a protocol problem. If this is just a security consideration regarding persist condition connections, then it should state that applications and/or operating systems need to look out for this attack and only abort those connections that it has determined are in fact attacks and not all persist condition connections (and probably give some implementation advice about how to distinguish real persist condition from an attack). And if this document is about the socket API, it should stick to discussion about that and not implicate 1122 in this mess. In either of the latter two cases, as per David Harrington's discussion, it should remove the 2119 language since it is informational and no protocol change is being made.
    7. Peter Saint-Andre: Comment [2011-06-07]:
      Please expand "DoS" on first use and add an informative reference to RFC 4732.
    8. Sean Turner: Comment [2011-06-09]:
      I'm with Dave on this - shouldn't this draft include "Updates: 1122 (once approved)" in the header? If it is updating 1122 then doesn't it have to go standards track?

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. The SSL Protocol Version 3.0 (Historic)
    draft-mavrogiannopoulos-ssl-version3-05
    Token: Sean Turner
    Note: Nikos Mavrogiannopoulos (nmav@gnutls.org) is the document shepherd; Please note the person submitting this draft is *NOT* one of the authors; however we felt it extremely important to retain their names and affiliations on this draft.
    Discusses/comments (from ballot 3787):
    1. Jari Arkko: Comment [2011-06-09]:
      I agree with Adrian's Discuss.
    2. Wesley Eddy: Comment [2011-06-07]:
      I support Adrian's DISCUSS
    3. Adrian Farrel: Discuss [2011-06-07]:
      Thank you for taking the trouble to produce this document and for including the Foreword to explain why the document is being published.
      I find that despite the Foreword and the Historic status, the tone of the document tends toward implying that the IETF supports implementation of SSL v3.0. This problem is caused by:
      - The Abstract not mentioning Historic or "do not implement"
      - The Introduction being copied from the original I-D (which obviously intended implementation)
      - The document containing a section "Goals of this document" which reflect the original aims of the document not the actual aims of the RFC.
      I don't want to cause a lot of work or heartache, but we need to make it abundantly clear what is going on. Can I make the following suggestions...
      1. Abstract: s/specifies/describes/
      2. Add a second short paragraph to the Abstract. "This document is published as a historical record of the SSL v3.0 protocol. New implementations of SSL v3.0 are not recommended because the protocol has been made obsolete by Transport Layer Security (TLS) described in RFC 5246."
      3. Remove section 3
      You might salvage some of the text by adding the following to the end of the Introduction...
      This document is not intended to supply any details of service definition nor interface definition, although it does cover select areas of policy as they are required for the maintenance of solid security.
    4. Stephen Farrell: Comment [2011-06-08]:
      (blank)

    Telechat:

3.2.2 Returning Items

  1. Multiple Attachments for EDI-INT (Informational)
    draft-meadors-multiple-attachments-ediint-12
    Token: Pete Resnick
    Discusses/comments (from ballot 3688):
    1. Stewart Bryant: Comment [2011-03-16]:
      There are a number of id-nits that need be fixed before the document considered ready for publication (IANA section and RFC2119 language). Also the editor should confirm that all of the lower case "should" instances are correctly set.
    2. Stephen Farrell: Comment [2011-05-30]:
      Even though this has enough positions to go ahead, Pete asked if newbies like me were ok with that, so since I'd not seen this before, I took a look. I've no problem if these are ignored really, but fwiw:
      (1) The draft says that people "began" doing stuff, which is fine, but would be even better with some references to that (if some exist) so the reader could understand better.
      (2) s/this body is covered/this body are covered/
      (3) It says the attachments "should" be inter-related - is that meant to be a 2119 SHOULD? I'm also unclear as to what inter-related means, but I guess that's really a higher layer issue (in which case do you really need to impose the constraint at this level?). If that was a 2119 SHOULD then under which conditions is it ok to ignore the rule? (maybe easiest is s/should/ought/ just to avoid potential 2119 confusion)
      (4) I think 2.3 says that for an encrypted message the MIC is calculated over the plaintext but is sent outside the encryption. If so, that's less common than also encrypting the MIC and is usually specifically justified, but maybe I'm misreading it (and I didn't go read the references to check sorry;-)
      (5) Section 4 mentions "the three EDI-INT transport standards" but doesn't include the references at that point - I think it'd be good to repeat those for clarity.
    3. Russ Housley: Comment [2011-03-16]:
      In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is raised. Please consider it:
      "There is a space in the declaration of boundary=" INNER-BOUNDARY"; in the example in section 3. I am not sure whether this was intentional or whether it will mess up a standard MIME parser, but you may want to remove it."
    4. Alexey Melnikov: Comment [2011-03-12]:
      Should this document be published with "no IETF consensus" boilerplate?
    5. Pete Resnick: Comment [2011-05-24]:
      This is an individual submission of an Informational document I picked up from Alexey, so I don't know the full history. Sean's discuss (the only one) has been cleared, so I could approve it, but since half of the IESG hasn't entered a position, I'd like to double-check and have people give it a gander before sending it on its merry way.
    6. Sean Turner: Comment [2011-03-16]:
      Sec 2.3 says: "If the expected MIC value differs from the calculated MIC value, all attachments MUST be considered invalid and retransmitted."
      Isn't telling the initiator that they didn't match and asking for the retransmission missing?

    Telechat:

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1259 EDT break

1300 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Content Delivery Networks Interconnection (cdni)
    Token: David

    Telechat:

4.1.2 Proposed for Approval

  1. Protocol to Access WS database (paws)
    Token: Peter

    Telechat:

  2. IPv6 Site Renumbering (6renum)
    Token: Ron

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Open Authentication Protocol (oauth)
    Token: Stephen

    Telechat:

5. IAB News We can use

6. Management Issues

  1. IESG Processing of RFC Errata concerning RFC Metadata (Stewart Bryant)

    Telechat:

  2. IESG Statement on Historic (Sean Turner)

    Telechat:

7. Agenda Working Group News

1341 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-06-09 07:31:13 PDT)

draft-ietf-sieve-external-lists

  1. Adrian Farrel: Comment [2011-06-09]:
    Just a couple of WIBNIs
    
    The first sentence of the Abstract could usefully mention email. The
    Introduction might benefit similarly.
    
    ---
    
    Would be nice if section 1.1 said "ABNF" when pointing to 5234.
    
  2. Stephen Farrell: Comment [2011-06-02]:
    "Implementations MAY support other tests but MUST raise an error
    (which SHOULD be a compile-time error, but MAY be a runtime error) when
    a script uses ":list" with a test for which it is not supported."
    
    That's a bit unclear - what's the last "it"? Maybe s/for which it/that/
    

draft-faltstrom-5892bis

  1. Ron Bonica: Comment [2011-06-08]:
    Unicode 6.0 is mentioned in the text body and included in the reference section,
    but there are no formal references to the document. (Run the nit-checker and you
    will see what I mean).
  2. Wesley Eddy: Comment [2011-06-03]:
    typo in section 1: "that where allocated" -> "that were allocated"?
  3. Adrian Farrel: Comment [2011-06-07]:
    Abstract
    
    I don't know what it means to "specify consensus". Suggest...
    
    OLD
       This document specifies IETF consensus
    NEW
       This memo documents IETF consensus
    END
    
  4. Stephen Farrell: Comment [2011-06-02]:
    s/This imply/This implies/
    

draft-ietf-ccamp-gmpls-vcat-lcas

  1. Stephen Farrell: Comment [2011-06-07]:
    
        
  2. Russ Housley: Comment [2011-06-08]:
      The Gen-ART Review by Kathleen Moriarty on 7-Jun-2011 includes
      several editorial improvements.  Please consider them.

draft-ietf-dhc-dhcpv6-relay-supplied-options

  1. Jari Arkko: Comment [2011-06-09]:
    The document says:
    
       DHCP server implementations SHOULD have a
       user-configurable list of RSOO-enabled options, so that new RSOO-
       enabled options do not require software to be updated.
    
    I think you mean "... administrator-configurable list ..." (the real end user
    should not be the one dictating what RSOO options are acceptable)
  2. Ralph Droms: Discuss [2011-06-08]:
        The second paragraph of section 8 should be edited to meet the
    guidelines for IANA Registry creation in RFC 5226.  It would be
    preferable to choose one of the well-known policies from section 4.1
    of RFC 5226 for the new registry. 
        
  3. Stephen Farrell: Comment [2011-06-04]:
    I added an RFC editor note for the hokey LDN draft as agreed
    with its authors. That's at:
    
       https://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/writeup/
  4. Russ Housley: Comment [2011-06-06]:
      The Gen-ART Review by Vijay Gurbani on 2-June-2011 includes two
      editorial improvements.  Please consider them.
  5. Pete Resnick: Comment [2011-06-06]:
    These two paragraphs from section 5:
    
       DHCP relay agents that implement this specification MUST be
       configurable not to send the Relay-Supplied Options option.
       
       Relay agents implementing this specification SHOULD have a
       configuration parameter that determines whether or not they will
       relay a Relay-Forward message toward the DHCP server if it contains a
       Relay-Supplied Options option.
    
    and this sentence from section 6:
    
       DHCP server implementations SHOULD have a
       user-configurable list of RSOO-enabled options, so that new RSOO-
       enabled options do not require software to be updated.
    
    seem like implementation advice, not protocol interoperability statements, and
    therefore are not appropriate for 2119 language. They should be re-worded.
  6. Sean Turner: Discuss [2011-06-09]:
        #1) Section 5 includes:
    
       Relay agents MAY include a Relay-Supplied Options option in the
       option payload of a Relay-Forward message.  Relay agents MUST NOT
       modify the contents of any message before forwarding it to the DHCP
       client.
    
    but RFC 3315 says:
    
     Clients MUST discard any received Relay-forward messages.
    
    so should DHCP client be replaced with DHCP server?  If not then I'm really
    confused because I thought this message was only to be sent by the Relay Agent
    to the Server (i.e., never to the client).
    
    If the last sentence is not specific to the RSSO option, then isn't it an update
    to RFC 3315 (at least I couldn't find it in 3315)?
    
    #2) The security considerations had me scratching my head.  It talks about DHCP
    relay agents being untrusted but 3315 includes the following:
    
       If a client message is relayed
       through multiple relay agents, each of the relay agents must have
       established independent, pairwise trust relationships. 
        
  7. Sean Turner: Comment [2011-06-09]:
    In Section 4: r/option should appear in an RSOO/option SHOULD appear in an RSOO
    ?
    
    

draft-ietf-dhc-duid-uuid

  1. Stephen Farrell: Comment [2011-06-03]:
    "That embeds a [UUID]."  - embeds a UUID in what? I guess
    client or server identifier - might be no harm to clarify if
    you want.
  2. Russ Housley: Comment [2011-06-08]:
      The Gen-ART Review by Wassim Haddad on 8-June-2011 includes one
      editorial improvement.  Please consider it.
  3. Peter Saint-Andre: Comment [2011-06-07]:
    Please make it clear whether a DUID contains a straight UUID (e.g., "f81d4fae-
    7dec-11d0-a765-00a0c91e6bf6") or the URN representation (e.g., "urn:uuid
    :f81d4fae-7dec-11d0-a765-00a0c91e6bf6").

draft-ietf-l3vpn-ibgp

  1. Adrian Farrel: Comment [2011-06-07]:
    A rather well written document. Thank you.
  2. Stephen Farrell: Discuss [2011-06-08]:
        
    I think this should be an easy one. 
    
    Can an ATTR_SET include an ATTR_SET? Currently, that
    appears to be allowed. I've no idea if that's intended
    or not. Maybe clarify? If allowed, would that complicate
    the stack push/pop model in the text?
     
        
  3. Stephen Farrell: Comment [2011-06-08]:
    (1) Some acronyms aren't expanded - VRF was the one that 
    got me as well as ASBR. I guess implementers of this would 
    know but just in case.
    
    (2) The diagram at the start of section 4 could be clearer.
    I found it confusing anyway. 
    
    (3) last line of p8 - is that "should" or "SHOULD"? When 
    would it be ok to not contain the ASN of the customer? 
    
    (4) s/VPN network/VPN/ (Sorry, pet peeve of mine:-)
    
    (5) When is it ok to include the NEXT_HOP attribute in
    an ATTR_SET? Text says SHOULD NOT which implies there
    are cases when its the right thing to do - documenting
    (some of) those would be better.
    
  4. Russ Housley: Comment [2011-06-08]:
      The Gen-ART Review by Suresh Krishnan on 7-Jun-2011 includes two
      suggestions for improvement.
      
      (1) The authors readily accepted the first suggestion.  Please
      make sure the changes related to the first one make it into the
      document prior to publication.
    
      (2) The authors questioned the value of the second suggestion.  My
      personal preference would be to include a very general statement the
      need for protection against memory exhaustion attacks in the security
      considerations section, but I will not demand one.
  5. Sean Turner: Comment [2011-06-09]:
    These ought to be pretty easy to fix up.  Most are about 2119 language usage.
    
    #1) elide the reference from the abstract
    
    #2) Section 4 contains the following:
    
       When a PE received route is imported into a VRF, its IGP metric, as
       far as BGP path selection is concerned, should be the metric to the
       remote PE address, expressed in terms of the service provider metric
       domain.
    
    r/should/SHOULD?
    
    #3) r/ATTR_SET is an optional transitive/ATTR_SET is an OPTIONAL transitive 
    
    #4) Section 5 contains the following:
    
       It
       should contain the autonomous-system number of the customer network
       that originates the given set of attributes.
    
    r/should/SHOULD?
    
    #5) Section 5 contains the following:
    
       BGP speakers that support the
       extensions defined in this document must also support RFC4893
       [RFC4893].
    
    r/must/MUST?
    
    #6) Section 5 contains the following:
    
       When
       present it should be ignored by the receiving PE.
    
    r/should/SHOULD?
    
    #7) Section 7 contains the following:
    
       Otherwise, in the case of an autonomous-
       system number mismatch, the set of attributes to be associated
       with the route shall be constructed as follows:
    
    and
    
       When advertising the VRF route to an Exterior BGP peer, a PE
       router shall apply steps 1 to 4 defined above and subsequently
       prepend its own autonomous-system number to the AS_PATH attribute.
    
    r/shall/SHALL ?
    
    #8) Section 8 contains the following:
    
       It is recommend that different VRFs of the same VPN (i.e. in
       different PE routers) which are configured with iBGP PE-CE peering
       sessions use different Route Distinguisher values.
    
    r/recommended/RECOMMENDED ?
    
    also r/Route Distinguisher values/Route Distinguisher (RD) values
    
    #9) In Section 8, expand NLRI

draft-ietf-pppext-trill-protocol

  1. Stewart Bryant: Comment [2011-06-03]:
    Thank you for addressing my concerns.
  2. Ralph Droms: Comment [2011-06-03]:
    I think the IANA considerations section needs more information for the creation
    of the "TNCP Configuration Options" registry; e.g., what is the format of the
    registry, what information needs to be provided for new registrations?
  3. Adrian Farrel: Comment [2011-06-09]:
    I agree with Ralph, the IANA section does not make it easy for IANA to get this
    right without having to ask questions.
    
    Please name the registry (not the protocol field). I assume you are using the
    "PPP DLL Protocol Numbers" registry.
    
    Please make it clear whether you expect all values of "XX" to be the same or
    not.
  4. Stephen Farrell: Discuss [2011-06-03]:
        
    The security considerations section of this doesn't appear to specify any
    mandatory to implement (MTI) security mechanism. It does say that there are
    lots of possible choices and perhaps one of the referenced specifications
    does have some MTI security mechanism that's inherited but that's not
    clear to me, and nor, I guess would it be clear to a developer. Can you 
    pick one of the various security mechanisms and nominate that as MTI
    or highlight that something inherited is MTI?
     
        
  5. Pete Resnick: Discuss [2011-06-05]:
        I have real process concerns with this document.
    
    The PPPEXT charter says, "The group is not expected to create new
    specifications, and if a need for such work comes up, a recharter is required."
    No charter changes occurred during the relevant timeframe. (Imagine the worst
    case scenario: Nobody expects PPPEXT to be producing new standards track
    documents without a re-charter, so nobody gave any attention to this document
    because there was no recharter announcement. For context, PPPEXT has not
    published a document since 2006, and hasn't published a standards track document
    since 2004.) So this document is, at the very least, outside of the scope of the
    charter for the WG. That's a straight up process violation.
    
    The IESG writeup says that there is no document shepherd because the (only) WG
    chair is the author of the document. That's not itself a process violation, but
    it is a concern. So I went to review the mailing list to see the history. This
    causes me concern also:
    
    Oct 2009: Chair submits -00, I-D which he authored. Asks for acceptance by WG.
    Silence. Put on WG page anyway.
    
    May/June 2010: Chair/author submits -01 I-D. One editorial comment.
    
    June 2010: Chair asks if anyone else has read the document. Silence.
    
    Jan 2011: Chair/author submits -02 I-D. Silence for 10 days, at which point
    chair makes a WGLC. Flurry of messages from 2 participants, 2 other messages,
    mostly about IS-IS.
    
    February 2011: One message about the draft, unreplied to until mid-March.
    
    March 2011: A few messages from the same two participants as January.
    
    March/April 2011: Chair/author submits -03 I-D. A few messages from the same two
    participants.
    
    May 2011: Chair/author submits -04 I-D. Three "looks OK to me" comments, one
    "agree to disagree" comment. Chair/author submits -05 I-D to fix nits. AD does
    review.
    
    May/June 2011: Chair/author submits -06 I-D to address AD comments. IETF LC. RTG
    Area review. Another flurry of IS-IS discussion.
    
    June 2011: Chair/author submits -07 I-D removing references to IS-IS including a
    complete change in a normative requirement in section 2 without any discussion I
    can find on the mailing list. Document goes to IESG Review.
    
    All of this seems problematic. I would prefer to see this document re-submitted
    as an individual submission through the AD and not as the product of this WG,
    mostly due to the charter violation, but also because (a) the chair as author
    makes this tricky and (b) it did not get significantly more review than it would
    have as an individual submission anyway. Maybe this is just process twiddling,
    but the above all looks very bad from a process perspective. 
        

draft-arkko-mikey-iana

  1. Russ Housley: Comment [2011-06-06]:
      IDnits reports:
      ** Downref: Normative reference to an Informational RFC: RFC 5410
      ** Downref: Normative reference to an Informational RFC: RFC 6043
  2. Robert Sparks: Comment [2011-06-07]:
    Consider text encouraging future registrants/area directors to seek IETF review
    instead of starting at IESG approval if there's any doubt about the need for
    that review.

draft-housley-two-maturity-levels

  1. Ralph Droms: Discuss [2011-06-08]:
        I support the intention and the specifics in this document, and intend
    to vote "yes" after we have discussed a couple of points.  In general,
    based on personal experience and observation, I believe that the
    changes to the standards track will improve those processes.  Perhaps
    now we can advance RFCs 2131, 2132 and 3315 to Internet Standard...
    
    However, I am not prepared to accept section 2.1 without further
    discussion.  My concern with section 2.1 is that there is no explicit
    explanation of the ways in which "publishing a Proposed Standard [is]
    much harder than the stated requirements in RFC 2026" and how "to
    restore practice to the requirements for Proposed Standard from RFC
    2026"."  For example, is the intention of this document for the IESG
    to self-regulate its review of specifications to return to the "stated
    requirements in RFC 2026?"
    
    In section 2.2, the specific mechanics for advancing to Internet
    Standard need to be clarified:
    
    OLD:
    
       The criteria for advancing from Proposed Standard to Internet
       Standard are confirmed by the IESG in an IETF-wide Last Call of at
       least two weeks:
    
    NEW:
    
       A specification must satisfy the following criteria before
       advancing to Internet Standard:
    
          [...]
    
       The IESG confirms that the specification meets the criteria.  The
       IESG uses an IETF-wide Last Call of at least two seeks to gather
       comments from the IETF community about advancement of the
       specification. 
        
  2. Stephen Farrell: Comment [2011-06-08]:
    (1) "limited to the changes" - might be good to make it clear 
    that all text changes are up for checking. Otherwise someone 
    will make an argument that "I only changed informative text, 
    the protocol's the same" and that the IESG therefore should
    shut up and go away.
    
    (2) I don't see that this document changes anything at all in 
    terms of the difficulty of getting a 1st PS. That's ok, but the 
    text is a bit misleading on this I think. In particular, I'd delete 
    "The intention of the two-tier maturity ladder is to restore 
    practice to the requirements for Proposed Standard from
    RFC 2026, and stop performing more scrutiny than intended 
    in IETF working groups and the IESG." That may be the 
    authors' intention and it might be good or bad, but this 
    document does nothing about it.
       
    (3) I don't know from reading this if STD numbers will be 
    allocated for "Internet Standard" RFCs.  (It says that 
    STD numbers are allocated to "full Standard maturity 
    level" documents, and that existing practice will remain, 
    but after this BCP there will be no more "full Standard"
    documents, so its not clear.)
    
  3. Pete Resnick: Discuss [2011-06-08]:
        I agree fully with Peter's DISCUSS. He summarized much better than I could have.
    
    I do believe that there probably *is* agreement on the requirement changes to
    move from Proposed to whatever is the next level and that these changes do
    address a problem by lowering the burden of moving out of Proposed. I would like
    to see those adopted, independent of agreement on the other two portions (i.e.,
    returning to a lower bar for Proposed, or removing one level of the standards
    track). 
        
  4. Peter Saint-Andre: Discuss [2011-06-08]:
        I would love to ballot "Yes" on this document.  However, having reviewed
    the feedback provided during IETF Last Call, I am not comfortable with
    saying that we have rough consensus to proceed with publication.  I hope 
    this DISCUSS will provide some helpful input to a conversation about the 
    path forward.
    
    My reading of the Last Call feedback is that there is quite a bit of
    confusion about what problem(s) we need to solve in this space.  Some of  
    the possibilities are:
    
    1. Make it easier to advance to Proposed Standard, e.g., by returning to  
    the RFC 2026 philosophy of what "Proposed" means.
    
    2. Simplify and clarify the process of progressing from Proposed
    Standard to Draft Standard, e.g. by telling folks that implementation
    reports don't need to be a huge undertaking.
    
    3. Advance more specifications to Full Standard, e.g. by removing
    obstacles or providing incentives for advancement.
    
    4. Improve our "branding" and better satisfy our "customers", e.g. by
    removing stages in the standards process that few people have used.
    
    5. Align our documentation with the reality of the processes that we
    actually follow.
    
    6. Start measuring the right things, e.g. by getting rid of
    interoperability reports and instead gauging widespread deployment.
    
    7. Encourage working groups and document editors to incorporate
    implementation and deployment feedback into their specs throughout the 
    process, e.g. by making it easier to iterate at Proposed Standard.
    
    It seems that until we have clarity in the community about which
    problem(s) we're trying to solve, we'll never reach consensus about
    which solutions we need.  My reluctant conclusion is that another 
    round of problem-defining is required before we proceed to 
    problem-solving.
     
        
  5. Sean Turner: Comment [2011-06-07]:
    Section 2 contains the following:
    
       Experience with a Proposed Standard often leads to revisions that
       clarify, modify, enhance, or remove features.  Review of revisions to
       a Proposed Standard that is submitted for publication at the same
       maturity level is generally limited to the changes.
    
    Perhaps r/the changes/these types of changes ?
    
    RFC 5967 already updates RFC 2026, but a reference to RFC 2026 in Section 2.2
    would be helpful to those writing implementation reports.

draft-ietf-mpls-mp-ldp-reqs

  1. Stephen Farrell: Comment [2011-05-30]:
    TCP MD5: yuk but, I guess, ok for an historic document
    
  2. Pete Resnick: Discuss [2011-06-05]:
        The only indication *in the document* of why this thing is being put forward as
    "Historic" is because it is "documenting the work done". But normally if that
    were the case, the document would be published as Informational. Historic
    documents are supposed to be "superseded by a more recent specification or is
    for any other reason considered to be obsolete", and nowhere in this document
    does it indicate any newer specification that supersedes it nor any reason it is
    obsolete. In fact, it reads as if it *is* a set of requirements, and uses lots
    of RFC 2119 language to do so. That sounds to me like it is trying to be
    standards track.
    
    However, when I go to the IESG Writeup, there is an indication that it is being
    published Historic because there is a specification that "already exists and
    there are deployed implementations" and that somehow this document might
    "conflict" with those. That reads to me like "the WG came up with this set of
    requirements for LDP extensions, but we didn't follow them". If *that's* true,
    then I want to hear about why these requirements weren't followed and why they
    shouldn't be. But when I try to figure out how the WG made the decision to go
    forward with this document, all I get in the writeup is:
    
    Working Group Summary
    
      This document is an output from the MPLS working group and we have
      good support for it.
    
    Document Quality
    
      The document is well reviewed.
    
    I'm sorry, but that writeup is utterly content-free. I have no idea why the MPLS
    WG would have *any* support for this document, and the above does nothing to
    explain it. I want a real IESG writeup of this document before I can even
    attempt to understand what the WG thought it was doing with this document. 
        
  3. Peter Saint-Andre: Discuss [2011-06-07]:
        I don't intend to hold up publication over the matter, but I'd like to have a
    conversation about why this document is Historic, not Informational. RFC 2026
    states:
    
       A specification that has been superseded by a more recent
       specification or is for any other reason considered to be obsolete is
       assigned to the "Historic" level.
    
    As far as I can see, this document has not been superseded and is not to be
    considered obsolete. 
        

draft-ietf-tcpm-persist

  1. Stewart Bryant: Comment [2011-05-23]:
       "Systems that adhere too strictly to the above verbiage of"
    
    Comment: In English English I would not  consider "verbiage" to be polite to the
    author of RFC1122.
  2. Ralph Droms: Comment [2011-06-07]:
    Are the phrases "Zero-Window Probe (ZWP)", 'persist condition', "ZWP
    state" and "ZWP or persist condition" all equivalent?  If so, for
    consistency, choose one and use it throughout.
    
    At the end of section 3, for clarity, I suggest changing:
    
    OLD:
    
       to persist legitimate connections
    
    NEW:
    
       to maintain legitimate connections in persist condition
    
  3. Adrian Farrel: Comment [2011-06-09]:
    Support David and Pete's Discusses
  4. David Harrington: Discuss [2011-06-01]:
        1) persist is Informational, but you are using RFC2119 language.
    
    2) does this document update rfc1122? the header doesn't say so, nor does the
    abstract or intro sections. 
        
  5. Russ Housley: Discuss [2011-06-08]:
        
      The Gen-ART Review by Brian Carpenter on 5-Jun-2011 started quite a
      discussion.  That discussion does not seem to have reached closure.
      I find myself siding with the argument presented by David Borman for
      publication of this document as an Informational RFC, but this
      discussion needs to come to closure for a reasonable consensus call
      on this point. 
        
  6. Pete Resnick: Discuss [2011-06-05]:
        In the introduction:
    
       This guidance is not intended to preclude resource management by the
       operating system or application, which may request connections to be
       aborted regardless of them being in the persist condition, and the
       TCP implementation should, of course, comply by aborting such
       connections.
    
    And in section 5:
    
       ...a TCP implementation MUST allow
       connections in the ZWP or persist condition to be closed or aborted
       by their applications or other resource management routines in the
       operating system.
    
    It's likely that these statements are either superfluous or incorrect. The 1122
    instructions say that "TCP MUST allow the connection to stay open." It doesn't
    put any requirement on operating systems or applications which might
    purposefully abort connections for any purpose, including the DoS attack
    identified in this document, or because of user-cancel operations, or system
    shutdowns, or any number of other reasons, and I have no indication (at least it
    is nowhere cited in this document) that anybody has taken the guidance to TCP to
    mean that such aborts should not be honored. So in that sense, I think the
    statement doesn't add much to the interpretation of TCP.
    
    However, insofar as this statement intends that operating systems or
    applications ought to be allowed to *blindly* abort connections in persist
    condition, I think it is flat wrong. That is to say, if the operating system has
    some reason to believe that the connection is actually dead, or an attack, of
    course an abort is justified. As the document says in section 4:
    
       A clever application might detect such attacks with connections that
       are not making progress, and could close these connections.
    
    And indeed, this should be recommended behavior in the face of the attack.
    However, the next sentence reveals what is actually going on here:
    
       ...However,
       some applications might have transferred all the data to the TCP
       socket and subsequently closed the socket leaving the connection with
       no controlling process, hereby referred to as orphaned connections.
    
    It is socket implementations, not TCP, that are the real problem here. Many of
    these APIs that allow applications to exit without gracefully closing TCP
    connections are what is causing the problem, not the protocol design of TCP or
    the implementation requirements in 1122.
    
    If the WG (and the IETF) really think that this has something to do with the
    requirements of 1122, then this document needs to be standards track, not
    informational, and should explain why this is a protocol problem. If this is
    just a security consideration regarding persist condition connections, then it
    should state that applications and/or operating systems need to look out for
    this attack and only abort those connections that it has determined are in fact
    attacks and not all persist condition connections (and probably give some
    implementation advice about how to distinguish real persist condition from an
    attack). And if this document is about the socket API, it should stick to
    discussion about that and not implicate 1122 in this mess. In either of the
    latter two cases, as per David Harrington's discussion, it should remove the
    2119 language since it is informational and no protocol change is being made. 
        
  7. Peter Saint-Andre: Comment [2011-06-07]:
    Please expand "DoS" on first use and add an informative reference to RFC 4732.
  8. Sean Turner: Comment [2011-06-09]:
    I'm with Dave on this - shouldn't this draft include "Updates: 1122 (once
    approved)" in the header?  If it is updating 1122 then doesn't it have to go
    standards track?

draft-mavrogiannopoulos-ssl-version3

  1. Jari Arkko: Comment [2011-06-09]:
    I agree with Adrian's Discuss.
  2. Wesley Eddy: Comment [2011-06-07]:
    I support Adrian's DISCUSS
  3. Adrian Farrel: Discuss [2011-06-07]:
        Thank you for taking the trouble to produce this document and for including the
    Foreword to explain why the document is being published.
    
    I find that despite the Foreword and the Historic status, the tone of the
    document tends toward implying that the IETF supports implementation of SSL
    v3.0. This problem is caused by:
    
    - The Abstract not mentioning Historic or "do not implement"
    
    - The Introduction being copied from the original I-D (which obviously
      intended implementation)
    
    - The document containing a section "Goals of this document" which
      reflect the original aims of the document not the actual aims of the
      RFC.
    
    I don't want to cause a lot of work or heartache, but we need to make it
    abundantly clear what is going on. Can I make the following suggestions...
    
    1. Abstract
    
       s/specifies/describes/
    
    2. Add a second short paragraph to the Abstract.
    
       This document is published as a historical record of the SSL v3.0
       protocol. New implementations of SSL v3.0 are not recommended 
       because the protocol has been made obsolete by Transport Layer
       Security (TLS) described in RFC 5246.
    
    3. Remove section 3
    
       You might salvage some of the text by adding the following to the
       end of the Introduction...
    
       This document is not intended to supply any details of service
       definition nor interface definition, although it does cover select
       areas of policy as they are required for the maintenance of solid
       security. 
        
  4. Stephen Farrell: Comment [2011-06-08]:
    
      

draft-meadors-multiple-attachments-ediint

  1. Stewart Bryant: Comment [2011-03-16]:
    There are a number of id-nits that need be fixed before the document considered
    ready for publication (IANA section and RFC2119 language). Also the editor
    should confirm that all of the lower case "should" instances are correctly set.
  2. Stephen Farrell: Comment [2011-05-30]:
    Even though this has enough positions to go ahead, Pete 
    asked if newbies like me were ok with that, so since I'd not 
    seen this before, I took a look. I've no problem if these are 
    ignored really, but fwiw:
    
    (1) The draft says that people "began" doing stuff, which is
    fine, but would be even better with some references to that
    (if some exist) so the reader could understand better.
    
    (2) s/this body is covered/this body are covered/
    
    (3) It says the attachments "should" be inter-related - is that
    meant to be a 2119 SHOULD? I'm also unclear as to what 
    inter-related means, but I guess that's really a higher
    layer issue (in which case do you really need to impose
    the constraint at this level?). If that was a 2119 SHOULD
    then under which conditions is it ok to ignore the 
    rule? (maybe easiest is s/should/ought/ just to avoid 
    potential 2119 confusion)
    
    (4) I think 2.3 says that for an encrypted message the MIC
    is calculated over the plaintext but is sent outside the
    encryption. If so, that's less common than also encrypting
    the MIC and is usually specifically justified, but maybe 
    I'm misreading it (and I didn't go read the references to
    check sorry;-)
    
    (5) Section 4 mentions "the three EDI-INT transport 
    standards" but doesn't include the references at that
    point - I think it'd be good to repeat those for clarity.
  3. Russ Housley: Comment [2011-03-16]:
      In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is
      raised.  Please consider it:
    
      There is a space in the declaration of boundary=" INNER-BOUNDARY";
      in the example in section 3.  I am not sure whether this was
      intentional or whether it will mess up a standard MIME parser, but
      you may want to remove it.
  4. Alexey Melnikov: Comment [2011-03-12]:
    Should this document be published with "no IETF consensus" boilerplate?
    
  5. Pete Resnick: Comment [2011-05-24]:
    This is an individual submission of an Informational document I picked up from
    Alexey, so I don't know the full history. Sean's discuss (the only one) has been
    cleared, so I could approve it, but since half of the IESG hasn't entered a
    position, I'd like to double-check and have people give it a gander before
    sending it on its merry way.
  6. Sean Turner: Comment [2011-03-16]:
    Sec 2.3 says: 
    
       If the expected MIC value differs from the calculated MIC value, all
       attachments MUST be considered invalid and retransmitted.
    
    Isn't telling the initiator that they didn't match and asking for the
    retransmission missing?