Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

From: Jouni <[email-masked]>
Date: Wed, 15 Jun 2016 10:16:12 -0700

Folks,

This email starts the WGLC #2 for draft-ietf-dmm-ondemand-mobility-05. Post your comment to the mailing list and also add your issues/correction requests/concerns etc into the Issue Tracker.

   WGLC #2 Starts: 6/15/2016
   WGLC #2 Ends: 6/29/2016 EOB PDT

Regards,
   Jouni & Dapeng

---

From: <[email-masked]>
Date: Tue, 21 Jun 2016 09:34:46 +0000

Hi,

I support this I-D.

Pierrick

> -----Message d'origine-----
> De : dmm [mailto:[email-masked]] De la part de Jouni
> Envoyé : mercredi 15 juin 2016 19:16
> À : [email-masked]
> Cc : "刘大鹏(鹏成)"
> Objet : [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05
> 
> Folks,
> 
> This email starts the WGLC #2 for draft-ietf-dmm-ondemand-mobility-05. Post your
> comment to the mailing list and also add your issues/correction requests/concerns
> etc into the Issue Tracker.
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 21 Jun 2016 18:51:52 +0900

Hi,

I have read and checked the updates in -03 version.
And I support this draft to move forward, if the following is clearly
resolved.

"4.2. IP Stack in the Mobile Host

...

If the network infrastructure supports On-Demand Mobility feature, the IP
stack may still request specific types of source IP address  transparently
to legacy applications."

As this draft is based on the application-driven API selection idea, if no
explicit request is given by an application, the type should be selected by
default, though the default behavior could be regulated by the network
operator. My comment is putting "based on a default havior" in a proper
place in the sentence would be exact, leaving no misunderstanding as if the
IP stack has the selection capability of source IP address type, instead of
the application.

One minor comment is [I-D.ietf-dmm-requirements] in the reference should be
replaced by RFC7333.

Regards,
Seil Jeon

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni
Sent: Thursday, June 16, 2016 2:16 AM
To: [email-masked]
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Folks,

This email starts the WGLC #2 for draft-ietf-dmm-ondemand-mobility-05. Post
your comment to the mailing list and also add your issues/correction
requests/concerns etc into the Issue Tracker.

Regards,
   Jouni & Dapeng

---

From: "Moses, Danny" <[email-masked]>
Date: Thu, 23 Jun 2016 10:06:03 +0000

Hi,

Thanks for the support.

I agree with your comment; the text might be misleading.
The general principle is to maintain the old behavior (prior to OnDemand support) when one entity is  legacy. According to this principle, if a legacy application is executed, it should experience the same behavior as if it would have been executed with a legacy IP stack and legacy network. The problem is however, that the behavior of the network in terms of IP address type allocation is not define.

So I am thinking of changing the text from –
"New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

To (the red text is new, the strikethrough text will be deleted)–
" New IP stacks must continue to support all legacy operations. If an
application does not use On-Demand Mobility feature, the IP stack
must respond in a legacy manner.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to the application request: If the
application requests a specific address type, the stack should forward
this request to the network. If the application does not request a specific
address type, the IP stack must not request an address type and leave
it to the network's default behavior to choose the type of the allocated
IP address. If an address was already allocated to the host, the IP stack
should use this address and not request a new one from the network.
may still request specific types of source IP address
transparently to legacy applications. This may be useful for
environments in which both legacy and new applications are executed.

The definition of what type of addresses to request and how they are
assigned to legacy applications are outside of the scope of this
specification."

Is that OK?

Thanks,
                /Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: [email-masked]
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

I have read and checked the updates in -03 version.
And I support this draft to move forward, if the following is clearly resolved.

...

If the network infrastructure supports On-Demand Mobility feature, the IP stack may still request specific types of source IP address  transparently to legacy applications."

As this draft is based on the application-driven API selection idea, if no explicit request is given by an application, the type should be selected by default, though the default behavior could be regulated by the network operator. My comment is putting "based on a default havior" in a proper place in the sentence would be exact, leaving no misunderstanding as if the IP stack has the selection capability of source IP address type, instead of the application.

One minor comment is [I-D.ietf-dmm-requirements] in the reference should be replaced by RFC7333.

Regards,
Seil Jeon

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni
Sent: Thursday, June 16, 2016 2:16 AM
To: [email-masked]<mailto:[email-masked]>
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Folks,

Regards,
   Jouni & Dapeng
_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 23 Jun 2016 19:32:36 +0900

Hi Danny,

Thanks for your revision. I mostly agree with your texts. But I put my small
revision on your texts.

For the last sentence, I hope we leave some spaces for any enhancement.

the IP stack should act according to follow the application request by
priority; If the  application requests a specific address type, the stack
should forward  this request to the network. If the application does not
request a specific  address type, the IP stack must not request an address
type and leave  it to the network's default behavior to choose the type of
the allocated  IP address. If an IP address was already allocated to the
host, the IP stack should uses this address and may not request a new ine
one from the network.

Regards,

Seil Jeon

From: Moses, Danny [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 7:06 PM
To: Seil Jeon; [email-masked]
Cc: '"???(??)"'
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

Thanks for the support.

The general principle is to maintain the old behavior (prior to OnDemand
support) when one entity is  legacy. According to this principle, if a
legacy application is executed, it should experience the same behavior as if
it would have been executed with a legacy IP stack and legacy network. The
problem is however, that the behavior of the network in terms of IP address
type allocation is not define.

specification."

specification."

Is that OK?

Thanks,

                /Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: [email-masked] <mailto:[email-masked]> 
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

 

...

 

 

Regards,

Seil Jeon

-----Original Message-----

To: [email-masked] <mailto:[email-masked]> 

Cc: "刘大鹏(鹏成)"

Folks,

Regards,

   Jouni & Dapeng

dmm mailing list

[email-masked] <mailto:[email-masked]> 

dmm mailing list

[email-masked] <mailto:[email-masked]>

---

From: "Moses, Danny" <[email-masked]>
Date: Sun, 26 Jun 2016 07:43:55 +0000

Hi Seil,

Thanks for the correction.
The only fix I did not understand is the addition of 'by priority'. The rest of the fixes are fine.

I will wait a couple of days to let additional people respond, and release a new version towards the end of this week.

                /Danny

From: Seil Jeon [mailto:[email-masked]]
Sent: Thursday, June 23, 2016 13:33
To: Moses, Danny
Cc: [email-masked]
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

Thanks for your revision. I mostly agree with your texts. But I put my small revision on your texts.
For the last sentence, I hope we leave some spaces for any enhancement.

If the network infrastructure supports On-Demand Mobility feature,
the IP stack should act according to follow the application request by priority; If the  application requests a specific address type, the stack should forward  this request to the network. If the application does not request a specific  address type, the IP stack must not request an address type and leave  it to the network's default behavior to choose the type of the allocated  IP address. If an IP address was already allocated to the host, the IP stack should uses this address and may not request a new ine one from the network.

Regards,
Seil Jeon

From: Moses, Danny [mailto:[email-masked]]
Sent: Thursday, June 23, 2016 7:06 PM
To: Seil Jeon; [email-masked]<mailto:[email-masked]>
Cc: '"???(??)"'
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

Thanks for the support.

Is that OK?

Thanks,
                /Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: [email-masked]<mailto:[email-masked]>
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

...

Regards,
Seil Jeon

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni
Sent: Thursday, June 16, 2016 2:16 AM
To: [email-masked]<mailto:[email-masked]>
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Folks,

Regards,
   Jouni & Dapeng

---

From: "Seil Jeon" <[email-masked]>
Date: Sun, 26 Jun 2016 17:21:03 +0900

Hi Danny,

It aims to clarify what order the IP stack should follow among the cases;
when an application does/doesn’t specify its requested type.

Regards,

Seil Jeon

From: Moses, Danny [mailto:[email-masked]] 
Sent: Sunday, June 26, 2016 4:44 PM
To: Seil Jeon
Cc: [email-masked]
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Seil,

The only fix I did not understand is the addition of 'by priority'. The rest
of the fixes are fine.

I will wait a couple of days to let additional people respond, and release a
new version towards the end of this week.

                /Danny

From: Seil Jeon [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 13:33
To: Moses, Danny
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

Regards,

Seil Jeon

From: Moses, Danny [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 7:06 PM
To: Seil Jeon; [email-masked] <mailto:[email-masked]> 
Cc: '"???(??)"'
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

Thanks for the support.

specification."

specification."

Is that OK?

Thanks,

                /Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: [email-masked] <mailto:[email-masked]> 
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

 

...

 

 

Regards,

Seil Jeon

-----Original Message-----

Cc: "刘大鹏(鹏成)"

Folks,

Regards,

   Jouni & Dapeng

dmm mailing list

dmm mailing list

---

From: "Moses, Danny" <[email-masked]>
Date: Sun, 26 Jun 2016 08:25:49 +0000

Isn't the text clear enough without this addition.
Let me think about this a little more.

Thanks,
                /Danny

From: Seil Jeon [mailto:[email-masked]]
Sent: Sunday, June 26, 2016 11:21
To: Moses, Danny
Cc: [email-masked]
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

It aims to clarify what order the IP stack should follow among the cases; when an application does/doesn’t specify its requested type.

Regards,
Seil Jeon

From: Moses, Danny [mailto:[email-masked]]
Sent: Sunday, June 26, 2016 4:44 PM
To: Seil Jeon
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Seil,

                /Danny

From: Seil Jeon [mailto:[email-masked]]
Sent: Thursday, June 23, 2016 13:33
To: Moses, Danny
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi Danny,

Regards,
Seil Jeon

Hi,

Thanks for the support.

Is that OK?

Thanks,
                /Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: [email-masked]<mailto:[email-masked]>
Cc: '"刘大鹏(鹏成)"'
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

...

Regards,
Seil Jeon

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni
Sent: Thursday, June 16, 2016 2:16 AM
To: [email-masked]<mailto:[email-masked]>
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Folks,

Regards,
   Jouni & Dapeng

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 28 Jun 2016 16:20:58 +0900

Support.

Regards,
--satoru

On Thu, Jun 16, 2016 at 2:16 AM, Jouni <[email-masked]> wrote:

> Folks,
>
> This email starts the WGLC #2 for draft-ietf-dmm-ondemand-mobility-05.
> Post your comment to the mailing list and also add your issues/correction

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 29 Jun 2016 13:44:13 +0000

I support this I-D.

John

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni
Sent: Wednesday, June 15, 2016 12:16 PM
To: [email-masked]
Cc: "刘大鹏(鹏成)"
Subject: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Folks,

Regards,
   Jouni & Dapeng

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 29 Jun 2016 16:51:17 +0200

Hi,

I support this draft but I have some comments.

The draft reads in some places as this were an IPv4 draft.

As opposed to IPv4 in IPv6 rarely if ever the network assigns an address
to a terminal.

In IPv6 most of the times the network advertises a prefix on a link. 
Rarely if ever (DHCPv6 is rarely used) is the host requesting an address 
from the network; and I am not talking of requesting a particular kind 
of address.

So, if the host rarely if ever requests an address, it's hard to 
assimilate that it's easy to request a particular address type.

As such it's hard to say:
> - Fixed IP Address
>
> A Fixed IP address is an address assigned to the mobile host by the
> network with a guarantee to be valid for a very long time,

Another comment is about this paragraph:
> At any point in time, a mobile host may have a combination of IP
> addresses configured.  Zero or more Non-persistent, zero or more
> Session-lasting, and zero or more Fixed IP addresses may be
> configured on the IP stack of the host.  The combination may be as a
> result of the host policy, application demand, or a mix of the two.

YEs, but never will a mobile host have zero IPv6 addresses configured.
Even if the network does not advertise a prefix towards it, and even if
DHCPv6 is not active, the mobile host will always self-form an IPv6
link-local address.

> In case an application requests one, the IP stack shall make an
> attempt to configure one by issuing a request to the network.

I can agree the host's IP stack can issue a request to the network.  But 
I dont know what kind of request is that?  DHCPv6 request?  ICMPv6 
Router Solicitation?

>    It is outside of the scope of this specification to define how the
>    host requests a specific type of address (Fixed, Session-lasting or
>    Non-persistent) and how the network indicates the type of address in
>    its advertisement of addresses (or in its reply to an address
>    request).

But this is contradictory to the above.

You are saying that the IP stack 'shall' make an attempt, and at the 
same time you dont tell how to make that attempt.

>    The following are matters of policy, which may be dictated by the
>    host itself, the network operator, or the system architecture
>    standard:
>
>    - The initial set of IP addresses configured on the host at the boot
>    time.

Do you mean something like this: address A is preconfigured on the host 
as session-lasting, and address B is pre-configured as fixed?

>    - Permission to grant various types of IP addresses to a requesting
>    application.

I dont understnad this?  Who grants to whom?

>    - Determination of a default address type when an application does
>    not make any explicit indication, whether it already supports the
>    required API or it is just a legacy application.

I understand this and it can make sense.

But none of these 3 policy tools give the host a means to make a request 
to the network.  Each of the 3  tools is a local tool - is the intent of 
the draft to have an entirely local decision making algorithm?  (no 
message exchange).

Alex

Le 15/06/2016 à 19:16, Jouni a écrit :
> Folks,
>
> This email starts the WGLC #2 for
> draft-ietf-dmm-ondemand-mobility-05. Post your comment to the mailing
> list and also add your issues/correction requests/concerns etc into
> the Issue Tracker.
>
> WGLC #2 Starts: 6/15/2016 WGLC #2 Ends: 6/29/2016 EOB PDT
>
> Regards, Jouni & Dapeng
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 29 Jun 2016 15:41:27 +0000

Support

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Satoru Matsushima <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 28, 2016 at 12:20 AM
To: Jouni <[email-masked]<mailto:[email-masked]>>
Cc: "刘大鹏(鹏成)" <[email-masked]<mailto:[email-masked]>>, dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Support.

Regards,
--satoru

On Thu, Jun 16, 2016 at 2:16 AM, Jouni <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Regards,
   Jouni & Dapeng

---

From: h chan <[email-masked]>
Date: Thu, 30 Jun 2016 02:22:15 +0000

support

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, June 29, 2016 9:51 AM
To: [email-masked]
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Hi,

As opposed to IPv4 in IPv6 rarely if ever the network assigns an address to a terminal.

In IPv6 most of the times the network advertises a prefix on a link. 
Rarely if ever (DHCPv6 is rarely used) is the host requesting an address from the network; and I am not talking of requesting a particular kind of address.

So, if the host rarely if ever requests an address, it's hard to assimilate that it's easy to request a particular address type.

Another comment is about this paragraph:
> Session-lasting, and zero or more Fixed IP addresses may be configured 
> on the IP stack of the host.  The combination may be as a result of 
> the host policy, application demand, or a mix of the two.

YEs, but never will a mobile host have zero IPv6 addresses configured.
Even if the network does not advertise a prefix towards it, and even if
DHCPv6 is not active, the mobile host will always self-form an IPv6 link-local address.

> attempt to configure one by issuing a request to the network.

I can agree the host's IP stack can issue a request to the network.  But I dont know what kind of request is that?  DHCPv6 request?  ICMPv6 Router Solicitation?

You are saying that the IP stack 'shall' make an attempt, and at the same time you dont tell how to make that attempt.

>    - The initial set of IP addresses configured on the host at the boot

Do you mean something like this: address A is preconfigured on the host as session-lasting, and address B is pre-configured as fixed?

But none of these 3 policy tools give the host a means to make a request to the network.  Each of the 3  tools is a local tool - is the intent of the draft to have an entirely local decision making algorithm?  (no message exchange).

Alex