On Aug 2, 2011, at 6:12 AM, Tero Kivinen wrote: > Paul Hoffman writes: >> You are *not* responsible for the IANA registries. RFC 5226 says: >> >> It should be noted that a key motivation for having designated >> experts is for the IETF to provide IANA with a subject matter expert >> to whom the evaluation process can be delegated. IANA forwards >> requests for an assignment to the expert for evaluation, and the >> expert (after performing the evaluation) informs IANA as to whether >> or not to make the assignment or registration. > > Ok, perhaps using word of being responsible for the IANA registries is > wrong as IANA will be responsible for the actual registries, but it is > my understanding that designed expert is support to help IANA to keep > the registries usable.
Absolutely. And, you have done a fine job of that so far (certainly better than I could have done). In my mind, keeping serious proposals for IKEv2 functionality out of the registry does not keep it useful. > If I have to be able to defend all my decisions to reject things based > on the RFC4306 only, there is no way I can reject anything as the only > text in there is text which says: > > ---------------------------------------------------------------------- > Note: When creating a new Transform Type, a new registry for it must > be created. > > Changes and additions to any of those registries are by expert > review. > ---------------------------------------------------------------------- You can reject whatever you want, subject to IETF review. This thread is that review, ahead of time. I am disagreeing with your apparent decision to reject these ahead of time. >>> I have stated my reasons why I consider allocating multiple payload >>> numbers etc for exactly same thing a bad thing. >> >> The three proposals do not do "exactly the same thing": they each >> have different cryptographic and administrative properties. This has >> been widely discussed in the WG. > > Note that I did not claim that three proposals are "exactly the same > thing", I said that the payload types they allocate are "for the > excatly same thing", i.e. transfering secure password protocol > specific data between the peers. And SHA-3 will do "exactly the same thing" as SHA-2: will you not allocate code points for it? :-) > In RFC4306 we do not have separate KE payload allocated for each > different key type (one for ECP, one for MODP etc). Same goes with the > CERT/AUTH etc payloads. The RFC4306 usually allocates one payload > number for one specific purpose and if multiple different formats for > the same thing is needed then there is subtype inside this payload. > This is true for KE/IDi/IDr/CERT/CERTREQ/AUTH/TSi/TSr/CP payloads at > least. SA/N/D payloads hava protocol ID inside which then changes the > values going after it. Actually only the Ni/Nr/V and EAP payloads do > not have subtype inside, and in EAP case there is subtype, but it is > inside the EAP payload. > > I.e. the current RFC4306 use of payloads do use subtypes a lot and > those subtypes change the payload format inside the main payload. Sure, but that is because we knew which values we wanted when we wrote IKEv2. Today, we are talking about extensions. > We do have two numbers for the same payload in the RFC4306 case, > especially for TSi/TSr and IDi/IDr, but this is because both of those > payloads (i.e. TSi/TSr and IDi/IDr) can happen in the same message, > and we wanted to remove the ordering restriction from there, meaning > instead of relying on the payload order to decide which of them is > initiator payload (TSi/IDi) and which is responder (TSr/IDr) we have > separate numbers for them. On the other hand we also use Ni/Nr for > nonces, but they only have one payload number allocated for them as > they can never happen in the same message, thus it is easy to see > which one is which. > > There are similar reasons why there is no need to allocate separate > exchange type for each of the protocols (all of them follow the > similar payload exchanges which are already done for the EAP, and we > didn't allocate separate exchange type for IKE_AUTH when used with > EAP, so we should not do it here too). > > To come back to the "The tree proposals do not do exactly same thing", > I do also consider the tree proposals do the same thing; they provide > solution to exactly same problem. They do have technical differences, > but they provide solution to the same problem, which I do consider > meaning they are do same thing. Thank you for giving the fuller explanation of your thinking. However, I still don't think that justifies rejecting ahead of time the idea that each gets its own IANA allocation: it just argues more effectively for your current draft on how to negotiate them. I think those two are completely separate discussions, which is why I changed the subject on this thread. >>> I am not sure whether we are doing that in the future or not. I want >>> to think more about this and see the actual protocols before deciding. >> >> This should be a WG/IETF decision, not that of a single person. > > How on earth can you interpret statement saying "I am not sure whether > *we* are doing that in the future or not." to indicate that it will be > a single persons decision? The "I" part. The expert reviewers for some IANA registries seem to think that they are the ones who do this consideration, and your use of "I" instead of "we" concerned me. (This could be an English/Finnish thing...) > I *as a community member* and as a designated expert do want to think > more about this before giving my input about this in future, and I do > not want to close our options now. Yay! We are in agreement then. > Also the WG will most likely be closed before those decisions needs to > be done. If I will get asked input from IANA as designated expert, I > will of course ask input from the community (ipsec-list) too, but the > list has not been as active as you would like to get input for > different things lately. If you have questions about what you are doing as expert reviewer, by all means please start discussions on this list, regardless of whether it is a WG or not. > Note, also that those documents will most likely come from the other > working groups and go through their own WGLC and then go to the IESG, > and they might have separate IANA registries and separate designated > etc. And this list should discuss that as well. > This part of the discussion is bit early, but as it is the problem > that I can see that the designated expert of the ikev2 registries > might see in the future (how far in future is different thing), and I > happen to be the designated expert now, I want to think about this > early, not only after the problem is there. Assuming you mean "we" instead of "I" there, we are in complete agreement. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
