Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-09

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

Lars Eggert No Objection

Comment (2009-09-08 for -)
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?)

(Ralph Droms; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2009-09-10 for -)
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?

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection (2009-09-10 for -)
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.

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection (2009-09-10 for -)
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.

(Pasi Eronen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info