Skip to main content

Last Call Review of draft-ietf-ipsecme-rfc4307bis-15

Request Review of draft-ietf-ipsecme-rfc4307bis
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-12-30
Requested 2016-12-16
Authors Yoav Nir , Tero Kivinen , Paul Wouters , Daniel Migault
I-D last updated 2017-02-02
Completed reviews Genart Last Call review of -15 by Pete Resnick (diff)
Secdir Last Call review of -15 by Phillip Hallam-Baker (diff)
Opsdir Last Call review of -15 by Susan Hares (diff)
Genart Telechat review of -17 by Pete Resnick (diff)
Assignment Reviewer Pete Resnick
State Completed
Request Last Call review on draft-ietf-ipsecme-rfc4307bis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 15 (document currently at 18)
Result Ready w/nits
Completed 2017-02-02
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments. (Apologies for the late submission.)

For more information, please see the FAQ at


Document: draft-ietf-ipsecme-rfc4307bis-??
Reviewer: Pete Resnick
Review Date: 2017-02-02
IETF LC End Date: 2017-01-31
IESG Telechat date: 2017-02-16


This document is basically ready, but there are a large number of nits, so many
that I would think additional review would be desired.

Major issues: None

Minor issues: None

Nits/editorial comments:

[Note: I do not see any particular technical problems with the document, but I
don't have expertise in this area. I have listed below many clarifications and
fixes to typographical and grammatical errors. (I did not note all of the
punctuation errors as none of them left ambiguity.) Normally, I would simply
list these as nits/editorial comments and leave it at that. But there are so
many of these that I'm a bit concerned that the document did not receive
sufficient technical review, given that it went through 15 versions and nobody
fixed all of these editorial issues. That said, that is an issue between the AD
and the WG.]

It seems like section 2 should be moved up above section 1 since these
specialized conventions are used in section 1.

1: The second to last sentence is ungrammatical and hard to read. Try this:

   This document describes the parameters of the IKE protocol and
   updates the IKEv2 specification because it changes the mandatory to
   implement authentication algorithms of the section 4 of the RFC7296
   by saying RSA key lengths of less than 2048 are SHOULD NOT.
   This document describes the parameters of the IKE protocol. It also
   updates the IKEv2 specification because it changes the mandatory to
   implement authentication algorithms of section 4 of RFC 7296
   by saying RSA key lengths of less than 2048 SHOULD NOT be used.

1.1, first sentence: s/then/than

1.1, last sentence: s/in a separate document/in this separate document.

1.2: The last sentence of the third paragraph repeats what is in the last
paragraph of 1.2 and therefore redundant. You can strike it.

2: I suggest adding a sentence after the first paragraph for clarification:
"When used in the tables in this document, these terms indicate that the listed
algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be implemented as part of
an IKEv2 implementation." 4307 never said that specifically, and I've always
found it weird.

3.1, first paragraph: s/an integrity algorithms in Section 3.3/one of the
integrity algorithms in Section 3.3

3.1, third paragraph: s/CRFG/the Crypto Forum Research Group (CFRG) of the IRTF

(You not only didn't define it, you got the acronym backwards.)

3.1, third from last paragraph: s/on those cases/in those cases

3.1, second from last paragraph: s/implementation/implementations

3.1, last paragraph: s/of-the-shelves/off-the-shelf ; s/therefor/therefore

3.3, last paragraph: s/status ware/statuses were

3.4, third paragraph: s/were/was

3.4, fourth paragraph: s/vulnerable to be broken/vulnerable to being broken

3.4, last paragraph: s/thater/that; s/academia have/academia has

4: s/concerned on/concerned with

4.1, first paragraph:

                                           RSA Digital Signature is not
   recommended for keys smaller then 2048, but since these signatures
   only have value in real-time, and need no future protection, smaller
   keys was kept at SHOULD NOT instead of MUST NOT.

        See section 4.1.1 for a discussion of key length recommendations for
        use in RSA Digital Signature.

(If you want, include some of the original text in 4.1.1.

4.1, third paragraph: s/it does not/they do not

4.2, paragraphs 1, 2, & 3: s/When Digital Signature authentication/When a
Digital Signature authentication ; also, strike the word "then" in the first
two paragraphs.