IESG Narrative Minutes

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

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

Corrections from: NONE

Changes: Addition of appendix with snapshot of discusses/comments

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. Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic (Proposed Standard)
    draft-ietf-msec-ipsec-group-counter-modes-05
    Token: Tim Polk
    Note: Vincent Roca (vincent.roca@inria.fr) is the document shepherd.
    Discusses/comments (from ballot 3398):
    1. Jari Arkko: Comment [2010-08-24]:
      A review by Ari Keränen: ...
      4. Group Key Management Conventions: How does the "delete and replace" happen in practice if the GKMS is a different entity than the one with the active AH or SA?
      "A GKMS MUST support a group member notifying the GCKS that its IV space will soon be exhausted..."
      Ignoring the IV space exhaustion notifications probably has some security implications worth noting in the security considerations sections.
    2. David Harrington: Comment [2010-08-23]:
      I support Alexey's DISCUSS. "MUST support" is ambiguous. and the following SHOULD/MAY combination is so loose, it is unclear what a compliant implementation MUST support.
    3. Alexey Melnikov: Discuss [2010-08-21]:
      4. Group Key Management Conventions: "A GKMS MUST support a group member notifying the GCKS that its IV space will soon be exhausted and requires a new SA to be distributed."
      Excuse my ignorance of the subject, but I would like to understand how this MUST can be achieved and whether any protocol extensions are needed to implement this requirement.
    4. Sean Turner: Discuss [2010-08-25]:
      DISCUSS-DISCUSS: I'd like to understand why this counter mode ID is on standards track when the last one (draft-ietf-ipsecme-aes-ctr-ikev2) had to go through as informational.
      regular DISCUSSes:
      #2: From SECDIR review: Please add a normative reference to draft-ietf-msec-gdoi-update-06 that references how to distribute the SIDs.
      #3: Section 4: "If the entire set of sender identifiers has been exhausted, the GKMS MUST refuse to allow new group members to join."
      If the GKMS got in this situation by using a small SID wouldn't another idea be to switch to a bigger SID? This obviously wouldn't work for the 16 but would for the 8 and 12 bit SIDs.
    5. Sean Turner: Comment [2010-08-25]:
      Sec 2: "It is the basis for several modes of operation that combine encryption, including CCM and GCM."
      combine with what? I assume you mean "combine authentication with encryption, including CCM and GCM."

    Telechat:

  2. Tunnelling of Explicit Congestion Notification (Proposed Standard)
    draft-ietf-tsvwg-ecn-tunnel-10
    Token: David Harrington
    Discusses/comments (from ballot 3426):
    1. Jari Arkko: Comment [2010-08-25]:
      A few comments from Ari Keranen: ...
    2. Stewart Bryant: Comment [2010-08-24]:
      "In some circumstances (e.g. pseudowires, PCN), the whole path is divided into segments, each with its own congestion notification and feedback loop."
      The above reference to PWs assumes an agreed documented MS-PW congestion architecture, whereas the most that exists is a few hints in RFC5659. The reference to PWs should be removed, or the text aligned with RFC5659.
    3. Adrian Farrel: Comment [2010-08-25]:
      In the Acknowledegements... "The views expressed here are those of the"author only."
      I know what you mean with respect to your sponsor, but the views expressed here represent IETF consensus now, so this sentence is not accurate.
    4. Sean Turner: Comment [2010-08-25]:
      #1 - Sometimes RFC4301 and RFC3168 is used when describing the IPsec tunnels and non-IPsec tunnels and sometimes it is used to describe the actual document. Could IPsec tunnels and non-IPsec tunnels be used instead when discussing the tunnels and [RFC4301] and [RFC3168] be used when describing the document?
      #2 - If there's one required mode and one optional, then I suggest in Section 4.1: "a REQUIRED `normal mode' and an OPTIONAL `compatibility mode'"
      #3 - The tables include codepoints and "drop". Can you add a NOTE that indicates "drop" in the tables is not a codepoint.
      #4 - Section 4.2: replace drop with "drop" ?
      #5 - Section 5.1 & 5.2, please indicate which sections are changed in 4301/3168. It will aid readers who are familiar with those documents.
      #6 - Section 5.2: r/optional/OPTIONAL?

    Telechat:

  3. Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) (Proposed Standard)
    draft-ietf-tsvwg-dtls-for-sctp-05
    Token: David Harrington
    Note: Gorry Fairhurst (gorry@erg.abdn.ac.uk ) is the document shepherd.
    Discusses/comments (from ballot 3432):
    1. Jari Arkko: Comment [2010-08-24]:
      Review by Ari Keränen: ...
    2. Ron Bonica: Comment [2010-08-26]:
      Support Lars' discuss
    3. Lars Eggert: Discuss [2010-08-23]:
      Section 3.1., paragraph 1: This section is in the wrong document. It will need to be in the DTLS bis document, because only when we have that will we know whether the hypothetical new version of DTLS cann support this spec or not.
    4. Lars Eggert: Comment [2010-08-23]:
      Section 1.1., paragraph 2: Which ones can they not use?
      Section 3.2., paragraph 1: You probably want to say "for the purposes of running over SCTP, the DTLS path MTU SHOULD be considered to be 2^14." (And should this not be a MUST?)
      Section 4.3., paragraph 1: Shouldn't these be MUSTs?
      Section 4.4., paragraph 2: Suggest to change the sentence logic to "SHOULD use other streams, MAY use 0 if <condition>" and therefore say when it is OK to go against the SHOULD.
      (two nits)
    5. Tim Polk: Comment [2010-08-26]:
      I support Lars discuss on section 3.1
      I support Sean's discuss issue #1 (restrict the DTLS cipher suites to ones that provide the required security services).
    6. Dan Romascanu: Comment [2010-08-25]:
      I support Lars's DISCUSS on section 3.1
    7. Robert Sparks: Comment [2010-08-24]:
      I also found section 3.1 awkward
    8. Sean Turner: Discuss [2010-08-25]:
      #1 - DTLS indicates that in the absence of an application specific profile that the TLS_RSA_WITH_AES_128_CBC_SHA is the mandatory to implement cipher suite... DTLS allows other cipher suites to be negotiated that would not provide these services. Please indicate the cipher suite you'd like support to support (or say that the default is used) and any restrictions on the choice of other cipher suites to ensure you get all three services.
      #2 - Any chance we can get a why on the MUST NOT in 3.3-3.5? DTLS says applications SHOULD support Anti-Replay and PMTU Discovery.
      #3 - Need to specify whether you support renegotiation.
    9. Sean Turner: Comment [2010-08-25]:
      #1 - Agree with Lars DISCUSS. A nice attempt at future proofing, but I don't think it'll fly ;)
      #2 - Sec 4.6: Should it just be "revoked by"?
      #3 - In the security considerations, the I-D notes that "It is possible to authenticate DTLS endpoints based on IP-addresses in certificates." I went and looked in SCTP and didn't find anything about limiting endpoints with IP-address in certificates. It'd be nice to have a reference for this?

    Telechat:

  4. Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings (Proposed Standard)
    draft-ietf-isms-radius-vacm-09
    Token: Sean Turner
    Note: Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de) is the document shepherd.
    Discusses/comments (from ballot 3521):
    1. Jari Arkko: Comment [2010-08-23]:
      (blank)
    2. Adrian Farrel: Comment [2010-08-25]:
      Section 4.1: "An implementation-specific identifier is needed for each AAA-authorized "session", corresponding to a communication channel, such as a transport session, for which a principal has been AAA-authenticated and which is authorized to offer SNMP service."
      The problem is around "implementation-specific" which implies that there is a single identifier for all communication channels from any Company-X Product-Y device. Not what you mean!
      Section 4.2: Not sure that the two uses of "MAY" in this section really need to be upper case, but it is not very important.
      Section 5.1: Would be nice to give a reference for the TCs mentioned.
    3. Russ Housley: Comment [2010-08-24]:
      Please consider the editorial comments in the Gen-ART Review from Francis Dupont.
    4. Tim Polk: Comment [2010-08-25]:
      Magnus Nystrom noted some confusion in the current section 7.2. I would suggest deleting "or equivalent" from the second and fourth bullets and appending something along the following lines at the end of the section: "As noted in section 4.2, the above text refers specifically to RADIUS attributes. Other AAA services can be substituted, but the requirements imposed on User-Name and Management-Policy-Id-Attribute MUST be satisfied using the equivalent fields for that service."
    5. Dan Romascanu: Discuss [2010-08-24]:
      there are a number of issues that were raised in the OPS-DIR review by Joel Jaeggli and in the MIB-Doctor review by Glenn Keeni which are under discussion with the authors. I am holding a DISCUSS until these issues are resolved.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Teredo Extensions (Proposed Standard)
    draft-thaler-v6ops-teredo-extensions-07
    Token: Jari Arkko
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    IPR: Microsoft Corporation's Statement about IPR related to draft-thaler-v6ops-teredo-extensions-01
    IPR: Microsoft Corporation's Statement about IPR related to draft-thaler-v6ops-teredo-extensions-02
    Discusses/comments (from ballot 2866):
    1. Russ Housley: Discuss [2010-08-24]:
      Roni Even raises two concerns in his Gen-ART Review. Please respond to both of the concerns.
    2. Alexey Melnikov: Comment [2010-08-26]:
      Trailer type field might benefit from having an IANA registry.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Transient Binding for Proxy Mobile IPv6 (Experimental)
    draft-ietf-mipshop-transient-bce-pmipv6-06
    Token: Jari Arkko
    Note: Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd
    IPR: NEC Europe Ltd.'s Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-04
    Discusses/comments (from ballot 3238):
    1. Adrian Farrel: Comment [2010-08-26]:
      Clearing my Discuss on the basis of Jari's answer: "That's a good question to ask. The answer is yes."
    2. Russ Housley: Comment [2010-08-26]:
      Please consider the editorial comments in the Gen-ART Review from Spencer dawkins on 25-Aug-2010.
    3. Alexey Melnikov: Comment [2010-08-26]:
      6. IANA Considerations: I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub-registry. Am I looking in a wrong place, or is it named differently?
    4. Sean Turner: Discuss [2010-08-26]:
      The security considerations section needs to indicate whether there are any new security considerations introduced in addition to those in RFC 5213.

    Telechat:

  2. Why RTP Does Not Mandate a Single Security Mechanism (Informational)
    draft-ietf-avt-srtp-not-mandatory-07
    Token: Robert Sparks
    Note: Tom Taylor (tom111.taylor@bell.net) is PROTO Shepherd.
    Discusses/comments (from ballot 3425):
    1. Jari Arkko: Comment [2010-08-24]:
      I did have two issues, however, but decided to place a Yes vote as opposed to holding a discuss. I do want to talk about these topics on the IESG telechat, however.
      The first issue is that in Section 4 MIKEY is ruled out as mechanism for supporting situations where the SIP infrastructure is untrusted. I do not understand why this is being done.
      The second issue relates to the main recommendations. The documents makes the argument that RTP applications are so diverse that they can not live under the same security solution. However, I am left wondering whether there would be mandatory-to-implement security solutions for specific applications. Do the authors for some reason believe that is not feasible or undesirable? Should there be IETF activities started on making such requirements for specific applications?
    2. Lars Eggert: Comment [2010-08-23]:
      Section 3., paragraph 4: Nit: It'd be better to refer to this URL as a reference.
      Section 4., paragraph 9: Nit: s/manangement./management./
    3. David Harrington: Comment [2010-08-25]:
      I support Russ's DISCUSS
    4. Russ Housley: Discuss [2010-08-24]:
      This draft seems to say that BCP 61 does not apply to RTP. BCP 61 describes the "Danvers Doctrine", which says that the IETF should standardize on the use of the best security available, regardless of national policies. BCP 61 also says: "One of the continuing arguments we hear against building security into protocols is the argument that a given protocol is intended only for use in "protected" environments where security will not be an issue. However it is very hard to predict how a protocol will be used in the future. What may be intended only for a restricted environment may well wind up being deployed in the global Internet. We cannot wait until that point to "fix" security problems. By the time we realize this deployment, it is too late..."
      I find it inappropriate for an Informational document to a BCP. If there is consensus that RTP is a special case, then the exception to BCP 61 ought to be documented in a BCP. I do not believe that there is such a consensus as it would contradict the results of the RTPSEC BOF held at IETF 68. The RTP security requirements were eventually published as RFC 5479, and then RFC 5763 and RFC 5764 (DTLS-SRTP) published a solution to those requirements.
      I recognize that DTLS-SRTP is not the solution for all environments. However, today most RTP in deployments use no security. BCP 61 argues for security to be implemented even if it is not turn on in every deployment. A secuity solution for unicast point-to-point audio is unlikely to work well for multicast IPTV. This does not argue for no security. Rather it argues for a collection of security solutions that accomodate the various environments that RTP supports.
    5. Tim Polk: Discuss [2010-08-26]:
      Note: This is a joint discuss from both Security ADs. Given the importance of this document, we are both holding a discuss position so we can participate in the discussion that follows.
      We accept the basic premise of this document: as a “framework protocol”, applying BCP 61 directly and mandating a single security solution is not appropriate and would not achieve the goal of BCP 61: ensuring that security mechanisms are implemented (and thus available) even if it is not turned on in every deployment. However, we do not believe the proposed solution (leaving the selection to each application of RTP) is any more likely to achieve that goal.
      To meet the spirit of BCP 61, we recommend that the working group consider the following approach: specify a small set of solutions that cover the major classes of applications, and mandate implementation of the appropriate solution for each RTP application.
    6. Dan Romascanu: Discuss [2010-08-24]:
      1. The last application scenario listed in Section 3 says: "Finally, the link layer may be secure, and it may be known that the RTP media data is constrained to that single link (for example, when operating in a studio environment, with physical link security). An environment like this is inherently constrained, but might avoid the need for application, transport, or network layer media security."
      I do not believe that this is relevant in a discussion about securing an IETF protocol. BCP 61 (RFC 3365) Section 6 is very clear in that: "One of the continuing arguments we hear against building security into protocols is the argument that a given protocol is intended only for use in "protected" environments where security will not be an issue..." I suggest to take out this case as irrelevant
      2. I am confused about what section 5 tries to say. First I do not know the term 'framework protocol' - this needs to be defined or referred to. What the section seems to say is that for that category of protocols (where RTP belongs) the strong security is more an application issue, where an application may be built of several building blocks, out of which the protocol is only one of them. This seems again to question or even justify an extemption from the requirements of BCP 61 [RFC3365] for RTP or even a whole class of protocols.
    7. Dan Romascanu: Comment [2010-08-24]:
      1. In Section 1: s/scenarios/most widely encountered scenarios/
      2. in Section 2 - why are the conferencing scenarios listing only video conferencing and not voice and video conferencing?
    8. Sean Turner: Discuss [2010-08-26]:
      Note: This is a joint discuss from both Security ADs...

    Telechat:

    Insert discussion of response to Morfin appeal:

     

  3. Trust Anchor Management Requirements (Informational)
    draft-ietf-pkix-ta-mgmt-reqs-06
    Token: Tim Polk
    Note: Steve Kent is the document shepherd
    Discusses/comments (from ballot 3459):
    1. Robert Sparks: Comment [2010-08-25]:
      (blank)
    2. Sean Turner: Comment [2010-08-25]:
      3.7.2. Rationale "There is no standardized format for trust anchors." Is this really true now that 5914 is published?

    Telechat:

  4. Multiple Interfaces Problem Statement (Informational)
    draft-ietf-mif-problem-statement-07
    Token: Jari Arkko
    Note: The document shepherd is Hui Deng (denghui02@hotmail.com).
    Discusses/comments (from ballot 3461):
    1. Ralph Droms: Discuss [2010-08-25]:
      I have a fundamental problem with the way in which this document characterizes the problems resulting from the simultaneous use of multiple interfaces as all resulting from receiving different configuration objects from different administrative domains...
      I see two ways to address my concern: either be explicit in limiting the problem statement and mif deliverables to those problems that can be solved with proper handling of configuration information from multiple admin domains or extend the scope of this document to include any problems that may result from the disparate environments (IP reachability, DNS resolution, QoS) to which interfaces are attached.
    2. Ralph Droms: Comment [2010-08-25]:
      Some of the symptoms don't derive from the stated operational environments...
    3. Lars Eggert: Discuss [2010-08-23]:
      Section 3., paragraph 1: "Interfaces of a MIF host can provide different characteristics (e.g. round-trip time, least cost, better bandwidth, etc....). So, user, applications or network provider may wish to influence routing to take benefit of this heterogeneity. However, with current host implementations, neither the Type-of-Service nor path characteristics can be taken into account in the routing table."
      DISCUSS: I don't think MIF can solve this problem. Yes, interfaces are the first hops into *paths* of different characteristics, but what service quality an application sees across a path depends on the destination, the transport protocol in use and the communication patterns of the application. There is nothing here that can be optimized without taking these into account.
    4. Lars Eggert: Comment [2010-08-23]:
      4 Nits
      Section 3.2., paragraph 2: Modern stacks don't store transport info in the route cache anymore. Suggest to remove the last sentence.
      Section 3.2., paragraph 3: ...And it will only be received on that interface, too.
      Section 3.2., paragraph 4: This doesn't really make the distinction clear. A weak host can send and receive packets ***addressed to or from any of its source addresses on any of its interfaces***.
      Section 3.5., paragraph 2: A referral also includes the transport protocol to be used.
      Section 2., paragraph 0: Note that "better" here is entirely dependent on what kind of traffic is to be exchanged with the destination, i.e., it is transport protocol and application dependent. General preferences of any sort are therefore likely to be wrong.
      Unused Reference
    5. Adrian Farrel: Discuss [2010-08-26]:
      I have not seen any discussion of the Routing Area Directorate review performed by Joel Halpern. I should like to see the issues raised debated and resolved before this document goes forward.
    6. Russ Housley: Comment [2010-08-26]:
      My concern is already captured in DISCUSS posiotns held by Ralph, so I am not going to pile on. However, I do want to make it known that I also have the same concern. (Note the same concern was raiseed by Roni Even in his Gen-ART Review dated 24-Aug-2010.)
    7. Dan Romascanu: Comment [2010-08-25]:
      1. In section 3.1: It would be good to be more exact about what is IEEE 802.21... An informative reference to IEEE 802.21 would also be in place.
      2. Expanding acronyms at their first occurance would be useful.
      3. The OPS-DIR review performed by Menachem Dodge also included a number of useful editorial comments which I suggest to consider.
    8. Robert Sparks: Comment [2010-08-24]:
      Some very minor editorial suggestions:
    9. Sean Turner: Discuss [2010-08-26]:
      This is a placeholder DISCUSS while the authors, AD, and SECDIR reviewer work on some expanded text for the security considerations section.

    Telechat:

  5. Guidelines for Authors and Reviewers of YANG Data Model Documents (Informational)
    draft-ietf-netmod-yang-usage-10
    Token: Dan Romascanu
    Note: David Partain (david.partain@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3474):
    1. Lars Eggert: Discuss [2010-08-23]:
      Section 4., paragraph 0: "3.7. Intellectual Property Section" DISCUSS: The current ID format does not have an Intellectual Property Section anymore.
    2. Lars Eggert: Comment [2010-08-23]:
      Section 3., paragraph 3: I think it makes sense here to separate this into sections that this memo requires for YANG modules (the first two), and into sections that the general ID template requires (the final three), because the latter can change...
      Section 3.1., paragraph 3: I note that YANG is listed in http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt, so you actually do not need to require the use of <CODE BEGINSi> and <CODE ENDS>.
      Section 4., paragraph 1: You may want to recommend that authors verify the syntax of their YANG module with an automated checker every time before submitting a new revision. (I see that Section 4.8 talks about that - maybe add a forward reference?)
      Section 4.5., paragraph 2: I don't know what "MAY be used with caution" means. Does it mean "SHOULD NOT, but if you do consider <this>"? Or does it mean "MUST be used in <this way>"? (The "with caution" phrasing appears elsewhere, and I have the same question about all occurrences.)
      Section 6.1., paragraph 1: Reference missing: RFC4742
    3. Adrian Farrel: Comment [2010-08-26]:
      Support Enrico's point in Russ's Discuss. It is not appropriate to keep the boilerplate outside the IETF domain. http://trac.tools.ietf.org/wg/netconf/trac/wiki may be an appropriate location.
      I wonder if there is scope for some common framework text like that held at http://www.ops.ietf.org/mib-boilerplate.html
      I am a bit worried that this document covers advice that is more general than just the Yang-related work in an I-D. This risks setting up contradictory advice in a number of places. (For example, discussing how the References should be split is generic advice for authors of I-Ds that could be changed at any time.)
    4. Russ Housley: Discuss [2010-08-24]:
      The Gen-ART Review by Enrico Marocco on 9-Jul-2010 leads me to ask a question about Section 3.4: "Each specification that defines one or more modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/netconf/yang-security-considerations.txt)."
      This seems like an odd place for a normative reference to point. I'd be much happier with a place that required some form of review and consensus call to be updated.
    5. Alexey Melnikov: Comment [2010-08-22]:
      3.6. Reference Sections: Why only a SHOULD (and not a MUST)?
      4.1. Module Naming Conventions: Why only a SHOULD?
      4.7. Module Header, Meta, and Revision Statements: I tend to think that this MUST will be ignored in practice. I think making authors update a revision date with every uncompatible change would be more sensible.
    6. Robert Sparks: Comment [2010-08-24]:
      Support Russ' discuss.
    7. Sean Turner: Comment [2010-08-26]:
      Is there a yang doctors set up yet (like there was MIB doctors) where people send their modules to get reviewed?

    Telechat:

  6. ASN.1 Translation (Informational)
    draft-ietf-pkix-asn1-translation-03
    Token: Tim Polk
    Note: Steve Kent (kent@bbn.com) is the Document Shepherd.
    Discusses/comments (from ballot 3479):
    1. (none)

    Telechat:

  7. Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) (Experimental)
    draft-ietf-tcpm-tcp-lcd-02
    Token: Lars Eggert
    Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
    Discusses/comments (from ballot 3517):
    1. Adrian Farrel: Comment [2010-08-26]:
      My first Comment is very close to being a Discuss, and I hope you feel able to add some text (perhaps to the Introduction) to give the reader (and future generations) some guidance.
      For experimental documents, I think it is important to give some parameters of the nature of the experiment.
      - What constraints will be placed on the experimental work to prevent the experiment spilling out into the Internet (walled garden)?
      - What are the risks if the experiment is released? (perhaps a forward pointer to section 7)
      - How will you judge whether the work is stable and successful?
      - Do you have plans / proposals to return and revise the work for the Standards Track?
      Section 2: Tiny nit, sorry
    2. Russ Housley: Comment [2010-08-26]:
      Please consider the editorial comments in the Gen-ART Review from Enrico Marocco on 25-Aug-2010.
    3. Sean Turner: Discuss [2010-08-26]:
      This is a placeholder DISCUSS. There has been no response to the SECDIR review comments from Catherine Meadows.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. An EAP Authentication Method Based on the EKE Protocol (Informational)
    draft-sheffer-emu-eap-eke-08
    Token: Russ Housley
    IPR: Yaron Sheffer's Statement about IPR related to draft-sheffer-emu-eap-eke-00 belonging to AT&T Bell Laboratories (possibly Alcatel-Lucent today)
    Discusses/comments (from ballot 3369):
    1. Adrian Farrel: Comment [2010-08-26]:
      I couldn't work out which range of EAP Method Types should be used for the allocation described at the head of Section 7 for "EAP-EKE Version 1".
      I presume you are headed for 1-191 or 256-... The difference at this stage is whether expert review needs to be invoked.
    2. Russ Housley: Discuss [2010-08-24]:
      Please respond to the comments from Dan Harkins on 18-Aug-2010.
    3. Alexey Melnikov: Discuss [2010-08-25]:
      [This is a preliminary DISCUSS and I might add a few extra items before the IESG telechat.]
      7.5. Identity Type Registry: DISCUSS DISCUSS: Is this value ever entered by a human? If the answer is yes, then this need some common user friendly input format for management of such identities.
    4. Alexey Melnikov: Comment [2010-08-25]:
      It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries.
    5. Tim Polk: Discuss [2010-08-26]:
      This is a placeholder discuss. Issues raised in Brian Weis' secdir review have not been addressed yet. Please involve Brian in the discussion as you address these issues!
    6. Sean Turner: Comment [2010-08-26]:
      I support Russ and Tim's DISCUSS positions.

    Telechat:

  2. Requirements to Extend the Datatracker for WG Chairs and Authors (Informational)
    draft-juskevicius-datatracker-wgdocstate-reqts-05
    Token: Russ Housley
    Discusses/comments (from ballot 3437):
    1. Ralph Droms: Comment [2010-08-25]:
      Is "WG I-D" a synonym for "I-D associated with an IETF WG"?
      I don't understand this requirement: "WG document status tracking SHOULD be implemented per-document, not per-WG. (R-012)" What would "per-WG WG document status tracking be?
    2. Lars Eggert: Discuss [2010-08-23]:
      Section 4.2., paragraph 1: DISCUSS: This is redundant with R-014.
      Section 4.2., paragraph 3: DISCUSS: This is redundant with R-014 and R-015, and it's unclear what the "one WG at a time" bit means.
      Section 4.2., paragraph 7: DISCUSS: This sounds like the delegates are personal delegates of the chair; in reality they are WG secretaries.
      Section 4.2., paragraph 9: DISCUSS: The shepherd must always be a chair or secretary, this cannot be delegated to others.
      Section 4.2., paragraph 11: DISCUSS: No. See above.
      Section 4.3., paragraph 0: DISCUSS: The "delegates" stuff is too complex and not in light with how WG secretaries work. For the purposes of the tracker, secretaries for a WG are just like chairs except they cannot appoint and remove secretaries.
      Section 4.4., paragraph 0: DISCUSS: The document is confused about what shepherds are. According to RFC4858, shepherds are chairs, and if the chairs are conflicted, they are secretaries, otherwise this role falls back to the AD. The shepherding role cannot be otherwise delegated.
      Section 6.1., paragraph 0: DISCUSS: This entire process for handling documents that may be candidates in multiple WGs is super complex and mostly useless, because such cases almost never exist, esp. not concurrently. Plus, it invents a new process with deadlines, timers and notifications where we currently have none, and I don't think that's the purpose of this document.
    3. Lars Eggert: Comment [2010-08-23]:
      Section 3., paragraph 1: Can we s/the people they designate to act as their delegates/secretaries/? AFAIK there are no other delegates allowed by the process. (Also elsewhere in the doc.)
      Section 3., paragraph 2: These examples don't clarify much. What they do is instead to make it sound OK for chairs of old WGs to not bother with these new functions, which I don't think is the message we want to send.
      Section 3., paragraph 8: The look and feel for R-005 and R-006 is somewhat important, but it is also maybe more important that the style sheets and javascript UI code be shared, so that when the IESG tracker is updated, the WG tracker benefits and vice versa.
      Section 7, paragraph 1: I think this needs to be a MUST, for transparency.
      Section 7, paragraph 2: I think this needs to be a MUST, for transparency.
      Section 7, paragraph 4: This is an implementation detail we don't care about, as long as the externally visible behavior is such.
      Section 7, paragraph 6: This is clearly a MUST. Otherwise, we don't *have* document tracking.
      Section 4.4., paragraph 2: There are no such shepherds. See above.
      Section 6., paragraph 0: Many of the issues I raised for draft-ietf-proto-wgdocument-states-08 apply here, too. If they result in any changes to that document, this document will need to be carefully brought in line.
      two Nits
    4. Adrian Farrel: Discuss [2010-08-25]:
      Discuss-Discuss: It seems to me that some of the sections of this document are constraining on the way that the WG chairs operate their WGs...
      Discuss 1. Requirement 2: This is ambiguous. It could be taken to mean chairs of other WGs. Suggest you use (e.g. another chair of the WG)
      2. Requirement 3: Appears to read like a requirement on the IETF or the WG chairs, not a requirement on the Datatracker.
      3. Requirements 7 and 8: Requirement 8 is a MUST. We cannot have documents changing state without accountability. I feel that requirement 7 is very close to a MUST because it is very important to be able to see how long a document has been "stuck" in a state. Pretty sure that R-042 is a MUST at the same time.
      4. A really useful feature of the datatracker is that a Comment can be inserted at any time to add context. This could be when there is a state change (or, indeed, when there isn't a state change when one might reasonably be expected). I think this should be called out explicitly as a feature and all of {WG chairs, delegates, shepherds} MUST be able to add comments which MUST be date stamped and tracked against the user. (This sort of shows up partially in R-037.)
      5. Requirement 18: It is not explained what an "ad hoc WG document state or state name" is.
      6. Requirements 37 and 38: 37 seems to say SHALL {prompt next state, prompt text}; 38 says SHOULD {prompt text}; So 37 and 38 overlap / conflict
      7. Section 5.3: This section appears to say that the write-up is a single entity that can be eddited, and some form of change log. I'm not oppsed to this, but i want to check that you are aware that this is different from the current system where any changes to the write-up are represented by a complete upload of a new copy of the write-up.
      8. Timer pops: (This may be a joint issue with draft-ietf-proto-wgdocument-states) There is inconsistency in how timer pops are handled. For example, when in CANDIDATE WG DOCUMENT and the timer expires, the state changes automatically; but when in IN WG LAST CALL and the timer expires, the state does not change. Inconsistency is not good! In fact, states that have a timer should have a "follow-up state" so that it is clear what the state is and what the next action actually is.
      9. Section 7: This is not how I read R-001! ...the requirement talks about the optionality applying to the drafts (one at a time). It does not talk about the optionality of some of the states. What is more, a number of the other requirements show some rules about state transitions that appear to indicate a lack of optionality.
      Section 7 goes on to say: "The same requirement also allows each IETF WG Chair to decide to *not* log-on to the Datatracker to manually input or update the status of drafts in her/his WG." This could be read two ways. One reading implies that the states can be changed in some way other than by logging on.
    5. Adrian Farrel: Comment [2010-08-25]:
      10. Could you mention WG Secretaries explicitly somewhere. Perhaps as an example when you mention delegates the first time?
      11. Minor inconsistency that "WG chair" and "IETF WG chair" are both used.
      12. Section 2: Maybe an unnecessary nit, but "are being considered" is passive voice and I know a number of document authors who do nothing but consider their I-Ds for adoption by a WG.
      13. Section 2: "is also to be interpreted" should be scoped to within the two bullets at the top of the section, I think...
      14. Requirement 10: I don't feel it is correct to place requirements on the implementation that do not affect: {the blackbox behavior, the cost, the maintainability}
      15. Requirement 40: s/all of the/each of the/
      16. Requirement 86: Why is the granularity required to be in weeks? Can we have a "date and time for end of last call"?
    6. Alexey Melnikov: Discuss [2010-08-15]:
      1) 3. General requirements: Why only SHOULDs (twice)?
      2) 6.1. Candidate WG Document: Should this also result in an email to Chairs/delegates of other WGs?
      3) 6.5. In WG Last Call: I believe this must be a MUST level requirement. Not allowing multiple WGLCs would be a serious deficiency in the tool.
      4) DISCUSS DISCUSS: 6.8. Revised I-D Needed (annotation tag): ... As an AD I would hate to be forced to use another interface to make a document as needing a new revision once the document is in IESG processing. Can this be clarified?
      5) 6.8. Revised I-D Needed (annotation tag): Does posting of a new revision automatically clear the "Revised I-D Needed" annotation tag?
      6) 8. WG document status change reporting requirements: Is there any reason why this information is only accessible to people with "write" access? One great advantage of the existing datatracker is that information about a document is visible to everyone (including all history), although there is a way to mark certain things as "private" (not visible to others).
    7. Alexey Melnikov: Comment [2010-08-15]:
      1) 4.2. For IETF Working Group Chairs: I think it would be a good idea to clearify the relationship between a user-id and an email address. Currently each user-id is an email address, but the text above seem to be implying that some kind of mapping might be possible. This also affects other sections (e.g. 4.3).
      2) 4.3. For Delegates of IETF WG Chairs: What about showing this information to the WG chair when he/she adds a delegate in the datatracker's web interface?
      3) 5.1. WG Document States: Why not just say that any state transitions are allowed. If the intent of the wording is to show that there should be an easy way to select one of the 'most likely' states, then that should be stated explicitly.
      4) 5.3. WG Document Protocol Write-ups:Speaking as an individual, I would dislike an interface that is forcing me to act in a particular role without allowing me to change the role. In particular I am hoping that once a role is selected, it can be changed without the need to logout and login again.
      5) 6.1. Candidate WG Document: I am slightly concerned about not allowing a replaced document to be used as a "Candidate WG Document". Sometimes documents get forked, or a document which was once replaced by another one might be abandonned by the WG. It should be possible to use such documents elsewhere.
      6) 6.1. Candidate WG Document: I hope you didn't mean that the status should be presented exactly in the form shown above.
      7) 6.3. Not Adopted by a WG: I think the same WG should also be allowed to adopt the document later on. I suggest dropping the word "different" above.
      8) 6.4. WG Document: Just to double check: this would allow to adopt a draft as a WG document, without renaming it? I think that would be useful.
    8. Tim Polk: Discuss [2010-08-26]:
      (Consistent with Robert's issue #1) The processing described in the Candidate WG Document state adds a lot of formality that are not currently practiced by most IETF working groups, and don't seem to be supported by 2026. Is a datatracker requirements draft the place to institute new process requirements?
    9. Tim Polk: Comment [2010-08-26]:
      [WGDRAFTS] does not define withdrawn.
      I share Lars' concerns regarding 4.2, paragraph 7, 9 , and 11. I am not sure I agree with his analysis, but this text deserves some discussion!
    10. Robert Sparks: Discuss [2010-08-24]:
      1) Where this document is capturing requirements to facilitate WG tracking using processes that WG chairs are already exercising I think it's on track. I believe it and it's companion state document are going going further than that in with the definition of the Candidate WG document and Not Adopted by a WG states and the behavior required not just of the tool but of the chairs by this document.
      Attempting to define a new process and codify it into a tool at the same time seems risky. I would prefer to see the requirements around tracking a document before WG adoption split into a separate effort, both in determining requirements and implementing the tool. (It would be even better if there was experience with the suggested process - an interested chair and cooperative AD could do this now with the comments field in the existing tracker.) Our initial effort should be scoped to helping WG chairs and other stakeholders track what they already do.
      2) R-003 can be read to mean that every IETF Stream document SHALL be tracked using this tool, contradicting R-001. I suggest that the first part of the requirement be rephrased thus: "When the WG status of an IETF Stream I-D is tracked, the Datatracker SHALL use the WG document states ..."
      3) Why is R-012 SHOULD and not MUST?
      4) There are a couple of places (For instance R-021) where a design decision is being made (probably the right decision, but I'm not sure this is the tool to make that decision with) - there are people now with exising datatracker/tools logins whose login name does not look like an email address. This decision will force delegation to them to be through an email address _associated_ with the login. MANY people with datatracker logins have more than one email address. Could we remove this bit of design? If not, can we acknowledge that people may have more than one email identifier?
      5) The delegation requirements in 4.2 seem to be written from the viewpoint of a chair delegating authority for all of the documents in the working group. Why are they not written so that delegation is done on a per-document basis (in the spirit of R-012)?
      6) R-054 (also touched in Alexey's comments) imply that someone must logout to change roles. If that was the intent, it should be made explicit. I hope that was NOT the intent and I think we need an additional requirement that a login that can serve multiple roles be allowed to change roles on demand without logging out.
    11. Robert Sparks: Comment [2010-08-24]:
      Early in the conventions section: There are instances of individual drafts being adopted by working groups that don't get renamed -ietf-.
      R-020 - is it worth calling out in the requirement that one of the delegates may also have other roles (like being the chair of another WG, or being an AD of another area). It might also help the implementer of these requirements if you made a forward reference to R-033 here. (btw - R033 is showing some edititis - it's referring to itself as if it were somewhere else.
      I have concerns with the process being proposed around the pre-WG adoption states and the mechanics associated with them... I think the proposal needs additional discussion before codifying it into a tool.
    12. Sean Turner: Discuss [2010-08-25]:
      #1) R-008: Why isn't the time-stamp and identification of the person who made the change a MUST? On a tangential note, maybe we should be tracking exactly who it is who did the submission. This information might be useful.
      #2) R-20: Should we limit the number of delegations allowed per-WG? Can we pick an upper bound of say 3 people per WG that aren't WG chairs?
      #3) Resolved.
      #4) R-035: When would the datatracker not show the state etc after logging on?
    13. Sean Turner: Comment [2010-08-11]:
      #1) R -019 r/(e.g., IANA status, RFC-Editor status, IESG status;/(e.g., IANA status, RFC-Editor status, IESG status);
      #2) R-020/025 Should the should be SHOULD:
      #3) R-022 r/for the different/the different
      #4) R-033: "each IETF AD SHALL have the privileges specified in Requirement R-033 for every WG in his or her Area (R-033)" I'm having trouble parsing this one. Is it meant to be recursive?
      #5) Page 12: The "a" is extra perhaps: "for adoption in a their IETF WG without"
      #6) R-073/094: Should the shall be SHALL?
      #7) Sec 6.3 last para: r/draft-IETF-/draft-ietf-
      #8) Sec 6.5: Should we add a default value for the length of the WG LC?

    Telechat:

  3. Definition of IETF Working Group Document States (Informational)
    draft-ietf-proto-wgdocument-states-08
    Token: Russ Housley
    Discusses/comments (from ballot 3441):
    1. Lars Eggert: Discuss [2010-08-23]:
      DISCUSS-DISCUSS: The title and abstract claim this document describes datatracker states. Reading the text, it's clear that the document also describes transitions between states, and this is where my rub is with the document: it's neither complete in describing these transitions, nor does it IMO necessarily characterize the possible or even typical transitions very accurately.
      DISCUSS: It seems that the model here is that three state machines exist: one for document availability (active/expired/replaced), one for the IESG, and one for the WG. The result is that a given document is in a specific state in all of these three state machines. This is not at all clearly explained in the document, it talks about the states of all three state machines interchangeably, which is really confusing. A clear overview with some diagrams would help a lot.
      Section 3.3.1., paragraph 4: "b) an I-D that the WG Chair asked an author to write;" DISCUSS: I disagree that this makes an ID a candidate WG document.
      Section 3.3.2., paragraph 0: "3.3.2. Adopted by a WG" DISCUSS: We don't need this state. It's equivalent to applying "WG Document" to an individual ID.
      Section 3.3.4., paragraph 0: "3.3.4. Adopted for WG Info Only" DISCUSS: I don't think we need this state, it's equivalent to "WG Document" that never progress (or eventually progress to "Withdrawn".)
      Section 3.3.5., paragraph 0: "3.3.5. Not Adopted by a WG" DISCUSS: What purpose does this state serve other than to shame authors?
      Section 3.5.4., paragraph 0: "3.5.4. Awaiting External Review / Resolution of Issues Raised" DISCUSS: Because "external" really means "external to the WG", this state subsumes states 3.5.1, 3.5.2 and 3.5.3. Review-team specific states are not a good idea; for example, you'd immediately need to add "MIME Types Review", "URL Team Review", "TSV Directorate Review", etc. etc.
      Appendix A:, paragraph 1: "This Appendix describes the status information currently stored in the IETF Datatracker tool for every I-D submitted to the IESG for publication. Most of the terms and definitions herein are as in [IESGSTAT]."
      DISCUSS: These definitions should be identical to [IESGSTAT], because it is not the purpose of this document to redefine what those states mean. If the descriptions in [IESGSTAT] can be improved, let's make the changes there, please.
    2. Lars Eggert: Comment [2010-08-23]:
      Section 2., paragraph 1: You probably want to add that a "working group I-D" is an I-D that has gotten consensus for adoption as a work item by a WG (compared to individual ones, that have not or not yet).
      Section 3.1.3., paragraph 3: It may be useful to add that "replacing" an ID in this form currently requires an explicit request by the WG chair. Without that request, the IDs will coexist and the individual one will eventually expire.
      Section 3.2., paragraph 0: The state definitions below are sightly different in wording than in [IESGSTAT] and in Appendix A. This is confusing.
      Section 3.2.3., paragraph 0: Suggest to swap the order of the two paragraphs.
      Section 3.3., paragraph 0: It would be good to make this a new top-level section, because unlike Sections 3.1 and 3.2, which were replicated for information and not new, this *is* the new stuff.
      Section 3.3., paragraph 1: What delegates? Secretaries?
      Section 3.3., paragraph 2: Don't we want to recommend that they should use them for all of their documents though?
      Section 3.3.1., paragraph 6: This sounds like we want to encourage shopping. Shouldn't the focus here be on adding functions that alert us to cases where shopping happens?
      Section 3.3.3., paragraph 3: Not relevant for the purposes of this document.
      Section 3.3.6., paragraph 0: Not clear if we need this state. Also, what it exactly means is unclear - does "parking" prevent a document from becoming expired?
      Section 3.3.7., paragraph 0: How is this different from a "WG Document" that is "Expired"?
      Section 3.4., paragraph 0: This section/diagram should really come before the detailed state descriptions earlier in Section 3.
      Section 3.6., paragraph 0: Sure, but this document is supposed to be on ID states.
    3. Adrian Farrel: Comment [2010-08-26]:
      I feel there is some confusion between "state" and "status" (for example, in the Abstract). This is handled in draft-juskevicius-datatracker-wgdocstate-reqts which says: "The phase "WG status of an I-D" is to be interpreted as referring to the WG document state that an I-D is in, as defined in Section 3.3 of [WGDRAFTS]. This phrase does not refer to an I-D's availability status (e.g. "Expired", "Active") as described in Section 3.1 of [WGDRAFTS], or the IESG state used by IETF Area Directors (ADs) to describe the status of an I-D they may be evaluating."
      I feel it would be helpful to use the same language in both documents.
      Section 3.1.2: "An "Active" I-D is a document that is not expired." In fact, an I-D that is an RFC, is not "Active". Ditto other states.
      Some inconsistency of "WG" and "IETF WG" that implies a difference of meaning that does not exst.
      Section 3.2: Not quite sure of the purpose of this section. It seems to me that "In Last Call" and "Waiting for AD Go-ahead" are also key states for interaction with the document authors. "AD is Watching" and "Dead" also seem to be pretty closely related to the authors.
      Figure 1: I know this is showing common transitions only, but I suspect you should show the arrow between "Candidate WG Document" and "Not Adopted be a WG" as double-headed.
    4. Alexey Melnikov: Comment [2010-08-14]:
      I am agreeing with Sean's comments. Additionally, I have some comments of my own:
      1) 3.3.3. WG Document: I would like to point out that frequently the "intended maturity level" is decided quite late in the WG process. So I want to make sure that this information is not required early on.
      2) 3.3.8. In WG Last Call: Personally I prefer the way how IETF LCs work: IETF LC lasts for a specified period of time, after which the document automatically moves to "Waiting for AD Go-Ahead" state. I think the same should happen to documents in WGLCs.
      3) 3.3.10. WG Consensus: Waiting for Write-Up: This might be an abuse of process, but I don't think write-up is always required when publication is requested. I sent several documents to IETF LC without a write-up, I think this should be allowed.
      4) A.1.2. Publication Requested: I don't think sending this to Secretariat is a requirement. All documents I've sponsored I entered into datatracker myself. So I suggest inserting the word "typically" before "copied".
    5. Tim Polk: Discuss [2010-08-25]:
      (a) Section 3.1: The document state withdrawn is listed but is not defined and no reference is given. "Withdrawn" is not supported in the old tracker, so I have no idea what is intended.
      (b) 3.1.3. Replaced: I have seen a number of cases where a single document was replaced by three or four documents. I suspect that the reverse situation (where multiple documents are replaced by one) also exists. The text in this section implies that the replacement is always one-for-one.
      (c) discuss-discuss: 3.6. "Intended Maturity Level of WG Documents" suggest that every wg document should indicate the intended maturity level. This is a decision that the wg often makes at a later stage in the process (before or during WG LC). Making the decision early may not be a good idea - the editor may regard that as a contract. Was the idea of an "undecided" maturity level considered?
    6. Tim Polk: Comment [2010-08-25]:
      (a) In 3.3.1: add "specifically for consideration as a WG draft;"
      (b) I support Lars' discuss on section 3.3.5. Not Adopted by a WG
      (c) Figure 1: There should be a line from WG LAST CALL to WG document. A chair may decide that Last Call failed, and send the document back to the working for extensive discussions. As drawn, any document that goes into Last Call has to go to the IESG before it can then be returned to the working group.
    7. Robert Sparks: Discuss [2010-08-24]:
      I think the proposal for a process to track documents before WG adoption should be split into a separate effort. This is coupled to a discuss point on the tracker requirements document
    8. Sean Turner: Comment [2010-08-11]:
      #1) Sec 3.3.7 and Figure 1: If a document is dead to the WG, then can the author take it to another WG and begin the shopping process all over again?
      #2) Sec 3.5: Should we add "Awaiting Media-Type Review / Resolution of Issues Raised" or more generally "Awaiting Expert Review" for any I-D that affects an IANA registry?
      #3) Sec 3.6: Is it "Standard" or "Internet Standard"? The title of section 4.1.3 of 2026 is the later. 2026 also uses the phrase when describing STDXXX.

    Telechat:

  4. Suite B Profile of Certificate Management over CMS (Informational)
    draft-turner-suiteb-cmc-03
    Token: Tim Polk
    Note: Sean Turner (turners@ieca.com) is the document shepherd.
    Discusses/comments (from ballot 3463):
    1. Alexey Melnikov: Comment [2010-08-15]:
      5.1. RA Processing of Requests: s/CA/RA ?
      6.1. CA Processing of PKI Requests: s/RAs/CAs ?

    Telechat:

  5. Comcast's Protocol-Agnostic Congestion Management System (Informational)
    draft-livingood-woundy-congestion-mgmt-08
    Token: Lars Eggert
    Note: AD sponsored by Lars Eggert (lars.eggert@nokia.com)
    Discusses/comments (from ballot 3500):
    1. Jari Arkko: Comment [2010-08-25]:
      A review by Ari Keranen:
    2. David Harrington: Comment [2010-08-23]:
      in 3.7, any device controlled by Comast? or any device?

    Telechat:

  6. Additional Private IPv4 Space Issues (Informational)
    draft-azinger-additional-private-ipv4-space-issues-04
    Token: Ron Bonica
    Discusses/comments (from ballot 3519):
    1. Jari Arkko: Discuss [2010-08-25]:
      The document is on the right track, but falls short on a couple of aspects. I would like to recommend revising the document once before we approve it.
      My main concern is that in my recollection the IETF made a very clear decision. All the discussion pointed to saying "no" for any new address space allocation for private addressing. There were numerous arguments why this is the right course of action. However, the document falls short of actually stating this. The document needs to say clearly that the IETF recommends against new private address space allocations.
      A couple of other issues:
      I have heard of operators running on unallocated address space, but never of CPEs. Do we have evidence of this from the field?
      In any case, the document does not describe what is the key problem for the CPE: having a *different* address range than the service provider network has.
      It would be good to mention already here that some ways of allocating new address space on the IPv4 side would result in equivalent implementation/deployment issues (such as updating all routers and hosts across the Internet to not drop 240/4).
      I would also like to see Thomas Narten's comment on peer-to-peer addressed (see below for a copy of his review).
      Finally, I think the section that talks about address sharing across multiple subscribes is probably a little too simplified. Note that the IETF already has ongoing work about such mechanisms (e.g., dual stack lite which implements a CGN to share addresses). I think the true driver behind new private address space is that the service providers do not want "new" solutions (such as IPv6, dual stack lite) but rather want to keep existing customer NATs and add one of their own.
    2. Jari Arkko: Comment [2010-08-25]:
      Thomas Narten's review:
    3. Ralph Droms: Discuss [2010-08-26]:
      mostly a discuss-discuss; I'd like to discuss some of the basic premises from which the doc is written.
      I don't see any acknowledgments of review by or input from other stakeholders like service providers, wireless operators, etc. I've asked John Brzozowski (Comcast) for his comments, which he expects to send to me by Sep 3.
      In my opinion, the document is not clear on the distinction between RFC 1918 addresses used to number "internal" interfaces, which are only used for internal communication, and addresses used to number "subscriber" interfaces, which need global access.
    4. Lars Eggert: Comment [2010-08-23]:
      INTRODUCTION, paragraph 2: Nit: Title can be misunderstood (as in "this doc talks about additional issues with regards to private address space.") Maybe: "Issues with Assigning Additional IPv4 Private Address Space"?
      Section 3., paragraph 0: I wish this section were more clear about the significant downsides that multiple levels of NAT have compared to a single level of NAT.
      Section 8.1., paragraph 2: Nit: Unused Reference: 'RFC2860'
    5. Adrian Farrel: Discuss [2010-08-25]:
      1. I got snarled up with some of the language around "interfaces". My initial reaction was to assume that you were talking about interfaces as links between routers. These are indentified for use in routing protocols, but do not need to be routable entities. Thus, I was surprised not to find any mention of unnumbered interfaces. But I suspect you are intending to scope to "interfaces to the network" since the text seems to focus on addressable points of attachment. Could we discuss this and, if I am right in my suspiscions, perhaps you could look at how to clrify this in the text.
      2. I found the example of VPNs a little uncomfortable (section 2). I believe that the VPN technologies developed in the IETF have included good precautions to avoid "address clashes" and, while I can believe that folk feel uneasy knowing that customer spaces have overlapping address spaces, this is not actually a significant risk.
    6. David Harrington: Comment [2010-08-23]:
      s/It is be/It is/
    7. Russ Housley: Comment [2010-08-26]:
      Some of the references are Internet-Drafts. These need to be marked as work-in-progress.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions Via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Mobility EXTensions for IPv6 (mext)
    Token: Jari

    Telechat:

  2. Network Configuration (netconf)
    Token: Dan

    Telechat:

  3. Behavior Engineering for Hindrance Avoidance (behave)
    Token: David

    Telechat:

