IPsec Cluster Problem Statement
RFC 6027

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

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.

(Russ Housley; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Sean Turner; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (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.

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Harrington; former steering group member) No Objection

No Objection (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.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ()
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) (was Yes) Recuse

Recuse ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info