Host Mobility with the Host Identity Protocol
draft-ietf-hip-rfc5206-bis-14

Thank you for addressing my comments.

I support Alexey's comment:
This document doesn't have "Changes since RFC XXXX" section as required for any -bis document. Can you please convert Appendix A to be such a section?

 Mehmet Ersue mehmet.ersue@nokia.com performed the opsdir review

I agree with Mirja's comment about including privacy considerations for exposure to middleboxes.

Some concrete comments:
1) Can you further explain the scenario assumed in these sentences! What is the middblebox supposed/expected to do?
"In this case, the OLD SPI and NEW SPI parameters
       both are set to the value of the preexisting incoming SPI; this
       ESP_INFO does not trigger a rekeying event but is instead
       included for possible parameter-inspecting middleboxes on the
       path. "
and
"An additional potential benefit of performing address verification is
   to allow middleboxes in the network along the new path to obtain the
   peer host's inbound SPI."

2) Section 3.2.1. step 2: I guess the peer would also need to retransmit the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check RFC7401...)

3) section 4: Can you give any hints how large the lifetime typically should be? Can only the original address have an unbounded lifetime (see section 5) or can I also set the lifetime value in a certain way to declare the lifetime of this address of unbounded?

4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST include all active addresses. I believe that's what you are doing from the description in section 5 but it's never really spelled out...

5) section 5.4: How long will an address be in UNVERIFIED state in case the verification is not successful (no reply). Is there a timer? How often will the peer retry the verification test? How long does the peer wait until resending the verification packet?

6) section 5.6: The proposed  Credit-Based Authorization  seems quite complicated for me. First please state clearly the goal: I guess the scenario is that that you send data to the host and the host switches to new address. To be able to keep sending data with the same rate during the "switch-over 3-way-handshake" you need this credit system. So, what you actually need is to estimate the current sending rate in packets per RTT and take this number of packets as your credit. If you know the RTT you can simply count the packets. You can probably always estimate the RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have a way to update this RTT estimate during the connection, you might just use 2xRTT or 3xRTT to be safe...

And more general comments:
1) Did you see any deployment problems because you don't expose a port number (at a know location above the IP header) with e.g. NATs?

2) Usually documents that obsolete another rfc have a "changes from RFCXXXX" section. Not sure if this is needed in this case when you move from experimental to proposed stanadard but given the rather larger number of changes, I would find it helpful.

3) I believe reading would be easier for me if section 4 would have been first but not sure...

4) This docuemnt states several times that mutlihoming is out of scope and only the handover case is described. I think it would be better to state this clearly at the very beginning and remove the other cases (I believe these are anyway kind of left-overs from the previous document.)

5) The security section should also talk about privacy concerns when exposing identifiers to middleboxes (see comment 1 above)

My review was based on the diff vs. 5206 [1], and turned
up nothing new of note:-) Seems like a reasonable update
to me.

I do however agree about the privacy issue raised by Mirja
wrt exposing locators. It is worth noting that, so that
implementers have it flagged that they need to consider
that - not doing so caused quite a fuss for WebRTC so
better to not repeat that.

   [1] https://tools.ietf.org/rfcdiff?url1=rfc5206&url2=draft-ietf-hip-rfc5206-bis-13.txt