5. IAB News We can use

  1. no IAB on call. Russ fills in.
  2. OAM workshop, oct 14th, Ron may move it.
  3. IAB working on privacy workshop, probably in Dec.
  4. Dave: does IAB not send a rep very often? Should we ask them to?
  5. Russ: Danny assured yesterday that he'd be here. i'll find out what's happening.
  6. Tim: date for privacy workshop?
  7. Russ: not that far along.
  8. Tim: to whom to send conflict dates?
  9. Russ: Hannes
  10. Stewart: i have something to discuss about OAM workshop
  11. Russ: ron's dropped off. send him a note

6. Management Issues

  1. [Possible Executive Session]: Discussion of the IAB Response to Morfin Appeal (Tim Polk, Russ Housley)

    Telechat:

  2. China Communication Standard Association (CCSA) Communication with the ITU-T (Adrian Farrel)

    Telechat:

  3. New item: PCP working group (Jari Arkko)

    Telechat:

  4. New item: Req'ts for DNS parameter registration (Michelle Cotton)

    Telechat:

7. Agenda Working Group News

1435 EDT Adjourned



Appendix: Snapshot of discusses/comments

(at 2010-08-26 08:29:44 PDT)

draft-ietf-msec-ipsec-group-counter-modes

  1. Jari Arkko: Comment [2010-08-24]:
    A review by Ari Keränen:
    
    4. Group Key Management Conventions
    
        o  When a GKMS determines that a particular group member is no longer
           a part of the group, then it MAY re-allocate any sender identifier
           associated with that group member for use with new group member.
           In this case, the GKMS MUST first delete and replace any active AH
           or ESP SAs with which the SID may have been used.
    
    How does the "delete and replace" happen in practice if the GKMS is a 
    different entity than the one with the active AH or SA?
    
        A GKMS MUST support a group member notifying the GCKS that its IV
        space will soon be exhausted and requires a new SA to be distributed.
        A group member SHOULD notify the GCKS in advance of its IV space
        being exhausted.  A GCKS MAY choose to ignore this notification based
        on policy (e.g., if the group member appears to be asking for new SAs
        so frequent as to negatively affect group communications).
    
    Ignoring the IV space exhaustion notifications probably has some 
    security implications worth noting in the security considerations sections.
  2. David Harrington: Comment [2010-08-23]:
    I support Alexey's DISCUSS. "MUST support" is ambiguous. and the following
    SHOULD/MAY combination is so loose, it is unclear what a compliant
    implementation MUST support.
    
    
  3. Alexey Melnikov: Discuss [2010-08-21]:
        This is a fine document, but I have one question:
    
    4.  Group Key Management Conventions
    
       A GKMS MUST support a group member notifying the GCKS that its IV
       space will soon be exhausted and requires a new SA to be distributed.
    
    Excuse my ignorance of the subject, but I would like to understand how this MUST
    can be achieved and whether any protocol extensions are needed to implement this
    requirement.
    
       A group member SHOULD notify the GCKS in advance of its IV space
       being exhausted.  A GCKS MAY choose to ignore this notification based
       on policy (e.g., if the group member appears to be asking for new SAs
       so frequent as to negatively affect group communications).
     
        
  4. Sean Turner: Discuss [2010-08-25]:
        This one is a DISCUSS-DISCUSS (i.e., no action required for authors).  
    
    I'd like to understand why this counter mode ID is on standards track when the
    last one (draft-ietf-ipsecme-aes-ctr-ikev2) had to go through as informational.
    
    These are regular DISCUSSes:
    
    #2: From SECDIR review:
    
    Please add a normative reference to draft-ietf-msec-gdoi-update-06 that
    references how to distribute the SIDs.
    
    #3: Section 4:
    
      If the entire set of sender identifiers has been
      exhausted, the GKMS MUST refuse to allow new group members to
      join.
    
    If the GKMS got in this situation by using a small SID wouldn't another idea be
    to switch to a bigger SID?  This obviously wouldn't work for the 16 but would
    for the 8 and 12 bit SIDs. 
        
  5. Sean Turner: Comment [2010-08-25]:
    #1: Sec 2: 
    
    It is the basis for several modes of operation that combine
       encryption, including CCM and GCM.
    
    combine with what?  I assume you mean "combine authentication with encryption,
    including CCM and GCM."

