IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

  1. Roll Call 1133 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. Diameter IKEv2 PSK: Pre-Shared Key-based Support for IKEv2 Server to Diameter Server Interaction (Proposed Standard)
    draft-ietf-dime-ikev2-psk-diameter-08
    Token: Dan Romascanu
    Note: Lionel Morand (lionel.morand@orange-ftgroup.com) is the document shepherd.
    Discusses/comments (from ballot 3771):
    1. Jari Arkko: Discuss [2011-06-23]:
      The document says:
      6.1.1. Ni: "The Ni AVP (AVP Code TBD5) is of type Unsigned32 and contains the IKEv2 initiator nonce."
      6.1.2. Nr: "The Nr AVP (AVP Code TBD6) is of type Unsigned32 and contains the IKEv2 responder nonce."
      However, Section 3.9 of RFC 4306 clearly states that nonces are variable length. How can you carry a variable length nonce in an Unsigned32?
    2. Jari Arkko: Comment [2011-06-23]:
      Regarding other Discusses, I am actually fine with the document otherwise except the above point, and with some documentation of the security assumptions and implications it should be possible to publish it.
      However, I do have one additional concern that should be discussed. I'm not too happy about the decision to leave the PSK generation algorithm outside the scope of this specification. It basically means that there is no interoperability.
    3. Stephen Farrell: Discuss [2011-06-18]:
      (1) The writing here is unclear at critical points, to the point where I find this hard to follow. I would recommend expanding and clarifying the 2nd paragraph of the introduction; e.g. adding a diagram showing the various parties involved in the exchanges; introducing the main use-case for this protocol and defining terms before use - in particular the IKEv2 Server and Peer, HAAA etc. The purpose of the IPsec exchange also needs to be explained. Without this its not really possible (for me anyway) to know if the main potential problem with this spec (sending cleartext keys) is fatal or not.
      (2) This specification calls for sending a symmetric key (realistically , in clear) in Diameter and then using that key to secure an IPsec SA establishment. The set of conditions under which that is a reasonable thing to do (which may be the empty set) need to be identified, but are not. For example, if the Diameter and IKE exchanges share a network segment then this is fairly pointless if there is a MITM.
      (3) (Similar to, but not identical to (2).) Routing the request based on IDi (as an NAI) seems to make it very hard to do that with security, unless there is some way to validate the domain component of the NAI (e.g via a whitelist or some broker). How is this done? If any old IDi/NAI value can be used, then it seems impossible to always setup a secure channel for the return of the key, which implies that the key effectively MUST be returned in clear, which seems unacceptable.
      (4) Sending IDi, Ni and Nr out-of-band of the IKEv2 exchange might lead to new attacks. For example, if I can feed selected Ni,Nr to someone who does crypto on those and gives me the result, then I may get to figure out a secret more easily than planned. Normally in IKE, IDi is only sent encrypted, but that differs here. Has this been analysed? (And where are the results?) If not, it should be.
      (5) What does this mean: "It is strongly RECOMMENDED that the HAAA uses the nonces Ni and Nr received in IKEv2-Nonces AVP to generate the PSK. " Are you changing IKE here? An IKE PSK is not "generated" it just is. (Apologies if I'm missing something here, but IKE's use of EAP is not something with which I'm very familiar.)
      (6) RFC 3588, section 4.5 has an "Encr" colum that is missing in the AVP flag rules here and that is presumably very very important for an AVP named Key. What's up there? Would adding the Encr column with a "Y" for the key be the right thing?
      (7) How does a programmer handle this statement in the draft: "For this reason, this specification strongly recommends using Diameter agents that can be trusted."? I think you have to have a MUST implement and MUST use TLS and that brokers MUST NOT be used if you want the Key AVP to be protected from the HAAA to the requesting node. Anything else needs to be specifically justified.
      (8) IKE_AUTH has an optional IDr field. That doesn't seem to be mentioned here at all. I'd have thought that it ought be in the IKEv2-PSK-Request if it was in the IKE_AUTH message? (I need to check if IDr can occur with an IKEv2 PSK, but seems like it ought be allowed.)
    4. Stephen Farrell: Comment [2011-06-18]:
      I agree with Pete that the last sentence of the abstract needs a rewrite.
    5. Russ Housley: Discuss [2011-06-22]:
      The Gen-ART Review by Ben Campbell on 3-Jun-2011 raised an important interoperability question. Ben pointed out that the the procedure used by the HAAA to generate the PSK is out of scope, but that interoperability cannot occur unless the same one is supported by all parties. The author responded that the PSK generation is important for interoperability, but that the specific PSK generation mechanisms have been intentionally left to other documents. Thus, the Diameter application must define the PSK generation mechanism. Apparently, 3GPP2 has such documents for its community.
      I would like to understand why the IETF is not specifying a mandatory to implement PSK generation mechanism, even if others are allowed. This could be done with a normative reference.
    6. Pete Resnick: Comment [2011-06-17]:
      I am neither an IKE person nor a Diameter person. That said, the following sentence, which appears in the Abstract and Introduction, is completely incomprehensible to me:
      "This document specifies IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre-shared key based authentication."
      If IKE and Diameter people will understand that sentence, you can feel free to ignore me, but I have no idea what that means.
    7. Robert Sparks: Comment [2011-06-22]:
      I support Russ' discuss.
      I also encourage stating more clearly that there is no mechanism for negotiating/detecting which PSK derivation algorithm is in use - that this is entirely manually managed configuration. Is it realistic that this would be run-time configuration, or is it expected that it would be set at manufacture or compile?

    Telechat:

  2. CA Key Rollover in the RPKI (BCP)
    draft-ietf-sidr-keyroll-07
    Token: Stewart Bryant
    Note: Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3777):
    1. Adrian Farrel: Comment [2011-06-21]:
      I have a couple of comments that don't merit a Discuss, but I would be grateful if the authors thought about them and made any necessary changes.
      I found Section 1... "This document defines a conservative procedure" ...ambiguous. I think that "conservative" needs to be qualified in some way. conservative with respect to conserving keys? Not changing keys often? Not requiring many messages? Not risking security?
      There are a couple of uses of SHOULD which I feel would benefit from an explanation of how/why a variation MAY be allowed. In one case, I am relatively sure you mean MUST rather than SHOULD, viz.
      "To perform a key rollover operation the CA MUST perform the following steps in the order given here. Unless specified otherwise each step SHOULD be performed without any intervening delay. The process MUST be run through to completion."
      That is, the variance is already handled by "unless specified otherwise" so there is no further scope for variance.
    2. Stephen Farrell: Comment [2011-06-17]:
      4.1 - is it really wise to encourage (even obliquely) re-use of serial numbers? I'd say s/MAY change/SHOULD change/ there would be better.
      If making that change, it'd be good to say when its ok to re-use serial numbers - that could be when an internal DB design uses certificate.serialNumber as a DB key which may be silly but has been done.
    3. Dan Romascanu: Comment [2011-06-22]:
      1. I agree with Adrian's comment that the term 'conservative' in the introductory section needs to be explained or dropped
      2. The note in the IANA considerations section is for the RFC Editor - doesn't matter too much though as it instructs to take our the null content section.

    Telechat:

  3. DKIM And Mailing Lists (BCP)
    draft-ietf-dkim-mailinglists-11
    Token: Sean Turner
    Note: Barry Leiba (barryleiba@computer.org) is the document shepherd.
    Discusses/comments (from ballot 3822):
    1. Jari Arkko: Comment [2011-06-22]:
      This is a complex topic full of difficult tradeoffs, but the document was a pleasure to read. Thank you for writing it in such a clear manner that it is understandable even by non-email experts.
    2. Ralph Droms: Comment [2011-06-22]:
      One quite minor editorial comment; the rest of the document was well-written and this bit of text stuck out. In Section 3.3:
      "List-specific header fields: [...] Therefore not seen as a concern.
      Was the sentence fragment intended?
    3. Adrian Farrel: Comment [2011-06-22]:
      I also dithered over the BCP/Informational issue. However, the document seems to involve issues of end-to-end service provision where the service is improved by adherence to the guidelines. This takes it over the line into a BCP, IMHO. If the impact of the document was entirely limited to within a single domain, I would say that it should be Informational.
      I did not find the use of RFC 2119 language helpful, and would suggest writing guidelines in English, reserving 2119 language for normative protocol specifications or for emphasis in requirements specs.
    4. Stephen Farrell: Comment [2011-06-15]:
      (1) I think section 5.2 is the "meat" of this basically, so would suggest a forward reference to there from last paragraph of the intro.
      (2) In 2.5 should the 1st "i.e.," really be "e.g.," - that is, are you saying "d=" is the *only* way to identify message streams? If so, then perhaps make that clear. (I just don't recall if there were other good ways. I do recall there being other bad ways:-)
      (3) 5.4 is a bit unclear to me. I suggest just adding an example.
    5. Russ Housley: Comment [2011-06-22]:
      Please consider the editorial comments from the Gen-ART Review by Pete McCann on 6-Jun-2011.
    6. Pete Resnick: Comment [2011-06-22]:
      3.1: "originator: The agent that accepts a message from the author, ensures it conforms to the relevant standards such as [MAIL], and then sends it toward its destination(s). This is often referred to as the Mail Submission Agent (MSA)."
      That definition is incorrect. The originator is not identical to the MSA. My secretary (whose address appears in the "Sender:" field of a message authored by me) is at least part of the "originator", but he is by no means part of the MSA. The MSA is a servce, in MAIL-ARCH terms. The originator is an actor role. I suspect in all of the definitions in this section, there is a conflation of these going on, but originator is the one that is most egrigeous.
      5.1: "However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents this or any standards body might produce. This sort of change will invalidate the signature on a message where the body hash covers the entire message. Thus, the following sections also discuss and suggest other processing alternatives."
      I think the document ought to explicitly say something stronger along the lines of, "MLMs that are DKIM-aware ought to stick to header field additions only and not make changes to headers and footers."
      (Note to IESG: Personally, I wish this document were part of the AS experiment and had even more MUSTs and SHOULDs. I will weep silently in my beer that it is not.)
    7. Peter Saint-Andre: Comment [2011-06-22]:
      This is a fine document. One nit: in Section 1.2, please expand "ADSP" on first use or change "ADSP policies" to something like "DKIM author domain signing practices [ADSP]".
    8. Robert Sparks: Comment [2011-06-21]:
      The 4th paragraph of section 1.2 (beginning "Some MLM behaviors") reads like motivation for starting a draft, rather than documenting the resulting discussion. Please consider updating its perspective or removing the paragraph.

    Telechat:

  4. Textual Conventions for the Representation of Floating-Point Numbers (Proposed Standard)
    draft-ietf-opsawg-mib-floats-02
    Token: Dan Romascanu
    Note: Chris Liljenstolpe (ietf@cdl.asgaard.org) is the document shepherd.
    Discusses/comments (from ballot 3824):
    1. Adrian Farrel: Comment [2011-06-21]:
      Typo:Section 1: s/and for a a/and for a/
    2. Stephen Farrell: Comment [2011-06-17]:
      - A reference to Knuth is always good:-)
      - Some examples would be even better.
    3. Russ Housley: Comment [2011-06-22]:
      I suggest that we remove "None" from the author's address.
    4. Sean Turner: Comment [2011-06-20]:
      <super nit> Section 5 includes a copyright year of 2010. </super nit>

    Telechat:

  5. Location Conveyance for the Session Initiation Protocol (Proposed Standard)
    draft-ietf-sipcore-location-conveyance-08
    Token: Robert Sparks
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3833):
    1. Stephen Farrell: Discuss [2011-06-18]:
      (1) I don't understand the privacy model for the case where a UA does not support this (or has turned it off) and the outbound proxy adds this header. How is the poor end user supposed to know what is happening in this case? What if a user specifically wants to use a UA that doesn't send her location (or have it added) - how could that be supported?
      (2) 4.1 says that SIP intermediaries "are not to view" location information. Why can't that be written with a MUST of some sort? It seems very weak at present. (The same "not to view" is repeated a few times later.) I don't understand what "viewing" means for a piece of software.
      (3) cleared
      (4) If a UA or intermediary inserts a Geolocation or Geolocation-Routing header field, I assume that doesn't get deleted later. So nothing prevents this information "leaking" out beyond the domain/operator who set the field. That means all operators are trusting all operators further down the signalling path with all users location information. Should there be something about deleting these fields at some stage in path? Did the WG consider this aspect?
      (5) There is a MUST for conforming to rfc 3693 that says that you have to follow the rules for retention and re-transmission. A quick look at 3693 seems to imply that that document does not set out rules with which one could conform, but only says those must exist. Am I right there? If so, then where do I go (as an implementer) to find out how to handle retention and re-transmission?
    2. Stephen Farrell: Comment [2011-06-17]:
      (1) Last para of section 3 - SIP intermediaries don't receive diagrams, probably needs a rephrase.
      (2) 3.1: Can Bob use the error code to get Alice to progressively give him more location information? If Alice's LO is "fuzzed" then each iteration might expose more precise information to Bob. If that's likely or possible, it probably deserves a mention in the security considerations. I'd suggest that Alice SHOULD include some kind of limit for repeatedly sending an LO in a short period, if she is fuzzing or similar. (Or maybe even generally - is there ever a real reason to iterate on this 10 times in a few minutes?)
      (3) Same as (3) but for section 3.2 - should the LS have some controls on how often Bob (or anyone) can de-reference the URI?
      (4) Are there a set of rules specified somewhere as to what is required of an LR? The repeated refereences to what is or is not an LR sort of implies there is, but rfc 3693 doesn't seem to contain that. If there are such rules specified somewhere then please add a reference.
      (5) 3.3, 1st para, could do with a bit more explaination of the location based routing case (maybe just as a forward reference or an example). The current text doesn't make it clear who'd be routing what for whom based on the LO.
      (6) I don't understand why GEO-URIs are not appropriate for use here - a sentence explaining why seems warranted.
      (7) What is a RuleMaker and where is that defined? I assume it means something like a telcoms regulator.
      (8) It seems odd to have a MUST not just for rfc 3693 but also for its "updates and successors" - how do you know that that'll be possible?
      (9) It seems odd that appendix A presents requirements but is not referenced in the text of the document at all. What is the status of this? Partly it looks like historic information that the WG used, but nothing says that.
      (10) UAC-7 s/must be met/MUST be met/ ?
    3. Russ Housley: Comment [2011-06-22]:
      Please consider the editorial comments from the Gen-ART Review by Pete McCann on 17-Jun-2011.
    4. Pete Resnick: Comment [2011-06-19]:
      I don't expect any of these to turn into "DISCUSS" comments, but I'd like some explanation to get my head around them:
      - Section 3 (or something similar to it) seems to be something I've seen before in other documents, though I can't figure out where it is I've seen it. Is this information that can be referenced from somewhere else?
      - Section 4.2 says: "The Geolocation-Routing header field satisfies the recommendations made in section 3.5 of RFC 5606 [RFC5606] regarding indication of permission to use location-based routing in SIP."
      My reading of 5606 3.5 is that the indication of "permission" is basically an optimization: That is, it is an indication that using the location is likely to fail and ought be avoided. But 4.2 reads differently, making it out to be some sort of access control mechanism (without any enforcement):
      "...when the Geolocation-Routing header-value is set to "no", if a cid:url is present in the SIP request, intermediaries SHOULD NOT view the location (because it is not for intermediaries to view), and if a location URI is present, intermediaries SHOULD NOT dereference it."
      I'm left wondering what the downside is if an intermediary does view or dereference a location when you've got a "Geolocation-Routing: no". Why is it that the intermediary SHOULD NOT do these things?
      - Sections 4.3. It seems inevitable that 424's will leak back to the originating UA even when the location was inserted by an intermediary (because there will be a badly behaved intermediary that doesn't handle a 424). Should there be any instruction about how a UA should handle (ignore?) a 424 even when it hasn't included location info?
      - Section 4.4. Is "permission reset" an understood term in SIP-land? It wasn't clear to me (though I could guess) how the term "reset" was being used in this context.
    5. Dan Romascanu: Comment [2011-06-21]:
      1. I think that the usage of the term 'SIP modifications' in the title and first paragraph of section 4 is too strong for what this document does. Modifications to SIP would imply updating some previous documents. I suggest replacing 'modifications' by 'extensions'.
      2. section 4.1: "The Geolocation header field can have one or more locationValues. A Geolocation header field MUST have at least one locationValue."
      The first sentence seems to have been made redundant by the second.
      3. "Any locationValue MUST be related to the original Target. This is equally true the location information in a SIP response, i.e., from a SIP intermediary back to the Target as explained in Section 3.4."
      Something is missing in the second sentence (maybe 'true FOR the location information ...)
      4. "The text string are OPTIONAL,"
      fix grammar
      5. Unless there is a specific reason here it would be better to order the RFCs in the references sections according to the RFC numbers.
    6. Peter Saint-Andre: Comment [2011-06-21]:
      This is a fine document. I have a few small comments and questions.
      Section 4.1 says "GEO-URIs [RFC5870] are not appropriate for usage in the SIP Geolocation header." It would be good to explain why not.
      Section 4.1 says "SIP intermediaries SHOULD NOT modify or delete any existing locationValue(s)." As we know, "SHOULD NOT" is functionally equivalent to "MUST NOT unless you have a really good reason"; what is the really good reason here?
      In Section 4.3, please add a reference for PIDF-LO (presumably RFC 4119). Such a reference exists in Section 4.4, but Section 4.3 contains the first mention of PIDF-LO.
      Sections 4.6 and 8.3 both have "via an HTTP ([RFC2616])" instead of, presumably, "via HTTP ([RFC2616])" or "via an HTTP URI ([RFC2616])".
    7. Sean Turner: Comment [2011-06-23]:
      I had many of the same concerns Stephen did. But, I see in the emails exchanged between the authors and Stephen that it all seems to be worked/ing out. I'll support Stephen's discuss, but I'll assume you'll fix the draft up as you've noted in the emails.

    Telechat:

2.1.2 Returning Items

  1. IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN (Proposed Standard)
    draft-ietf-l3vpn-mvpn-infra-addrs-04
    Token: Stewart Bryant
    Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the document shepherd.
    Discusses/comments (from ballot 3671):
    1. Jari Arkko: Comment [2011-06-22]:
      Editorial suggestion: In Section 2, items 2 through 4 please provide references to the place where these attributes were originally defined. I had some trouble tracking them down, and I'm still not sure if I found the authoritative specification for them.
    2. Sean Turner: Comment [2011-06-22]:
      The draft header indicates that this document updates draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, but the abstract doesn't seem to mention this, which it should.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Protocol for Carrying Authentication for Network Access (PANA) Relay Element (Proposed Standard)
    draft-ohba-pana-relay-03
    Token: Jari Arkko
    Note: Margaret Wasserman (margaretw42@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3811):
    1. Adrian Farrel: Comment [2011-06-22]:
      Section 1: "For example, in ZigBee IP"
      Needs a reference.
    2. Stephen Farrell: Discuss [2011-06-18]:
      I hope this turns out to be a simple one - you almost, but not quite, have a mandatory to implement security mechanism. I think one would be good:
      "Required security can be achieved by using IPsec or another mechanism (e.g., via physical security, cryptographically-secured link-layers, DTLS, etc.). "
      Pick one. It looks from this like you've picked IPsec, if not why not and what other choice are you making? If so, great - jusy say so.
    3. Stephen Farrell: Comment [2011-06-18]:
      (1) Why not specify how the PaC finds the PRE here? Seems odd.
      (2) This entire paragraph is very unclear. "The Session Identifier and Sequence Number of a PRY message are set to zero. A PRY message is never retransmitted by the PRE or the PAA. The PRE and PAA do not advance their incoming or outgoing sequence numbers for request when transmitting or receiving a PRY message. Note that the PANA message carried in a Relayed-Message may be retransmitted by the PaC or PAA, leading to transmission of another PRY carrying the same Relayed-Message." For example, you need to state a condition that causes the session id and sequence # to be set to zero - it surely doesn't happen just once every blue moon :-) (Same thing is restated later.)
      (3) It would be stronger to say that multiple proxys are a MUST NOT.
      (4) 1st sentence of section 3; s/must/MUST/?
      (5) "Because the PREs and PAAs are used within an organization,..." That should be clearer up front.
    4. Pete Resnick: Comment [2011-06-19]:
      Is the only reason for this protocol so that the PRE does not need to keep the context for every PaC request? I don't quite understand why the PAA has to be involved in this at all except to turn around the information for the PRE to find the PaC.
    5. Peter Saint-Andre: Comment [2011-06-21]:
      I support Stephen Farrell's DISCUSS.
    6. Sean Turner: Comment [2011-06-20]:
      I had an issue with the first paragraph in Section 3 until I saw the exchange between Stephen and Alper. Long way of saying I support Stephen's discuss.

    Telechat:

2.2.2 Returning Items

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

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Advisory Guidelines for 6to4 Deployment (Informational)
    draft-ietf-v6ops-6to4-advisory-02
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3813):
    1. Jari Arkko: Comment [2011-06-23]:
      Thank you for writing this. Some minor comments: Section 5.2 could say something about using routing protocols between the gateway and the two routers.
      Section 7.2 title has a typo.
    2. Ralph Droms: Comment [2011-06-22]:
      Very nice document. Thank you. One small question...
      After reading this sentence: "In practice, there are few if any deployments of Router 6to4 following these recommendations."
      I wonder if the author has any insight into how many deployments of Router 6to4 are not following the recommendations in RFC 3056?
    3. Wesley Eddy: Comment [2011-06-16]:
      The document is clear and well-written.
      Does it make sense at the end of Section 1 to mention that this is not a BCP but only Informational because of the fact that 6to4 is being made Historic in parallel?
      Does this update 3056/3068, or does that not matter since they're going to be Historic?
    4. Stephen Farrell: Comment [2011-06-21]:
      Very nicely written document.
      I see that draft-ietf-v6ops-6to4-to-historic also mentions the 2.0.0.2.ip6.arpa domain, but that's not mentioned at all here. Should it be?
    5. Russ Housley: Discuss [2011-06-22]:
      Discussion following the Gen-ART Review by Alexey Melnikov on 6-Jun-2011 lead to proposed text changes. I would like to see them incorporated into the document. I understand the author has done the work and is waiting for word from the Sponsoring AD.
    6. Pete Resnick: Comment [2011-06-21]:
      I do not object to the publication of this document. However:
      1. Though it is only a "informative" reference, I do wonder how dependent this document is on moving 6to4 to Historic in the minds of WG members. Maybe they are completely independent. But it is a concern, especially if the IETF decides to *not* move 6to4 to Historic.
      2. The document says: "Other advice applies to content providers and implementers, but this document does not discuss aspects that are mainly outside the scope of network operators..."
      I do wonder where that other information is going to be collected together for an overview of dealing with 6to4.

    Telechat:

  2. IPv6 Multihoming without Network Address Translation (Informational)
    draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3815):
    1. Wesley Eddy: Discuss [2011-06-22]:
      1- Section 6 and 7 are outside of the Abstract's stated scope and are a little confusing because they don't seem to very clearly or directly give any conclusion about these approaches with regard to the stated requirements. If this is really supposed to be a problem statement and requirements document, then these sections either don't belong, or at least need to be better described with regards to the stated requirements.
      2- The mention of SCTP multihoming in the introduction is not quite correctly used here, since it only works for applications that are built on top of SCTP, and only provides limited functionality for those specific applications within an SCTP association, not host-level or interface-level functions as can be provided below in the network layer.
      3 - Strangely, there is no mention of SHIM6 or HIP, both of which would be more appropriate than SCTP to bring into the discussion. There's only a very passing reference to SHIM6 and no discussion of a technical shortcoming or comparison of the resulting requirements that this document develops.
      4 - One point of confusion in all of the scenarios in section 3 is why there is only a single host, rather than a small network as was described in the introduction. In a small network, is it expected that all hosts are on a link, or do they have independent links to the routers in some of the scenarios? This is not clear.
      5- Section 3.1, Scenario 1 lists broadband service as an example. I may just be uninformed, but I've used several broadband service providers and never had such a setup with multiple routers connected to a single host on the same link. Is this really a good example of how this scenario would occur in real life?
      6 - Scenario 2 lists VPN as an example, but this would usually have Router 2 and Network 2 on the right side of Network 1 connected to the host or gateway via a tunnel, so I don't understand this example, even though the scenario itself makes sense, the example seems either poor or poorly described (overly terse).
    2. Wesley Eddy: Comment [2011-06-22]:
      1- the abbreviation ASP is used without explanation
      2- In the third paragraph of the introduction that says "... more than one active IPv6 addresses", it should be more clear that the multiple addresses are actually multiple global scope addresses with different prefixes, since all IPv6 hosts have multiple addresses even with only one provider. The "For example" sentence is also strange in this paragraph since it points to a situation not with multiple link providers but with a single link provider and an additional address from another network connected via a tunnel which is a different use case than multihoming via multiple link providers.
    3. Stephen Farrell: Comment [2011-06-21]:
      Please note the secdir review from Hilarie Orman... I think the points made there are worth noting in the security considerations section. There is text in the review that could almost be cut and pasted for that.
    4. Pete Resnick: Discuss [2011-06-23]:
      I support Wes's DISCUSS. This document is very thin when it comes to examining technologies available to hosts having to deal with multihoming. Indeed, in addition to SCTP, HIP and SHIM6, the document also ignores MPTCP. But overall, the document does a lot of "handwaving" when it comes to issues of how applications deal with a multihomed environment. The document ignores the requirement of legacy apps that IP addresses remain stable over long periods of time (because once address selection is done for an app, connections will be torn down if that address changes). It refers to different DNS resolvers, but waits until section 6 to even mention that the reason that any of this makes a difference is because of broken split-horizon implementations, and even there only vaguely mentions split-horizon. This document does not seem to have had enough review.

    Telechat:

  3. Subnet Allocation Option (Informational)
    draft-ietf-dhc-subnet-alloc-12
    Token: Ralph Droms
    Note: John Jason Brzozowski (john_brzozowski@cable.comcast.com) is the document shepherd.
    IPR: Cisco's Statement about IPR claimed in draft-ietf-dhc-subnet-alloc-04.txt
    Discusses/comments (from ballot 3817):
    1. Jari Arkko: Comment [2011-06-23]:
      I agree about the suggested title change. I think Informational is fine for this type of documents. This is NOT a standard, we are describing a vendor's pre-standard approach to something. Its also not an experiment either.
    2. Adrian Farrel: Discuss [2011-06-21]:
      I'm afraid I agree with Pete's Discuss so strongly that I will raise it as my own Discuss.
      Either this document should be recast as "Description of Cisco Systems' Subnet Allocation Option for DHCP" (in which case Informational is acceptable) such that it is obvious what and why people might be implementing. Or it should be put on to the Standards Track.
      For the avoidance of doubt, I do not object to documents describing what is in the field and allowing people to decide to interoperate with that. In particular, in the 3942 context, this is good and proper. But I do not like the way this document sits on the fence between defining "a new DHCP option" and being Informational.
    3. Stephen Farrell: Comment [2011-06-20]:
      So I don't mind if I don't get an answer for this one or not but I always wondered, (though never bothered to ask;-) if an IPR declaration like this one [1] says that "if this standard blah blah then <<terms>>" but then the document ends up informational, as in this case, then do the stated terms apply or not?
    4. Russ Housley: Comment [2011-06-22]:
      Please update the title of this document to indicate that this is a Cisco protocol.
    5. Pete Resnick: Discuss [2011-06-20]:
      1. Technical (thanks Alexey): In section 3.2: "The "Name" in this suboption is simply a number of octets and need not be ASCII text."
      Please specify as UTF-8 [RFC3629] unless you've got some really impressive reason not to.
      2. Procedural: I don't understand why this document is being put forward as Informational. It is clearly protocol. It clearly has the potential to be used by multiple implementors. It's converting an private code point to a public one. It's being put forth by a WG and is not individuals documenting a private protocol. What reason is there for this to not be either Proposed Standard or Experimental. Please explain.
      3. Procedural: The document writeup says: "There was nothing controversial about this document. There was consensus in the working group to include the following text in the document:"
      Something is odd about this. If there was nothing controversial, why was the text added between versions -11 and -12? When I went to take a look at the list archive to see if I could figure out why, I did not see *any* comment on the document between version -11 and version -12. That doesn't really justify saying that there was consensus in the WG for the text. Please explain.
    6. Dan Romascanu: Comment [2011-06-20]:
      I am fine with approving this document. I have a number of comments (in part based on the OPS-DIR review performed by Fred Baker) that could improve IMO the clarity and accuracy of the document, but none is a show-stopper:
      1. I suspected this was an IPv4 prefix throughout, the only clues I had of that were that the protocol in question is "DHCP" as opposed to "DHCPv6", a statement in a field description in section 3.2.1 indicated that "Addr" designates an "IPv4 Network Number" (which seems strange; why not call it a prefix or a network number as opposed to an 'Addr'?), and the distinction from DHCPv6 Prefix Delegation discussed in section 9. If the authors revise the draft, I would suggest replacing "prefix" or "subnet" with "IPv4 prefix" or "IPv4 Subnet" in the title, at least one place in the abstract, and at least one place in the introduction.
      2. I think that the statement in the introduction 'Alternate methods of allocation, such as AAA are not appropriate for various reasons and the most straight-forward way to accomplish this allocation is via DHCP. ' needs either to be explained or dropped.
      3. In Section 3.2.1.1 - 'Additional statistics may be added to this option in the future. If so, they MUST be appended to the end of the option.' s/to the end of the option/immediately after the already defined statistics fileds/
      4. In section 4.2: "The Server need not reserve the subnets which are being offered, but SHOULD strive to not offer the same subnets to another DHCP Client until a reasonable time period (implementation dependent) has passed. (This is similar to normal DHCP address allocation.)"
      s/SHOULD strive to not offer/SHOULD not offer/
      5. The usage of the kewwords is inconsistent and in a number of place it looks like capitalized keywords need to be used. A list that may not be complete:
      - section 4.2: s/the DHCP Server should respond with a DHCPOFFER message/the DHCP Server SHOULD respond with a DHCPOFFER message/
      - section 5.3: s/The DHCP Client should send a DHCPRELEASE/The DHCP Client SHOULD send a DHCPRELEASE/
      - section 5.4: s/The DHCP Server may issue a DHCPFORCERENEW [RFC3203] message/DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message/
      - section 6: s/A DHCP Client may request from the DHCP Server a list/A DHCP Client MAY request from the DHCP Server a list/
      - section 6.1: s/The DHCP Client DHCPDISCOVER message, when used to discover already allocated subnet information, should contain a Subnet-Request suboption/The DHCP Client DHCPDISCOVER message, when used to discover already allocated subnet information, SHOULD contain a Subnet-Request suboption/
      - section 6.2: s/Any DHCP Server which has allocated subnets to the Client should respond/Any DHCP Server which has allocated subnets to the Client SHOULD respond/
      - section 6.3: s/The Client, upon receiving any Server DHCPOFFER messages containing Subnet Information suboption information with the 'c' ("Client") bit set, should gather the network number/The Client, upon receiving any Server DHCPOFFER messages containing Subnet Information suboption information with the 'c' ("Client") bit set, SHOULD gather the network number/
    7. Peter Saint-Andre: Comment [2011-06-21]:
      I agree with Adrian Farrel about the document title. Changing it to something like "Description of Cisco Systems' Subnet Allocation Option for DHCP" would be consistent with other vendor uses of reclassified options from RFC 3942, as evidenced by RFC 4578 ("Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)") and RFC 5071 ("Dynamic Host Configuration Protocol Options Used by PXELINUX"). If that change is made, I think Informational is fine (since RFC 4578 and RFC 5071 are also informational).
    8. Sean Turner: Comment [2011-06-21]:
      #1) I support Dan's discuss wrt whether this is for IPv4 or IPv6. Just say so early on in the document.
      #2) In Section 3.1 and 3.2, please indicate whether unused flags are ignored by a recipient if non-zero.
      #3) Section 3.2.1 contains the following:
          0                   1                   2                   3 
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         |                           Network                             | 
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         |    Prefix     |     Flags |h|d|   Stat-len    |  Optional stats... 
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
         Addr   = IPv4 network number (4 octets) 
      
      Did you mean "Network"? There is no "Addr" in the table above.
      #4) Section 3.2.1.1 contains the following: "Fewer fields may be included than what is specified in any current RFC, but all fields which are included MUST remain in order specifed here."
      Can you elaborate on what this mean? Does it mean only including 1 or 2 of the specified fields?

    Telechat:

  4. Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status (Informational)
    draft-ietf-v6ops-6to4-to-historic-04
    Token: Ron Bonica
    Note: The document shepherd is Fred Baker (fred@cisco.com).
    Discusses/comments (from ballot 3836):
    1. Stewart Bryant: Comment [2011-06-20]:
      Looking at the IETF LC discussion it's clear that consensus to proceed is pretty rough. However I think that on ballance the rough is probably in favour of publication.
      Given the above, I think that the responsible AD needs to provide a more extensive review of the consensus issues in the announcement text than is currently proposed.
      Given the extended dialogue that the proto statement indicates took place I am supprised that there is not greater discussion of the alternatives and rational for picking this approach provided in the text of the draft.
    2. Ralph Droms: Comment [2011-06-22]:
      I've reviewed the IETF last call discussion for this document, and come to my own conclusion about consensus of community support for publication of this document. Based on my conclusion, I will vote "No Objection."
      Like Stewart, I would like the responsible AD to provide a summary of the issues raised in the IETF last call, some indication of whether those issues will result in any changes to the document and a consensus call on the discussion.
    3. Wesley Eddy: Comment [2011-06-16]:
      Should "transitioning" be "transition" in the abstract?
      Note, this is informational and uses 2119 language in section 4.
    4. Adrian Farrel: Comment [2011-06-22]:
      I am ballotting "no Objection" but I agree with the bulk of Discuss and Comments raised
    5. Stephen Farrell: Comment [2011-06-21]:
      (1) Why repeat stuff from draft-ietf-v6ops-6to4-advisory? I think just referring to that document would be better since it gives a fuller and better explanation. That could lead to just removing section 3 entirely I think.
      (2) I have no strong opinion as to whether deprecating the domain and addresses in section 5 is right or wrong. However, I do think that since draft-ietf-v6ops-6to4-advisory does have what look like some very useful recommendations about these, that a reference to that document in the IANA considerations section would be good since the current text there looks like its saying "turn all that off please" and I don't think that's what you're trying to say.
      Maybe something like:"Note however that [I-D.ietf-v6ops-6to4-advisory] recommends that various actors take various actions related to these addresses. The reader is encouraged to follow those recommendations and is not encouraged to simply turn off these addresses."
      If putting that in the IANA considerations section is wrong, then I think correcting the impression elsewhere would be good, maybe with something like:
      "Despite what you might think from reading the IANA considerations section of this document, we are not recommending that people turn off the addresses deprecated there. The IANA considerations section is simply a set of instructions to IANA. Please consult [I-D.ietf-v6ops-6to4-advisory] for the actual set of actions recommended."
      (I'm sure the phrase "turn off" in the suggested text above is wrong, but that should be easily corrected and it may need to also say something about the domain as well, I don't know.)
    6. Russ Housley: Comment [2011-06-22]:
      The authors have agreed to incorporate the editorial comments from the Gen-ART Review by Ben Campbell on 17-Jun-2011.
    7. Pete Resnick: Discuss [2011-06-19]:
      1. I am not convinced of consensus for this document based on the Last Call discussion.
      2. In light of draft-ietf-v6ops-6to4-advisory, I do not understand the necessity of this document.
      3. Procedural: This Informational document invokes Standards Actions (i.e., moving two documents from Standards Track to Historic and making changes to IANA registries). However, the ballot procedure we are using is the one for Informational documents which requires only a single "Yes" and no "Discuss". That seems inappropriate.
    8. Dan Romascanu: Comment [2011-06-23]:
      I support the procedural issue raised by Pete.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1227 EDT break

