Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
RFC 6932

Note: This ballot was opened for revision 04 and is now closed.

(Sean Turner) Yes

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Wesley Eddy) No Objection

Comment (2013-02-27)
No email
send info
I agree with the principles in others' Abstain positions and with Pete's notion that some of the text from Russ's position should appear in an IESG Note.  I think that if the registry is indeed already overloaded, and if the community and sponsoring AD do think it's the right thing to do at the moment, it does seem odd to suddenly draw the line here, and block this from happening with too many Abstains ... thus I'm balloting No Objection.

(Stephen Farrell) No Objection

Comment (2013-02-25)
No email
send info
- Intro: Would it make sense to add a bit more text e.g.
saying "these were generated by <foo> in <20xx> and have been
widely used since then by <bar> and papers [refs] on their
goodness have been published by <baz>, technial details of all
of that can be found in [EBP] and 5639." You do almost but not
quite say that kind of thing.

- Section 2 nitty nits;-) I'm sure anyone who'd implement
would not need these clarified, but you never know...

   - its confusing to say "x,y" are the co-ordinates of the
   generator G when x,y are used in the equation of the curve
   just above. Wouldn't it be better to use e.g.  x(P_0)
   as used in [EBP]?

   - you don't say what group you mean 

   - you don't say that h or z are for (z is explained well
   enough at the end of section 2 though)


- s/varient/variant/
- s/arithmatical/arithmetic/ I think or maybe arithmetical 
but the RFC editor should know;-)

- And finally: I didn't check the values are all correct vs.
[EBP] or 5639, though I did compare a few bits. I sure hope
someone has:-)

(Martin Stiemerling) No Objection

(Ron Bonica) Abstain

(Stewart Bryant) Abstain

(Brian Haberman) Abstain

(Russ Housley) Abstain

Comment (2013-02-24)
No email
send info
  The use of the Internet Key Exchange (IKE) registry by protocols other
  than IKE is not a good idea.  This overloading results in new registry
  entries that cannot be used by IKE, and it leads to implementer
  confusion for IKE as well as the other protocols that use the IKE
  registry.  That said, the overloading of the IKE algorithm registry
  has been going on for too long to easily correct now.  For that
  reason, I am not blocking the addition of these entries, but I want
  to strongly discourage future overloading of any algorithm registries.

Barry Leiba Abstain

Comment (2013-02-25)
No email
send info
What Russ said.  This is the right thing to do in this case at this time, but is the wrong thing to do in general.

(Pete Resnick) Abstain

Comment (2013-02-26)
No email
send info
If this registry is obsolete, perhaps we should strengthen the note that appear on the registry:

   these values were reserved as per draft-ipsec-ike-ecc-groups
   which never made it to the RFC. These values might be used by some
   implementations as currently registered in the registry, but new
   implementations should not use them.

The note doesn't explicitly say, "This is obsolete. It remains here for historical purposes only and should not be used." Having this document update the note on the registry seems like a good thing to do.

Also, it seems to me that some of the text in Russ's Abstain should appear in an IESG Note in this document. There should probably be explicit text in the document that this is a "bad idea".

(Robert Sparks) Abstain

Comment (2013-02-26)
No email
send info
Please see Russ' Abstain position. This is a unique situation, and the pattern should not be followed.