On Fri, October 12, 2012 4:56 am, Tero Kivinen wrote: > Dan Harkins writes: >> Again, this could've been just like RFC 5114-- no fuss, no mess, >> no hullaballo. If precedence has been followed, none of this nonsense >> would've happened. > > It is even easier to just drop the whole issue, and leave brainpool > curves completely out, no fuss, no mess, no hullaballo. There has been > precedence for that too, we have had proposals for IKEv1 which have > been dropped and never gone forward or never even implemented (for > example my revised hash format, notify message payload format etc).
You're conflating two different issues. This has nothing to do with the protocol. > All additions / modifications etc do require some considerations > before they are accepted. Things in the documents are not same (for > example number of groups, the fact that 5114 already defines ECP > groups for IKEv1 etc), time is not same (IKEv1 has been obsoleted > almost 5 more years after the 5114 was published) etc. But this is not a modification. This is an RFC required change to a registry. We're talking about making an RFC to update the registry. >> I have a draft that will need to get updated and the clock is >> ticking on that (cut-off date is 22 Oct). I need to know what you >> want my draft to say. > > What is this draft you are refering here? Some IETF draft or some IEEE > document? The draft that is referred to in the subject of this email. The draft that is going to end up having all these nonsensical notes and pointers and crap in it. That draft. >> Can you ask the IESG to just do what it has done in the past? That is, >> just update the registry to include code points for new curves without >> any bizarre notes or pointers? No fuss, no mess, just a few new rows >> in a table. > > How about asking instead that do nothing, do not update the registry, > and if IEEE has problems with that they can fix their document to > refer to their own registries, or ask IANA to allocate new registry > which they can manage and use that... We've already been through that. It's not a productive use of time to bring this up again. > I think the compromise Sean is proposing (i.e. add them as reserved > values to the IKEv1 registry, add note to point them to new registry > which defines them and create that new registry containing them) is > good proposal, and I do not see why you are so much against it? It > will allow using the groups in the IEEE, it does add one extra > redirection, but only implementors should ever need that thus they > should be able to follow pointers, it makes it clear for IKEv1 > implementors that these numbers are not for IKEv1, which will make > some people (including me) happy. It's not so much that I'm against this, it's that there is this huge discussion about notes and pointers and whether people will respect the notes and whether they can follow the pointers and making sure there is a sufficiently large enough firewall to keep IKEv1 implementers out while allowing others in... All of this is manufactured. These are all solutions to problems that we are imposing on ourselves. If we just decide not to impose those problems on ourselves then there is no need for these convoluted and ridiculous "solutions". H.L. Mencken once said that "puritanism is the haunting fear that someone somewhere might be having a good time." I think you have a haunting fear that someone somewhere might actually be working on IKEv1. And because of this haunting fear of yours you have succeeded in creating the problems and issues that require this convoluted and bizarre "way ahead" that we are all discussing. All of these problems just go away if we follow process and precedence. If you will just stop being afraid that someone somewhere might do something you don't like we can get this nonsense behind us. We're discussing a way ahead in this thread. I think that way is clear: let's just let Johannes follow the path that draft-lepinski-dh-groups did. A short, simple draft to update both registries without any cruft and notes and pointers and nonsense. It's easy, it's problem-free! Dan. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
