Hi Alissa, Thanks for your comments. Following are me responses: DISCUSS (1): Normative requirements on "the IP stack" are too broad: I have checked all places that have normative requirements regarding "IP stack" in the document. Please see my response per instance: Section 3.4 - On Demand Nature has several normative requirements on the "IP stack". One example: "When an application requires a specific type of IP address and such an address is not already configured on the host, the IP stack SHALL attempt to configure one."
This section describes the new On Demand feature and is part of section 3 which describes the Solution for On Demand mobility. As such, I believe it is clear from the context that the normative requirements in this section are for stacks that implement the On Demand features and believe there is no need to be more specific in this place. Section 5.2 - IP Stack in the Mobile Host There are several normative requirements on New IP stacks. This section is part of section 5 that discusses backwards compatibility and as such we assumed that "New IP stacks" refer to IP stacks that implement On Demand functionality. Still, I can see how this might be confusing and thus, I will modify the text from: "New IP stacks" to "new IP stack (that implement On Demand functionality)" to be more precise. DISCUSS (2): Intersection between definitions of address types and recommendations in this document and RFC 7721, RFC 4941 and RFC 8064. We had similar comments and discussions in dmm. The On Demand document does not define new address types. It formalizes types of services that are associated with the mobility nature of a mobile host in a mobile network environment: Reachability and session continuity. It further defines an association between these services and a source IP address (or IP prefix). The motivation of associating between the service and the IP address is to enable a common understanding between the network and the application on the mobile host, with regards to reachability and session continuity provided as a mobile service by the mobile network. This is completely orthogonal with the definition of address types in the RFCs mention in the comment or the definition of the different IPv6 address types. COMMENT (1): What is a "very long time" in section 3.2 A "very long time" is so long that the address is guaranteed to be fixed even after the mobile host disconnects from the network and reconnects later on (and even when this occurs several times). It is much longer than a guarantee to be valid throughout the life-time of an opened socket (which is longer than and address with no guarantee at all). We thought this is clear from the description of the other types of IP addresses. If not, we could change the order of the definition of addresses and have the Fixed address definition after the Session-lasting address definition. Do you recommend that we re-order the definitions? COMMENT (2): Remove normative MUST in section 5.1 Ack. Will be removed in the next revision. COMMENT (3): Required discussion on privacy and security implications in section 7 I have discussed the content of section 7 with Daniel Migault and ended up with a completely rewritten section. I hope the new version will satisfy your concerns. Thanks for the review and comments, Danny -----Original Message----- From: dmm [mailto:[email protected]] On Behalf Of Alissa Cooper Sent: Thursday, February 21, 2019 16:01 To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Dapeng Liu <[email protected]> Subject: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-dmm-ondemand-mobility-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) There are a bunch of places in this document that place normative requirements on "the IP stack" or "IP stacks." This seems too broad to me -- aren't these meant to apply to IP stacks that implement the new API? It seems like RFC 5014 was more careful in its use of normative language and I think that care is warranted here as well. (2) RFC 7721 defines a bunch of address types that are somewhat overlapping with the definitions here. RFC 4941 and RFC 8064 provide recommendations for configuration of different address types. How do the address types and recommendations in this document intersect with the address types and recommendations in those documents? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 3.2 = "A Fixed IP address is an address with a guarantee to be valid for a very long time" This seems vague. What is a very long time? = Section 5.1 = "Applications using the new On-Demand functionality MUST be aware that they may be executed in legacy environments that do not support it." This should not be a normative recommendation. = Section 7 = This section needs to discuss the privacy and security implications of the different address types (see, e.g., RFC 7721 Sections 3 and 4). _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- 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
