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 rev. 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
Draft last updated 2015-10-02
Completed reviews Genart Last Call review of -05 by Joel Halpern (diff)
Secdir Last Call review of -05 by Alexey Melnikov (diff)
Assignment Reviewer Joel Halpern
State Completed
Review review-mglt-ipsecme-clone-ike-sa-05-genart-lc-halpern-2015-10-02
Reviewed rev. 05 (document currently at 09)
Review result Almost Ready
Review completed: 2015-10-02

Review
review-mglt-ipsecme-clone-ike-sa-05-genart-lc-halpern-2015-10-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.

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: