Subject: [Gen-art] A new *batch* of IETF LC reviews - 2015-10-01

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 1 Oct 2015 17:05:45 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Dan Romascanu     2015-10-08   draft-ietf-ospf-rfc4970bis-04

David Black       2015-10-08   draft-ietf-ospf-node-admin-tag-05

Elwyn Davies      2015-10-26   draft-ietf-ipfix-mib-variable-export-09
   
Francis Dupont    2015-10-13   draft-ietf-cdni-media-type-03

Joel Halpern      2015-10-27   draft-mglt-ipsecme-clone-ike-sa-05

Jouni Korhonen    2015-10-27   draft-santesson-auth-context-extension-09

Meral Shirazipour 2015-10-14   draft-ietf-pcp-port-set-10

Paul Kyzivat      2015-10-15   draft-ietf-aqm-ecn-benefits-06

Pete Resnick      2015-10-15   draft-ietf-aqm-fq-implementation-02

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The /updated/ template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 2 Oct 2015 13:25:28 -0400

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:

---

From: Daniel Migault <[email-masked]>
Date: Thu, 8 Oct 2015 14:20:30 +0000

Hi Joel, 

Thank you for taking time to review and comment the draft. 

We propose to add the following text to clarify the example in section 2 before the two last paragraphs. The following text expects to clarify the following points:
   - 1) The creation of VPN is a local policy matter
   - 2) Moving one duplicated VPN to different interfaces may involve multiple MOBIKE operations
   - 4) There is no needs to create all possible VPNs ( might be similar to item 1)

The following text has been added to our local copy. If you would like us to publish a new version, feel free to let us know. Our intention is to keep the updates local until you ask us to publish the draft.  

BR, 
Daniel and Valery

NEW TEXT -- BEGIN
Note that it is up to host's local policy which additional VPNs to create and 
when to do it. The process of selecting address pairs for migration is 
 a local matter. Furthermore, in the case of multiple interfaces on 
 both ends care should be taken to avoid the VPNs to be duplicated by both ends or moved to the both interfaces.

 In addition multiple MOBIKE operation may be involved from the 
 Security Gateway or the VPN End User.
 Suppose, as depicted in Figure 3 for example that the cloned VPN is 
 between Interface _0 and Interface_0', and the VPN End User and the 
 Security Gateway wants to move it to Interface_1 and Interface_1'. The 
 VPN End User may initiate a MOBIKE exchange in order to move it to 
 Interface_1, in which case the cloned VPN is now between Interface_1 
 and Interface_0'. Then the Security Gateway may also initiate a MOBIKE exchange in order to move the VPN to Interface_1' in which case the VPN has reached its final destination.
NEW TEXT -- END

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, October 02, 2015 1:25 PM
To: A. Jean Mahoney; General Area Review Team; [email-masked]
Subject: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

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.

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:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 8 Oct 2015 12:18:33 -0400

That would work very well for me.  Thank you for addressing my concerns.
Yours,
Joel