draft-ietf-tsvwg-ecn-tunnel

  1. Jari Arkko: Comment [2010-08-25]:
    A few comments from Ari Keranen:
    
    1. Introduction
    
       Nonetheless, the latest IPsec architecture [RFC4301] considered a
       bandwidth limit of 2 bits per packet on a covert channel made it a
       manageable risk.
    
    Remove "made it"?
    
    4. New ECN Tunnelling Rules
    
       an alternate congestion marking scheme used by a specific Diffserv
       PHB (see S.5 of [RFC3168] and [RFC4774]).
    
    For consistency: s/S/Section/
    (also in Section 7 and Appendix B1)
  2. Stewart Bryant: Comment [2010-08-24]:
    > In some circumstances (e.g. pseudowires, PCN), the whole path
    > is divided into segments, each with its own congestion
    > notification and feedback loop. 
    
    The above reference to PWs assumes an agreed  documented MS-PW congestion
    architecture, whereas the most that exists is a few hints in RFC5659. The
    reference to PWs should be removed, or the text aligned with RFC5659.
  3. Adrian Farrel: Comment [2010-08-25]:
    A quick note.
    In the Acknowledegements...
    
       The views expressed here are those of the
       author only.
    
    I know what you mean with respect to your sponsor, but the views expressed here
    represent IETF consensus now, so this sentence is not accurate.
  4. Sean Turner: Comment [2010-08-25]:
    A fine document.  I've only got some non-blocking comments:
    
    #1 - Sometimes RFC4301 and RFC3168 is used when describing the IPsec tunnels and
    non-IPsec tunnels and sometimes it is used to describe the actual document.
    Could IPsec tunnels and non-IPsec tunnels be used instead when discussing the
    tunnels and [RFC4301] and [RFC3168] be used when describing the document?  I
    think it would make it clearer.
    
    #2 - If there's one required mode and one optional, then I suggest in Section
    4.1:
    
    OLD:
    
    a REQUIRED `normal mode' and a `compatibility mode'
    
    NEW:
    
    a REQUIRED `normal mode' and an OPTIONAL `compatibility mode'
    
    #3 - The tables include codepoints and "drop". Can you add a NOTE that indicates
    "drop" in the tables is not a codepoint.
    
    #4 - Section 4.2: 
    
     This is because the
     inner Not-ECT marking is set by transports that use drop as an
                                                             
                                        replace drop with "drop" ?
    
      indication of congestion and would not understand or respond to
      any other ECN codepoint [RFC4774].
    
    #5 - Section 5.1 & 5.2, please indicate which sections are changed in 4301/3168.
    It will aid readers who are familiar with those documents.
    
    #6 - Section 5.2:
    
    The compatibility mode of encapsulation is identical to the
          encapsulation behaviour of the limited functionality mode of an
          RFC3168 ingress, except it is optional.
                                        ^^^^^^^^r/optional/OPTIONAL?

