IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)
draft-ietf-ipsec-ike-auth-ecdsa-06

Note: the reference to draft-ietf-ipsec-ike-ecp-groups is a downref.

Nits from Gen-ART review by Gonzalo Camarillo:

The boilerplates should be updated to be compliant with current IETF policies.

Acronyms in the title of the draft should be expanded.

In section 3, the draft says: The document defines the following... the phrase would be clearer if it said instead: *This* document defines...

The second paragraph of page 4 refers the IANA registry by giving a pointer to a reference ([IANA]). The reference [IANA] points to the registry using its URI. IANA registries should not be referenced by their URIs; they should be referenced by their names. In this case, "The IANA Registry for IPSEC Authentication Methods". This should be changed in both Sections 3 and 5.

The Security Considerations and IANA Considerations Sections are typically the last sections before the References and the Authors' Addresses. This draft has a section (Section 6) after the IANA Considerations section. I suggest that that section is converted into an appendix or moved before the Security Considerations Section. 

Nits from Last Call review by Elwyn Davies:

s1, para 2 contains the assertion 'For any given level of security against the best attacks known, ECDSA signatures are smaller than RSA signatures and ECDSA keys require less bandwidth than DSA keys; there are also advantages of computational speed and efficiency in many settings.'  If the reference [LV] backs up this assertion it would be good to reference it here also.  If not it would be good to have some other reference that justifies this assertion.

(actually editorial+): s5: It would be useful to give the three methods mnemonic names which can be placed in the IANA registry and document them in s5.


s1: Acronyms IPsec, RSA and DSA need expansion.

s3: Acronym MAC needs expansion.

s3, table: To avoid confusion with references, the code points (e.g., [19]) currently enclosed in square brackets would be better in round brackets.

s6: It might be helpful to explicitly bracket y^2 = x^3 - 3 x + b  modulo p   - I think this is supposed to be y^2 = (x^3 - 3 x + b)  modulo p

s7.1: BTW IKEv2 has made it to RFC - RFC4306.

Has significant idnits.