Last Call Review of draft-mglt-ipsecme-clone-ike-sa-05
review-mglt-ipsecme-clone-ike-sa-05-genart-lc-halpern-2015-10-02-00
Request | Review of | draft-mglt-ipsecme-clone-ike-sa |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2015-10-27 | |
Requested | 2015-10-01 | |
Authors | Daniel Migault , Valery Smyslov | |
I-D last updated | 2015-10-02 | |
Completed reviews |
Genart Last Call review of -05
by Joel M. Halpern
(diff)
Secdir Last Call review of -05 by Alexey Melnikov (diff) |
|
Assignment | Reviewer | Joel M. Halpern |
State | Completed | |
Request | Last Call review on draft-mglt-ipsecme-clone-ike-sa by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 05 (document currently at 09) | |
Result | Almost ready | |
Completed | 2015-10-02 |
review-mglt-ipsecme-clone-ike-sa-05-genart-lc-halpern-2015-10-02-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 < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-mglt-ipsecme-clone-ike-sa-05.txt Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2) Reviewer: Joel M. Halpern Review Date: 2-Oct-2015 IETF LC End Date: 27-Oct-2015 IESG Telechat date: N/A Summary: This document is nearly ready for publication as a Propsoed Standard RFC. Major issues: The introductory material talks about the case where both sides have multiple interfaces. It is not clear what will happen with this mechanism in that case. In particular, if I have two systems, with three interfaces, it seems that this will start by creating the S1-D1 Security Association. It seems straightforward for each side to create their simple additional assocations (S2-D1, S3-D1, and S1-D2, S1-D3). But the introduction suggests that we also want to create S2-D2, S3-D3, S2-D3, and S3-D2. With no other guidance, it appears that both sides will try to create all four of those, creating 8 security associations instead of 4. I hope that I have simply missed something in the document that resolves this. Minor issues: Nits/editorial comments: