Re: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Hi Danny,

> On Feb 22, 2019, at 9:06 AM, Moses, Danny <[e-mail]> wrote:
> 
> 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.

I disagree. At a minimum I think 3.4 needs to specify that its normative requirements apply only to implementations that support the API specified in Section 6.1.

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

If that is the case, why is Section 3.2 entitled “Types of IP Addresses” and why does it begin with the line "Four types of IP addresses are defined with respect to mobility management”? Why does the API take in an argument called “addressType”?

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

I don’t understand how it is completely orthogonal. Are you saying that any of the address types previously defined — public, stable, and temporary — could be generated and used as any of the four address types defined in this document? That’s what it would mean to be completely orthogonal, I think. And if that is not true, I think this document needs to explain which previously defined address types can be used as each newly defined type in this document. Historically we have specified a bunch of different address generation mechanisms and selection guidance inconsistently such that it’s not clear to implementors how to choose an address type for a given situation; this document should not make that situation worse.

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

Specifying this by using the time period is still vague, though. Is there a difference between this type and public address as defined in RFC 7721? That is, is the point of this that other nodes are expecting such an address to host specific resources or services, which is why the address must remain the same through network disconnections? That’s what it seems like to me.

Thanks,
Alissa

> 
> 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:[e-mail]] On Behalf Of Alissa Cooper
> Sent: Thursday, February 21, 2019 16:01
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Dapeng Liu <[e-mail]>
> 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
> [e-mail]
> 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.
>