draft-ietf-tsvwg-dtls-for-sctp

  1. Jari Arkko: Comment [2010-08-24]:
    Review by Ari Keränen:
    
    3.1. Future Versions of DTLS
    
        This document is based on [RFC4347].  If a new RFC updates or
        obsoletes [RFC4347], this documents also applies to the newer
        document defining DTLS unless this document also gets updated or
        revised.
    
    How do you know whether the "new DTLS" is compatible with this spec?
  2. Ron Bonica: Comment [2010-08-26]:
    Support Lars' discuss
  3. Lars Eggert: Discuss [2010-08-23]:
        Section 3.1., paragraph 1:
    >    This document is based on [RFC4347].  If a new RFC updates or
    >    obsoletes [RFC4347], this documents also applies to the newer
    >    document defining DTLS unless this document also gets updated or
    >    revised.
    
      DISCUSS: This section is in the wrong document. It will need to be in
      the DTLS bis document, because only when we have that will we know
      whether the hypothetical new version of DTLS cann support this spec or
      not. If it can, the DTLS bis will Update this document and indicate
      this, and if not, it will need to move this document to Historic. In
      other words, I believe this section should be removed.
     
        
  4. Lars Eggert: Comment [2010-08-23]:
    Section 1.1., paragraph 2:
    >    Security features provided by DTLS over SCTP include authentication,
    >    message integrity and privacy of user messages.  Applications using
    >    DTLS over SCTP can use almost all transport features provided by SCTP
    >    and its extensions.
    
      Which ones can they not use? (Also, nit, I'm not a big fan of 1:1
      repetition of the abstract in the introduction.)
    
    Section 3.2., paragraph 1:
    >    DTLS limits the DTLS user message size to the current Path MTU minus
    >    the header sizes.  This limit SHOULD be increased to 2^14 Bytes for
    >    DTLS over SCTP.
    
      The wording here is odd. You don't actually want to increase a limit
      of the base DTLS spec (because otherwise you'd need to Update it.) You
      probably want to say "for the purposes of running over SCTP, the DTLS
      path MTU SHOULD be considered to be 2^14." (And should this not be a
      MUST?)
    
    Section 4.3., paragraph 1:
    >    Application protocols running over DTLS over SCTP SHOULD register and
    >    use a separate payload protocol identifier (PPID) and SHOULD NOT
    >    reuse the PPID that they registered for running directly over SCTP.
    
      Shouldn't these be MUSTs?
    
    Section 4.4., paragraph 2:
    >    All DTLS messages of the ApplicationData protocol MAY be transported
    >    over stream 0, but users SHOULD use other streams to avoid possible
    >    performance problems due to head of line blocking.
    
      Suggest to change the sentence logic to "SHOULD use other streams, MAY
      use 0 if <condition>" and therefore say when it is OK to go against
      the SHOULD.
    
    Section 1.1., paragraph 17:
    >    o  The DTLS user can not perform the SCTP-AUTH key management,
    
      Nit: s/can not/cannot/
    
    Section 4.5., paragraph 1:
    >    This makes sure that an attacker can not modify the stream in which a
    
      Nit: s/can not/cannot/
    
  5. Tim Polk: Comment [2010-08-26]:
    I support Lars discuss on section 3.1
    
    I support Sean's discuss issue #1 (restrict the DTLS cipher suites to ones that
    provide the required security services).
  6. Dan Romascanu: Comment [2010-08-25]:
    I support Lars's DISCUSS on section 3.1
  7. Robert Sparks: Comment [2010-08-24]:
    I also found section 3.1 awkward
  8. Sean Turner: Discuss [2010-08-25]:
        #1 - DTLS indicates that in the absence of an application specific profile that
    the TLS_RSA_WITH_AES_128_CBC_SHA is the mandatory to implement cipher suite.
    Assuming that's the only cipher suite you use you can get the services you
    noted: authentication, message integrity and privacy of user messages.  DTLS
    allows other cipher suites to be negotiated that would not provide these
    services.  Please indicate the cipher suite you'd like support to support (or
    say that the default is used) and any restrictions on the choice of other cipher
    suites to ensure you get all three services.
    
    #2 - Any chance we can get a why on the MUST NOT in 3.3-3.5?  DTLS says
    applications SHOULD support Anti-Replay and PMTU Discovery.
    
    #3 - Need to specify whether you support renegotiation.  The following was used
    in draft-ietf-nsis-ntlp-sctp (feel free to tweak):
    
    DTLS renegotiation [7] may cause problems for applications such that connection
    security parameters can change without the application knowing it.  Hence, it is
    RECOMMENDED that renegotiation be disabled for GIST over DTLS. 
        
  9. Sean Turner: Comment [2010-08-25]:
    #1 - Agree with Lars DISCUSS.  A nice attempt at future proofing, but I don't
    think it'll fly ;)
    
    #2 - Sec 4.6:
    
      Before sending a ChangeCipherSpec message all outstanding SCTP user
      messages MUST have been acknowledged by the SCTP peer and MUST NOT be
      revoked anymore by the SCTP peer.
    
    anymore?  Should it just be "revoked by"?
    
    #3 - In the security considerations, the I-D notes that  "It is possible to
    authenticate DTLS endpoints based on IP-addresses in certificates."  I went and
    looked in SCTP and didn't find anything about limiting endpoints with IP-address
    in certificates.  It'd be nice to have a reference for this?

draft-ietf-isms-radius-vacm

  1. Jari Arkko: Comment [2010-08-23]:
    
        
  2. Adrian Farrel: Comment [2010-08-25]:
    Thanks for this I-D. I have no objection to its publication as an RFC.
    
    Section 4.1
    
    I found the following sentence somewhat tricky.
    
       An implementation-specific identifier is needed for each AAA-
       authorized "session", corresponding to a communication channel, such
       as a transport session, for which a principal has been AAA-
       authenticated and which is authorized to offer SNMP service.
    
    The problem is around "implementation-specific" which implies that 
    there is a single identifier for all communication channels from any
    Company-X Product-Y device. Not what you mean!
    
    If you have time to tweak this a little, that would be good.
    
    ---
    
    Section 4.2
    
    Not sure that the two uses of "MAY" in this section really need to be
    upper case, but it is not very important.
    
    ---
    
    Section 5.1
    
    Would be nice to give a reference for the TCs mentioned.
  3. Russ Housley: Comment [2010-08-24]:
      Please consider the editorial comments in the Gen-ART Review from
      Francis Dupont.  The review can be found at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-ietf-isms-radius-vacm-09-dupont.txt
  4. Tim Polk: Comment [2010-08-25]:
    Magnus Nystrom noted some confusion in the current section 7.2.  After reviewing
    the text, I think he has a point.
    
    I would suggest deleting "or equivalent" from the second and fourth bullets and
    appending something along the
    following lines at the end of the section:
    
    As noted in section 4.2, the above text refers specifically to RADIUS
    attributes.  Other AAA services can be
    substituted, but the requirements imposed
    on User-Name and Management-Policy-Id-Attribute MUST be
    satisfied using the
    equivalent fields for that service.
  5. Dan Romascanu: Discuss [2010-08-24]:
        This is a very good document and I plan to enter a 'Yes' in the ballot, but
    there are a number of issues that were raised in the OPS-DIR review by Joel
    Jaeggli and in the MIB-Doctor review by Glenn Keeni which are under discussion
    with the authors. I am holding a DISCUSS until these issues are resolved. 
        
  6. Dan Romascanu: Comment [2010-08-24]:
    
      

draft-thaler-v6ops-teredo-extensions

  1. Russ Housley: Discuss [2010-08-24]:
        
      Roni Even raises two concerns in his Gen-ART Review.  Please respond
      to both of the concerns.  The review can be found at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-thaler-v6ops-teredo-extensions-07-even.txt 
        
  2. Alexey Melnikov: Comment [2010-08-26]:
    Trailer type field might benefit from having an IANA registry.

draft-ietf-mipshop-transient-bce-pmipv6

  1. Adrian Farrel: Comment [2010-08-26]:
    Clearing my Discuss on the basis of Jari's answer:
    "That's a good question to ask. The answer is yes."
  2. Russ Housley: Comment [2010-08-26]:
      Please consider the editorial comments in the Gen-ART Review from
      Spencer dawkins on 25-Aug-2010.
  3. Alexey Melnikov: Comment [2010-08-26]:
    6.  IANA Considerations
    
       This specification also adds one status code value to the Proxy
       Binding Acknowledge message, the
       PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code.  The
       PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in
       Section 4.7.  Its value must be assigned from the same number space
       used for the Mobile IPv6 Binding Acknowledgement status values, as
       defined in [RFC3775], and must be smaller 128.
    
    I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility-
    parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub-
    registry. Am I looking in a wrong place, or is it named differently?
  4. Sean Turner: Discuss [2010-08-26]:
        The security considerations section needs to indicate whether there are any new
    security considerations introduced in addition to those in RFC 5213. 
        

