A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
draft-ietf-ipsec-dpd-04

[Ballot comment]
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

An updated Internet-Draft has been posted that addresses the concerns raised last month.  I am putting this on the agenda for the next telechat to confirm that they are completely resolved.

[Ballot comment]
US/American slang hits us in protocol design:
Page 7:
      Notify                      Message Value
      R-U-THERE                  36136
      R-U-THERE-ACK              36137

Aaarrrggghh

[Ballot discuss]
- Page 8
  - SPI Size (2 octets)
  But the diagram above shows it as 1 octet
  - Notification Data (4 octets)
  But the diagram shows it as multiple sets of 4 octets

[Ballot comment]
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.

This document describes what people do.  It is an Informational to just document current practice.  The group does not want to make revisions, even if better mechanisms are discovered.  Changes would mean that the document does not describe what people already do.

Please add a sentence or two of explanatory text to the Introduction.

Draft does not have a security considerations section.  Section 7 requires a sequence number, but it is not clear why a random nonce is not sufficient.  A random nonce does not require state at both peers, but the proposed sequence number mechanism does require state at both peers.