Hi,
On 11/28/2017 07:10 PM, Jeff Ahrenholz wrote:
Miika,
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.
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.
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...
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"?
yes, the Data Relay is the root of the problem. Fixed.
“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?
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)
regards,
-Jeff
On 11/22/17, 3:21 AM, "Hipsec on behalf of Gonzalo Camarillo"
<[email protected] on behalf of [email protected]> wrote:
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
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
