Skip to main content

Last Call Review of draft-ietf-ipsecme-dh-checks-04
review-ietf-ipsecme-dh-checks-04-genart-lc-romascanu-2013-05-13-00

Request Review of draft-ietf-ipsecme-dh-checks
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-05-20
Requested 2013-05-08
Authors Yaron Sheffer , Scott Fluhrer
I-D last updated 2013-05-13
Completed reviews Genart Last Call review of -04 by Dan Romascanu (diff)
Secdir Last Call review of -04 by Leif Johansson (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-ipsecme-dh-checks by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 05)
Result Ready
Completed 2013-05-13
review-ietf-ipsecme-dh-checks-04-genart-lc-romascanu-2013-05-13-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may
receive.

Document: draft-ietf-ipsecme-dh-checks-04
Reviewer: Dan Romascanu
Review Date: 5/13/13
IETF LC End Date: 5/20/13
IESG Telechat date:

Summary:

This document is Ready. It is clearly written and easy to follow, even for a
non-expert in security. I appreciated the sections that describe the transition
to implementations that support the update and the ones that describe behavior
upon test failures - which are of value to implementers and operators. One
minor issue related to the IANA registry may be only an issue of clarification.

Major issues:

Minor issues:

The IANA Considerations Sections mention that Groups 27-30 have been recently
defined in [I-D.merkle-ikev2-ke-brainpool]. This is an Informational Reference
which is somehow odd, because without this reference the IANA actions could not
be completed. On the other hand making [I-D.merkle-ikev2-ke-brainpool]
Normative Reference would create a downref because the later is informational.
I believe this is OK, because I see the document in RFC Editor Queue waiting
for IANA actions, which may actually be exactly the ones described in this I-D,
but a cleaner solution would have been not defining at all Groups 27-30 here.

Nits/editorial comments: