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. > . . . > > Designated experts are expected to be able to defend their decisions > to the IETF community, and the evaluation process is not intended to > be secretive or bestow unquestioned power on the expert. Experts are > expected to apply applicable documented review or vetting procedures, > or in the absence of documented criteria, follow generally accepted > norms, e.g., those in Section 3.3. > > I do not believe that you can defend a decision to reject > registrations based on what is in RFC 4306. If you disagree, please > show which text you are referring to. 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. ---------------------------------------------------------------------- So if someone sends IANA a request (note, you do not even need Internet-Draft or RFC) saying that he made typo in his code and wrote 53 instead of 3 for his 3DES algorithm number and now wants to make new allocation saying that 53 means ENCR_3DES, then I do not have any way to say that this should not be allowed to IANA, as RFC4306 does not give such option. Or if someone wants to change numbers like Diffie-Hellman Group Transform ID 19 to mean completely something else than what it means now (which actually did happen, and during that discussion area directors managed to convince me that it would be better to accept that change of existing codepoint, and not allocate new codepoint for this new use). What is the point of having designated expert if there is nothing he can do than to follow RFC creating the registries, especially when those RFCs do not give any specific instructions? My undestandating has been that as the RFCs creating the IANA registries do not include exact rules for allocations then it is designated experts responsiblity to interpreted what could have been said in the RFC in question for those allocations. This would mean things like "do not make changes to existing code points which are not needed", "do not make duplicate allocations for existing code points without good reason" etc. In some cases it is needed to do that kind of things, like there was in the ECP group i.e. some of the existing vendors had already used the number in question that way and it was seen that those vendors were important enough and slow enough that they would never update their products to new numbers if such numbers would be allocated. In some cases there is no need to break those unwritten rules. This is the case where I do not see real reason to break those unwritten rules which say "no duplicate codepoints for the same thing". Of course people who are unhappy with the work of the expert are allowed to appeal to the IESG about every decision the expert makes. > > 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. 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. 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. > > 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? 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. 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. 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. 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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
