Sean Turner writes: > From the discussion following publication, it's still clear the dual > use of the registry is still unloved. I share that view. I think it
Actually as Dan pointed out it is not only dual use, as there is other protocols using the registry. I think this makes it even more clear that we want them to refer to another registry, not reuse the IKEv1 registry. > comes down to this: > > - On the one hand, putting "not for IKEv1" in the notes column assumes > that whoever consults the registry will make note of the note and not > implement (or ask for them to be implemented) the code points in IKEv1. > Concerns have been expressed that the note won't be enough to stop > people asking for IKEv1 products to support these new code points - not > thrilled about this prospect. And next questions comes to implementors reading the registry: "This is IKEv1 registry, and these entries are 'not for IKEv1', so for what reason they are added here?" Which means we still need to add pointer to other protocols / specifications using the registry. > - On the other hand, getting the IEEE spec to point to a new registry is > (or might be) a no-go because of their publishing cycle. Assuming the > IEEE spec can't be changed and we don't assign the code points, I'm sure > some kind of inter-SDO struggle/spat will occur - not thrilled about > this this prospect either. Actually we should propably make formal request to ask from IEEE what other options there are, i.e. I know they have errata, they also make amendments which are then rolled in to the their actual standards, and most implementors actually already implement those amendments as soon as they are ready. I also think they have some kind of maintenance process which is allowed to make changes (additions etc) to the standards without going through the full amendment process for simple things (for example allocating just one number). I think all this also depends on the working group (i.e. 802.11 here), so it would need to get some 802.11 WG officials to answer whats their processing rules for all those. Unfortunately I was not able to be in the last IEEE interm meeting, and I am going to miss next plenary too, so I cannot ask those questions from the people who know more in person. > In this unfortunate situation, I'd like everyone to consider the (third > surgically attached) hand that shares the burden: reserve the code > points for 802.11 SAE in the Group Description registry, be very > explicit about it in the draft/regstry, and then point from the Group > Description registry to another registry (thanks to whoever suggested > this at the secdir lunch we probably should have explored this more). > The burden is then shared by the IETF assigning code points for > something some despise/dislike and the IEEE implementers following an > additional link from the registry they've already got to consult (they > have to follow the link because the registry values aren't copied to > their spec). The registry entries would appear as follows (well Value, > Group, Reference, and Notes would normally appear on one line but it > wraps in email and I thought this would be easier to follow): I think that would be good way forward. Also it might be possible to make errata for their specification to point to the right registry directly. There is also the RFC 5931 which reuses same registry. Is there other RFCs? > #4) Pick fewer curves. Not sure which ones but if we end up doing > brainpool in TLS I'd like to see us pick the same ones. Not sure which > ones those will be. I'm thinking like 3 - probably lining up with the 3 > ECP groups. Actually if the new registry is going to be Generic Group Description registry, I see no reason to limit the number of groups that it can include. It will most likely be 16-bit registry or similar, thus there is enough space for everything. On the IKEv2 and TLS we can limit the number of groups if we like, but I see no reason why this generic "group description" <-> "group number" registry should be limited to only certain groups. Actually it could be something like "first come first served"-allocation policy and anybody could allocate any group from there just to get number it can use in other protocols. If this is going to be registry only for IEEE 802.11 SAE, then we most likely need to ask from them what do they want to have for allocation policy. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
