Subject: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-23

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Nov 2017 13:21:39 +0200

Folks,

we already WGLCed version 15 of this draft back in February. Miika has
addressed a few comments since then. I would like to start a second WGLC
on the the draft to make sure it is ready for publication request. This
WGLC will end on December 7th:

https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

Thanks,

Gonzalo

---

From: Jeff Ahrenholz <[email-masked]>
Date: Tue, 28 Nov 2017 17:10:48 +0000

Miika,
I reviewed your changes, and sent you some typos / editorial nits.

Here are some further comments:

Section 4.9

"It SHOULD wait for all of them to respond for two minutes"

Where does this value come from?
Should this be a configurable time, default two minutes?

It seems like a long time in the context of address mobility, which you want to complete as soon as possible. Then again, on a high-latency network or overloaded server, maybe we need to wait longer.

Section 4.12.3

"but could occur on a busy server acting as a Responder"

What does this mean, acting as a Responder? Should this read "acting as a Relay"?

“The same applies also the handover
   procedures; the Data Relay Client MUST NOT include the relayed
   address candidate when sending its new locator set in an UPDATE to
   its peer if it would cause a SPI conflict with another peer.”

Is it possible then to have no valid locators here, due to the SPI collision? What will happen then?

regards,
-Jeff

On 11/22/17, 3:21 AM, "Hipsec on behalf of Gonzalo Camarillo" <[email-masked] on behalf of [email-masked]> wrote:

    Folks,

    
    Thanks,
    
    Gonzalo
    
    _______________________________________________
    Hipsec mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/hipsec

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Nov 2017 19:19:42 +0200

Hi,

> I reviewed your changes, and sent you some typos / editorial nits.

thanks, you're nits are included in version 24 as well as your other 
comments below.

> It seems like a long time in the context of address mobility, which you want to complete as soon as possible. Then again, on a high-latency network or overloaded server, maybe we need to wait longe…

now it says:

It SHOULD wait for all of them to respond for a configurable time, by 
default two minutes, and then continue with the handover procedure...

> What does this mean, acting as a Responder? Should this read "acting as a Relay"?

yes, the Data Relay is the root of the problem. Fixed.

> Is it possible then to have no valid locators here, due to the SPI collision? What will happen then?
The hosts will anyway send their local locators and server reflexive 
ones, and only the relayed one must be omitted. So, this means that no 
connectivity if NAT traversal fails. Remember that this is just a back 
up plan which the data relay client executes only when it fails to 
register for a new relayed candidate *and* the SPI would conflict. In 
other words, a data relay client MAY reuse server relayed candidates 
only if SPI does not conflict.

(I did not correct anything related to this, let me know explicitly if 
you would like to see some changes)

---

From: Jeff Ahrenholz <[email-masked]>
Date: Wed, 29 Nov 2017 18:33:35 +0000

Miika,

>    default two minutes, and then continue with the handover procedure...

OK, various changes look good.

>    you would like to see some changes)

OK, thanks for the explanation. I don’t think any further changes are needed here.

-Jeff