draft-ietf-avt-srtp-not-mandatory

  1. Jari Arkko: Comment [2010-08-24]:
    This is a very much needed document, well written, and makes IMO the
    right conclusions.
    
    I did have two issues, however, but decided to place a Yes vote as
    opposed to holding a discuss. I do want to talk about these topics
    on the IESG telechat, however.
    
    The first issue is that in Section 4 MIKEY is ruled out as mechanism for
    supporting situations where the SIP infrastructure is untrusted. I do not
    understand why this is being done. MIKEY can provide end-to-end authentication,
    which would seem to thwart attacks where SDES would
    clearly fail. Can this
    exclusion be elaborated and/or removed?
    
    The second issue relates to the main recommendations. The documents
    makes the argument that RTP applications are so diverse that they can
    not live under the same security solution. However, I am left wondering
    whether there would be mandatory-to-implement security solutions for
    specific applications. Do the authors for some reason believe that is
    not feasible or undesirable? Should there be IETF activities started
    on making such requirements for specific applications?
  2. Lars Eggert: Comment [2010-08-23]:
    Section 3., paragraph 4:
    >    [ETSI.TS.102.474], where one mode of operation uses ISMAcryp
    >    (http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP
    >    payload data only.
    
      Nit: It'd be better to refer to this URL as a reference.
    
    Section 4., paragraph 9:
    >    authentication solutions that are tied into the key manangement.
    
      Nit: s/manangement./management./
    
  3. David Harrington: Comment [2010-08-25]:
    I support Russ's DISCUSS
    
  4. Russ Housley: Discuss [2010-08-24]:
          This draft seems to say that BCP 61 does not apply to RTP.  BCP 61
      describes the "Danvers Doctrine", which says that the IETF should
      standardize on the use of the best security available, regardless of
      national policies.  BCP 61 also says:
    
      > One of the continuing arguments we hear against building security
      > into protocols is the argument that a given protocol is intended only
      > for use in "protected" environments where security will not be an
      > issue.
      >
      > However it is very hard to predict how a protocol will be used in the
      > future.  What may be intended only for a restricted environment may
      > well wind up being deployed in the global Internet.  We cannot wait
      > until that point to "fix" security problems.  By the time we realize
      > this deployment, it is too late.
      >
      > The solution is that we MUST implement strong security in all
      > protocols to provide for the all too frequent day when the protocol
      > comes into widespread use in the global Internet.
    
      I find it inappropriate for an Informational document to a BCP.  If
      there is consensus that RTP is a special case, then the exception to
      BCP 61 ought to be documented in a BCP.
      
      I do not believe that there is such a consensus as it would contradict
      the results of the RTPSEC BOF held at IETF 68.  The RTP security
      requirements were eventually published as RFC 5479, and then RFC 5763
      and RFC 5764 (DTLS-SRTP) published a solution to those requirements.
    
      I recognize that DTLS-SRTP is not the solution for all environments.
      However, today most RTP in deployments use no security.  BCP 61 argues
      for security to be implemented even if it is not turn on in every
      deployment.  A secuity solution for unicast point-to-point audio is
      unlikely to work well for multicast IPTV.  This does not argue for no
      security.  Rather it argues for a collection of security solutions
      that accomodate the various environments that RTP supports.
     
        
  5. Tim Polk: Discuss [2010-08-26]:
        Note: This is a joint discuss from both Security ADs.  Given the importance of
    this
    document, we are both holding a discuss position so we can participate in
    the
    discussion that follows.
    
    We accept the basic premise of this document: as a “framework protocol”,
    applying
    BCP 61 directly and mandating a single security solution is not
    appropriate and
    would not achieve the goal of BCP 61: ensuring that security
    mechanisms are
    implemented (and thus available) even if it is not turned on in
    every deployment.
    However, we do not believe the proposed solution (leaving the
    selection to each
    application of RTP) is any more likely to achieve that goal.
    In most actual deployments,
    RTP is basically not secured.  Allowing a thousand
    flowers to bloom practically 
    guarantees that real deployments will not include
    security mechanisms (since there
    is so little prospect of code re-use and many
    current deployments won’t turn it on.)
    
    To meet the spirit of BCP 61, we recommend that the working group consider the
    following approach: specify a small set of solutions that cover the major
    classes of
    applications, and mandate implementation of the appropriate solution
    for each RTP
    application.  RTP application standards would be required to
    justify a mandatory to
    implement security scheme that does not fall within this
    set.  We believe this solution 
    provides the best opportunity to achieve the
    goals of BCP 61 for RTP-based applications. 
        
  6. Dan Romascanu: Discuss [2010-08-24]:
        This document does a good job in building the case that SRTP is not universally
    fit as a security solution for all use cases of RTP. I have however a couple of
    issues with two sections in the document that I would like to be discussed
    before I can approve the document:
    
    1. The last application scenario listed in Section 3 says: 
    
    >  Finally, the link layer may be secure, and it may be known that the
       RTP media data is constrained to that single link (for example, when
       operating in a studio environment, with physical link security).  An
       environment like this is inherently constrained, but might avoid the
       need for application, transport, or network layer media security.
    
    I do not believe that this is relevant in a discussion about securing an IETF
    protocol. BCP 61 (RFC 3365) Section 6 is very clear in that:
    
    >  One of the continuing arguments we hear against building security
       into protocols is the argument that a given protocol is intended only
       for use in "protected" environments where security will not be an
       issue.
    ...
       The solution is that we MUST implement strong security in all
       protocols to provide for the all too frequent day when the protocol
       comes into widespread use in the global Internet.
    
    I suggest to take out this case as irrelevant
    
    2. I am confused about what section 5 tries to say. First I do not know the term
    'framework protocol' - this needs to be defined or referred to. What the section
    seems to say is that for that category of protocols (where RTP belongs) the
    strong security is more an application issue, where an application may be built
    of several building blocks, out of which the protocol is only one of them. This
    seems again to question or even justify an extemption from the requirements of
    BCP 61 [RFC3365] for RTP or even a whole class of protocols. 
        
  7. Dan Romascanu: Comment [2010-08-24]:
    1. In Section 1: s/Section 2 describes the scenarios in which RTP is
    deployed./Section 2 describes the most widely encountered scenarios in which RTP
    is deployed./
    
    2. in Section 2 - why are the conferencing scenarios listing only video
    conferencing and not voice and video conferencing?
  8. Sean Turner: Discuss [2010-08-26]:
        Note: This is a joint discuss from both Security ADs.  Given the importance of
    this
    document, we are both holding a discuss position so we can participate in
    the
    discussion that follows.
    
    We accept the basic premise of this document: as a “framework protocol”,
    applying
    BCP 61 directly and mandating a single security solution is not
    appropriate and
    would not achieve the goal of BCP 61: ensuring that security
    mechanisms are
    implemented (and thus available) even if it is not turned on in
    every deployment.
    However, we do not believe the proposed solution (leaving the
    selection to each
    application of RTP) is any more likely to achieve that goal.
    In most actual deployments,
    RTP is basically not secured.  Allowing a thousand
    flowers to bloom practically 
    guarantees that real deployments will not include
    security mechanisms (since there
    is so little prospect of code re-use and many
    current deployments won’t turn it on.)
    
    To meet the spirit of BCP 61, we recommend that the working group consider the
    following approach: specify a small set of solutions that cover the major
    classes of
    applications, and mandate implementation of the appropriate solution
    for each RTP
    application.  RTP application standards would be required to
    justify a mandatory to
    implement security scheme that does not fall within this
    set.  We believe this solution 
    provides the best opportunity to achieve the
    goals of BCP 61 for RTP-based applications. 
        

draft-ietf-pkix-ta-mgmt-reqs

  1. Robert Sparks: Comment [2010-08-25]:
    
        
  2. Sean Turner: Comment [2010-08-25]:
    This is along the same line as Alexey's:
    
    3.7.2.  Rationale
        There is no standardized format for trust anchors.
    
    Is this really true now that 5914 is published?

draft-ietf-mif-problem-statement

  1. Ralph Droms: Discuss [2010-08-25]:
        I have a fundamental problem with the way in which this document characterizes
    the problems resulting from the simultaneous use of multiple interfaces as all
    resulting from receiving different configuration objects from different
    administrative domains.  In my opinion, some of the example problems in the
    document are a result of other problems inherent with the simlutaneous use of
    multiple interfaces.  This distinction is important because , again in my
    opinion, there are mif problems which cannot be solved by changes to the
    configuration behavior in the host.
    
    For example, in section 4.1, the symptom:
    
       4.  S1 or S2 has been used to resolve "a.private.example.com" to an
           [RFC1918] address.  Both N1 and N2 are [RFC1918] addressed
           networks.  IPv4 source address selection may face challenges, as
           due address overlapping the source/destination IP addresses do
           not necessarily provide enough information for making proper
           address selection decisions.
    
    is inherent in having interfaces connected to networks using overlapping address
    spaces, and cannot be solved by improvements to the configuration behavior.
    
    Similarly in section 4.1:
    
       5.  H1 has resolved an FQDN to locally valid IP address when
           connected to N1.  After movement from N1 to N2, the host tries to
           connect to the same IP address as earlier, but as the address was
           only locally valid, connection setup fails.  Similarly, H1 may
           have received NXDOMAIN for an FQDN when connected to N1.  After
           movement from N1 to N2, the host should not assume the FQDN
           continues to be nonexistent.
    
    How is this problem caused by configuration objects from different domains?
     
    I
    see two ways to address my concern: either be explicit in limiting the problem
    statement and mif deliverables to those problems that can be solved with proper
    handling of configuration information from multiple admin domains or extend the
    scope of this document to include any problems that may result from the
    disparate environments (IP reachability, DNS resolution, QoS) to which
    interfaces are attached. 
        
  2. Ralph Droms: Comment [2010-08-25]:
    Some of the symptoms don't derive from the stated operational environments.  For
    example, in section 4.1:
    
       3.  H1 keeps only one set of DNS server addresses from the received
           configuration objects and kept S2 address.  H1 sends the DNS
           query for a.private.example.com to S2.  S2 asks its upstream DNS
           and gets an IP address for a.private.example.com.  However, the
           IP address is not the same one S1 would have given.  Therefore,
           the application tries to connect to the wrong destination host,
           or to the wrong interface of the latter, which may imply security
           issues or result in lack of service.
    
    seems to be in conflict with the constraint at the top of the section that 'name
    "a.private.example.com" [...] is within the private namespace of S1 and only
    resolvable by S1'; that is, if the constraint holds, H1 would not get a
    resolution for a.private.example.com by sending a resolution query to S2.
    
    Also in section 4.1:
    
       5.  H1 has resolved an FQDN to locally valid IP address when
           connected to N1.  After movement from N1 to N2, the host tries to
           connect to the same IP address as earlier, but as the address was
           only locally valid, connection setup fails.  Similarly, H1 may
           have received NXDOMAIN for an FQDN when connected to N1.  After
           movement from N1 to N2, the host should not assume the FQDN
           continues to be nonexistent.
    
    what does "movement from N1 to N2" mean?
    
    Still in section 4.1:
    
       A MIF host may also be provisioned with a Interface-specific suffix
       search list ([I-D.ietf-mif-current-practices]).  In this situation,
       if H1 sends DNS query on I1 using the search list tied to I2, the
       namespace could be not valid on I1 and the name could be not
       resolved.
    
    isn't the described host behavior clearly a bug in the host stack?
    
    From Andrew Sullivan, dns-directorate review:
    
     First, this is an implicit recognition that the DNS namespace is not
     actually a single, unified namespace.  I think that's just
     acknowledging the facts in the world, but I know there are people
     opposed to that.
    
     Second, it seems to be setting up the mif WG to be trying to "solve"
     the DNS split-views problem.  I think this effectively means that
     we're (i.e. the dns-dir crowd) will need to keep on top of MIF.
    
  3. Lars Eggert: Discuss [2010-08-23]:
        Section 3., paragraph 1:
    >        2.  Interfaces of a MIF host can provide different
    >            characteristics (e.g. round-trip time, least cost, better
    >            bandwidth, etc....).  So, user, applications or network
    >            provider may wish to influence routing to take benefit of
    >            this heterogeneity.  However, with current host
    >            implementations, neither the Type-of-Service nor path
    >            characteristics can be taken into account in the routing
    >            table.
    
      DISCUSS: I don't think MIF can solve this problem. Yes, interfaces are
      the first hops into *paths* of different characteristics, but what
      service quality an application sees across a path depends on the
      destination, the transport protocol in use and the communication
      patterns of the application. There is nothing here that can be
      optimized without taking these into account.
     
        
  4. Lars Eggert: Comment [2010-08-23]:
    INTRODUCTION, paragraph 4:
    >    of its provisioning domain.  Some configuration objects are global to
    
      Nit: s/domain/domains/
    
    Section 1., paragraph 1:
    >    A multihomed host have multiple provisioning domains (via physical
    
      Nit: s/have/has/
    
    Section 1., paragraph 4:
    >    values from each provisioning domains, such as different DNS servers
    
      Nit: s/from/for/
    
    Section 3.1., paragraph 1:
    >    [RFC5113] is out of scope of this document.  Moreover, lower layer
    
      Nit: s/is/are/
    
    Section 3.2., paragraph 2:
    >    The host maintains a route cache table where each entry contains the
    >    local IP address, the destination IP address, Type-of-Service and
    >    Next-hop gateway IP address.  The route cache entry would have data
    >    about the properties of the path, such as the average round-trip
    >    delay measured by a transport protocol.
    
      Modern stacks don't store transport info in the route cache anymore.
      Suggest to remove the last sentence.
    
    Section 3.2., paragraph 3:
    >    As per [RFC1122], two models are defined:
    >    o  The "Strong" host model defines a multihomed host as a set of
    >       logical hosts within the same physical host.  In this model a
    >       packet must be sent on an interface that corresponds to the source
    >       address of that packet.
    
      And it will only be received on that interface, too.
    
    Section 3.2., paragraph 4:
    >    o  The "Weak" host model describes a host that has some embedded
    >       gateway functionality.  In the weak host model, the host can send
    >       and receive packets on any interface.
    
      This doesn't really make the distinction clear. A weak host can send
      and receive packets ***addressed to or from any of its source
      addresses on any of its interfaces***.
    
    Section 3.5., paragraph 2:
    >    Some application protocols do referrals of IP addresses and port
    >    numbers for further exchanges.
    
      A referral also includes the transport protocol to be used.
    
    Section 2., paragraph 0:
    >    2.  For the IP1 address family, H1 has one default route (R1, R2) per
    >        network (N1, N2).  IP1 is reachable by both networks, but N2 path
    >        has better characteristics, such as better round-trip time, least
    >        cost, better bandwidth, etc....  These preferences could be
    >        defined by user, by the provider, by discovery or else.  H1 stack
    >        uses R1 and tries to send through I1.  IP1 is reached but the
    >        service would be better by I2.
    
      Note that "better" here is entirely dependent on what kind of traffic
      is to be exchanged with the destination, i.e., it is transport
      protocol and application dependent. General preferences of any sort
      are therefore likely to be wrong.
    
    Section 11., paragraph 23:
    >    [RFC4477]  Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
    >               Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
    >               Issues", RFC 4477, May 2006.
    
      Nit: Unused Reference: 'RFC4477'
    
  5. Adrian Farrel: Discuss [2010-08-26]:
        
    I have not seen any discussion of the Routing Area Directorate review performed
    by Joel Halpern. I should like to see the issues raised debated and resolved
    before this document goes forward.
    
    ===
    
    This is a Routing Area Review.  Please consult with your document 
    shepherd before making any changes.  Consult the Routing Area 
    Directorate page for information on the review process 
    (http://www.ietf.org/iesg/directorate/routing.html)
    
    Document file: draft-ietf-mif-problem-statement-07.txt
    Document Name: Multiple Interfaces Problem Statement
    Reviewer: Joel M. Halpern
    Review Date: 15-August-2010
    Last Call End Date: 2010-08-23
    Telechat Date: 2010-08-26
    Summary: This document is nearly ready for publication as an 
    informational RFC.
         However, there are some items that should be attended do.
    
    Comments:
    Moderate:
    Section 5, item 3 on routing, sub-bullet 2 describes an underlying 
    problem attributed to routing.  As routing is sued by this section, it 
    seems to apply to host interface selection, first hop router selection, 
    and general path selection.  As written, the text seems an invitation 
    for the MIF working group to delve into the issues of host control over 
    routing path selection.  Please do not go there.  I sould suggest 
    tightening the text up to make it clear that what is meant is policy 
    based itnerface and first-hop router selection, where policy may reflect 
    the many things listed in sub-bullet 2.
    
    Minor:
    Section 2: MIF Characgteristics:
    It is a bit odd to list the characteristics of a MIG host in the 
    Terminology section.  It seems like a section on its own.
    
    In the thrid bullet in the characteristics, the English usage is a bit 
    misleading.  The text says "A MIF host can attach to more than one 
    provisioning domains."  I suspect that "can" here means "may be", that 
    is that the document recognizes the possibility of such attachment.  As 
    written, the text almost seems to be requiring special logic for 
    handling multiple domaisn, which while it may be a conclusion of the MIF 
    group is clearly not a requirement for the problem statement.  (The 
    following item uses "may be" in exactly the way I would recommend for 
    item 3.)
    
    The last item in the list of characteristics refers to a MIF host as 
    potentially forwarding packets.  While the document is clear that such 
    behavior is out of scope (which is good), I wonder if it would be better 
    to note the IPv6 terminology and say that such devices are not hosts? 
    (they are nodes, but they are not hosts.)  The reason I raise this is 
    that the host-like logic in a router is probably also out of scope for 
    MIF, isn't it?
    
    Section 3.5 on Finding and Sharing IP Addresses with Peers contains 
    clear, and to the best of my knowledge accurate, information.  However, 
    I can note determine what the relationship of this topic is to MIF.  I 
    suspect that the intention is to say that MIF will not be working on NAT 
    traversal of referral issues.  But the text does not seem to say that.
    Similarly, for section 3.6 on APIs and connection managers, the text 
    talks about the issues, but is unclear as to whether they are in or out 
    of scope for MIF.
    
    Yours,
    Joel M. Halpern 
        
  6. Adrian Farrel: Comment [2010-08-26]:
    
        
  7. Russ Housley: Comment [2010-08-26]:
      My concern is already captured in DISCUSS posiotns held by Ralph,
      so I am not going to pile on.  However, I do want to make it known
      that I also have the same concern.  (Note the same concern was
      raiseed by Roni Even in his Gen-ART Review dated 24-Aug-2010.)
  8. Dan Romascanu: Comment [2010-08-25]:
    This is an useful document. The comments below are not blocking, but in case
    they are considered they could improve readability:
    
    1. In section 3.1 the following statement is made: 
    
    >  Network discovery and selection on lower layers as defined by
       [RFC5113] is out of scope of this document.  Moreover, lower layer
       interaction such as IEEE 802.21 is also out of scope.
    
    It would be good to be more exact about what is IEEE 802.21 - for example 
    
    s/lower layer interaction such as IEEE 802.21/handover and interoperability
    between lower layer networks such as the mechanisms defined in IEEE 802.21/
    
    An informative reference to IEEE 802.21 would also be in place. 
    
    2. Expanding acronyms at their first occurance would be useful.
    
    3. The OPS-DIR review performed by Menachem Dodge also included a number of
    useful editorial comments which I suggest to consider.
  9. Robert Sparks: Comment [2010-08-24]:
    Some very minor editorial suggestions:
    
    Is there a missing word (I think "may" at "may have") in the first sentence of
    the introduction?
    
    Should the first sentence of 3.6 start with "An Application"?
  10. Sean Turner: Discuss [2010-08-26]:
        An updated DISCUSS that includes a reference to the SECDIR review.
    
    This is a placeholder DISCUSS while the authors, AD, and SECDIR reviewer work on
    some expanded text for the security considerations section.  See the thread:
    http://www.ietf.org/mail-archive/web/secdir/current/msg01963.html 
        

draft-ietf-netmod-yang-usage

  1. Lars Eggert: Discuss [2010-08-23]:
        Section 4., paragraph 0:
    > 3.7.  Intellectual Property Section
    
      DISCUSS: The current ID format does not have an Intellectual Property
      Section anymore.
     
        
  2. Lars Eggert: Comment [2010-08-23]:
    Section 3., paragraph 3:
    >    The following sections MUST be present in an Internet-Draft
    >    containing a module:
    >    o  Narrative sections
    >    o  Definitions section
    >    o  Security Considerations section
    >    o  IANA Considerations section
    >    o  References section
    
      I think it makes sense here to separate this into sections that this
      memo requires for YANG modules (the first two), and into sections that
      the general ID template requires (the final three), because the latter
      can change and obviously YANG IDs need new sections if they become
      required to submit an ID. For the latter, you should rephrase the
      sections that describe their content in a way that makes it clear that
      they are currently required, but that new ones may be added and just
      maybe some of the listed ones will dissappear.
    
    Section 3.1., paragraph 3:
    >    Each YANG module or submodule contained within an Internet-Draft or
    >    RFC is considered to be a code component.  The strings '<CODE
    >    BEGINS>' and '<CODE ENDS>' MUST be used to identify each code
    >    component.
    
      I note that YANG is listed in
      http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt,
      so you actually do not need to require the use of <CODE BEGINS> and
      <CODE ENDS>.
    
    Section 4., paragraph 1:
    >    In general, modules in IETF standards-track specifications MUST
    >    comply with all syntactic and semantic requirements of YANG.
    >    [I-D.ietf-netmod-yang].  The guidelines in this section are intended
    >    to supplement the YANG specification, which is intended to define a
    >    minimum set of conformance requirements.
    
      You may want to recommend that authors verify the syntax of their YANG
      module with an automated checker every time before submitting a new
      revision. (I see that Section 4.8 talks about that - maybe add a
      forward reference?)
    
    Section 4.5., paragraph 2:
    >    The 'attribute' and 'namespace' axes are not supported in YANG, and
    >    MAY be empty in a NETCONF server implementation.
    
      s/MAY/may/ (I don't think the idea is to make requirements on NETCONF
      servers here)
    
    >    The 'position' and 'last' functions MAY be used with caution. 
    
      I don't know what "MAY be used with caution" means. Does it mean
      "SHOULD NOT, but if you do consider <this>"? Or does it mean "MUST be
      used in <this way>"? (The "with caution" phrasing appears elsewhere,
      and I have the same question about all occurrences.)
    
    Section 6.1., paragraph 1:
    >    transport is SSH [RFC4742].
    
      Reference missing: RFC4742
    
  3. Adrian Farrel: Comment [2010-08-26]:
    Thanks for this document. I think it will be useful.
    
    ---
    
    Support Enrico's point in Russ's Discuss.
    It is not appropriate to keep the boilerplate outside the IETF domain.
    
    http://trac.tools.ietf.org/wg/netconf/trac/wiki may be an appropriate
    location.
    
    ---
    
    I wonder if there is scope for some common framework text like that
    held at http://www.ops.ietf.org/mib-boilerplate.html
    
    ---
    
    I am a bit worried that this document covers advice that is more general than
    just the Yang-related work in an I-D. This risks setting up contradictory advice
    in a number of places. (For example, discussing how the References should be
    split is generic advice for authors of I-Ds that could be changed at any time.)
  4. Russ Housley: Discuss [2010-08-24]:
        
      The Gen-ART Review by Enrico Marocco on 9-Jul-2010 leads me to ask a
      question about Section 3.4.
    
      Section 3.4 says:
      >
      > Each specification that defines one or more modules MUST contain a
      > section that discusses security considerations relevant to those
      > modules.  This section MUST be patterned after the latest approved
      > template (available at
      > http://www.ops.ietf.org/netconf/yang-security-considerations.txt).
      >
      This seems like an odd place for a normative reference to point.
      I'd be much happier with a place that required some form of review
      and consensus call to be updated.
     
        
  5. Alexey Melnikov: Comment [2010-08-22]:
    I am generally glad that this document is written. Some comments/questions
    below:
    
    3.6.  Reference Sections
    
       For every normative reference statement which appears in a module
       contained in the specification, which identifies a separate document,
       a corresponding normative reference to that document SHOULD appear in
       the Normative References section.
    
    Why only a SHOULD (and not a MUST)?
    
    4.1.  Module Naming Conventions
    
       Modules contained in standards track documents SHOULD be named
       according to the guidelines in the IANA considerations section of
       [I-D.ietf-netmod-yang].
    
    Why only a SHOULD?
    
       A distinctive word or acronym (e.g., protocol name or working group
       acronym) SHOULD be used in the module name.  If new definitions are
       being defined to extend one or more existing modules, then the same
       word or acronym should be reused, instead of creating a new one.
    
    s/should/SHOULD ?
    
    4.7.  Module Header, Meta, and Revision Statements
    
       It is acceptable to reuse the same revision statement within
       unpublished versions (i.e., Internet-Drafts), but the revision date
       MUST be updated to a higher value each time the Internet-Draft is re-
       published.
    
    I tend to think that this MUST will be ignored in practice. I think making
    authors update a revision date with every uncompatible change would be more
    sensible.
  6. Robert Sparks: Comment [2010-08-24]:
    Support Russ' discuss.
  7. Sean Turner: Comment [2010-08-26]:
    Is there a yang doctors set up yet (like there was MIB doctors) where people
    send their modules to get reviewed?

draft-ietf-pkix-asn1-translation

  1. (none)

draft-ietf-tcpm-tcp-lcd

  1. Adrian Farrel: Comment [2010-08-26]:
    Thank you for this work and for proposing it as Experimental.
    
    My first Comment is very close to being a Discuss, and I hope you
    feel able to add some text (perhaps to the Introduction) to give
    the reader (and future generations) some guidance.
    
    For experimental documents, I think it is important to give some
    parameters of the nature of the experiment. 
    - What constraints will be placed on the experimental work to prevent
      the experiment spilling out into the Internet (walled garden)?
    - What are the risks if the experiment is released?
      (perhaps a forward pointer to section 7)
    - How will you judge whether the work is stable and successful?
    - Do you have plans / proposals to return and revise the work for
      the Standards Track?
    
    ---
    
    Section 2
    
    Tiny nit, sorry
    
       This document improves TCP's behavior in case of "long connectivity
       disruptions".
    
    Well, the document doesn't do that of itself :-)
  2. Russ Housley: Comment [2010-08-26]:
      Please consider the editorial comments in the Gen-ART Review from
      Enrico Marocco on 25-Aug-2010.
  3. Sean Turner: Discuss [2010-08-26]:
        This is a placeholder DISCUSS.
    
    There has been no response to the SECDIR review comments from Catherine Meadows
    (http://www.ietf.org/mail-archive/web/secdir/current/msg01965.html). 
        

draft-sheffer-emu-eap-eke

  1. Adrian Farrel: Comment [2010-08-26]:
    I couldn't work out which range of EAP Method Types should be used for
    the allocation described at the head of Section 7 for "EAP-EKE Version
    1".
    
    I presume you are headed for 1-191 or 256-...
    The difference at this stage is whether expert review needs to be 
    invoked.
  2. Russ Housley: Discuss [2010-08-24]:
        
      Please respond to the comments from Dan Harkins on 18-Aug-2010. 
        
  3. Alexey Melnikov: Discuss [2010-08-25]:
        [This is a preliminary DISCUSS and I might add a few extra items before the IESG
    telechat.]
    
    This is a well written document and in general I have no objections to its
    publication. However I have several points I would like to discuss before
    recommending approval of this document:
    
    3)
    7.5.  Identity Type Registry
    
       In addition, an identity type registry is defined:
    
       +-----------+---------+---------------------------------------------+
       | Name      | Value   | Definition                                  |
       +-----------+---------+---------------------------------------------+
       | Reserved  | 0       |                                             |
       | ID_OPAQUE | 1       | An opaque octet string                      |
    
    DISCUSS DISCUSS: Is this value ever entered by a human? If the answer is yes,
    then this need some common user friendly input format for management of such
    identities. 
        
  4. Alexey Melnikov: Comment [2010-08-25]:
    It would have been nice to be able to piggyback on one of existing
    MAC/PRF/Encryption algorithm registries.
    
    4.2.3.  The EAP-EKE-Confirm Payload
    
       PNonce_PS/PNonce_S:
    
          This field ("proptected nonce") contains the encrypted and
    
    typo: protected
    
          integrity-protected response to the other party's challenge, see
          Section 5.3 and Section 5.4.  Similarly to the PNonce_P field,
          this field's size is determined by the encryption and MAC
          algorithms.
    
  5. Tim Polk: Discuss [2010-08-26]:
        This is a placeholder discuss.  Issues raised in Brian Weis' secdir review have
    not been addressed yet.  Please
    involve Brian in the discussion as you address
    these issues! 
        
  6. Sean Turner: Comment [2010-08-26]:
    I support Russ and Tim's DISCUSS positions.

draft-juskevicius-datatracker-wgdocstate-reqts

  1. Ralph Droms: Comment [2010-08-25]:
    I have a couple of minor comments.
    
    Is "WG I-D" a synonym for "I-D associated with an IETF WG"?
    
    I don't understand this requirement:
       WG document status tracking SHOULD be implemented per-document, not
       per-WG. (R-012)
    What would "per-WG WG document status tracking be?
  2. Lars Eggert: Discuss [2010-08-23]:
        Section 4.2., paragraph 1:
    >    When an IETF WG Chair needs to input or update the WG status of an
    >    I-D in one of his or her WGs, the WG Chair SHALL be required to log-
    >    on to the Datatracker using a personal user-id and password (e.g.,
    >    an IETF tools password) in order to gain 'write' access. (R-015)
    
      DISCUSS: This is redundant with R-014.
    
    Section 4.2., paragraph 3:
    >   - SHALL be given full 'read' and 'write' privileges to input and
    >     update WG status information for all of the I-Ds associated with
    >     their WGs, one WG at a time; (R-016)
    
      DISCUSS: This is redundant with R-014 and R-015, and it's unclear what
      the "one WG at a time" bit means.
    
    Section 4.2., paragraph 7:
    >   - SHALL be able to designate one or more people to act as delegates
    >     to input and update the WG status of the I-Ds associated with their
    >     WGs; (R-020)  The identifier for each delegate should be the
    >     person's e-mail address; (R-021)
    >   - SHALL be able to designate different people to act as delegates for
    >     them in different WGs when the WG Chairs are also responsible for
    >     the different IETF WGs; (R-022)
    
      DISCUSS: This sounds like the delegates are personal delegates of the
      chair; in reality they are WG secretaries.
    
    Section 4.2., paragraph 9:
    >   - SHALL be able to assign people to be Document Shepherds for one or
    >     more WG I-Ds if this role will not be performed by a WG Chair or a
    >     designated delegate; (R-024)  The identifier for each Document
    >     Shepherd should be the person's e-mail address. (R-025)
    
      DISCUSS: The shepherd must always be a chair or secretary, this cannot
      be delegated to others. (If all chairs and secretaries are
      disqualified from being shepherds, this role falls back to the AD.)
    
    Section 4.2., paragraph 11:
    >   - SHALL be able to review and change the people assigned to be
    >     Document Shepherds in their WGs, one WG at a time. (R-027)
    
      DISCUSS: No. See above.
    
    Section 4.3., paragraph 0:
    > 4.3. For Delegates of IETF WG Chairs
    
      DISCUSS: The "delegates" stuff is too complex and not in light with
      how WG secretaries work. For the purposes of the tracker, secretaries
      for a WG are just like chairs except they cannot appoint and remove
      secretaries.
    
    Section 4.4., paragraph 0:
    > 4.4. For IETF WG Document Shepherds
    
      DISCUSS: The document is confused about what shepherds are. According
      to RFC4858, shepherds are chairs, and if the chairs are conflicted,
      they are secretaries, otherwise this role falls back to the AD. The
      shepherding role cannot be otherwise delegated.
    
    Section 6.1., paragraph 0:
    > 6.1. Candidate WG Document
    
      DISCUSS: This entire process for handling documents that may be
      candidates in multiple WGs is super complex and mostly useless,
      because such cases almost never exist, esp. not concurrently. Plus, it
      invents a new process with deadlines, timers and notifications where
      we currently have none, and I don't think that's the purpose of this
      document.
     
        
  3. Lars Eggert: Comment [2010-08-23]:
    Section 3., paragraph 1:
    >    The Datatracker SHALL be enhanced to provide IETF WG Chairs and the
    >    people they designate to act as their delegates with the flexibility
    >    to input and update the WG status of some, all, or none of the I-Ds
    >    associated with their WGs using the WG document states and status
    >    annotation tags defined in [WGDRAFTS]. (R-001)
    
      Can we s/the people they designate to act as their
      delegates/secretaries/? AFAIK there are no other delegates allowed by
      the process. (Also elsewhere in the doc.)
    
    Section 3., paragraph 2:
    >    The following two examples clarify Requirement R-001:
    >   - the Chairs (and their delegates) of a newly chartered IETF WG may
    >     choose to input the WG status of all of the I-Ds associated with
    >     their WG to provide maximum transparency to the IETF community and
    >     to manage the progression of the I-Ds;
    >   - the Chairs (and delegates) of a mature WG (e.g. a WG that is
    >     nearing the completion of its charter milestones) may decide not to
    >     manually input the status of their WG I-Ds into the Datatracker.
    
      These examples don't clarify much. What they do is instead to make it
      sound OK for chairs of old WGs to not bother with these new functions,
      which I don't think is the message we want to send.
    
    Section 3., paragraph 8:
      The look and feel for R-005 and R-006 is somewhat important, but it is
      also maybe more important that the style sheets and javascript UI code
      be shared, so that when the IESG tracker is updated, the WG tracker
      benefits and vice versa.
    
    Section 7, paragraph 1:
    >    The Datatracker SHOULD date and timestamp every update to the WG
    >    status of an IETF Stream I-D and use that information when it needs
    >    to display the WG status change history of that I-D. (R-007)
    
      I think this needs to be a MUST, for transparency.
    
    Section 7, paragraph 2:
    >      The WG
    >    status change history for each I-D SHOULD also identify the person
    >    or entity that updated the WG status of the I-D (e.g. one of the
    >    WG's Chairs, a delegate, an AD, the System, the IETF Secretariat)
    >    and describe the change in the WG status of the I-D (e.g. "WG State
    >    changed from 'a' to 'b'", "Document Annotation Tag 'x' Set (or
    >    Reset)", "Document Availability status changed from 'j' to 'k'").
    >    (R-008)
    
      I think this needs to be a MUST, for transparency.
    
    Section 7, paragraph 4:
    >    WG document status tracking SHOULD be implemented using a new WG
    >    state machine that is separate from Datatracker's existing IESG
    >    document status tracking state machine. (R-010)
    
      This is an implementation detail we don't care about, as long as the
      externally visible behavior is such.
    
    Section 7, paragraph 6:
    >    WG document status tracking SHOULD be implemented per-document, not
    >    per-WG. (R-012)
    
      This is clearly a MUST. Otherwise, we don't *have* document tracking.
    
    Section 4.4., paragraph 2:
    >    The requirements in this Section describe the access privileges to
    >    be granted to a WG Document Shepherd who is not a WG Chair or a
    >    delegate of a WG Chair with the privileges described in Section 4.3.
    
      There are no such shepherds. See above.
    
    Section 6., paragraph 0:
    > 6. Special requirements for some WG I-D states and conditions
    
      Many of the issues I raised for draft-ietf-proto-wgdocument-states-08
      apply here, too. If they result in any changes to that document, this
      document will need to be carefully brought in line.
    
    Section 6.2., paragraph 3:
    >    adopted by another IETG WG. (R-073)  If a WG Chair or delegate moves
    
      Nit: s/IETG/IETF/
    
    Section 7., paragraph 3:
    >    associated with an IETG WG:
    
      Nit: s/IETG/IETF/
    
  4. Adrian Farrel: Discuss [2010-08-25]:
        
    Thank you for undertaking this work which I see as very important for
    the stability of the IETF as it continues to be under a lot of
    pressure caused by increasing workloads and decreasing resources.
    
    I will move to a "Yes" ballot after we have addressed my small issues,
    below. I also have one point for discussion with the rest of the IESG.
    
    (A large number of issues reflects the importance of the work and the
    readability of the work; it does not indicate any quality issues.)
    
    ===
    
    Discuss-Discuss (i.e. author need take no action)
    
    It seems to me that some of the sections of this document are
    constraining on the way that the WG chairs operate their WGs. For
    example, in section 6.1
    
       The "Candidate WG Document" state may be used to describe:
    
      - an I-D that someone has asked to be considered by a WG, if the WG
        Chair has agreed with the request;
    
      - an I-D that the WG Chair asked an author to write; or
    
      - an I-D listed as a 'candidate draft' in the WG charter.
    
    And similarly, in section 6.1
    
       The first WG Chair (or delegate) to move an I-D into the "Candidate
       WG Document" state SHALL be required to specify the maximum length
       of time that the I-D may remain in this state. (R-056)  The maximum
       length of time that an I-D may remain in the "Candidate WG Document"
       state SHOULD be specified as a number of weeks. (R-057)
    
    Don't we want to be careful to not create WG operational process as a
    side effect of this document? Shouldn't this document be limited to
    the behavior of the tool?  Noting, in particular, that
    draft-ietf-proto-wgdocument-states is Informational and not a BCP.
    
    For example, in the second case, this would change to "SHALL be able to"
    
    ===
    
    Discuss
    
    1. Requirement 2
    
      (e.g. other WG Chairs)
    
    This is ambiguous. It could be taken to mean chairs of other WGs.
    Suggest you use
      (e.g. another chair of the WG)
    
    ---
    
    2. Requirement 3
    
       The WG status of every IETF Stream I-D SHALL be tracked using the WG
       document states, WG document status annotation tags, and intended
       document maturity levels specified in [WGDRAFTS]. (R-003)
    
    Appears to read like a requirement on the IETF or the WG chairs, not a
    requirement on the Datatracker.
    
    Do you mean:
       It SHALL be possible to track the WG status of...
    
    ---
    
    3. Requirements 7 and 8
    
    Requirement 8 is a MUST. We cannot have documents changing state without
    accountability. 
    
    I feel that requirement 7 is very close to a MUST because it is very 
    important to be able to see how long a document has been "stuck" in a
    state.
    
    Pretty sure that R-042 is a MUST at the same time.
    
    ---
    
    4. A really useful feature of the datatracker is that a Comment can be
    inserted at any time to add context. This could be when there is a
    state change (or, indeed, when there isn't a state change when one
    might reasonably be expected).
    
    I think this should be called out explicitly as a feature and all of
    - WG chairs
    - delegates
    - shepherds
    MUST be able to add comments which MUST be date stamped and tracked
    against the user.
    
    (This sort of shows up partially in R-037.)
    
    ---
    
    5. Requirement 18
    
      - SHALL NOT be allowed to create ad hoc WG document states or state
        names; (R-018)
    
    It is not explained what an "ad hoc WG document state or state name" is.
    - ad hoc WG?
    - ad hoc document in a WG?
    - ad hoc state?
    
    I suspect that the text would read as well by deleting "ad hoc".
    
    ---
    
    6. Requirements 37 and 38
    
       After displaying the information required by R-036, the Datatracker
       SHALL prompt the WG Chair or delegate to select a next state for the
       I-D and to enter some text to explain the state change for the I-D's
       status change history. (R-037)  The Datatracker SHOULD always prompt
       the person who updates or changes the WG state of an I-D to input
       some text for the I-D's status change history. (R-038)
    
    37 seems to say SHALL {prompt next state, prompt text}
    38 says SHOULD {prompt text}
    
    So 37 and 38 overlap / conflict
    
    ---
    
    7. Section 5.3
    
    This section appears to say that the write-up is a single entity that
    can be eddited, and some form of change log. I'm not oppsed to this,
    but i want to check that you are aware that this is different from the
    current system where any changes to the write-up are represented by a
    complete upload of a new copy of the write-up.
    
    ---
    
    8. Timer pops
    
    (This may be a joint issue with draft-ietf-proto-wgdocument-states
    
    There is inconsistency in how timer pops are handled.
    For example, when in CANDIDATE WG DOCUMENT and the timer expires, the
    state changes automatically; but when in IN WG LAST CALL and the timer
    expires, the state does not change.
    
    Inconsistency is not good!
    In fact, states that have a timer should have a "follow-up state" so
    that it is clear what the state is and what the next action actually
    is.
    
    ---
    
    9. Section 7
    
       Requirement R-001 provides each IETF WG Chair with the freedom to
       decide to use all or just some of the WG document states defined in
       [WGDRAFTS] to indicate the status and progression of documents in
       his or her working group.
    
    This is not how I read R-001! It reads...
    
       The Datatracker SHALL be enhanced to provide IETF WG Chairs and the
       people they designate to act as their delegates with the flexibility
       to input and update the WG status of some, all, or none of the I-Ds
       associated with their WGs using the WG document states and status
       annotation tags defined in [WGDRAFTS]. (R-001)
    
    I.e., the requirement talks about the optionality applying to the 
    drafts (one at a time). It does not talk about the optionality of
    some of the states. What is more, a number of the other requirements
    show some rules about state transitions that appear to indicate a
    lack of optionality. 
    
    Section 7 goes on to say:
    
       The same requirement also allows each
       IETF WG Chair to decide to *not* log-on to the Datatracker to
       manually input or update the status of drafts in her/his WG.
    
    This could be read two ways. One reading implies that the states
    can be changed in some way other than by logging on. 
        
  5. Adrian Farrel: Comment [2010-08-25]:
    10. Could you mention WG Secretaries explicitly somewhere. Perhaps 
    as an example when you mention delegates the first time?
    
    ---
    
    11. Minor inconsistency that "WG chair" and "IETF WG chair" are both
    used.
    
    ---
    
    12. Section 2
    
      - I-Ds that are being considered for adoption by one or more WGs.
    
    Maybe an unnecessary nit, but "are being considered" is passive voice
    and I know a number of document authors who do nothing but consider
    their I-Ds for adoption by a WG. Would you mind changing to...
    
      - I-Ds that are being considered under the guidance of a WG chair for
        adoption by one or more WGs.
    
    ---
    
    13. Section 2
    
       An I-D having a filename that includes the author's name and a WG
       acronym but not the string "-ietf-" may be a candidate for adoption
       by a WG and is also to be interpreted as being an "I-D associated
       with an IETF WG" for the purposes of this document.
    
    Sorry to be a pedantic lawyer, but... :-)
    
    "is also to be interpreted" should be scoped to within the two bullets
    at the top of the section, I think. So perhaps...
    
       An I-D having a filename that includes the author's name and a WG
       acronym but not the string "-ietf-" may be a candidate for adoption
       by a WG and, if so, is also to be interpreted as being an "I-D 
       associated with an IETF WG" for the purposes of this document.
    
    ---
    
    14. Requirement 10
    
    I don't feel it is correct to place requirements on the implementation
    that do not affect:
    - the blackbox behavior
    - the cost
    - the maintainability
    
    It is possible that you feel that this requirement falls into the third
    category, but it seems a bit out of scope to me.
    
    Alternatively, it may be that you simply meant that the implementation
    should use the state machines documented in [WGDRAFTS]  to determine 
    the valid state transitions.
    
    ---
    
    15. Requirement 40
    
    Very pedantic. Sorry!
    
       The Datatracker SHALL allow WG Chairs and their delegates to set and
       reset all of the WG I-D status annotation tags defined in Section
       3.5 of [WGDRAFTS] for every I-D associated with their WGs. (R-040)
    
    s/all of the/each of the/
    
    (The subtly being that you have implied that they can set/reset "all at 
    once" - a button that often exists on GUIs, but not what you mean.)
    
    ---
    
    16. Requirement 86
    
    Pretty petty, but...
    
       The WG Chair (or delegate) who moves an I-D into the "In WG Last
       Call" state SHALL be required to specify the number of weeks that
       the document may remain in this state.
    
    Why is the granularity required to be in weeks?
    Can we have a "date and time for end of last call"?
    Very often I have started a WG last call on a Friday and wanted to let
    it run two weeks and until first thing Monday morning.
  6. Alexey Melnikov: Discuss [2010-08-15]:
        I am largely happy with this document. However there are a couple of issues I
    would like to discuss before recommending approval of this document:
    
    1) 3. General requirements
    
       The Datatracker SHOULD date and timestamp every update to the WG
       status of an IETF Stream I-D and use that information when it needs
       to display the WG status change history of that I-D. (R-007)  The WG
       status change history for each I-D SHOULD also identify the person
       or entity that updated the WG status of the I-D (e.g. one of the
       WG's Chairs, a delegate, an AD, the System, the IETF Secretariat)
       and describe the change in the WG status of the I-D (e.g. "WG State
       changed from 'a' to 'b'", "Document Annotation Tag 'x' Set (or
       Reset)", "Document Availability status changed from 'j' to 'k'").
       (R-008)
    
    Why only SHOULDs (twice)?
    
    2) 6.1. Candidate WG Document
    
       The Datatracker SHALL also remove the name of the IETF WG from its
       WG status display (of other WGs (per Requirement R-061) in which the
       I-D is still being considered for adoption), and remove the Chairs
       (and delegates) of the WG from the distribution list for the e-mails
       that may be generated per Requirements R-063, and R-065 to R-069
       inclusive. (R-072)
    
    Should this also result in an email to Chairs/delegates of other WGs?
    
    3) 6.5. In WG Last Call
    
       It is possible that a WGLC may lead directly back into another WGLC
       for the same document.  For example, an I-D that completed a WGLC as
       an "Informational" document may need another WGLC if a decision is
       taken to convert the I-D into a standards track document.  The
       Datatracker SHOULD allow this to occur. (R-090)
    
    I believe this must be a MUST level requirement. Not allowing multiple WGLCs
    would
    be a serious deficiency in the tool.
    
    4) DISCUSS DISCUSS:
    
    6.8. Revised I-D Needed (annotation tag)
    
       A document that needs revision may be identified when the WG Chair,
       delegate, or the Responsible AD logs-on to the Datatracker to append
       one of the "Issue Raised - Revision Needed" annotation tags to the
       status of the document.  The Datatracker SHALL require the person
       who attaches one of these annotation tags to a document to indicate
       the number of weeks that it should take for the revised document to
       be produced (R-096).  The Datatracker should also prompt the user to
       consider changing the WG state of the I-D from "Submitted to IESG
       for Publication" to something else (e.g., Parked WG Document, WG
       Document, Waiting for WG Chair Go-Ahead). (R-097)
    
    As an AD I would hate to be forced to use another interface to make a document
    as needing a new revision once the document is in IESG processing.
    Can this be
    clarified?
    
    5) 6.8. Revised I-D Needed (annotation tag)
    
       The Datatracker should be programmed to send an e-mail to the WG's
       Chairs and delegates after the number of weeks specified in R-087 to
       remind or 'nudge' the WG Chairs and delegates to follow-up on the
       revisions to the document, unless a revised document is submitted
       before the time elapses. (R-098)
    
    Does posting of a new revision automatically clear the "Revised I-D Needed"
    annotation tag?
    
    6) 8. WG document status change reporting requirements
    
       Everyone with 'write' access to WG document status information
       SHOULD be able to obtain a summary display of all status changes
       made to the WG documents they are responsible for, from the present
       time backwards, split by pages, after successfully logging-on to the
       Datatracker. (R-101)
    
    Is there any reason why this information is only accessible to people with
    "write" access? One great advantage of the existing datatracker is that
    information about a document is visible to everyone (including all history),
    although there is a way to mark certain things as "private" (not visible to
    others). 
        
  7. Alexey Melnikov: Comment [2010-08-15]:
    1) 4.2. For IETF Working Group Chairs
    
       When an IETF WG Chair needs to input or update the WG status of an
       I-D in one of his or her WGs, the WG Chair SHALL be required to log-
       on to the Datatracker using a personal user-id and password (e.g.,
       an IETF tools password) in order to gain 'write' access. (R-015)
    
     [...]
    
      - SHALL be able to designate one or more people to act as delegates
        to input and update the WG status of the I-Ds associated with their
        WGs; (R-020)  The identifier for each delegate should be the
        person's e-mail address; (R-021)
    
    I think it would be a good idea to clearify the relationship between a user-id
    and an email address. Currently each user-id is an email address, but the text
    above seem to be implying that some kind of mapping might be possible.
    This also
    affects other sections (e.g. 4.3).
    
    2) 4.3. For Delegates of IETF WG Chairs
    
       The Datatracker SHOULD alert the WG Chairs, the IETF Secretariat,
       and the newly designated delegate via e-mail if a person who is
       newly designated to be a delegate of a WG Chair does not have a
       personal user-id and password to log-on to the Datatracker. (R-029)
    
    What about showing this information to the WG chair when he/she adds a delegate
    in the datatracker's web interface?
    
    3) 5.1. WG Document States
    
       The Datatracker SHALL allow WG Chairs and their delegates to select
       the next state for an I-D from one of the 'most likely' next states
       described in Requirement R-035, or from any of the other WG document
       states (per Requirement R-017) if needed. (R-039)
    
    Why not just say that any state transitions are allowed.
    If the intent of the
    wording is to show that there should be an easy way to select one of the 'most
    likely' states, then that should be stated explicitly.
    
    4) 5.3. WG Document Protocol Write-ups
    
       IETF WG Chairs and delegates may designate themselves to act as the
       Document Shepherds for some or all of the I-Ds in their own WGs.  In
       the WGs where this happens, the Datatracker SHOULD ask the WG Chairs
       and delegates which role they are playing when the log in, in order
       to display the most appropriate user-interface for that role.
       (R-053)
    
    Speaking as an individual, I would dislike an interface that is forcing me to
    act in a particular role without allowing me to change the role. In particular I
    am hoping that once a role is selected, it can be changed without the need to
    logout and login again.
    
    5) 6.1. Candidate WG Document
    
       The Datatracker SHALL allow an IETF WG Chair or delegate to identify
       an I-D as a "Candidate WG Document" in her or his WG if the I-D has
       not yet been adopted by any IETF WG, is not expired and has not been
       withdrawn or replaced by another I-D. (R-054)  The Datatracker
       should not allow a document that is expired, withdrawn, replaced or
       already adopted by an IETF WG to be moved into the "Candidate WG
       Document" state.
    
    I am slightly concerned about not allowing a replaced document to be used as a
    "Candidate WG Document". Sometimes documents get forked, or a document which was
    once replaced by another one might be abandonned by the WG. It should be
    possible to use such documents elsewhere.
    
    6) 6.1. Candidate WG Document
    
       When Requirements R-056 and R-057 are met, the Datatracker SHALL
       display the WG status of the I-D as follows: "Candidate WG Document
       in (name of IETF WG)". (R-058)
    
    I hope you didn't mean that the status should be presented exactly in the form
    shown above.
    
    7) 6.3. Not Adopted by a WG
    
       Notwithstanding the aforementioned, a different IETF WG may decide
    
    I think the same WG should also be allowed to adopt the document later on.
    I suggest dropping the word "different" above.
    
       to adopt an I-D after it has entered the "Not Adopted by a WG"
       state.  The Datatracker SHALL allow a WG Chair or delegate to move
       an I-D that is in the "Not Adopted by a WG" state into the "Adopted
       by a WG" state if the I-D has not expired, been withdrawn, or been
       replaced by another I-D. (R-075)
    
    8) 6.4. WG Document
    
       The Datatracker SHALL allow WG Chairs and their delegates to move an
       I-D into the "WG Document" state from a different document state as
       defined in Section 3.3 of [WGDRAFTS] if the I-D has not expired,
       been withdrawn or replaced by another I-D. (R-079)
    
    Just to double check: this would allow to adopt a draft as a WG document,
    without renaming it?
    I think that would be useful.
  8. Tim Polk: Discuss [2010-08-26]:
        (Consistent with Robert's issue #1)
    
    The processing described in the Candidate WG Document state adds a lot of
    formality that are not currently
    practiced by most IETF working groups, and
    don't seem to be supported by 2026.  Is a datatracker requirements
    draft the
    place to institute new process requirements? 
        
  9. Tim Polk: Comment [2010-08-26]:
    [WGDRAFTS] does not define withdrawn.
    
    I share Lars' concerns regarding 4.2, paragraph 7, 9 , and 11.  I am not sure I
    agree with his analysis, but
    this text deserves some discussion!
  10. Robert Sparks: Discuss [2010-08-24]:
        
    1) Where this document is capturing requirements to facilitate WG tracking
    using
       processes that WG chairs are already exercising I think it's on track.
    I believe
       it and it's companion state document are going going further than
    that in 
       with the definition of the Candidate WG document and Not Adopted by
    a WG states
       and the behavior required not just of the tool but of the chairs
    by this document.
       Attempting to define a new process and codify it into a
    tool at the same time seems
       risky. I would prefer to see the requirements
    around tracking a document before WG
       adoption split into a separate effort,
    both in determining requirements and implementing
       the tool. (It would be even
    better if there was experience with the suggested process -
       an interested
    chair and cooperative AD could do this now with the comments field in the
    existing tracker.) Our initial effort should be scoped to helping WG chairs and
    other 
       stakeholders track what they already do.
    
    2) R-003 can be read to mean that every IETF Stream document SHALL be tracked
    using this tool,
    contradicting R-001. I suggest that the first part of the
    requirement be rephrased thus:
    
      When the WG status of an IETF Stream I-D is tracked, the Datatracker SHALL use
    the
      WG document states ...
    
    3) Why is R-012 SHOULD and not MUST?
    
    4) There are a couple of places (For instance R-021) where a design decision is
    being
    made (probably the right decision, but I'm not sure this is the tool to
    make that 
    decision with)- there are people now with exising datatracker/tools
    logins whose login name
    does not look like an email address. This decision will
    force delegation to them to be through
    an email address _associated_ with the
    login. MANY people with datatracker logins have more than
    one email address.
    Could we remove this bit of design? If not, can we acknowledge that
    people may
    have more than one email identifier?
    
    5) The delegation requirements in 4.2 seem to be written from the viewpoint of a
    chair
    delegating authority for all of the documents in the working group. Why
    are they not
    written so that delegation is done on a per-document basis (in the
    spirit of R-012)?
    
    6) R-054 (also touched in Alexey's comments) imply that someone must logout to
    change
    roles. If that was the intent, it should be made explicit.  I hope that
    was NOT the 
    intent and I think we need an additional requirement that a login
    that can serve 
    multiple roles be allowed to change roles on demand without
    logging out.
    
        
  11. Robert Sparks: Comment [2010-08-24]:
     
    Early in the conventions section: There are instances of individual drafts
    being adopted 
    by working groups that don't get renamed -ietf-.
    
    R-020 - is it worth calling out in the requirement that one of the delegates may
    also have
    other roles (like being the chair of another WG, or being an AD of
    another area). It might
    also help the implementer of these requirements if you
    made a forward reference to R-033 
    here. (btw - R033 is showing some edititis -
    it's referring to itself as if it were somewhere
    else.
    
    I have concerns with the process being proposed around the pre-WG adoption
    states and the
    mechanics associated with them. I'm capturing a couple of them
    here as a comment, but in
    general I think the proposal needs additional
    discussion before codifying it into a tool.
       - Many working groups consider
    all documents that fall within their scope candidates 
         for adoption. Is the
    goal here to focus attention on documents a chair plans to
         issue a call for
    adoption on? If so, a chair can do that with email, and I don't
         see the
    benefit tracking this state brings. I _can_ see this introducing pressure
    on chairs to "bless" documents ahead of time, and becoming a breeding ground for
    process confusion (similar to the must-bar-bof-twice misconception that has been
    recently raised)
       - What is the point of the "Not adopted by a WG state"? If
    it was to help push back
         against proposal replay attacks? If so, I think
    just having a way to capture that
         a group was asked to adopt a document and
    declined would be just as powerful and
         would be far less complex to
    implement. (The tool could present the chair with
         a button that put a chunk
    of well-known, searchable, text into a comment for example).
  12. Sean Turner: Discuss [2010-08-25]:
        Updated to remove #3, but I retained the numbering.
    
    Great document.  Just a couple of things I'd like to clear up:
    
    #1) R-008: Why isn't the time-stamp and identification of the person who made
    the change a MUST?  On a tangential note, maybe we should be tracking exactly
    who it is who did the submission.  This information might be useful.
    
    #2) R-20: Should we limit the number of delegations allowed per-WG?  Can we pick
    an upper bound of say 3 people per WG that aren't WG chairs?
    
    #3) Resolved.
    
    #4) R-035: When would the datatracker not show the state etc after logging on? 
        
  13. Sean Turner: Comment [2010-08-11]:
    #1) R -019 r/(e.g., IANA status, RFC-Editor status, IESG status;/(e.g., IANA
    status, RFC-Editor status, IESG status);
    
    #2) R-020/025 Should the should be SHOULD: The identifier for each delegate
    should
    
    #3) R-022 r/for the different/the different
    
    #4) R-033: each IETF AD SHALL have the privileges specified
       in Requirement R-033 for every WG in his or her Area (R-033)
    
    I'm having trouble parsing this one.  Is it meant to be recursive?
    
    #5) Page 12: The "a" is extra perhaps: for adoption in a their IETF WG without
    
    #6) R-073/094: Should the shall be SHALL?
    
    #7) Sec 6.3 last para: r/draft-IETF-/draft-ietf-
    
    #8) Sec 6.5: Should we add a default value for the length of the WG LC?

draft-ietf-proto-wgdocument-states

  1. Lars Eggert: Discuss [2010-08-23]:
          DISCUSS-DISCUSS: The title and abstract claim this document describes
      datatracker states. Reading the text, it's clear that the document
      also describes transitions between states, and this is where my rub is
      with the document: it's neither complete in describing these
      transitions, nor does it IMO necessarily characterize the possible or
      even typical transitions very accurately. (For example, starting
      Section 3.2.3 by saying that "IESG Evaluation is another state that
      may cause an I-D to be  sent back to an IETF WG for revision" really
      paints an incorrect picture of the common case.)
    
      DISCUSS: It seems that the model here is that three state machines
      exist: one for document availability (active/expired/replaced), one
      for the IESG, and one for the WG. The result is that a given document
      is in a specific state in all of these three state machines. This is
      not at all clearly explained in the document, it talks about the
      states of all three state machines interchangeably, which is really
      confusing. A clear overview with some diagrams would help a lot.
      (Section 3.4 has some of this, but much too late.)
    
    Section 3.3.1., paragraph 4:
    >        b) an I-D that the WG Chair asked an author to write;
    
      DISCUSS: I disagree that this makes an ID a candidate WG document.
    
    Section 3.3.2., paragraph 0:
    >   3.3.2. Adopted by a WG
    
      DISCUSS: We don't need this state. It's equivalent to applying "WG
      Document" to an individual ID.
    
    Section 3.3.4., paragraph 0:
    >   3.3.4. Adopted for WG Info Only
    
      DISCUSS: I don't think we need this state, it's equivalent to "WG
      Document" that never progress (or eventually progress to "Withdrawn".)
    
    Section 3.3.5., paragraph 0:
    >   3.3.5. Not Adopted by a WG
    
      DISCUSS: What purpose does this state serve other than to shame
      authors?
    
    Section 3.5.4., paragraph 0:
    >   3.5.4. Awaiting External Review / Resolution of Issues Raised
    
      DISCUSS: Because "external" really means "external to the WG", this
      state subsumes states 3.5.1, 3.5.2 and 3.5.3. Review-team specific
      states are not a good idea; for example, you'd immediately need to add
      "MIME Types Review", "URL Team Review", "TSV Directorate Review", etc.
      etc.
    
    Appendix A:, paragraph 1:
    >    This Appendix describes the status information currently stored in
    >    the IETF Datatracker tool for every I-D submitted to the IESG for
    >    publication.  Most of the terms and definitions herein are as in
    >    [IESGSTAT].
    
      DISCUSS: These definitions should be identical to [IESGSTAT], because
      it is not the purpose of this document to redefine what those states
      mean. If the descriptions in [IESGSTAT] can be improved, let's make
      the changes there, please.
     
        
  2. Lars Eggert: Comment [2010-08-23]:
    Section 2., paragraph 1:
    >    The phrase "working group document" is to be interpreted as being
    >    synonymous with "working group I-D".  The same is true for the
    >    plural case of each phrase.
    
      You probably want to add that a "working group I-D" is an I-D that has
      gotten consensus for adoption as a work item by a WG (compared to
      individual ones, that have not or not yet).
    
    Section 3.1.3., paragraph 3:
    >       - The filename of an individual I-D that is being considered for
    >         adoption by an IETF WG will typically include the name of its
    >         author (e.g. 'draft-author-wgname-topic-nn').  If the I-D is
    >         adopted by a WG, its filename will change to 'draft-ietf-
    >         wgname-topic-00', and the Datatracker will describe the older
    >         individual I-D as having been "Replaced by" a newer WG I-D.
    
      It may be useful to add that "replacing" an ID in this form currently
      requires an explicit request by the WG chair. Without that request,
      the IDs will coexist and the individual one will eventually expire.
    
    Section 3.2., paragraph 0:
    > 3.2. IESG Document States
    
      The state definitions below are sightly different in wording than in
      [IESGSTAT] and in Appendix A. This is confusing.
    
    Section 3.2.3., paragraph 0:
    >   3.2.3. IESG Evaluation
    
      Suggest to swap the order of the two paragraphs.
    
    Section 3.3., paragraph 0:
    > 3.3. Working Group Document States
    
      It would be good to make this a new top-level section, because unlike
      Sections 3.1 and 3.2, which were replicated for information and not
      new, this *is* the new stuff.
    
    Section 3.3., paragraph 1:
    >    This section describes new states to be added to the Datatracker to
    >    make it possible for IETF WG Chairs and/or their delegates to
    >    indicate the status of I-Ds associated with their working groups.
    
      What delegates? Secretaries?
    
    Section 3.3., paragraph 2:
    >    WG Chairs will have the option to use some, all or none of these WG
    >    document states to describe the status of some, all or none of the
    >    I-Ds associated with their WGs.
    
      Don't we want to recommend that they should use them for all of their
      documents though?
    
    Section 3.3.1., paragraph 6:
    >      Note that a document author may "shop" an I-D to multiple working
    >      groups hoping to get the I-D adopted somewhere.  In order to track
    >      this, the Datatracker will be enhanced to enable an I-D to be in
    >      the "Candidate WG Document" state in more than one WG at a time.
    
      This sounds like we want to encourage shopping. Shouldn't the focus
      here be on adding functions that alert us to cases where shopping
      happens?
    
    Section 3.3.3., paragraph 3:
    >      Every "WG Document" should have an "intended maturity level" (e.g.
    >      Informational, Proposed Standard, Experimental) associated with it
    >      as described in Section 3.6.  This information is often requested
    >      by IETF participants and it is now required by the IESG for every
    >      I-D that is submitted to the IESG for publication.
    
      Not relevant for the purposes of this document.
    
    Section 3.3.6., paragraph 0:
    >   3.3.6. Parked WG Document
    
      Not clear if we need this state. Also, what it exactly means is
      unclear - does "parking" prevent a document from becoming expired?
    
    Section 3.3.7., paragraph 0:
    >   3.3.7. Dead WG Document
    
      How is this different from a "WG Document" that is "Expired"?
    
    Section 3.4., paragraph 0:
    > 3.4. Working Group Document State Diagram
    
      This section/diagram should really come before the detailed state
      descriptions earlier in Section 3.
    
    Section 3.6., paragraph 0:
    > 3.6. Intended Maturity Level of WG Documents
    
      Sure, but this document is supposed to be on ID states.
    
  3. Adrian Farrel: Comment [2010-08-26]:
    Many thanks for taking on this important work. Just a few Comments
    that you might consider as the I-D goes forward.
    
    I feel there is some confusion between "state" and "status" (for
    example, in the Abstract). This is handled in
    draft-juskevicius-datatracker-wgdocstate-reqts which says:
    
       The phase "WG status of an I-D" is to be interpreted as referring to
       the WG document state that an I-D is in, as defined in Section 3.3
       of [WGDRAFTS].  This phrase does not refer to an I-D's availability
       status (e.g. "Expired", "Active") as described in Section 3.1 of
       [WGDRAFTS], or the IESG state used by IETF Area Directors (ADs) to
       describe the status of an I-D they may be evaluating.
    
    I feel it would be helpful to use the same language in both documents.
    
    ---
    
    Section 3.1.2
    
         An "Active" I-D is a document that is not expired.
                                                                            
    In fact, an I-D that is an RFC, is not "Active". Ditto other states.
    
    ---
    
    Some inconsistency of "WG" and "IETF WG" that implies a difference of
    meaning that does not exst.
    
    ---
    
    Section 3.2
    
    Not quite sure of the purpose of this section.
    
    It seems to me that "In Last Call"and "Waiting for AD Go-ahead" are
    also key states for interaction with the document authors.
    
    "AD is Watching" and "Dead" also seem to be pretty closely related to 
    the authors.
    
    ---
    
    Figure 1
    
    I know this is showing common transitions only, but I suspect you should
    show the arrow between "Candidate WG Document" and "Not Adopted be a WG"
    as double-headed.
  4. Alexey Melnikov: Comment [2010-08-14]:
    I am in favor of publishing this document, as it would help to be transparent in
    WG processes.
    
    I am agreeing with Sean's comments. Additionally, I have some comments of my
    own:
    
    1) 3.3.3. WG Document
    
         Every "WG Document" should have an "intended maturity level" (e.g.
         Informational, Proposed Standard, Experimental) associated with it
         as described in Section 3.6.  This information is often requested
         by IETF participants and it is now required by the IESG for every
         I-D that is submitted to the IESG for publication.
    
    I would like to point out that frequently the "intended maturity level" is
    decided quite late in the WG process. So I want to make sure that this
    information is not required early on.
    
    2)  3.3.8. In WG Last Call
    
         A document in this state should remain "In WG Last Call" until the
         WG Chair moves it to another state.  The WG Chair may configure
         the Datatracker to send an e-mail after a specified period of time
         to remind or 'nudge' the Chair to conclude the WGLC and to
         determine the next state for the document.
    
    Personally I prefer the way how IETF LCs work: IETF LC lasts for a specified
    period of time, after which the document automatically moves to "Waiting for AD
    Go-Ahead" state. I think the same should happen to documents in WGLCs.
    
    3)  3.3.10. WG Consensus: Waiting for Write-Up
    
         A document in the "WG Consensus: Waiting for Write-Up" state has
         essentially completed its development within the working group,
         and is nearly ready to be sent to the IESG for publication.  The
         last thing to be done is the preparation of a protocol write-up by
         a document shepherd.  The IESG requires that a document shepherd
         write-up be completed before publication of the I-D is requested.
    
    This might be an abuse of process, but I don't think write-up is always required
    when publication is requested. I sent several documents to IETF LC without a
    write-up, I think this should be allowed.
    
    4) A.1.2. Publication Requested
    
       A formal request has been made to advance/publish the document,
       following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the
       request could be from a WG Chair, or from an individual.  Note: the
       Secretariat (iesg-secretary@ietf.org) is copied on these requests to
       ensure that the request makes it into the Datatracker.
    
    I don't think sending this to Secretariat is a requirement. All documents I've
    sponsored I entered into datatracker myself. So I suggest inserting the word
    "typically" before "copied".
    
       A document
       in this state has not (yet) been reviewed by an Area Director nor
       has any official action been taken yet, other than to note that its
       publication has been requested.
  5. Tim Polk: Discuss [2010-08-25]:
        (a) Section 3.1
    
    The document state withdrawn is listed but is not defined and no reference is
    given.  "Withdrawn" is not supported
    in the old tracker, so I have no idea what
    is intended.
    
    (b) 3.1.3. Replaced
    
    I have seen a number of cases where a single document was replaced by three or
    four documents.  I suspect that
    the reverse situation (where multiple documents
    are replaced by one) also exists. The text in this section implies
    that the
    replacement is always one-for-one.
    
    (c) This one is a discuss-discuss.  I am not requesting any change, but do want
    to see some discussion of this
    concept
    
    3.6. "Intended Maturity Level of WG Documents" suggest that every wg document
    should indicate the intended 
    maturity level.  This is a decision that the wg
    often makes at a later stage in the process (before or during WG LC).
    Making the
    decision early may not be a good idea - the editor may regard that as a
    contract.  Was the idea of an
    "undecided"maturity level considered? 
        
  6. Tim Polk: Comment [2010-08-25]:
    (a) In 3.3.1
    
    OLD
          b) an I-D that the WG Chair asked an author to write;
    NEW
          b) an I-D that the WG Chair asked an author to write specifically
          for consideration as a WG draft;
    
    (b) I support Lars' discuss on section 3.3.5. Not Adopted by a WG
    
    (c) Figure 1
    There should be a line from WG LAST CALL to WG document.  A chair
    may decide that Last Call failed, and
    send the document back to the working for
    extensive discussions.  As drawn, any document that goes into Last Call
    has to
    go to the IESG before it can then be returned to the working group.
  7. Robert Sparks: Discuss [2010-08-24]:
        I think the proposal for a process to track documents before WG adoption should
    be split
    into a separate effort. This is coupled to a discuss point on the
    tracker requirements document
    copied here for convenience:
    
      Where this document is capturing requirements to facilitate WG tracking using
    processes that WG chairs are already exercising I think it's on track. I believe
    it and it's companion state document are going going further than that in
    with the definition of the Candidate WG document and Not Adopted by a WG states
    and the behavior required not just of the tool but of the chairs by this
    document.
       Attempting to define a new process and codify it into a tool at the
    same time seems
       risky. I would prefer to see the requirements around tracking
    a document before WG
       adoption split into a separate effort, both in
    determining requirements and implementing
       the tool. (It would be even better
    if there was experience with the suggested process -
       an interested chair and
    cooperative AD could do this now with the comments field in the
       existing
    tracker.) Our initial effort should be scoped to helping WG chairs and other
    stakeholders track what they already do. 
        
  8. Sean Turner: Comment [2010-08-11]:
    #1) Sec 3.3.7 and Figure 1: If a document is dead to the WG, then can the author
    take it to another WG and begin the shopping process all over again?
    
    #2) Sec 3.5: Should we add "Awaiting Media-Type Review / Resolution of Issues
    Raised" or more generally "Awaiting Expert Review" for any I-D that affects an
    IANA registry?
    
    #3) Sec 3.6: Is it "Standard" or "Internet Standard"?  The title of section
    4.1.3 of 2026 is the later.   2026 also uses the phrase when describing STDXXX.

