Skip to main content

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

Yes

(Ralph Droms)

No Objection

(Cullen Jennings)
(Jari Arkko)
(Lisa Dusseault)
(Pasi Eronen)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)

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

Lars Eggert
No Objection
Comment (2009-09-08)
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 IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-09-10)
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 IESG member
No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2009-09-10)
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 IESG member
(was Discuss) No Objection
No Objection ()

                            
Lisa Dusseault Former IESG member
No Objection
No Objection ()

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2009-09-10)
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 IESG member
No Objection
No Objection ()

                            
Robert Sparks Former IESG member
No Objection
No Objection ()

                            
Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection ()