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

"Moses, Danny" <> Fri, 22 February 2019 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08BDA129A87; Fri, 22 Feb 2019 06:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZKEpKPHSv1Na; Fri, 22 Feb 2019 06:06:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A70EE128766; Fri, 22 Feb 2019 06:06:46 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2019 06:06:46 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.58,400,1544515200"; d="scan'208";a="322549782"
Received: from ([]) by with ESMTP; 22 Feb 2019 06:06:45 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 22 Feb 2019 06:06:44 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 22 Feb 2019 06:06:44 -0800
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Fri, 22 Feb 2019 16:06:41 +0200
From: "Moses, Danny" <>
To: Alissa Cooper <>, The IESG <>
CC: "" <>, "" <>, "" <>, Dapeng Liu <>
Thread-Topic: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)
Thread-Index: AQHUye31InEL51d3bUS9HMeS4ujDsaXr236Q
Date: Fri, 22 Feb 2019 14:06:41 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ctpclassification: CTP_NT
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTljYjA0YjAtYzljYi00ZDVlLTllZmYtNmQwZDM1ZDJlMjBhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQlU4SGFHTE9HK25zN2NiZzhMQjYwM1h1UGgxZkh4cXlCYVpMMHNabU5sdHppVGNWN2t3RU1aZEhXWVZQeGVGaCJ9
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Feb 2019 14:06:49 -0000

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,

-----Original Message-----
From: dmm [] On Behalf Of Alissa Cooper
Sent: Thursday, February 21, 2019 16:01
To: The IESG <>
Cc:;;; Dapeng Liu <>
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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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


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