IPsec Cluster Problem Statement
RFC 6027

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

(Russ Housley) Yes

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2010-06-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
INTRODUCTION, paragraph 4:
>    An agreed terminology, problem statement and
>    requirements will allow the IPSECME WG to consider development of
>    IPsec/IKEv2 mechanisms to simplify cluster implementations.

  Suggest to remove text that talks about IETF WGs, which are after all
  ephemeral, from this document before publication as an RFC.

(Adrian Farrel) No Objection

(David Harrington) No Objection

Comment (2010-06-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
1) in 3.7, I think it would make the document easier to read if you spelled out the LS and HS acronyms. 

2) "the other half of the flow" - s/the the/the/
is "the other half" a response, or ...; can you clarify, "the other half" doesn't seem very specific.

3) in 3.8 "this looks weird". I don't think the problem is that it looks weird; it's that the peer might respond to the fact that it looks weird and do something like discard it or filter it, and this would cause problems. Simply saying "it looks weird" doesn't really describe this in a clear and unambiguous manner.

4) "Reply packets might arrive ..." I think this should be discussed in the security considerations

5) in section 2, PAD needs to be spelled out or referenced.

6) aren't RFC2119, IKEv2bis and 4306 normative? Others may be also, but these seem obvious.

Alexey Melnikov No Objection

Comment (2010-06-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think some of the references should be Normative.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Jari Arkko) (was Yes) Recuse