Dan Harkins writes: > I voiced support but there was some opposition along the lines of: > > * we cannot update the IANA registry of an obsoleted protocol. > * it is not appropriate for a protocol other than RFC 2409 to use > the IANA registry created by RFC 2409. > > Both of these are wrong. RFC 5114 updated this very same registry > after RFC 2409 was obsoleted and there was no hullabaloo over > that action.
When draft-lepinski-dh-groups was discussed in the ipsec-list we were most concerned about the format of the KE payloads and so on, and I do not think anybody actually even reacted to the fact that it updates IKEv1 registry too. At that point it was also 2 years since the IKEv1 was obsoleted, now it is 7 years, so I do think there is a difference. > And RFC 5931 (EAP-pwd) uses that registry and it > got approved for publication long after RFC 2409 was obsoleted, > again without any hullabaloo. Never knew that RFC 5931 is using that same registry. This was not pointed out in the IPsec list, thus I think most peoples just didn't realize the issue. The fact that it uses the registry of the obsoleted IKEv1 protocol, is said like this in the RFC: The Group Description field value is taken from the IANA registry for "Group Description" created by IKE [RFC2409]. There is no link to the registry itself, no IANA considerations section comment, only saying the group description field is taken from that registry. I think one of the problems we have in IANA registries is that, we do not have back pointers. I.e. it is impossible to know which protocols use which registries. If the protocol just uses (instead of making additions to it) the IANA registry, there is no need for IANA actions, thus IANA (or the expert or WG etc) is not even aware of the fact that some protocol is using some registry. Perhaps we should start adding some kind of back pointers to the IANA registries, i.e. which protocols use which registry. > There is no valid process reason to not just let Johannes's draft > update the IKEv1 registry while it's updating the IKEv2 registry > (just like RFC 5114 did) and there is precedence which we could > just follow to avoid all this mess. It is time to stop updating obsoleted IKEv1 protocol. Even when there has been case where it was approved 5 years ago, that does not mean we are going to do it forever. > In spite of that. it was decided to not update the IKEv1 registry > with the Brainpool curves. When IEEE got wind of this, they sent > a request, via the IEEE-to-IETF liaison, to please reconsider since > they have more than 1 protocol used in 802.11 that reference > that registry (i.e. it's not just SAE). I could not find any other protocol than SAE, can you give me references to which other IEEE protocols use that registry directly (i.e. not through some RFC). > The concern was that there may be administrative or regulatory > reasons for some entity to desire or require using the Brainpool > curves and 802.11 wants to ensure that it can be used everywhere, or > at least not prohibited from being used because of a misguided > effort by the IETF to kill off use of a different protocol. Which is exacty the reason why protocols should not reuse registries from other protocols. If IETF wants to kill of some protocol, it should be able to do so. And if IETF wants to say that there is no more additions to that protocol, that should be possible, even when some other STD (or RFC) uses that protocol. > It is the nature of this reconsideration-- forbid IKEv1 from using > the updated registry or create some new registry and forbid IKEv1 > from using it-- that is causing this whole kerfuffle. IEEE 802.11's > long (from our standpoint) revision schedule is not the cause of > the problem here. I do not think IEEE revision schedule is that long. Our drafts to RFCs cycles are around 2-4 years in normal case (and close to 10 years for slow documents) I do not think IEEEs revision cycle is that long. I think there is also errata for IEEE documents, but I do not know how that works. There is also some kind of faster and more lightway way of making some fixes/additions to documents, at least that was told to me in the 802.15.9 session when we were talking about that we need some changes to some other documents. For example I think updating the pointer from IKEv1 registry to its own registry for this IEEE document is something that could be done on errata. Checking at the errata documents for other IEEE documents (http://standards.ieee.org/findstds/errata/index.html) they do seem to change things like "32 s" -> "32 µs", which is quite big technical change (http://standards.ieee.org/findstds/errata/802.11h-2003.pdf), compared to this pointer change. Especially if the IKEv1 registry is made so that it points to the new registry, so regardless whether IEEE users notice the errata or not, they finally get to the right place. > So my preference would be to follow existing precedence and let > Johannes's draft update both registries without any ridiculous notes. > If that were to happen we could let my draft die a natural death and > end the kerfuffle. If that just cannot be then I'll update my draft to > reflect your proposed edits, with the modification that this is not just > for SAE and not just for 802.11. You should actually enumerate for which protocols it is then. If there is even more than 802.11 SAE and RFC 5931, then it will affect the discussion here. For example the RFC5931 can be Updated by your new draft and RFC 5931 should now use the newly created registry for groups, and we can add another note to the old IKEv1 registry pointing RFC 5931 users to this new registry. > Also, if you want to limit the number of curves (item #4) you should > coordinate with Johannes on his draft for the IKEv2 registry as well > as his TLS draft. Yes. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
