Joel, thank you very much for uncovering this issue, and thank you Daniel for addressing it. I have balloted no-obj for tonight’s IESG telechat for this document.
Jari On 08 Oct 2015, at 19:18, Joel M. Halpern <[email protected]> wrote: > That would work very well for me. Thank you for addressing my concerns. > Yours, > Joel > > On 10/8/15 10:20 AM, Daniel Migault wrote: >> 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 protected]] >> Sent: Friday, October 02, 2015 1:25 PM >> To: A. Jean Mahoney; General Area Review Team; >> [email protected] >> 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. >> >> 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: >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
