Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
RFC 5770

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

(Ralph Droms) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2009-09-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 50500, paragraph 0:
>    Upon publication of this document, IANA is requested to register a
>    UDP port and the RFC editor is requested to change all occurrences of
>    port HIPPORT to the port IANA has registered.  The HIPPORT number
>    50500 should be used for initial experimentation.

  I believe you want to remove the sentence about port 50500, because
  that was only intended to be used while there was no registered port.
  (Also, I assume you want a Registered port > 1024 and not a Well Known
  port, correct?)

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2009-09-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I'm happy to see this work progress, and I welcome it being published as Experimental. 

Please consider adding some text to the document to discuss the scope of the experiment. What concerns are there about releasing this into the Internet (i.e., why the Experiment)? How is the experiment limited (i.e., what rules ensure that this is operating within some kind of wall)? How will you determine if the experiment is a success?

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Dan Romascanu) No Objection

Comment (2009-09-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the last issue raised by Jari in his DISCUSS concerning the need for a default value for the transaction pacing value parameter.

(Robert Sparks) No Objection

Magnus Westerlund No Objection

Comment (2009-09-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 4.7:

HIP relay servers MAY refrain
   from sending keepalives if it's known that they are not behind a
   middlebox that requires keepalives.

As it appears to be an assumption that the Relay server is not behind a NAT I don't see any meaning in the relay sending keep-alives. That as NATs normally only do keep-alive from their inside. And as that is mandated their are no point in the server on the external side to initiate keep-alive messages.