Last Call Review of draft-ietf-ipsecme-qr-ikev2-09
review-ietf-ipsecme-qr-ikev2-09-genart-lc-holmberg-2019-12-13-00
Request | Review of | draft-ietf-ipsecme-qr-ikev2 |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2019-12-25 | |
Requested | 2019-12-11 | |
Authors | Scott Fluhrer , Panos Kampanakis , David McGrew , Valery Smyslov | |
I-D last updated | 2019-12-13 | |
Completed reviews |
Secdir Last Call review of -09
by Watson Ladd
(diff)
Genart Last Call review of -09 by Christer Holmberg (diff) |
|
Assignment | Reviewer | Christer Holmberg |
State | Completed | |
Request | Last Call review on draft-ietf-ipsecme-qr-ikev2 by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/t51j90-apJSrRRimcq9isuCcTnQ | |
Reviewed revision | 09 (document currently at 11) | |
Result | Almost ready | |
Completed | 2019-12-13 |
review-ietf-ipsecme-qr-ikev2-09-genart-lc-holmberg-2019-12-13-00
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. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ipsecme-qr-ikev2-09 Reviewer: Christer Holmberg Review Date: 2019-12-13 IETF LC End Date: 2019-12-25 IESG Telechat date: Not scheduled for a telechat Summary: The document is well-written, and almost ready for publication. However, I have a couple of minor comments that I would like the authors to address. Major issues: None Minor issues: Q1: The Security Considerations lists IKEv2/IPSec algorithms that are not considered quantum-resistant. However, that is not mentioned anywhere else. I think it would be good to mention that in the Abstract and/or Introduction. Q2: Section 3 says: "If the responder does not support this specification or does not have any PPK configured, then it ignores the received notification and continues with the IKEv2 protocol as normal." I assume the ignoring of a non-supported notification and continuing with normal IKEv2 is part of the IKEv2 specification. If so, I suggest to say add something like: ", as described in RFCXXXX." Nits/editorial comments: Q3: The Security Considerations talk about the Grover's algorithm. Please add a reference.