1233 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Home Networks (homenet)
    Token: Jari

    Telechat:

4.1.2 Proposed for Approval

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

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Common Authentication Technology Next Generation (kitten)
    Token: Stephen

    Telechat:

  2. Kerberos (krb-wg)
    Token: Stephen

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IESG Statement on Historic (Sean Turner)

    Telechat:

  2. Request for an IPv4 Option Number [IANA #459951] (Michelle Cotton)

    Telechat:

  3. IESG Requirements for NomCom (Russ Housley)

    Telechat:

  4. Moving items from July 14th to June 30th (Robert)

    Telechat:

  5. Agenda collisions for QC (Russ)

    Telechat:

7. Agenda Working Group News

1410 EDT Adjourned



Appendix: Snapshot of discusses/comments

(at 2011-06-23 07:30:09 PDT)

draft-ietf-dime-ikev2-psk-diameter

  1. Jari Arkko: Discuss [2011-06-23]:
        The document says:
    
    > 6.1.1. Ni
    >
    >   The Ni AVP (AVP Code TBD5) is of type Unsigned32 and contains the
    >   IKEv2 initiator nonce.
    >
    > 6.1.2. Nr
    >
    >   The Nr AVP (AVP Code TBD6) is of type Unsigned32 and contains the
    >   IKEv2 responder nonce.
    
    However, Section 3.9 of RFC 4306 clearly states that nonces are variable length.
    How can you carry a variable length nonce in an Unsigned32? 
        
  2. Jari Arkko: Comment [2011-06-23]:
    Regarding other Discusses, I am actually fine with the document otherwise except
    the above point, and with some documentation of the security assumptions and
    implications it should be possible to publish it.
    
    However, I do have one additional concern that should be discussed. I'm not too
    happy about the decision to leave the PSK generation algorithm outside the scope
    of this specification. It basically means that there is no interoperability.
  3. Stephen Farrell: Discuss [2011-06-18]:
        
    (1) The writing here is unclear at critical points, to the point
    where I find this hard to follow. I would recommend expanding and
    clarifying the 2nd paragraph of the introduction; e.g. adding a
    diagram showing the various parties involved in the exchanges;
    introducing the main use-case for this protocol and defining terms
    before use - in particular the IKEv2 Server and Peer, HAAA etc. The
    purpose of the IPsec exchange also needs to be explained.  Without
    this its not really possible (for me anyway) to know if the main
    potential problem with this spec (sending cleartext keys) is fatal
    or not. 
    
    (2) This specification calls for sending a symmetric key
    (realistically , in clear) in Diameter and then using that key to
    secure an IPsec SA establishment.  The set of conditions under
    which that is a reasonable thing to do (which may be the empty set)
    need to be identified, but are not.  For example, if the Diameter
    and IKE exchanges share a network segment then this is fairly
    pointless if there is a MITM. 
    
    (3) (Similar to, but not identical to (2).) Routing the request
    based on IDi (as an NAI) seems to make it very hard to do that with
    security, unless there is some way to validate the domain component
    of the NAI (e.g via a whitelist or some broker). How is this done?
    If any old IDi/NAI value can be used, then it seems impossible to
    always setup a secure channel for the return of the key, which
    implies that the key effectively MUST be returned in clear, which
    seems unacceptable.
    
    (4) Sending IDi, Ni and Nr out-of-band of the IKEv2 exchange might
    lead to new attacks. For example, if I can feed selected Ni,Nr to
    someone who does crypto on those and gives me the result, then I
    may get to figure out a secret more easily than planned. Normally
    in IKE, IDi is only sent encrypted, but that differs here. Has this
    been analysed? (And where are the results?) If not, it should be.
    
    (5) What does this mean: "It is strongly RECOMMENDED that the HAAA
    uses the nonces Ni and Nr received in IKEv2-Nonces AVP to generate
    the PSK. " Are you changing IKE here? An IKE PSK is not "generated"
    it just is. (Apologies if I'm missing something here, but IKE's 
    use of EAP is not something with which I'm very familiar.)
    
    (6) RFC 3588, section 4.5 has an "Encr" colum that is missing in
    the AVP flag rules here and that is presumably very very important
    for an AVP named Key.  What's up there? Would adding the Encr
    column with a "Y" for the key be the right thing?
    
    (7) How does a programmer handle this statement in the draft: "For
    this reason, this specification strongly recommends using Diameter
    agents that can be trusted."? I think you have to have a MUST
    implement and MUST use TLS and that brokers MUST NOT be used if you
    want the Key AVP to be protected from the HAAA to the requesting
    node. Anything else needs to be specifically justified.
    
    (8) IKE_AUTH has an optional IDr field. That doesn't seem to be
    mentioned here at all. I'd have thought that it ought be in the
    IKEv2-PSK-Request if it was in the IKE_AUTH message? (I need to
    check if IDr can occur with an IKEv2 PSK, but seems like it ought
    be allowed.)
     
        
  4. Stephen Farrell: Comment [2011-06-18]:
    I agree with Pete that the last sentence of the abstract needs
    a rewrite.
  5. Russ Housley: Discuss [2011-06-22]:
        
      The Gen-ART Review by Ben Campbell on 3-Jun-2011 raised an important
      interoperability question.  Ben pointed out that the the procedure
      used by the HAAA to generate the PSK is out of scope, but that
      interoperability cannot occur unless the same one is supported by all
      parties.  The author responded that the PSK generation is important
      for interoperability, but that the specific PSK generation mechanisms
      have been intentionally left to other documents.  Thus, the Diameter
      application must define the PSK generation mechanism.  Apparently,
      3GPP2 has such documents for its community.
    
      I would like to understand why the IETF is not specifying a mandatory
      to implement PSK generation mechanism, even if others are allowed.
      This could be done with a normative reference. 
        
  6. Pete Resnick: Comment [2011-06-17]:
    I am neither an IKE person nor a Diameter person. That said, the following
    sentence, which appears in the Abstract and Introduction, is completely
    incomprehensible to me:
    
       This document specifies IKEv2 server, as a Diameter
       client, to the Diameter server communication for IKEv2 with pre-
       shared key based authentication.
    
    If IKE and Diameter people will understand that sentence, you can feel free to
    ignore me, but I have no idea what that means.
  7. Robert Sparks: Comment [2011-06-22]:
    I support Russ' discuss.
    
    I also encourage stating more clearly that there is no mechanism for
    negotiating/detecting which PSK derivation algorithm is in use - that this is
    entirely manually managed configuration. Is it realistic that this would be run-
    time configuration, or is it expected that it would be set at manufacture or
    compile?

draft-ietf-sidr-keyroll

  1. Adrian Farrel: Comment [2011-06-21]:
    I have a couple of comments that don't merit a Discuss, but I would be
    grateful if the authors thought about them and made any necessary
    changes.
    
    ---
    
    I found Section 1...
       This document defines a conservative procedure
        
  2. ...ambiguous. I think that "conservative" needs to be qualified in some way. conservative with respect to conserving keys? Not changing keys often? Not requiring many messages? Not risking security? --- There are a couple of uses of SHOULD which I feel would benefit from an explanation of how/why a variation MAY be allowed. In one case, I am relatively sure you mean MUST rather than SHOULD, viz. To perform a key rollover operation the CA MUST perform the following steps in the order given here. Unless specified otherwise each step SHOULD be performed without any intervening delay. The process MUST be run through to completion. That is, the variance is already handled by "unless specified otherwise" so there is no further scope for variance.
  3. Stephen Farrell: Comment [2011-06-17]:
    4.1 - is it really wise to encourage (even obliquely) 
    re-use of serial numbers? I'd say  s/MAY change/SHOULD 
    change/ there would be better. 
    
    If making that change, it'd be good to say when its ok 
    to re-use  serial numbers - that could be when an internal
    DB design uses certificate.serialNumber as a DB 
    key which may be silly but has been done.
  4. Dan Romascanu: Comment [2011-06-22]:
    1. I agree with Adrian's comment that the term 'conservative' in the
    introductory section needs to be explained or dropped
    
    2. The note in the IANA considerations section is for the RFC Editor - doesn't
    matter too much though as it instructs to take our the null content section.

draft-ietf-dkim-mailinglists

  1. Jari Arkko: Comment [2011-06-22]:
    This is a complex topic full of difficult tradeoffs, but the document was a
    pleasure to read. Thank you for writing it in such a clear manner that it is
    understandable even by non-email experts.
  2. Ralph Droms: Comment [2011-06-22]:
    One quite minor editorial comment; the rest of the document was well-written and
    this bit of text stuck out.  In Section 3.3:
    
       List-specific header fields:  [...]
          Therefore not seen as a concern.
    
    Was the sentence fragment intended?
  3. Adrian Farrel: Comment [2011-06-22]:
    I also dithered over the BCP/Informational issue. 
    However, the document seems
    to involve issues of end-to-end service provision where the service is improved
    by adherence to the guidelines. This takes it over the line into a BCP, IMHO.
    If
    the impact of the document was entirely limited to within a single domain, I
    would say that it should be Informational.
    
    I did not find the use of RFC 2119 language helpful, and would suggest writing
    guidelines in English, reserving 2119 language for normative protocol
    specifications or for emphasis in requirements specs.
  4. Stephen Farrell: Comment [2011-06-15]:
    (1) I think section 5.2 is the "meat" of this basically, so would
    suggest a forward reference to there from last paragraph of the 
    intro.
    
    (2) In 2.5 should the 1st "i.e.," really be "e.g.," - that is, are
    you saying "d=" is the *only* way to identify message streams? 
    If so, then perhaps make that clear. (I just don't recall if there
    were other good ways. I do recall there being other bad ways:-)
      
    (3) 5.4 is a bit unclear to me. I suggest just adding an example.
    
  5. Russ Housley: Comment [2011-06-22]:
      Please consider the editorial comments from the Gen-ART Review by
      Pete McCann on 6-Jun-2011.
  6. Pete Resnick: Comment [2011-06-22]:
    3.1:
    
       originator:  The agent that accepts a message from the author,
          ensures it conforms to the relevant standards such as [MAIL], and
          then sends it toward its destination(s).  This is often referred
          to as the Mail Submission Agent (MSA).
    
    That definition is incorrect. The originator is not identical to the MSA. My
    secretary (whose address appears in the "Sender:" field of a message authored by
    me) is at least part of the "originator", but he is by no means part of the MSA.
    The MSA is a servce, in MAIL-ARCH terms. The originator is an actor role. I
    suspect in all of the definitions in this section, there is a conflation of
    these going on, but originator is the one that is most egrigeous.
    
    5.1
    
       However, the practice of applying headers and footers to message
       bodies is common and not expected to fade regardless of what
       documents this or any standards body might produce.  This sort of
       change will invalidate the signature on a message where the body hash
       covers the entire message.  Thus, the following sections also discuss
       and suggest other processing alternatives.
    
    I think the document ought to explicitly say something stronger along the lines
    of, "MLMs that are DKIM-aware ought to stick to header field additions only and
    not make changes to headers and footers."
    
    (Note to IESG: Personally, I wish this document were part of the AS experiment
    and had even more MUSTs and SHOULDs. I will weep silently in my beer that it is
    not.)
  7. Peter Saint-Andre: Comment [2011-06-22]:
    This is a fine document. One nit: in Section 1.2, please expand "ADSP" on first
    use or change "ADSP policies" to something like "DKIM author domain signing
    practices [ADSP]".
  8. Robert Sparks: Comment [2011-06-21]:
    The 4th paragraph of section 1.2 (beginning "Some MLM behaviors") reads like
    motivation for starting a draft, rather than documenting the resulting
    discussion. Please consider updating its perspective or removing the paragraph.

draft-ietf-opsawg-mib-floats

  1. Adrian Farrel: Comment [2011-06-21]:
    Typo
    
    Section 1
    
    s/and for a a/and for a/
    
  2. Stephen Farrell: Comment [2011-06-17]:
    - A reference to Knuth is always good:-)
    - Some examples would be even better.
    
  3. Russ Housley: Comment [2011-06-22]:
      I suggest that we remove "None" from the author's address.
  4. Sean Turner: Comment [2011-06-20]:
    <super nit>
    
    Section 5 includes a copyright year of 2010.
    
    </super nit>

draft-ietf-sipcore-location-conveyance

  1. Stephen Farrell: Discuss [2011-06-18]:
        (1) I don't understand the privacy model for the case where a UA
    does not support this (or has turned it off) and the outbound proxy 
    adds this header. How is the poor end user supposed to know what 
    is happening in this case? What if a user specifically wants to use 
    a UA that doesn't send her location (or have it added) - how could 
    that be supported?
    
    (2) 4.1 says that SIP intermediaries "are not to view" location
    information.  Why can't that be written with a MUST of some sort?
    It seems very weak at present. (The same "not to view" is repeated
    a few times later.) I don't understand what "viewing" means for
    a piece of software. 
    
    (3) cleared
    
    (4) If a UA or intermediary inserts a Geolocation or
    Geolocation-Routing header field, I assume that doesn't get
    deleted later.  So nothing prevents this information "leaking" out
    beyond the domain/operator who set the field. That means all
    operators are trusting all operators further down the signalling
    path with all users location information.  Should there be
    something about deleting these fields at some stage in path? Did
    the WG consider this aspect?
    
    (5) There is a MUST for conforming to rfc 3693 that says that you
    have to follow the rules for retention and re-transmission. A quick
    look at 3693 seems to imply that that document does not set out
    rules with which one could conform, but only says those must exist.
    Am I right there?  If so, then where do I go (as an implementer) to
    find out how to handle retention and re-transmission?
     
        
  2. Stephen Farrell: Comment [2011-06-17]:
    (1) Last para of section 3 - SIP intermediaries don't receive
    diagrams, probably needs a rephrase.
    
    (2) 3.1: Can Bob use the error code to get Alice to progressively
    give him more location information? If Alice's LO is "fuzzed" then
    each iteration might expose more precise information to Bob. If
    that's likely or possible, it probably deserves a mention in the
    security considerations. I'd suggest that Alice SHOULD include some
    kind of limit for repeatedly sending an LO in a short period, if
    she is fuzzing or similar. (Or maybe even generally - is there ever
    a real reason to iterate on this 10 times in a few minutes?)
    
    (3) Same as (3) but for section 3.2 - should the LS have some
    controls on how often Bob (or anyone) can de-reference the URI?
    
    (4) Are there a set of rules specified somewhere as to what is
    required of an LR? The repeated refereences to what is or is not an
    LR sort of implies there is, but rfc 3693 doesn't seem to contain
    that. If there are such rules specified somewhere then please add a
    reference.
    
    (5) 3.3, 1st para, could do with a bit more explaination of the
    location based routing case (maybe just as a forward reference or
    an example). The current text doesn't make it clear who'd be
    routing what for whom based on the LO.
    
    (6) I don't understand why GEO-URIs are not appropriate for use
    here - a sentence explaining why seems warranted.
    
    (7) What is a RuleMaker and where is that defined?  I assume it
    means something like a telcoms regulator.
    
    (8) It seems odd to have a MUST not just for rfc 3693 but also for
    its "updates and successors" - how do you know that that'll be
    possible?
    
    (9) It seems odd that appendix A presents requirements but is not
    referenced in the text of the document at all. What is the status
    of this? Partly it looks like historic information that the WG
    used, but nothing says that.
    
    (10) UAC-7 s/must be met/MUST be met/ ?
    
  3. Russ Housley: Comment [2011-06-22]:
      Please consider the editorial comments from the Gen-ART Review by
      Pete McCann on 17-Jun-2011.
  4. Pete Resnick: Comment [2011-06-19]:
    I don't expect any of these to turn into "DISCUSS" comments, but I'd like some
    explanation to get my head around them:
    
    - Section 3 (or something similar to it) seems to be something I've seen before
    in other documents, though I can't figure out where it is I've seen it. Is this
    information that can be referenced from somewhere else?
    
    - Section 4.2 says:
    
       The Geolocation-Routing header field satisfies the recommendations 
       made in section 3.5 of RFC 5606 [RFC5606] regarding indication of 
       permission to use location-based routing in SIP.
    
    My reading of 5606 3.5 is that the indication of "permission" is basically an
    optimization: That is, it is an indication that using the location is likely to
    fail and ought be avoided. But 4.2 reads differently, making it out to be some
    sort of access control mechanism (without any enforcement):
    
       ...when the Geolocation-Routing 
       header-value is set to "no", if a cid:url is present in the SIP 
       request, intermediaries SHOULD NOT view the location (because it is 
       not for intermediaries to view), and if a location URI is present, 
       intermediaries SHOULD NOT dereference it.
    
    I'm left wondering what the downside is if an intermediary does view or
    dereference a location when you've got a "Geolocation-Routing: no". Why is it
    that the intermediary SHOULD NOT do these things?
    
    - Sections 4.3. It seems inevitable that 424's will leak back to the originating
    UA even when the location was inserted by an intermediary (because there will be
    a badly behaved intermediary that doesn't handle a 424). Should there be any
    instruction about how a UA should handle (ignore?) a 424 even when it hasn't
    included location info?
    
    - Section 4.4. Is "permission reset" an understood term in SIP-land? It wasn't
    clear to me (though I could guess) how the term "reset" was being used in this
    context.
  5. Dan Romascanu: Comment [2011-06-21]:
    1. I think that the usage of the term 'SIP modifications' in the title and first
    paragraph of section 4 is too strong for what this document does. Modifications
    to SIP would imply updating some previous documents. I suggest replacing
    'modifications' by 'extensions'.
    
    2. section 4.1: 
    
       The Geolocation header field can have one or more locationValues. A 
       Geolocation header field MUST have at least one locationValue. 
    
    The first sentence seems to have been made redundant by the second. 
    
    3. 
    
       Any locationValue MUST be related to the original Target. This is 
       equally true the location information in a SIP response, i.e., from 
       a SIP intermediary back to the Target as explained in Section 3.4.
    
    Something is missing in the second sentence (maybe 'true FOR the location
    information ...)
    
    4. 
    
    The text string are
       OPTIONAL,
    
    fix grammar
    
    5. Unless there is a specific reason here it would be better to order the RFCs
    in the references sections according to the RFC numbers.
  6. Peter Saint-Andre: Comment [2011-06-21]:
    This is a fine document. I have a few small comments and questions.
    
    Section 4.1 says "GEO-URIs [RFC5870] are not appropriate for usage in the SIP
    Geolocation header." It would be good to explain why not.
    
    Section 4.1 says "SIP intermediaries SHOULD NOT modify or delete any existing
    locationValue(s)." As we know, "SHOULD NOT" is functionally equivalent to "MUST
    NOT unless you have a really good reason"; what is the really good reason here?
    
    In Section 4.3, please add a reference for PIDF-LO (presumably RFC 4119). Such a
    reference exists in Section 4.4, but Section 4.3 contains the first mention of
    PIDF-LO.
    
    Sections 4.6 and 8.3 both have "via an HTTP ([RFC2616])" instead of, presumably,
    "via HTTP ([RFC2616])" or "via an HTTP URI ([RFC2616])".
  7. Sean Turner: Comment [2011-06-23]:
    I had many of the same concerns Stephen did.  But, I see in the emails exchanged
    between the authors and Stephen that it all seems to be worked/ing out.  I'll
    support Stephen's discuss, but I'll assume you'll fix the draft up as you've
    noted in the emails.

draft-ietf-l3vpn-mvpn-infra-addrs

  1. Jari Arkko: Comment [2011-06-22]:
    Editorial suggestion: In Section 2, items 2 through 4 please provide references
    to the place where these attributes were originally defined. I had some trouble
    tracking them down, and I'm still not sure if I found the authoritative
    specification for them.
  2. Sean Turner: Comment [2011-06-22]:
    The draft header indicates that this document updates draft-ietf-l3vpn-2547bis-
    mcast-bgp-08.txt, but the abstract doesn't seem to mention this, which it
    should.

draft-ohba-pana-relay

  1. Adrian Farrel: Comment [2011-06-22]:
    Section 1
    
       For example, in ZigBee IP
    
    Needs a reference.
  2. Stephen Farrell: Discuss [2011-06-18]:
        
    I hope this turns out to be a simple one - you almost, but not
    quite, have a mandatory to implement security mechanism. I
    think one would be good:
    
    "Required security can be achieved by using IPsec or another
    mechanism (e.g., via physical security, cryptographically-secured
    link-layers, DTLS, etc.). " Pick one. It looks from this like
    you've picked IPsec, if not why not and what other choice are you
    making? If so, great - jusy say so. 
        
  3. Stephen Farrell: Comment [2011-06-18]:
    (1) Why not specify how the PaC finds the PRE here?  Seems odd.
    
    (2) This entire paragraph is very unclear. "The Session Identifier
    and Sequence Number of a PRY message are set to zero.  A PRY
    message is never retransmitted by the PRE or the PAA.  The PRE and
    PAA do not advance their incoming or outgoing sequence numbers for
    request when transmitting or receiving a PRY message.  Note that
    the PANA message carried in a Relayed-Message may be retransmitted
    by the PaC or PAA, leading to transmission of another PRY carrying
    the same Relayed-Message." For example, you need to state a
    condition that causes the session id and sequence # to be set to
    zero - it surely doesn't happen just once every blue moon :-) (Same
    thing is restated later.)
    
    (3) It would be stronger to say that multiple proxys are a MUST
    NOT.
    
    (4) 1st sentence of section 3; s/must/MUST/?
    
    (5) "Because the PREs and PAAs are used within an organization,..."
    That should be clearer up front.
    
  4. Pete Resnick: Comment [2011-06-19]:
    Is the only reason for this protocol so that the PRE does not need to keep the
    context for every PaC request? I don't quite understand why the PAA has to be
    involved in this at all except to turn around the information for the PRE to
    find the PaC.
  5. Peter Saint-Andre: Comment [2011-06-21]:
    I support Stephen Farrell's DISCUSS.
  6. Sean Turner: Comment [2011-06-20]:
    I had an issue with the first paragraph in Section 3 until I saw the exchange
    between Stephen and Alper.  Long way of saying I support Stephen's discuss.

draft-housley-two-maturity-levels

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

draft-ietf-v6ops-6to4-advisory

  1. Jari Arkko: Comment [2011-06-23]:
    Thank you for writing this.
    
    Some minor comments: Section 5.2 could say something about using routing
    protocols between the gateway and the two routers.
    
    Section 7.2 title has a typo.
  2. Ralph Droms: Comment [2011-06-22]:
    Very nice document.  Thank you.
    
    One small question...
    
    After reading this sentence:
    
       In
       practice, there are few if any deployments of Router 6to4 following
       these recommendations.
    
    I wonder if the author has any insight into how many deployments of
    Router 6to4 are not following the recommendations in RFC 3056?
    
  3. Wesley Eddy: Comment [2011-06-16]:
    The document is clear and well-written.
    
    Does it make sense at the end of Section 1 to mention that this is not a BCP but
    only Informational because of the fact that 6to4 is being made Historic in
    parallel?
    
    Does this update 3056/3068, or does that not matter since they're going to be
    Historic?
  4. Stephen Farrell: Comment [2011-06-21]:
    Very nicely written document.
    
    I see that draft-ietf-v6ops-6to4-to-historic also mentions
    the 2.0.0.2.ip6.arpa domain, but that's not mentioned at all
    here. Should it be?
    
  5. Russ Housley: Discuss [2011-06-22]:
        
      Discussion following the Gen-ART Review by Alexey Melnikov on
      6-Jun-2011 lead to proposed text changes.  I would like to see
      them incorporated into the document.  I understand the author
      has done the work and is waiting for word from the Sponsoring AD. 
        
  6. Pete Resnick: Comment [2011-06-21]:
    I do not object to the publication of this document. However:
    
    1. Though it is only a "informative" reference, I do wonder how dependent this
    document is on moving 6to4 to Historic in the minds of WG members. Maybe they
    are completely independent. But it is a concern, especially if the IETF decides
    to *not* move 6to4 to Historic.
    
    2. The document says:
    
       Other advice applies to content providers and implementers, but this
       document does not discuss aspects that are mainly outside the scope
       of network operators...
    
    I do wonder where that other information is going to be collected together for
    an overview of dealing with 6to4.

draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

  1. Wesley Eddy: Discuss [2011-06-22]:
        1- Section 6 and 7 are outside of the Abstract's stated scope and are a little
    confusing because they don't seem to very clearly or directly give any
    conclusion about these approaches with regard to the stated requirements.  If
    this is really supposed to be a problem statement and requirements document,
    then these sections either don't belong, or at least need to be better described
    with regards to the stated requirements.
    
    2- The mention of SCTP multihoming in the introduction is not quite correctly
    used here, since it only works for applications that are built on top of SCTP,
    and only provides limited functionality for those specific applications within
    an SCTP association, not host-level or interface-level functions as can be
    provided below in the network layer.
    
    3 - Strangely, there is no mention of SHIM6 or HIP, both of which would be more
    appropriate than SCTP to bring into the discussion.  There's only a very passing
    reference to SHIM6 and no discussion of a technical shortcoming or comparison of
    the resulting requirements that this document develops.
    
    4 - One point of confusion in all of the scenarios in section 3 is why there is
    only a single host, rather than a small network as was described in the
    introduction.  In a small network, is it expected that all hosts are on a link,
    or do they have independent links to the routers in some of the scenarios?  This
    is not clear.
    
    5- Section 3.1, Scenario 1 lists broadband service as an example.  I may just be
    uninformed, but I've used several broadband service providers and never had such
    a setup with multiple routers connected to a single host on the same link.  Is
    this really a good example of how this scenario would occur in real life?
    
    6 - Scenario 2 lists VPN as an example, but this would usually have Router 2 and
    Network 2 on the right side of Network 1 connected to the host or gateway via a
    tunnel, so I don't understand this example, even though the scenario itself
    makes sense, the example seems either poor or poorly described (overly terse). 
        
  2. Wesley Eddy: Comment [2011-06-22]:
    1- the abbreviation ASP is used without explanation
    
    2- In the third paragraph of the introduction that says "... more than one
    active IPv6 addresses", it should be more clear that the multiple addresses are
    actually multiple global scope addresses with different prefixes, since all IPv6
    hosts have multiple addresses even with only one provider.  The "For example"
    sentence is also strange in this paragraph since it points to a situation not
    with multiple link providers but with a single link provider and an additional
    address from another network connected via a tunnel which is a different use
    case than multihoming via multiple link providers.
  3. Stephen Farrell: Comment [2011-06-21]:
    Please note the secdir review from Hilarie Orman, [1] 
    I think the points made there are worth noting in the 
    security considerations section. There is text in the
    review that could almost be cut and pasted for that.
    
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02739.html
  4. Pete Resnick: Discuss [2011-06-23]:
        I support Wes's DISCUSS. This document is very thin when it comes to examining
    technologies available to hosts having to deal with multihoming. Indeed, in
    addition to SCTP, HIP and SHIM6, the document also ignores MPTCP. But overall,
    the document does a lot of "handwaving" when it comes to issues of how
    applications deal with a multihomed environment. The document ignores the
    requirement of legacy apps that IP addresses remain stable over long periods of
    time (because once address selection is done for an app, connections will be
    torn down if that address changes). It refers to different DNS resolvers, but
    waits until section 6 to even mention that the reason that any of this makes a
    difference is because of broken split-horizon implementations, and even there
    only vaguely mentions split-horizon. This document does not seem to have had
    enough review. 
        

draft-ietf-dhc-subnet-alloc

  1. Jari Arkko: Comment [2011-06-23]:
    I agree about the suggested title change. I think Informational is fine for this
    type of documents. This is NOT a standard, we are describing a vendor's pre-
    standard approach to something. Its also not an experiment either.
  2. Adrian Farrel: Discuss [2011-06-21]:
        I'm afraid I agree with Pete's Discuss so strongly that I will raise it as my
    own Discuss.
    
    Either this document should be recast as "Description of Cisco Systems' Subnet
    Allocation Option for DHCP" (in which case Informational is acceptable) such
    that it is obvious what and why people might be implementing. Or it should be
    put on to the Standards Track.
    
    For the avoidance of doubt, I do not object to documents describing what is in
    the field and allowing people to decide to interoperate with that. In
    particular, in the 3942 context, this is good and proper. But I do not like the
    way this document sits on the fence between defining "a new DHCP option" and
    being Informaitonal. 
        
  3. Stephen Farrell: Comment [2011-06-20]:
    So I don't mind if I don't get an answer for this one or not but I always 
    wondered, (though never bothered to ask;-) if an IPR declaration 
    like this one [1] says that "if this standard blah blah then <<terms>>" 
    but then the document ends up informational, as in this case, then 
    do the stated terms apply or not? 
    
    [1] https://datatracker.ietf.org/ipr/811/
    
  4. Russ Housley: Comment [2011-06-22]:
      Please update the title of this document to indicate that this is a Cisco
    protocol.
  5. Pete Resnick: Discuss [2011-06-20]:
        1. Technical (thanks Alexey): In section 3.2:
    
       The "Name" in this suboption is simply a number of octets and
       need not be ASCII text.
    
    Please specify as UTF-8 [RFC3629] unless you've got some really impressive
    reason not to.
    
    2. Procedural: I don't understand why this document is being put forward as
    Informational. It is clearly protocol. It clearly has the potential to be used
    by multiple implementors. It's converting an private code point to a public one.
    It's being put forth by a WG and is not individuals documenting a private
    protocol. What reason is there for this to not be either Proposed Standard or
    Experimental. Please explain.
    
    3. Procedural: The document writeup says:
    
       There was nothing controversial about this document.  There was
       consensus in the working group to include the following text in the
       document:
    
    Something is odd about this. If there was nothing controversial, why was the
    text added between versions -11 and -12? When I went to take a look at the list
    archive to see if I could figure out why, I did not see *any* comment on the
    document between version -11 and version -12. That doesn't really justify saying
    that there was consensus in the WG for the text. Please explain. 
        
  6. Dan Romascanu: Comment [2011-06-20]:
    I am fine with approving this document. I have a number of comments (in part
    based on the OPS-DIR review performed by Fred Baker) that could improve IMO the
    clarity and accuracy of the document, but none is a show-stopper:
    
    1. I suspected this was an IPv4 prefix throughout, the only clues I had of that
    were that the protocol in question is "DHCP" as opposed to "DHCPv6", a statement
    in a field description in section 3.2.1 indicated that "Addr" designates an
    "IPv4 Network Number"  (which seems strange; why not call it a prefix or a
    network number as opposed to an 'Addr'?), and the distinction from DHCPv6 Prefix
    Delegation discussed in section 9. If the authors revise the draft, I would
    suggest replacing "prefix" or "subnet" with "IPv4 prefix" or "IPv4 Subnet" in
    the title, at least one place in the abstract, and at least one place in the
    introduction.
    
    2. I think that the statement in the introduction 'Alternate methods of
    allocation, such as AAA are not appropriate for various reasons and the most
    straight-forward way to accomplish this allocation is via DHCP. ' needs either
    to be explained or dropped.
    
    3. In Section 3.2.1.1 - 'Additional statistics may be added to this option in
    the future. If so, they MUST be appended to the end of the option.' s/to the end
    of the option/immediately after the already defined statistics fileds/
    
    4. In section 4.2: 
    
    The Server need not reserve the subnets which are being offered, but
       SHOULD strive to not offer the same subnets to another DHCP Client
       until a reasonable time period (implementation dependent) has passed.
       (This is similar to normal DHCP address allocation.)
    
    s/SHOULD strive to not offer/SHOULD not offer/
    
    5. The usage of the kewwords is inconsistent and in a number of place it looks
    like capitalized keywords need to be used. A list that may not be complete: 
    -
    section 4.2: s/the DHCP Server should respond with a DHCPOFFER message/the DHCP
    Server SHOULD respond with a DHCPOFFER message/
    - section 5.3: s/The DHCP Client
    should send a DHCPRELEASE/The DHCP Client SHOULD send a DHCPRELEASE/
    - section
    5.4: s/The DHCP Server may issue a DHCPFORCERENEW [RFC3203] message/DHCP Server
    MAY issue a DHCPFORCERENEW [RFC3203] message/
    - section 6: s/A DHCP Client may
    request from the DHCP Server a list/A DHCP Client MAY request from the DHCP
    Server a list/
    - section 6.1: s/The DHCP Client DHCPDISCOVER message, when used
    to discover already allocated subnet information, should contain a Subnet-
    Request suboption/The DHCP Client DHCPDISCOVER message, when used to discover
    already allocated subnet information, SHOULD contain a Subnet-Request suboption/
    - section 6.2: s/Any DHCP Server which has allocated subnets to the Client
    should respond/Any DHCP Server which has allocated subnets to the Client SHOULD
    respond/ 
    - section 6.3: s/The Client, upon receiving any Server DHCPOFFER
    messages containing Subnet Information suboption information with the 'c'
    ("Client") bit set, should gather the network number/The Client, upon receiving
    any Server DHCPOFFER messages containing Subnet Information suboption
    information with the 'c' ("Client") bit set, SHOULD gather the network number/
    
    '
  7. Peter Saint-Andre: Comment [2011-06-21]:
    I agree with Adrian Farrel about the document title. Changing it to something
    like "Description of Cisco Systems' Subnet
    Allocation Option for DHCP" would be
    consistent with other vendor uses of reclassified options from RFC 3942, as
    evidenced by RFC 4578 ("Dynamic Host Configuration Protocol (DHCP) Options for
    the Intel Preboot eXecution Environment (PXE)") and RFC 5071 ("Dynamic Host
    Configuration Protocol Options Used by PXELINUX"). If that change is made, I
    think Informational is fine (since RFC 4578 and RFC 5071 are also
    informational).
  8. Sean Turner: Comment [2011-06-21]:
    #1) I support Dan's discuss wrt whether this is for IPv4 or IPv6.  Just say so
    early on in the document.
    
    #2) In Section 3.1 and 3.2, please indicate whether unused flags are ignored by
    a recipient if non-zero.
    
    #3) Section 3.2.1 contains the following:
    
        0                   1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                           Network                             | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |    Prefix     |     Flags |h|d|   Stat-len    |  Optional stats... 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
       Addr   = IPv4 network number (4 octets) 
    
    Did you mean "Network"? There is no "Addr" in the table above. 
    
    #4) Section 3.2.1.1 contains the following:
    
       Fewer fields may be included than what is specified in any current 
       RFC, but all fields which are included MUST remain in order specifed 
       here. 
    
    Can you elaborate on what this mean? Does it mean only including 1 or 2 of the
    specified fields?

draft-ietf-v6ops-6to4-to-historic

  1. Stewart Bryant: Comment [2011-06-20]:
    Looking at the IETF LC discussion it's clear
    that consensus to proceed is pretty rough.
    However I think that on ballance the rough is 
    probably in favour of publication.
    
    Given the above, I think that the responsible AD
    needs to provide a more extensive review of
    the consensus issues in  the announcement
    text than is currently proposed.
    
    Given the extended dialogue that the proto statement
    indicates took place I am supprised that there is not
    greater discussion of the alternatives and rational
    for picking this approach provided in the text of
    the draft.
  2. Ralph Droms: Comment [2011-06-22]:
    I've reviewed the IETF last call discussion for this document, and
    come to my own conclusion about consensus of community support for
    publication of this document.  Based on my conclusion, I will vote "No
    Objection." 
    
    Like Stewart, I would like the responsible AD to provide a summary of
    the issues raised in the IETF last call, some indication of whether
    those issues will result in any changes to the document and a
    consensus call on the discussion.
    
  3. Wesley Eddy: Comment [2011-06-16]:
    Should "transitioning" be "transition" in the abstract?
    
    Note, this is informational and uses 2119 language in section 4.
  4. Adrian Farrel: Comment [2011-06-22]:
    I am ballotting "no Objection" but I agree with the bulk of Discuss and Comments
    raised
  5. Stephen Farrell: Comment [2011-06-21]:
    (1) Why repeat stuff from draft-ietf-v6ops-6to4-advisory?  I think
    just referring to that document would be better since it gives a
    fuller and better explanation. That could lead to just removing
    section 3 entirely I think.
    
    (2) I have no strong opinion as to whether deprecating the
    domain and addresses in section 5 is right or wrong. However, I do
    think that since draft-ietf-v6ops-6to4-advisory does have what look
    like some very useful recommendations about these, that a reference
    to that document in the IANA considerations section would be
    good since the current text there looks like its saying "turn all
    that off please" and I don't think that's what you're trying to say. 
    
    Maybe something like: 
    
    "Note however that [I-D.ietf-v6ops-6to4-advisory] recommends that 
    various actors take various actions related to these addresses. The 
    reader is encouraged to follow those recommendations and is not 
    encouraged to simply turn off these addresses." 
    
    If putting that in the IANA considerations section is wrong,  then 
    I think correcting the impression elsewhere would be good, maybe 
    with something like:
    
    "Despite what you might think from reading the IANA considerations
    section of this document, we are not recommending that people turn 
    off the addresses deprecated there. The IANA considerations section
    is simply a set of instructions to IANA. Please consult  
    [I-D.ietf-v6ops-6to4-advisory] for the actual set of actions 
    recommended."
    
    (I'm sure the phrase "turn off" in the suggested text above is wrong,
    but that should be easily corrected and it may need to also say 
    something about the domain as well, I don't know.)
    
    
  6. Russ Housley: Comment [2011-06-22]:
      The authors have agreed to incorporate the editorial comments from the
      Gen-ART Review by Ben Campbell on 17-Jun-2011.
  7. Pete Resnick: Discuss [2011-06-19]:
        1. I am not convinced of consensus for this document based on the Last Call
    discussion.
    
    2. In light of draft-ietf-v6ops-6to4-advisory, I do not understand the necessity
    of this document.
    
    3. Procedural: This Informational document invokes Standards Actions (i.e.,
    moving two documents from Standards Track to Historic and making changes to IANA
    registries). However, the ballot procedure we are using is the one for
    Informational documents which requires only a single "Yes" and no "Discuss".
    That seems inappropriate. 
        
  8. Dan Romascanu: Comment [2011-06-23]:
    I support the procedural issue raised by Pete.