draft-turner-suiteb-cmc

  1. Alexey Melnikov: Comment [2010-08-15]:
    5.1. RA Processing of Requests 
    
       RAs conforming to this document MUST ensure that only the permitted 
       signature, hash, and MAC algorithms described throughout this profile 
       are used in requests; if they are not, the CA MUST reject those 
    
    s/CA/RA ?
    
       requests.  The RA SHOULD return a CMCFailInfo with the value of 
       badAlg [RFC5272]. 
    
    6.1. CA Processing of PKI Requests 
    
       When processing end-entity generated SignedData objects, RAs MUST NOT 
    
    s/RAs/CAs ?
    
       perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) 
       certificate extension [CCC] processing.

draft-livingood-woundy-congestion-mgmt

  1. Jari Arkko: Comment [2010-08-25]:
    A review by Ari Keranen:
    
    There's some repetition especially in section 7. For example, the following
    sentence is there twice:
    
       As a
       result, the congestion management system measures the traffic
       conditions as observed by each CMTS, and applies any policy actions
       to traffic on a specific interface of a CMTS (rather than some other,
       more distant segment of the network).
    
    The described approach may have at least one problem: given that there is a
    "fixed" limit (e.g., 70% utilization for 15 minutes) after which user enters the
    Extended High Consumption State (EHCS), it gives users incentives to linger just
    below the limit (e.g., 100% utilization for 14.5 minutes and 60% for 30
    seconds). Even if the limits would be unknown to subscribers, the user could try
    to probe them and try to stay just below the probed limit and thus get a bigger
    share of the congested link than users not doing that.
    
    Instead, if the user could be partially in ECHS, depending on the utilization
    after some threshold, there would not be such incentives. For example, after
    using 80% of the link for 15 minutes (or 100% for 5 minutes), one third of the
    packets would be marked BE, or for 90% utilization for 15 minutes, two thirds of
    the packets would be BE, etc. This approach would also prevent the oscillation
    problem.
    
    In section 7.3 it is mentioned that (in theory) BE traffic might not be
    delivered at all in case of high link utilization. Wouldn't it be better to
    deliver BE packets just with (much) lower probability?
  2. David Harrington: Comment [2010-08-23]:
    in 3.7, any device controlled by Comast? or any device?
    

