Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)
draft-ietf-hip-hiccups-05

The Introduction says...

   The HIP_DATA packet is not aimed to be a
   replacement for ESP transport instead it SHOULD only be used to
   exchange few packets between the peers.

I find this woolly on three counts.

1. "not aimed" Is it or is it not?
2. "SHOULD only" Feels like you need to flip this to a "SHOULD NOT"
   For example: "SHOULD NOT be used to exchange more than..."
3. "exchange [a] few packets" Your opinion of "a few" may differ from
   mine. What is the real 2119 constraint here?

---

Would be helpful to explain what a MAC is in section 2.

---

Is it the intention that new HIP implementations should include support for the DATA packet? If so, doesn't this I-D update 5201?

---

Section 4 appears to use some form of syntax to define the DATA packet. You should probably include a reference to the definition of that syntax.

Thank you for addressing my earlier discusses and comments. One more issue resulting from the most recent change:

5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet


   The following steps define the conceptual processing rules for
   handling a SEQ_DATA parameter in a received HIP DATA packet.

   The system MUST verify the SIGNATURE in the HIP DATA packet.  If the
   verification fail, the packet SHOULD be dropped and an error message
   logged.

   If the value in the received SEQ_DATA and MIC value received
   PAYLOAD_MIC corresponds to a HIP DATA packet that has recently been
   processed, the packet is treated as a retransmission.  The SIGNATURE
   verification (next step) MUST NOT be skipped.

This sentence needs to be deleted, because you've reordered paragraphs as I suggested earlier.

   (A byte-by-byte
   comparison of the received and a stored packet would be adequate,
   though.)  It is recommended that a host cache HIP DATA packets sent
   with ACKs to avoid the cost of generating a new ACK packet to respond
   to a retransmitted HIP DATA packet.  The host MUST acknowledge,
   again, such (apparent) HIP DATA packet retransmissions but SHOULD
   also consider rate-limiting such retransmission responses to guard
   against replay attacks.

  The Gen-ART Review by Elwyn Davies on 15 June 2010 offers many minor
  comments and editorial nits.  Please consider them.

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-hip-hiccups-02-davies.txt

I support Peter's DISCUSS.

I also support Jari's first DISCUSS position.

I support Peter's discuss position.