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 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
