In IETF99 (Prague) the following comments/questions were raised regarding the OnDemand draft:
1. Need to clarify in the text that the setsc() API is blocking 2. It is not clear from the text that the APIs are abstract 3. How does this work merge with RFC5014? 4. Request for a description of a use-case for 'Graceful-Replacement' To address these, we have posted a new version of the draft (v12) that includes the following modifications: Clarified the text describing setsc(): The following text was added at the end of section 6.1 - New APIs: "setsc() may block the invoking thread if it triggers the TCP/IP stack to request a new IP prefix from the network to construct the desired source IP address. If an IP prefix with the desired session continuity features already exists (was previously allocated to the mobile host) and the stack is not required to request a new one as a result of setting the IPV6_REQUIRE_SRC_ON_NET flag (defined below), setsc() may return immediately with the constructed IP address and will not block the thread. " Clarifying that the code in the draft is abstract We changed the word 'code' to 'pseudo-code' where code samples are provided in the text In section 3.4 the original text: "(See code example in Section 4 below)" was replaced with: "(See pseudo-code example in Section 4 below)" In section 4 the original text: "The following example shows the code for creating..." was replaced with: "The following example shows the pseudo-code for creating..." Merging this work with RFC5014: Added a new section - 5.4 Coexistence with rfc5014 - that describes the coexistence with source address selection defined in RFC5014: "RFC5014 defines new flags that may be used with setsockopt() to influence source IP selection for a socket. The list of flags include: source home address, care-of address, temporary address, public address CGA (Cryptographically Created Address) and non-CGA. When applications require session continuity service and use setsc() and bind(), they should not set the flags specified in RFC5014. However, if an application sets a specific option using setsockopt() with one of the flags specified in RFC5014 and also selects a source IP address using setsc() and bind() the IP address that was generated by setsc() and bound using bind() will be the one used by traffic generated using that socket and the options set by setsockopt() will be ignored. If bind() was not invoked after setsc() by the application, the IP address generated by setsc() will not be used and traffic generated by the socket will use a source IP address that complies with the options selected by setsockopt()." In my next email to the list, I will provide a description of the OnDemand session continuity services including 'Graceful-Replacement' to elaborate on the differences between them and use-cases for their need. Thanks for the useful comments. Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
