Sean, It was a two-part request. I'd like the IESG to follow the same process they followed for what became RFC 5114.
Is there a way to get an RFC published to update this registry that does not need to go through the IESG? If not then the 2nd part is the critical one; if so then we can just end this fiasco now. regards, Dan. On Thu, October 18, 2012 7:58 am, Sean Turner wrote: > Dan, > > There's not need to ask the IESG about the process to update the > registry in question it's clear: RFC required. You can get an RFC > through a WG, through an AD, or through the ISE. > > spt > > On 10/15/12 10:54 PM, Dan Harkins wrote: >> >> Hi Sean, >> >> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>> >>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>> >>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>> >>>>> I'm going to run my proposal and Michael's by the IESG on an informal >>>>> telechat to see which one's got the best chance of getting through >>>>> the >>>>> process to resolve the IEEE's request. >>>> >>>> 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. >>>> >>>> The worst that could happen if the IESG agrees to do that is that >>>> someone >>>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>>> but they're not zero. And if that happens then so what? Really. So >>>> what? >>> >>> The RFC 5114 example wasn't published to address another SDO request >>> for >>> a code point so I don't think it's the same situation. >> >> That's certainly a distinction but I don't see how that matters. You >> could also >> note that RFC 5114 added MODP groups as well as ECP groups. Also a >> distinction that really doesn't matter. >> >> Again, the SDO request is a _by-product_ of the opposition to just >> letting >> Johannes' draft update the registry. It is this same opposition that is >> creating >> these problems about notes and pointers and the concern over whether >> they >> will have the desired effect and what we should do to ensure they do. If >> this >> opposition had not materialized there never would've been another SDO >> request. >> >> It is the same situation, indulge me here a bit: >> >> What we had was another organization (NIST) came up with some new DH >> groups and there was a proposal to add them to both IKEv1 and IKEv2 >> registries. And now, quite similarly, there's another organization (the >> ECC >> Brainpool) that came up with some new DH groups and there was a proposal >> to add them to both IKEv1 and IKEv2 registries. >> >> When the proposal was made to add the NIST groups to the IKEv1 >> registry there was no hullabaloo over updating a deprecated protocol's >> registry and there was no concern that someone somewhere might use >> the NIST groups with IKEv1. >> >> But when Johannes made his proposal to add the ECC Brainpool curves >> to the IKEv1 registry there was all of a sudden a hullabaloo and much >> concern that someone somewhere might use the ECC Brainpool groups >> with IKEv1. >> >> So my request to you is to ask that the IESG consider what the >> process >> defined for updating this registry is (it's RFC required) and to note >> that >> there is precedence to update the registry of this deprecated protocol. >> So please ask the IESG to just approve a draft (either Johannes' or >> mine) >> for publication as an RFC to update this registry in the same manner >> that >> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >> >> Then there'd be no need for the IESG to have a discussion about the >> (de)merits of notes and pointers in registries and how best to ensure >> that >> no one nowhere ever even thinks about using an ECC Brainpool curve in >> IKEv1 and that certainly sounds like a better use of everyone's time. >> >> regards, >> >> Dan. >> >> >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
