Protocol Support for High Availability of IKEv2/IPsec
RFC 6311

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

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-04-26)
No email
send info
I also have a few minor suggestions you might consider to help polish the document

---

I missed a reference to RFC 6027 in Section 1.

---

Please consider whether a reference figure showing a "cluster" would
help the reader.    

---

Section 1

   This document proposes an extension to the IKEv2 protocol to solve
   the main issues of IKE Message ID synchronization and IPsec SA replay
   counter synchronization and gives implementation advice for others.
   Following is a summary of the solutions provided in this document:

This is a Standards Track document, so you "define" not "propose".

Ditto Section 5

Additionally could you clarify "for others"? I think this is "to
address other issues."

---

It would be helpful if this document made a distinction between 2119
langauge for behavior that is defined in this document and behavior
defined in another document (such as the based spec.) Perhaps use 
lower case for behavior defined elsewhere, and include an explicit
reference to where the behavior is defined.

---                                  

I think:

10.  Interaction with other drafts

...should s/drafts/specifications/

(Stephen Farrell) No Objection

Comment (2011-04-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- I guess there's a 4th case for the list on the end of p10 - that
the newly active member does neither if the peer didn't support this
spec. Maybe worth a mention.

- 5.2 says a "rekey SHOULD follow shortly..." is that really 2119
language or just what's going to happen when you add a large 
increment? If the latter, then maybe s/SHOULD/is likely to/

- 6.4: The sentence "Note that this solution requires that
all these Child SAs either use or do not use Extended Sequence
Numbers" seems odd - I guess you mean "requires that either all 
Child SAs use Extended Sequence Numbers or else that no Child SA 
uses Extended Sequence Numbers," which is different. 

- a nit, 5.1, 1st sentence; s/two counter value/two counter/values/

(Russ Housley) No Objection

Comment (2011-04-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the editorial comments from the Gen-ART Review by
  Alexey Melnikov on 9-Apr-2011.

(Pete Resnick) No Objection

Comment (2011-04-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please insert in section 6, just before 6.1.

   All multi-octet fields representing integers are laid out in big
   endian order (also known as "most significant byte first", or
   "network byte order").

(This should have appeared at the top of section 3 of RFC 5996, but unfortunately it only appears in section 3.1. Just trying to avoid confusion.)

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

Comment (2011-04-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please add a little more detail to the examples on page 22 (explain what the tuples represent), and verify that the examples are correct.

(Jari Arkko) Recuse