draft-azinger-additional-private-ipv4-space-issues

  1. Jari Arkko: Discuss [2010-08-25]:
        This is a very much needed document. The document is on the right track,
    but falls short on a couple of aspects. I would like to recommend
    revising the document once before we approve it.
    
    My main concern is that in my recollection the IETF made a very clear
    decision. All the discussion pointed to saying "no" for any new
    address space allocation for private addressing. There were numerous
    arguments why this is the right course of action. However, the document
    falls short of actually stating this. The document needs to say clearly
    that the IETF recommends against new private address space allocations.
    
    A couple of other issues:
    
       It is not always
       possible to rely on CPE devices using any particular range, however.
       In some cases this means that CPE devices can use unallocated address
       space or address space allocated to other network operators.
    
    I have heard of operators running on unallocated address space, but
    never of CPEs. CPEs may default to different values with the RFC 1918
    range of course. (Though when we talked about this in OPSAREA a couple
    of IETFs ago Dave Tahler pointed out that majority if not all new 
    equipment defaults to 192.168/16.) But CPE that defaults to unallocated
    or someone's address space? Really? Do we have evidence of this from the
    field?
    
    In any case, the document does not describe what is the key problem
    for the CPE: having a *different* address range than the service provider
    network has.
    
       Using unique, globally scoped IPv6 unicast addresses is the preferred
       option as it removes any concerns about address scarcity.  In some
       cases implementing a new network protocol on a very large network
       takes more time than is available, based on network growth and the
       proportion of private space that has already been used.
    
    It would be good to mention already here that some ways of allocating
    new address space on the IPv4 side would result in equivalent 
    implementation/deployment issues (such as updating all routers and
    hosts across the Internet to not drop 240/4).
    
    I would also like to see Thomas Narten's comment on peer-to-peer
    addressed (see below for a copy of his review).
    
    Finally, I think the section that talks about address sharing
    across multiple subscribes is probably a little too simplified.
    Note that the IETF already has ongoing work about such mechanisms
    (e.g., dual stack lite which implements a CGN to share addresses).
    I think the true driver behind new private address space is that
    the service providers do not want "new" solutions (such as IPv6,
    dual stack lite) but rather want to keep existing customer NATs
    and add one of their own. 
        
  2. Jari Arkko: Comment [2010-08-25]:
    Thomas Narten's review:
    
    Overall, I think the document is useful, but another pass would be
    good. My review comments below.
    
    Thomas
    
    > >    any Internet registry.  Very large networks can find that they need
    > >    to connect more interfaces than the number of addresses available in
    > >    these three ranges.  It has occasionally been suggested that
    
    better:
    
        Very large networks can find that they need to number more device
        interfaces than there are available addresses in these three
        ranges.
    
    > >    these three ranges.  It has occasionally been suggested that
    > >    additional private IPv4 address space should be reserved for use by
    > >    these networks.  Although such an action might address some of the
    > >    needs for these very large network operators it is not without
    > >    consequences, particularly as we near the date when the IANA free
    > >    pool will be fully allocated.
    
    This document should (probably) say that the question of reserving
    more private space is out of scope and not adddressed by this
    document.
    
    > >    The address space set aside in [RFC1918] is a finite resource which
    > >    can be used to provide limited Internet access via Network Address
    > >    Translation (NAT).  A discussion of the advantages and disadvantages
    > >    of NATs is outside the scope of this document.  Nonetheless, it must
    
    But at least provide references  to some of the documents that do
    discuss that... I think the IAB has authored 2..
    
    > >    others.  For instance, it is often technically feasible to use NAT or
    > >    even multiple layers of NAT within the networks operated by
    > >    residential users or corporations where peer to peer communication is
    > >    not needed.  Where true peer to peer communication is needed or where
    
    This is too simplistic. Its not just peer-to-peer. More like if only
    clients (and no servers) are behind the NAT. This document is likely
    to have problems trying to summarize the pros/cons of NAT. Can't you
    just point to some other document and move on?
    
    I particularly object to the word "often" above. It all depends on
    what you are doing, and "often" suggests it mostly works.
    
    > >    In many cases it is possible to use multiple layers of NAT to re-use
    > >    parts of the address space defined in [RFC1918].  It is not always
    
    Again, "in many cases" sets the wrong tone, IMO.
    
    > >    In some cases this means that CPE devices can use unallocated address
    > >    space or address space allocated to other network operators.  In
    
    "can use" is a very positive tone and suggests this is a good idea or
    acceptable. Please rephrase.
    
    > >    Another option is to share one address across multiple interfaces and
    > >    in some cases, subscribers.  This model breaks the classical model
    > >    used for logging address assignments and creates some risks
    > >    [CLAYTON].  This concept is more fully explored in [FORD].
    
    how can using the same address by multiple susbcribers work? How do
    you make routing work?
    
    > > 4.1.  Unique Globally Scoped IPv6 Unicast Addresses
    > > 
    > >    Using unique, globally scoped IPv6 unicast addresses is the preferred
    > >    option as it removes any concerns about address scarcity.  In some
    > >    cases implementing a new network protocol on a very large network
    > >    takes more time than is available, based on network growth and the
    > >    proportion of private space that has already been used.  In these
    > >    cases, there is a call for additional private address space that can
    > >    be shared by all network operators.  [DAVIES] makes one such case.
    > >
    
    This section needs work. Deploying IPv6 is not a simple solution for
    someone running out of IPv4 space. What about providing backwards
    compatability with IPv4?
    
    What might be best is to just say that moving to IPv6 is the best long
    term solution, but in the short term having IPv4 is probably still a
    requirement. And that this document just focusses on IPv4.
    
    Making it sound like you can just move to IPv6 as a solution is silly
    and not helpful.
    
    Also, I'd put 4.1 and 4.2 into their own section that focusses on IPv6
    issues. These are the only 2 subsections that talk about IPv6, I
    believe.
    
    > >    cost.  However, it is unlikely to become available in large
    > >    contiguous blocks and this would add to the network managment burden
    > >    for the operator.
    
    You might want to explain what the increased burden is. ALso, you
    don't say how much of a burdon this would be. Presumably, running out
    of usable space is a bigger burden to have to deal with...
    
    > >  For these reasons, address transfers will not be
    > >    an attractive proposition to many large network operators.
    
    This is just the author's opinion. Better to say something more like:
    
      For these reasons, address transfers will likely provide only
      limited help to many large network operators.
    
    And, BTW, what is "large"?  
    
    > > Leases
    > >    might not be attractive to some organizations if both parties cannot
    > >    agree a suitable length of time.  Also, the lessor might worry about
    > >    its own unanticipated needs for additional IPv4 address space.
    
    I think the above can be dropped. There are many issues that would
    impact the viability of such an approach. You only mention a couple,
    and I'm not sure they are even the important ones.
    
    > > 4.4.  Using Unannounced Address Space Allocated to Another Organization
    > > 
    > >    Some network operators have considered using IP address space which
    > >    is allocated to another organization but is not publicly visible in
    > >    BGP routing tables.  This option is very strongly discouraged as the
    > >    fact that an address block is not visible from one view does not mean
    
    Just "strongly discouraged?" Shame on you! This should not be
    recommended at all, as it can lead to interoperability problems to
    sites that legitimately own that space. (You start to mention them
    later.)
    
    > >    queries, traceroute output and other ways.  The ambiguity this causes
    > >    is problematic for multiple organizations.  This issue is addressed
    > >    in [RFC3879], section 2.3.
    
    "is addressed" is wrong wording. I think you mean to say that this
    issue is discussed in more detail on that section....
    
    > >    It is also possible that the registrant of the address block might
    > >    want to increase its visibility to other networks in the future,
    > >    causing problems for anyone using it unofficially.  In some cases
    > >    there might also be legal risks involved in using address space
    > >    officially allocated to another organization.
    
    It's not just if it is announced publically, also happens if the
    network interconnect privately...
    
    > > 4.5.  Unique IPv4 Space Registered by an RIR
    > > 
    > >    The policy framework shared by the RIRs does not discriminate based
    > >    on what an address is used to do, just on how efficiently the
    > >    assigned addresses are used.
    
    Please just say: RIR policies allow organizations to get public space
    even if the addresses will only be used for internal purposes.
    
    > > Unique IPv4 addresses registered by an
    > >    RIR are potentially available to organizations whose networks have
    > >    used all the addresses set aside in [RFC1918].
    
    This makes it sound like you have to first use up your addresses
    before going to an RIR. That is not true and should be made more
    clear.
    
    > > Nonetheless, network
    > >    operators are naturally disinclined to request unique IPv4 addresses
    > >    for a purpose that could be met with private addresses were it not
    > >    for the size of the network because addresses assigned in this way
    > >    are not available for anyone else to use and so their registration
    > >    denies them to new entrants, including potential customers.
    
    I don't quite understand what this is trying to say...
    
    > >    It is be possible to re-designate a portion of the current global
    
    s/be///
    
    > >    When considering re-designating a portion of the current global
    > >    unicast IPv4 address space as private unicast address space it is
    > >    important to consider how much space would be used and for how long
    > >    it would be sufficient.  Not all of the large networks making full
    > >    use of the space defined in [RFC1918] would have their needs met with
    > >    a single /8.  In 2005, [HAIN] suggested reserving three /8s for this
    > >    purpose while in 2009 [DAVIES] suggested a single /10 would be
    > >    sufficient.  There does not seem to be a consensus for a particular
    > >    prefix length nor an agreed basis for deciding what is sufficient.
    > >    The problem is exacerbated by the continually changing needs of ever
    > >    expanding networks.
    
    Actually, there has not been consensus to reserver *any* additional
    space. The above should say that clearly. Saying we just haven't
    agreed on the size is misleading.
    
    Hmm. this document just ends without a summery or recommendation. That
    doesn't seem right...
  3. Ralph Droms: Discuss [2010-08-26]:
        This position is mostly a discuss-discuss; I'd like to discuss some of the basic
    premises from which the doc is written.
    
    I don't see any acknowledgments of review by or input from other stakeholders
    like service providers, wireless operators, etc.  I've asked John Brzozowski
    (Comcast) for his comments, which he expects to send to me by Sep 3.
    
    In my opinion, the document is not clear on the distinction between RFC 1918
    addresses used to number "internal" interfaces, which are only used for internal
    communication, and addresses used to number "subscriber" interfaces, which need
    global access.  So, for example, in section 3:
    
       The address space set aside in [RFC1918] is a finite resource which
       can be used to provide limited Internet access via Network Address
       Translation (NAT).  A discussion of the advantages and disadvantages
       of NATs is outside the scope of this document.  Nonetheless, it must
       be acknowledged that NAT is adequate in some situations and not in
       others.  For instance, it is often technically feasible to use NAT or
       even multiple layers of NAT within the networks operated by
       residential users or corporations where peer to peer communication is
       not needed.
    
    unless the operator is using RFC 1918 address space for subscriber devices
    (e.g., HGW, host, mobile device), I don't see how this text is relevant to RFC
    1918 address space exhaustion.
    
    A little farther along in section 3:
    
       Another option is to share one address across multiple interfaces and
       in some cases, subscribers.  This model breaks the classical model
       used for logging address assignments and creates some risks
       [CLAYTON].  This concept is more fully explored in [FORD].
    
    This text, if I understand it correctly, talks about sharing a global address
    (not RFC 1918 space) among multiple subscribers, and isn't germane to the
    discussion of RFC 1918 address space exhaustion.
    
    Regarding section 4.2: if the addresses in question are truly site-scoped and
    not routed outside the operator's domain, how is the (probabilistically
    unlikely) prefix clash a problem?  Is the use of IPv6 ULAs any more difficult
    than the use of IPv6 GUAs; I don't undertstand the different descriptions for
    the problems listed in sections 4.1 and 4.2.
    
    In section 4.3, are the global addresses in question for use in supplementing
    internal addressing for which RFC 1918 is insufficient?  Is it feasible to
    obtain enough addresses in this way to make significantly more address space
    available than is in 10/8?
    
    In section 5.3:
    
       If additional private address space is not defined and the large
       network operators affected by this problem are not able to solve
       their problems with IPv6 address space or by segmenting their
       networks into multiple routing domains, those networks will need
       unique IPv4 addresses.  It is possible and even likely that a single
       network could consume a whole IPv4 /8 in a year.
    
    Is this projected rate of consumption based on global addresses required for
    subscriber equipment accessing the Internet and (potentially) private addresses
    for numbering internal interfaces?  Do the authors have any data to support
    their claim? 
        
  4. Lars Eggert: Comment [2010-08-23]:
    INTRODUCTION, paragraph 2:
    >                   Additional Private IPv4 Space Issues
    
      Nit: Title can be misunderstood (as in "this doc talks about
      additional issues with regards to private address space.") Maybe:
      "Issues with Assigning Additional IPv4 Private Address Space"?
    
    Section 3., paragraph 0:
    > 3.  Network Address Translation
    
      I wish this section were more clear about the significant downsides
      that multiple levels of NAT have compared to a single level of NAT.
    
    Section 8.1., paragraph 2:
    >    [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
    >               Understanding Concerning the Technical Work of the
    >               Internet Assigned Numbers Authority", RFC 2860, June 2000.
    
      Nit: Unused Reference: 'RFC2860'
    
  5. Adrian Farrel: Discuss [2010-08-25]:
        
    I support this document as a really helpful anchor for discussing an
    important problem space.
    
    My Discuss is around the scope of the problem as expressed in the
    document.
    
    1. I got snarled up with some of the language around "interfaces". My
       initial reaction was to assume that you were talking about interfaces
       as links between routers. These are indentified for use in routing
       protocols, but do not need to be routable entities. Thus, I was 
       surprised not to find any mention of unnumbered interfaces.
       But I suspect you are intending to scope to "interfaces to the
       network" since the text seems to focus on addressable points of
       attachment.
       Could we discuss this and, if I am right in my suspiscions, perhaps
       you could look at how to clrify this in the text.
    
    2. I found the example of VPNs a little uncomfortable (section 2). I
       believe that the VPN technologies developed in the IETF have included
       good precautions to avoid "address clashes" and, while I can believe
       that folk feel uneasy knowing that customer spaces have overlapping
       address spaces, this is not actually a significant risk. 
        
  6. Adrian Farrel: Comment [2010-08-25]:
    
        
  7. David Harrington: Comment [2010-08-23]:
    s/It is be/It is/
    
  8. Russ Housley: Comment [2010-08-26]:
      Some of the references are Internet-Drafts.  These need to be marked
      as work-in-progress.