The Host Identity Protocol (HIP) Experiment Report

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

(Jari Arkko) Yes

(Ralph Droms) Yes

Comment (2011-10-18 for -)
No email
send info
It would be helpful to include a terminology section, for those not so
familiar with HIP.

section 1.2: "HIT-based lookups"

  expand HIT on first usage

section 2.3.5: Are there any specific references to the "initial
specification attempts?"

   To solve this problem, the HIP layer could
   inform the transport layer of mobility events.  This method, known as
   transport triggers, is still under research although initial
   specification attempts have been made in the IET

section 2.5: I can't quite parse this sentence:

   Although counter-examples exist, e.g.  SCTP is a large
   unit in the kernel, the Linux community resisted incorporating the
   HIP code.

It's not clear to me what SCTP is a counter-example for?

section 3.2: are there an acronym expansions for "HI" and "I2"?

   when the HI is
   encrypted, middleboxes in the network cannot verify the signature of
   the I2

(Stephen Farrell) Yes

Comment (2011-11-02 for -)
No email
send info
- A lot of this document would apply to any overlay or
alternative n/w approach and not just HIP. Might be
worth a mention in the abstract?

- not all acronyms are expanded on 1st use, e.g. sigma, beet, tap

- I wondered what were the "controversial experiences" on p10. Seems
a shame to tease the reader like that.

- What is an "I1" on p13? And "I2" on p17. Maybe expand those to
the full message names or something?

- Isn't TKK now Aalto? (p15 & p23)

- A reference for the "double jump mobility" problem on p19
would be good.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

Comment (2011-11-03 for -)
No email
send info
A very good document. I would like to see more of this type describing experience in implementation and deployment of protocols developped in the IETF. 

(Robert Sparks) No Objection