Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2
RFC 5903

[Ballot discuss]
Discuss has been further updated after document updates.

The only remaining issue is...

--
Although the only change in the registry is to the referenced RFC,
shouldn't this bevertheless be shown to the designated expert for
the registry?
--

This is with Tim Polk to resolve.

[Ballot discuss]
Discuss has been updated after telechat

I appreciate that the changes to the document are very small, and I hope that these Discuss issues are equally small and can be resolved simply.

--
It is really helpful if a bis revision of an RFC includes a section
that sets out the changes from that RFC.
--
Although the only change in the registry is to the referenced RFC,
shouldn't this bevertheless be shown to the designated expert for
the registry?
--
I am not sure what the value is of using 2119 langauge in this
Informational document. For example in 3.1...
  IKE and IKEv2 implementations SHOULD support an ECP group with the
  following characteristics.
Does this Informational document attmept to direct the content of IKEv2
implementations? Doesn't that mean that it has to be PS and update 4306?

[Ballot discuss]
Should this document also update RFC 5114? (The format of KE payloads
and shared secret is specified on group-by-group basis, and
5114 defines two new ECP groups that use the RFC 4753 version
of shared secret/KE payload. Note that

Given the confusion about the KE payload/shared secret encoding,
I think Section 8 should explicitly note that some other
elliptic curves (such as those in RFC 2409) might use different
formats.

I agree with Adrian that the document should be clearer about what's
being changed compared to RFC 4753, and the reasons for this change
(especially since the text in RFC 4753 is not unambiguous, and is
a totally reasonable design decision).

[Ballot discuss]
I appreciate that the changes to the document are very small, and I hope that these Discuss issues are equally small and can be resolved simply.

--
It is really helpful if a bis revision of an RFC includes a section
that sets out the changes from that RFC.
--
Although the only change in the registry is to the referenced RFC,
shouldn't this bevertheless be shown to the designated expert for
the registry?
--
Shouldn't you update the reference to RFC 2409 to read RFC 4306 and
remove all reference to IKE (not IKEv2)? It is my understanding that
4306 obsoleted 2409, so we should no longer be describing extensions
to 2409
--
I am not sure what the value is of using 2119 langauge in this
Informational document. For example in 3.1...
  IKE and IKEv2 implementations SHOULD support an ECP group with the
  following characteristics.
Does this Informational document attmept to direct the content of IKEv2
implementations? Doesn't that mean that it has to be PS and update 4306?

IANA comments:

Upon approval of this document, IANA will replace the references to
RFC4753 with references to this document for the following registrations:

Transform Type 4 - Diffie-Hellman Group Transform IDs

19 256-bit random ECP group
20 384-bit random ECP group
21 521-bit random ECP group

See
http://www.iana.org/assignments/ikev2-parameters


Group Description

256-bit random ECP group 19
384-bit random ECP group 20
521-bit random ECP group 21

See
http://www.iana.org/assignments/ipsec-registry