Skip to main content

Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
draft-harkins-brainpool-ike-groups-04

Yes

(Sean Turner)

No Objection

(Benoît Claise)
(Gonzalo Camarillo)
(Martin Stiemerling)

Abstain

(Brian Haberman)
(Ron Bonica)
(Stewart Bryant)

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

Sean Turner Former IESG member
Yes
Yes () Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-02-25) Unknown
- 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)

typos:

- 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:-)
Wesley Eddy Former IESG member
No Objection
No Objection (2013-02-27) Unknown
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.
Barry Leiba Former IESG member
Abstain
Abstain (2013-02-25) Unknown
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.
Brian Haberman Former IESG member
Abstain
Abstain () Unknown

                            
Pete Resnick Former IESG member
Abstain
Abstain (2013-02-26) Unknown
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 Former IESG member
Abstain
Abstain (2013-02-26) Unknown
Please see Russ' Abstain position. This is a unique situation, and the pattern should not be followed.
Ron Bonica Former IESG member
Abstain
Abstain () Unknown

                            
Russ Housley Former IESG member
Abstain
Abstain (2013-02-24) Unknown
  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.
Stewart Bryant Former IESG member
Abstain
Abstain () Unknown