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
- Roll Call 1133 EDT Amy:
- Bernard Aboba--- regrets
- Jari Arkko--- y
- Ron Bonica--- y
- Stewart Bryant--- regrets
- Gonzalo Camarillo--- y
- Michelle Cotton--- y
- Ralph Droms--- y
- Wesley Eddy--- y
- Adrian Farrel--- y
- Stephen Farrell--- y
- Sandy Ginoza--- y
- Susan Hares--- regrets
- David Harrington--- y
- Russ Housley--- y
- Barry Leiba--- scribe
- John Leslie--- scribe
- Cindy Morgan--- y
- Ray Pelletier--- regrets
- Pete Resnick--- y
- Dan Romascanu--- y
- Peter Saint-Andre--- y
- Robert Sparks--- y
- Hannes Tschofenig--- late
- Sean Turner--- y
- Amy Vezza--- y
- Bash the Agenda
- Amy: Put homenet into 4.1.1; move draft-housley to end of call. Any other changes?
- Robert: Should we have a mgmt item to look at the next two telechat agendas, to see if we can move anything?
- Russ: OK. Also, if there's time let's spend a few minutes on the collisions discussed on the mailing list for sessions in QC.
- Approval of the Minutes of the past telechat
- June 7 minutes--- no objection, approved
- June 7 narrative minutes--- no objection, approved
- Review of Action Items from last Telechat
- Jari Arkko to add guidance on multi-Area work to the wiki.
Jari: Still no progress. I intend to do something soon.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
- 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):
- 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?
- 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.
- 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.)
- Stephen Farrell: Comment [2011-06-18]:
I agree with Pete that the last sentence of the abstract needs a rewrite.
- 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.
- 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.
- 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:
- Dan: The DISCUSS about specification of key generation method. I'd like to understand what will solve your concern.
- Russ: I'd like to see a normative ref to a must implement.
- Dan: Did you see the proposal from one of the authors?
- Russ: No.
- Dan: He suggested adding a reference. OK, I know how to take it from here. I want to clarify some other issues raised. I'll get a more complete answer in the coming days. Unless anyone else wants to discuss something, this goes to revised i-d.
- 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):
- 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.
- 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.
- 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:
- Amy: No discusses. If no objection, approved.
- Adrian: Need to go to approved, point raised. There are enough comments that Stewart will want to look at it.
- 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):
- 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.
- 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?
- 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.
- 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.
- Russ Housley: Comment [2011-06-22]:
Please consider the editorial comments from the Gen-ART Review by Pete McCann on 6-Jun-2011.
- 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.)
- 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]".
- 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:
- Amy: No discusses. If no objection, approved. OK. Is the RFC editor note correct and complete?
- Sean: Checking. Yes. Just instructions for publication. Make it point raised; there's a comment we need to resolve.
- 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):
- Adrian Farrel: Comment [2011-06-21]:
Typo:Section 1: s/and for a a/and for a/
- Stephen Farrell: Comment [2011-06-17]:
- A reference to Knuth is always good:-)
- Some examples would be even better.
- Russ Housley: Comment [2011-06-22]:
I suggest that we remove "None" from the author's address.
- Sean Turner: Comment [2011-06-20]:
<super nit> Section 5 includes a copyright year of 2010. </super nit>
Telechat:
- Amy: No discusses. If no objection, approved.
- Dan: One question to ask about a comment by Russ. You commented that [something] should be taken out.
- Russ: Usually they put "independent". But I was talking about the street address, which says "none". Just take it out.
- Dan: OK, I'll put in an RFC editor note, in the next 5 or 10 minutes.
- Amy: I'll put it in point raised, and Dan will let us know when the note is done.
- 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):
- 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?
- 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/ ?
- Russ Housley: Comment [2011-06-22]:
Please consider the editorial comments from the Gen-ART Review by Pete McCann on 17-Jun-2011.
- 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.
- 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.
- 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])".
- 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:
- Robert: I don't think we need to discuss it; the email conversation is converging. Revised I-D, please.
2.1.2 Returning Items
- 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):
- 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.
- 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:
- Amy: No discusses. If no objections, approved.
- Adrian: Jari, you entered discuss text, but balloted yes.
- Jari: I thought I had discovered something, but after further checking, it's OK.
- Adrian: OK, I just wanted to make sure that's what you intended.
- Amy: Do we need to hold this for Stewart to OK?
- Adrian: I think we should. We might need an RFC editor note, and Stewart should make that choice.
2.2 Individual Submissions
2.2.1 New Items
- 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):
- Adrian Farrel: Comment [2011-06-22]:
Section 1: "For example, in ZigBee IP"
Needs a reference.
- 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.
- 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.
- 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.
- Peter Saint-Andre: Comment [2011-06-21]:
I support Stephen Farrell's DISCUSS.
- 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:
- Ron: Add a "no objection position for me.
- Jari: We were talking on the email list about the security stuff. The document already goes far, but maybe should mandate something. I'm a little unhappy about doing that. Even though there are security considerations talking about vulnerabilities, if there's security on the path going out and not coming in, you still need to deal with security. If you're a man in the middle, you can block people from completing. Even if you have a secure panel you can still block people. I'm reluctant to add more security requirements.
- Stephen: In the mail exchange we ended up with SHOULDs, and the authors were happy with that. SHOULD support IPSEC. They seemed happy with that and it would work fine for me.
- Jari: I'm pushing back a little on adding security requirements. If you actually do the analysis of what can go wrong with and without IPSEC, the delta isn't that big. I'm concerned with adding material to this or other RFCs... obeying the letter, and implementers will not necessarily follow. I'm fine with a SHOULD. But I'd be happier with something else.
- Stephen: As the draft says, you can use IPSEC. I think SHOULD is probably correct. I need to look at the security considerations for that point.
- Jari: I think the document doesn't say anything.
- Stephen: It says required security can be achieved using IPSEC or another mechanism.
- Jari: And it's excellent that they do specify how IPSEC can be used. But what you actually buy with additional security, I think the text from that point is fine.
- Stephen: I was reacting to the lack of a keyword. I can look again at the security considerations text, to see if it makes a good argument about why you might not get much benefit from IPSEC.
- Jari: There are security holes, but there aren't that many things you can actually protect against.
- Stephen: I'll look at it again.
- Jari: If you look during the call, we can chat later and provide guidance to the authors.
- Stephen: I think someone else agreed with my discuss. Peter?
- Jari: Peter do you have an opinion?
- Peter StA: I don't, no.
- Jari: OK, let's make this AD follow-up.
- Peter StA: My opinion is that it's nice to pick one.
- Stephen: That's probably a fair point. If they're going to specify how to do IPSEC, wouldn't it help implementors if they have a SHOULD there?
- Jari: In terms of interoperability, maybe. But does it actually buy you much?
- Stephen: I'll read through the text. But putting in a SHOULD will help interop.
- Jari: Yes, if it's useful functionality. Maybe even if it's useless. OK, there will be more research.
- Amy: OK, AD follow-up.
2.2.2 Returning Items
- 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):
- 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.
- 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."
- 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.)
- 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).
- 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.
- 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:
- Russ: I sent a not-posted update to see if people thought that was a way forward, and got no feedback. I wanted to know whether I should argue with one of my co-authors, and wanted to know if it was in the right direction.
- Jari: Maybe we should talk about the right direction first. Last time we talked about this, we agreed that several of us would analyze the discussion. I have done that, and I'm not sure I have an answer about what to do. In terms of support, not, partial, it's relatively evenly split. I got 13 strongly in favour, 6 in favour with minor changes, 9 strongly against. Looking at more specific topics, like removing full standard... that was mostly in favour, but it's hard to tell about people who made a blanket statement against. On decreasing quality of PS level, that was evenly split. Going by Pete's classification, as far as I could tell everyone was in favour. There were a bunch of random topics that were brought up. Smoother transition. I can say there's consensus for how we progress to DS, but on the decreasing quality of PS and killing full std, those are trickier. Any consensus is extremely rough.
- Pete R: I got partway through, and didn't get all the way through looking at the messages. I thought the editorial changes were fine, but the bigger picture wasn't clear to me. I'm still not clear whether your direction will work.
- Russ: If you guys are in support of the direction, which I think addresses all the things we talked about in our follow-up discussion, if this group thinks we're in a place that makes sense, I'm not opposed to a second last call to find out.
- Peter StA: I think the direction is better now, and clearer. But it seems that we need to have a second last call to make sure it's something people agree on.
- Jari: Russ can you summarize the last version?
- Russ: I tried not to talk about anything that wasn't directly affected by the changes the doc proposes. I took al the discussion about ease of getting to PS, as a second-order effect. I took out the discussion of other things going forward, about downrefs, about restrictions on what portions of the document could be reviewed in a bis document used for progression. It's restructured a fair amount.
- Jari: It sounds reasonable to me, and possibly it would help. We'd have to do a last call again. The "going back to original PS level" is a political statement, and some people might withdraw their support without that.
- Russ: The doc is shorter now, so please review it and give feedback on whether you can support this formulation.
- Jari: Your change will probably resolve Ralph's concern. What about Pete and Peter?
- Pete R: My personal feelings about the direction notwithstanding, I'm not convinced that this will move things forward, but we'll get more data when we do it.
- Jari: Is everyone on the IESG on board with doing this, and that our DISCUSSes will be based on the opinions on the list, not on our personal opinions?
- Pete R: That's my intent.
- Ralph: I don't know whether my DISCUSS was addressed. Russ do you think your updates address the DISCUSS about what the details of returning to 2026 would look like?
- Russ: I believe it was addressed by removing that statement. So, the opposite way. The real question is, if we focus on the later levels of the maturity level, does the community accept that, or does the community really want us to tie the hands of future IESGs.
- Ralph: That's the right question to ask. I don't know what the answer would be, but it will address my DISCUSS.
- Russ: Focus on one problem at a time, or at least a small handful.
- Peter StA: I think you did a good job with that. I will send a reply to your message. I have some points. I'll do that today.
- Pete R: I just sent my message.
- Russ: OK, we're done with this one: I take comments from Pete and Peter, work with my co-authors, re-post, then last-call again.
- Jari: Should I summarize where we are now on the list?
- Russ: Yes, that would help.
- Amy: Jari, keep this in AD follow-up, or go to revised I-D needed?
- Jari: Revised I-D.
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
- 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):
- 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.
- 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?
- 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?
- 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?
- 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.
- 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:
- Ron: There was an exchange on the DISCUSS, everyone agreed, and there'll be a new version. Revised I-D needed.
- 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):
- 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).
- 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.
- 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.
- 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:
- Ron: DISCUSSes are best handled offline. Put it in AD follow-up.
- 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):
- 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.
- 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.
- 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?
- Russ Housley: Comment [2011-06-22]:
Please update the title of this document to indicate that this is a Cisco protocol.
- 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.
- 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/
- 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).
- 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:
- Ralph: I want to have a brief discussion. Pete and I have had a discussion, and I think we came to a resolution of Pete's DISCUSS issue. I've asked him to suggest specific text. Adrian's was closely related. Would a resolution along the lines of what Pete and I discussed handle yours too?
- Adrian: You've discussed changing the doc title, and that's the main meat of my concern. And then folding that title into the intro and abstract would be fine.
- Ralph: Dan had some good comments that will be addressed in the revision of the doc. one procedural issue, a goof on my part: I claimed that the disclaimer text was reviewed by the WG, but it was only by chairs and authors. So this will go back to the WG briefly, and then I will confirm with Adrian and Pete before publication.
- Dan: Are there precedents for this?
- Ralph: There are other docs that have gone through this process of looking for review of items in the private range, documenting them, then doing a descriptive RFC.
- Dan: Please send the RFC numbers. I'm curious about the text they used.
- Peter StA: I looked into it, and I found RFCs 4578 and 5071.
- Pete R: Ralph, there's no procedural requirement to go back through IETF last call?
- Ralph: It's a judgment call. I'd be happy to run it through another last call for completeness.
- Pete R: I'm ambivalent. The text being added is more disavowing the doc, so it's hard to imagine that another last call would make anyone less happy.
- Ralph: I think for transparency, it would not be a bad thing.
- Amy: Is this revised I-D?
- Ralph: Yes. More than I want to do in an RFC ed note.
- 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):
- 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.
- 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.
- Wesley Eddy: Comment [2011-06-16]:
Should "transitioning" be "transition" in the abstract?
Note, this is informational and uses 2119 language in section 4.
- Adrian Farrel: Comment [2011-06-22]:
I am ballotting "no Objection" but I agree with the bulk of Discuss and Comments raised
- 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.)
- 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.
- 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.
- Dan Romascanu: Comment [2011-06-23]:
I support the procedural issue raised by Pete.
Telechat:
- Ron: I'd like to discuss with Pete. You have three parts. First is you're not sure there's IETF consensus. Two people said the same, that there is consensus but it's rough, and they want a writeup about the last call. If I did that, would that be OK?
- Pete R: I think there's a point at which "really rough" turns out not to be consensus. I certainly don't think that the only issue being raised is that the intention is to kill 6to4 and that's a bad thing. I was hearing more than that coming up. There was an awful lot of yelping. But number two is the most important.
- Ron: There are two things that number two could mean: yuou have an objection to making it historic, or not.
- Pete R: I have an objection. There's no reason to do this if we have a document that says "if you're going to do this, here's how." And there's deployment out there.
- Ron: We want to discourage people from doing more of it.
- Pete R: You need a doc saying "you ought not do this, and here are the reasons." But that doesn't make it historic. It means that "it's bad, and ought not be done", or "something has superceded it."
- Jari: You have this other doc that says what you should be doing instead.
- Pete R: The 6to4 advisory doc? That's saying "continue to use the protocol in this particular set of ways."
- Ralph: It says "here are some things that will mitigate the problems," not "continue to use it."
- Jari: It actually does say stop using it in this situation.
- Ron: It's showing you the protocol with sharp edges, and saying you probably shouldn't use it, and be careful if you do.
- Pete R: There are several circumstances where using 6to4 is reasonable and desirable, because other things simply don't fit.
- Ralph: That's something with the other doc that I want to hear more about. What was learned from the last call, and what was the consensus?
- Ron: Rough at best, very vocal objection from some people. But most people accepted that it wasn't widely deployed, not widely used, and has lots of sharp edges.
- Pete R: There's no doubt there's failure of full consensus. Was there any attempt to come to consensus with folks about what could be done with documentation? Is this an attempt to make it historic prematurely? How about putting in the warnings without making it historic?
- Ron: I don't recall anyone suggesting that.
- Ralph: I have a vague memory that at least one of the strong opponents for historic agreed that we should print the advisory, but not ban the product.
- Peter StA: But the document doesn't try to ban the product. It just says don't make more.
- Pete R: And throw away the recipe, it's historic now. It's "historic" that people are screaming loudest about. What is gained by that, rather than just explaining the sharp edges?
- Ron: We're not expunging the RFC from the series.
- Pete R: Now you're saying this is a marketing move. You want to make it LOOK historic.
- Ron: That's exactly what historic is.
- Jari: This is partially a marketing message. We're saying this thing is now good, and it's a standard, or it's informational, or historic, and we're not recommending its use any more. It's down to this judgment about whether there are enough use cases left that it should not be historic.
- Pete R: It sounds like people's positions are hardened on what's a marketing issue. There's no desire to come to consensus about the marketing issue.
- Ron: If 6to4 were coming out as PS today, would it have a chance of approval?
- Pete R: Probably experimental, not PS.
- Ron: In that case, why should it not be historic. We supported it then, not now.
- Pete R: It's deployed. It's in use, it fills a gap. We should document how not to hurt yourself with it. Labelling it historic is sticking our fingers in our ears.
- Ron: We're at an impasse.
- Russ: Is Pete the only one with his view? Is he in the rough? Does anyone support Pete's position? [silence]
- Ron: The third point is whether you can make historic a PS document with an informational doc.
- Pete R: No. The only issue is the procedural one... this is generating a standards action, moving something to historic. Have we done all of the procedural niceties for a standards action?
- Ron: We probably have done everything. IETF last call, consensus of the IESG. Just have to announce it correctly as a stds action.
- Dave: Pete, are you looking for a change to the tools, the procedures?
- Pete R: It would be nice if the tools made this automatic, but as long as the secretariat knows what to do, we're OK. Back to point 2, should I just abstain now?
- Russ: That would be a fine way to handle it.
- Pete R: OK, abstain is fine. So the question is just one of secretariat procedure, that a standards action is generated against the original RFC.
- Robert: I have a nagging feeling that we're going off the wrong slope, that we're not seeing some of the other things that will result. As we move forward, we need to do so with sensitive feelers.
- Pete R: Once procedural workaround is that we have an info doc that makes another RFC historic... take the other RFC and give it its own agenda item to make it historic. That ends up as a protocol action, and we're done.
- Robert: That would be less perilous. I'm not concerned with this particular document, but I see this as something we're going to repeat.
- Russ: Later in the agenda we're going to approve a statement of how to move things to historic. Why don't we follow it?
- Sean: It says that last call should go out saying that the info document was approved and the document will go to historic.
- Pete R: I think that's already clear. In this case the right thing happened.
- Russ: It's clear that the community was not taken by surprise. Robert, are you happy?
- Robert: I'm not unhappy with the statement or with this document. I just want to be sure it's encoded into the tools.
- Pete R: I've changed my ballot to abstain.
- Ron: That makes it approved, point raised... I owe the group a writeup on the IETF last call.
- Michelle: I posted in the jabber room that IANA has issues with this document. We received responses to our last call comments but have not reviewed the comments yet.
- Amy: Ron, let us know when you and IANA are content, and we'll send the announcement.
3.1.2 Returning Items
- (none)
3.2 Individual Submissions Via AD
3.2.1 New Items
- (none)
3.2.2 Returning Items
- (none)
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
- (none)
3.3.2 Returning Items
- (none)
1227 EDT break
1233 EDT back
- Bernard Aboba--- regrets
- Jari Arkko--- y
- Ron Bonica--- y
- Stewart Bryant--- regrets
- Gonzalo Camarillo--- y
- Michelle Cotton--- y
- Ralph Droms--- y
- Wesley Eddy--- y
- Adrian Farrel--- y
- Stephen Farrell--- y
- Sandy Ginoza--- y
- Susan Hares--- regrets
- David Harrington--- y
- Russ Housley--- y
- Barry Leiba--- scribe
- John Leslie--- scribe
- Cindy Morgan--- y
- Ray Pelletier--- regrets
- Pete Resnick--- y
- Dan Romascanu--- y
- Peter Saint-Andre--- y
- Robert Sparks--- y
- Hannes Tschofenig--- y
- Sean Turner--- y
- Amy Vezza--- y
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
- Home Networks (homenet)
Token: Jari
Telechat:
- Amy: This is the FUN BoF that was approved last week. Just for discussion now, because it's just in internal review.
- Jari: Last week we decided to approve the slot for this, and the plan was to make some changes to approve a WG. I have implemented those changes. There's a clear point in the charter where they do architecture and requirements, and then come back to request protocol work. The charter talks about likely protocol work, but requires them to check with the IESG. I removed some protocol names, changed the wording on BNF extensions. It's on this call because I wanted to discuss controversy. I wanted to get an early view of whether you're fine with this.
- Russ: Thank you for incorporating all the guidance. I haven't finished reviewing, but what I saw makes sense.
- Dave: It sounds as though you've put in what I needed. I haven't had a chance to look yet.
- Jari: OK. I put this in late. I appreciate if you have a chance to look at this during the next week, and not wait for the call. We want to create the WG before the IETF meeting, so let's resolve issues before next week's call.
- Ralph: The WG, as I understand it is allowed to do preliminary work based on the architecture while the architecture doc is being done, but they can't submit anything yet. But they can think about those issues in parallel with the architecture doc.
- Jari: Yes, and that's modeled on softwire. I'm not completely sure that's the right model, but that seems to work with what we discussed in last week's call.
- Ralph: I agree with that strategy. There's a window of opportunity that will be lost if this work doesn't proceed quickly. I think this is the right approach.
- Jari: I'll wait for more detailed reviews over the next week. And we have this on the agenda for next week as well.
4.1.2 Proposed for Approval
- Content Delivery Networks Interconnection (cdni)
Token: David
Telechat:
- Amy: Any objections to creating this WG? None. David, we still need chairs?
- Dave: Rich Woundy and François... the BoF chairs. I haven't announced that, but wanted to clear it with the IESG first.
- Peter StA: They did a nice job with the BoF.
- Amy: We'll send out a WG action announcement, and will tell Wanda for scheduling.
- Peter StA: Did they request a session?
- Dave: They did, yes, and it's been scheduled.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
- Common Authentication Technology Next Generation (kitten)
Token: Stephen
Telechat:
- Amy: Any objection to the changes here? Does it need full IETF review?
- Stephen: I think we can approve them. There was one tweak to the charter, which I mailed to the list during the meeting.
- Amy: No objections heard. You have an edit that needs to go in before we make the announcement. Please send it to iesg-secretary.
- Kerberos (krb-wg)
Token: Stephen
Telechat:
- Amy: Changes here are small, doesn't need full review. Any objections to these changes?
- Russ: The concerns I raised on the mailing list have been sorted out.
- Amy: No objections heard. Have there been any updates since the 13th?
- Stephen: No.
4.2.2 Proposed for Approval
- (none)
5. IAB News We can use
- Hannes: I wrote up what I want to say and sent it in email. We went through detailed status updates on our programs. One was on privacy, another on internationalization. I listed the IAB and non-IAB members. Some of that information can be found on the IAB web page. In the privacy program, there are a couple of non-IAB members, and more will be added for input. The most important is the privacy design guidelines doc, to provide the best guidance to developers. Take a look at the document, and we invite your feedback.
- Hannes: There's a work in progress doc on a workshop report, and there's a link in your mail. There are conference calls as part of these programs. The slide set that's also in your mail talks about the next steps. The internationalization program, what you might find interesting is a new document with relationship to security and internationalization, identifier comparison.
- Hannes: The IP evolution initiative, the smart object [?] is being worked on. Have a look at it and provide feedback. Jari and I are working on that. The IANA evolution program, working on a response to IANA functions notice of inquiry. The IAB has provided a response, and now there's another one we need to respond to.
- Hannes: Finally, the preparation of the technical plenary. (1) Report from IPv6 day, (2) Privacy. For privacy we have three speakers. One is Fred Carter from Canadian data protection authority. We hope to get more feedback on the experience of others working on privacy, and trying to incorporate privacy in technical specifications.
- Hannes: We would like feedback on the documents in progress.
6. Management Issues
- IESG Statement on Historic (Sean Turner)
Telechat:
- Sean: There are two new paragraphs added to this, the third and second from last. Are we ready to accept/confirm this and approve the statement?
- Pete R: Has the secretariat looked at the second-to-last, and do they think it's OK?
- Russ: It would force you to edit something that's drafted by the tool before sending.
- Pete R: This is the point that RObert brought up earlier. We could do it as two separate actions, where we actually last-call the old RFC as "protocol action, moving to historic".
- Amy: I'm unsure that we could handle an informational doc as a protocol action. The tools don't work that way
- Robert: I was hearing some confusion... the issue is not last calls. The issue is how we deal with what we're currently using ballots for.
- Pete R: One issue is how we deal with it on the ballot, and the other is how we do the notifications.
- Amy: TO do what that paragraph says, the secretariat would have to hand-craft all announcements for these types of documents. We can do that, but the AD needs to tell us.
- Robert: So we'd be doing this through tickets.
- Russ: Yes, until we figure out how we want the tracker modified. And I think that's OK.
- Amy: It also won't show up in the agenda in the right place.
- Pete R: Robert's suggestion is just to add an agenda item manually.
- Sean: Are there any objections to the statement as written? I guess we call this approved.
- Amy: Now this needs to be sent to the announce list and posted on the web site. Does it need to go anywhere else?
- Russ: No, that's sufficient.
- Request for an IPv4 Option Number [IANA #459951] (Michelle Cotton)
Telechat:
- Michelle: We received a request for an IPv4 option number, and the requester asked to use an existing number. I brought it to get a decision on what to do from the IESG.
- Jari: I haven't looked at the details, but it seems like a bad idea. Apparently, they've decided that this temporary number... the general purpose experimental number is not sufficient for them. I would never give them a permanent code point, that would be bad. If they're unhappy with the experimental number, that leaves us with a 12-month allocation. I wouldn't mind that. But it would be good if we had a policy.
- Russ: It's standards action, IETF consensus, or IESG approval. I would oppose IESG approval without a document to point to.
- Michelle: Should I go back to ask the requester if they have a document?
- Russ: If they have a doc, I would feel very different.
- Jari: I think you should ask them, if they want an allocation other than the experimental number, they have to have a doc they can bring to the IETF. That's the first step.
- Michelle: If I draft a response to the requester, can I run it by Russ or Jari?
- Russ: Yes, sure.
- IESG Requirements for NomCom (Russ Housley)
Telechat:
- Russ: We have a draft, I got comments, I've incorporated them. Are we ready to approve this and send it to the NomCom?
- ... [Couple of "yes".]
- Pete R: Did my stuff on the generic make it in here?
- Russ: Did I miss a comment? I put every one I saw in there.
- Pete R: This is the discussion of...
- Russ: Oh, I know. I wasn't sure there was closure on that. Then the list went silent about it.
- Pete R: Sorry... I should have pushed the conversation. Are you OK updating with the split paragraph?
- Russ: Yes. With that change, are people happy?
- ... [Couple of "yes".]
- Russ: I'll run the last update by Pete to make sure he's happy, and then I'll send it to Alexa to send to the NomCom chair.
- Moving items from July 14th to June 30th (Robert)
Telechat:
- Robert: People, please look at what you have on 7/14 and move it to 6/30, because the latter is underused.
- Sean: I've already moved rfc4871bis to 6/30.
- Adrian: I had a couple of docs that had to go back for an IPR reason. If you're happy to do the evaluation before the last call completes, provisionally, we can do that.
- Peter StA: I have one where last call completes on the 29th, so that's a possibility.
- Robert: OK, I think we've discussed the item.
- Agenda collisions for QC (Russ)
Telechat:
- Russ: I would like to figure out how to project Wanda's spreadsheet. Wanda, can you give it to Cindy so she can share it? Let's do two-maturity-levels first, and come back to this.
- ... [spreadsheet shared]
- ... [IESG worked with secretariat to arrange agenda slots]
7. Agenda Working Group News
- Jari Arkko (Internet)--- Issues in SAVI WG: Chair unhappy with lots of end-process work (and lack of co-chair). Participants unhappy with IESG pushback.
- Ron Bonica (O & M)--- none
- Stewart Bryant (Routing)--- none
- Gonzalo Camarillo (RAI)--- none
- Ralph Droms (Internet)--- Scott Brim will step down as intarea chair, and we're looking for a replacement.
- Wesley Eddy (Transport)--- none
- Adrian Farrel (Routing)--- Stewart and I are in the process of shuffling working groups because of my change of funding source. I now get manet, and Steward will soon get bfd.
- Stephen Farrell (Security)--- none
- David Harrington (Transport)--- none
- Russ Housley (General)--- We have asked the IAB to send a note to ARIN about special /10 assignment... that it must be done by the IETF. The address requests will land in Ron's lap for shepherding.
- Pete Resnick (Apps)--- A concern was raised in ftpext2 about the amount of review that docs have actually gotten in last call. The chairs are working on this.
- Dan Romascanu (O & M)--- none
- Peter Saint-Andre (Apps)--- We changed chairs in vCardDAV. I might have changes in IRI, but I'll talk about those next week.
- Robert Sparks (RAI)--- none
- Sean Turner (Security)--- none
1410 EDT Adjourned
Appendix: Snapshot of discusses/comments
(at 2011-06-23 07:30:09 PDT)
draft-ietf-dime-ikev2-psk-diameter
- 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?
- 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.
- 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.)
- Stephen Farrell: Comment [2011-06-18]:
I agree with Pete that the last sentence of the abstract needs
a rewrite.
- 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.
- 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.
- 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
- 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.
- 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.
- 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
- 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.
- 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?
- 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.
- 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.
- Russ Housley: Comment [2011-06-22]:
Please consider the editorial comments from the Gen-ART Review by
Pete McCann on 6-Jun-2011.
- 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.)
- 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]".
- 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
- Adrian Farrel: Comment [2011-06-21]:
Typo
Section 1
s/and for a a/and for a/
- Stephen Farrell: Comment [2011-06-17]:
- A reference to Knuth is always good:-)
- Some examples would be even better.
- Russ Housley: Comment [2011-06-22]:
I suggest that we remove "None" from the author's address.
- Sean Turner: Comment [2011-06-20]:
<super nit>
Section 5 includes a copyright year of 2010.
</super nit>
draft-ietf-sipcore-location-conveyance
- 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?
- 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/ ?
- Russ Housley: Comment [2011-06-22]:
Please consider the editorial comments from the Gen-ART Review by
Pete McCann on 17-Jun-2011.
- 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.
- 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.
- 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])".
- 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
- 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.
- 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
- Adrian Farrel: Comment [2011-06-22]:
Section 1
For example, in ZigBee IP
Needs a reference.
- 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.
- 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.
- 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.
- Peter Saint-Andre: Comment [2011-06-21]:
I support Stephen Farrell's DISCUSS.
- 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
- 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.
- 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.
- 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.)
- 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).
- 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.
- 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
- 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.
- 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?
- 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?
- 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?
- 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.
- 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
- 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).
- 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.
- 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
- 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
- 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.
- 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.
- 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/
- Russ Housley: Comment [2011-06-22]:
Please update the title of this document to indicate that this is a Cisco
protocol.
- 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.
- 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/
'
- 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).
- 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
- 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.
- 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.
- Wesley Eddy: Comment [2011-06-16]:
Should "transitioning" be "transition" in the abstract?
Note, this is informational and uses 2119 language in section 4.
- Adrian Farrel: Comment [2011-06-22]:
I am ballotting "no Objection" but I agree with the bulk of Discuss and Comments
raised
- 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.)
- 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.
- 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.
- Dan Romascanu: Comment [2011-06-23]:
I support the procedural issue raised by Pete.