Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 7791

Note: This ballot was opened for revision 06 and is now closed.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-12-01 for -06)
No email
send info
I don't have any substantive comments, but do have a number of editorial comments:

- Abstract:
-- The abstract seems unnecessarily long, can it be edited down? I suggest moving most of the text into the introduction and creating a much shorter abstract.
-- 2nd paragraph, second sentence: "... using multiple interfaces requires to set up an IKE SA..."
There appears to be a missing word after "requires". That is, requires _what_ to set up the SA?  (Alternately, "...requires an IKE SA to be set up...")
-- Please expand MOBIKE on first use (both in the abstract and in the body).

- Section 2, 2nd paragraph after Figure 3: 
-- s/"In case of IPsec it means..."/"In the case of IPSEC, this means..."
-- s/"drawback of such approach"/"drawback of such an approach"
-- What does "transactionally" mean in context of "transactionally synchronized"? Is that different than just "synchronized"?
-- s/"The drawback of such  approach is that it requires new IKE SA"/"The drawback of such _an_approach is that it requires new IKE SA"

- 2, third paragraph from end:  "the VPN End User and the Security Gateway wants to move"
s/wants/want

-4, first paragraph:
-- The language "The goal of the document..." makes it sound like there is a chance the document might fail to achieve the goal. I assume that is not the intent. I suggest reformulating along the lines of "This document specifies..."
-- "without performing an authentication."
without performing a _new_ authentication?

- 5.2, 2nd paragraph from end:
I don't understand the phrase "If the CREATE_CHILD_SA request concerns an IKE SA rekey ..." Maybe s/concerns/requests?

-5.3, 4th paragraph:
s/"In some cases responder..."/"In some cases, the responder..."

- 8, third paragraph:
Does this talk about resource exhaustion in general, or a resource exhaustion _attack_?

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-12-02 for -06)
No email
send info
- General: What'd happen if I used MPTCP with this? In particular
with the multiple client i/f version. It should work I guess but I
wonder if anyone's thought about any corner case issues (e.g. 
timing) that might come up?

- section 4: "would be deleted" is too vague really - what did
you want to see happen? 

- section 2: I don't get the last paragraph. What's that mean?

nits:

- General: There are many minor grammatical issues, e.g. cases of
missing "an" or "the." It'd be nice to fix those before the RFC
editor has to.

- section 2: typo: "with with"

(Joel Jaeggli) No Objection

Comment (2015-12-02 for -06)
No email
send info
needs an editorial scrub for clarity, bens review is spot on.

Barry Leiba No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection