A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
Note: This ballot was opened for revision 04 and is now closed.
(Russ Housley; former steering group member) Yes
(Bert Wijnen; former steering group member) (was Discuss, No Objection) No Objection
US/American slang hits us in protocol design: Page 7: Notify Message Value R-U-THERE 36136 R-U-THERE-ACK 36137 Aaarrrggghh
(Margaret Cullen; former steering group member) No Objection
Tiny nit, easily fixed in an RFC editor note: Abstract This document describes the method detecting a dead IKE peer that is >> s/the method detecting/a method for detecting
(Ned Freed; former steering group member) No Objection
(Randy Bush; former steering group member) No Objection
(Steven Bellovin; former steering group member) No Objection
This is very close to a DISCUSS... As I understand the situation, the document describes current practice, rather than defining new protocol elements. This is not clear in the text of the document. (It also uses numbers from the private range, which would be exceedingly bad for a standards-track protocol.) The fourth paragraph of the Introduction, which begins "To this end", should start something like this: To this end, a number of vendors have implemented their own approach to dead peer detection. This document describes how they detect peer liveliness without needing ... The abstract (and perhaps the title) should probably have similar changes.
(Ted Hardie; former steering group member) No Objection
Why is this informational? Section 6 looks like protocol specification to me, and this a working group document, so I'm a bit surprised.