Sean, The thing is, they're not just for 802.11. RFC 5931 uses them too.
Dan. On Thu, October 18, 2012 9:12 am, Sean Turner wrote: > Dan, > > After talking it over the preferred* approach to answer the 802.11 > request is to include them in the IKEv1 registry (as suggested by > Michael R.) with a tweaked note. Rationale being that if you used what > I suggested you'd have to make sure two registries were updated if a > change was made to the registry at some later time. i.e.,: > > Value > ----- > 27 > ... > y > > Group > ----- > Reserved for 802.11 Brainpool Group 1 > ... > Reserved for 802.11 Brainpool Group n > > Description > ----------- > This specification > ... > This specification > > Notes > ----- > Only for 802.11 - Not for use with IKEv1 > Only for 802.11 - Not for use with IKEv1 > Only for 802.11 - Not for use with IKEv1 > > spt > > * I say preferred because you can try another approach if you want. > > On 10/18/12 10: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 >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
