Heartbeat Mechanism for Proxy Mobile IPv6
RFC 5847

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

(David Ward) Discuss

Discuss (2009-03-11 for -** No value found for 'p.get_dochistory.rev' **)
Why isn't this based on BFD with large intervals?

(Jari Arkko) Yes

(Dan Romascanu) Yes

Comment (2009-03-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This is a calear and well-written document that could benefit from a few clarifications. 

1. I suppose that a future chartered work in this WG will add a management interface - MIB module or similar. It would be good to mention what information is configurable and may be important to be exposed for an operator: certainly configuration of the parameters described in Section 5, maybe notifications of the failuere and restarts detections, other? 

3.   HEARTBEAT_INTERVAL

      This variable is used to set the time interval in seconds between
      two consecutive Heartbeat Request messages.  The default value is
      60 seconds.  It SHOULD NOT be set to less than 30 seconds.

Would not it make sense to define a high limit here as well? 

3.   MISSING_HEARTBEATS_ALLOWED

      This variable indicates the maximum number of consecutive
      Heartbeat Request messages that a PMIPv6 node can miss before
      concluding that the peer PMIPv6 node is not reachable.  The
      default value for this variable is 3.

Should not rather be 'are not responded' than 'can miss'?

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2009-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I am not going to perpetuate Dave's Discuss, but I am hugely surprised that the Abstract says:
   This document describes a heartbeat
   mechanism between the MAG and the LMA to detect failures quickly and
   take appropriate action.
While Section 3 says:
   The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than
   30 seconds.
Everything is relative, but these two statements are contradictions in my book. Section 1 exacerbates the problem by reapeatedly using the word "quickly."

I would really appreciate it if you could change the Abstract and Introduction to give relative scale to "quick" by referencing other protocol actions that may be carried out or attempted in the non-detection window.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-03-12)
No email
send info

In Section 3, paragraph 3:

   The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than
   30 seconds.  Sending heartbeat messages too often may become an
   overhead on the path between the MAG and the LMA.  The
   HEARTBEAT_INTERVAL can be set to a much larger value on the LMA, if
   required, to reduce the burden of sending periodic heartbeat
   messages.

By omission, the last sentence implies that the HEARTBEAT_INTERVAL should not be set
to a much larger value on the MAG.  If there *are* reasons not to configure larger intervals
on the MAG that should be noted here...

(Mark Townsley) No Objection

Magnus Westerlund No Objection

Comment (2009-03-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Supports Lars Eggert's Discuss.

I think the document would be clearer if there where place holder text for making clear the cope points that are to be assigned to the MH type and the option. That way when reading the ready RFC one gets the numbers directly instead of having to go to the IANA section. In general the text is not formulated to make it clear what IANA assigns.