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
