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). 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. Also we do make mistakes, and we are supposed to be able to fix them. If we are never allowed doing anything else than what was done before, there is no way we can fix mistakes afterwards as this is how it was done once before, this is how it must be done forever in the future too. > 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? > 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... 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
