Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03

From: Jouni Korhonen <[email-masked]>
Date: Fri, 03 Apr 2015 17:03:57 -0700

Folks,

This email starts a two week adoption call for the I-D
   draft-yegin-dmm-ondemand-mobility-03
to confirm its adoption as a DMM WG document and as a basis for the 
technical solution. The call ends April 17th EOB PDT.

Express your support or opposition to the mailing list. During the 
IETF92 meeting we got 10 voices for the adoption and 3 against. we 
expect at least the same amount of expressed opinions on the list.

Notice that version -01 of this I-D had an IPR declared to it. See 
https://datatracker.ietf.org/ipr/2309/

- Jouni & Dapeng

---

From: "Moses, Danny" <[email-masked]>
Date: Sat, 4 Apr 2015 08:08:51 +0000

I support adopting draft-yegin-dmm-ondemand-mobility-03 as a DMM WG document.

Regards,
	/Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Saturday, April 04, 2015 03:04
To: [email-masked]; Jouni; Dapeng Liu; [email-masked]
Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03

Folks,

This email starts a two week adoption call for the I-D
   draft-yegin-dmm-ondemand-mobility-03
to confirm its adoption as a DMM WG document and as a basis for the technical solution. The call ends April 17th EOB PDT.

Express your support or opposition to the mailing list. During the
IETF92 meeting we got 10 voices for the adoption and 3 against. we expect at least the same amount of expressed opinions on the list.

Notice that version -01 of this I-D had an IPR declared to it. See https://datatracker.ietf.org/ipr/2309/

- Jouni & Dapeng

_______________________________________________
dmm mailing list
[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: "Weixinpeng (Jackie)" <[email-masked]>
Date: Mon, 6 Apr 2015 10:14:24 +0000

I think the document has some basic issues that have not be clearified, and don't think it is ready for WG adoption.

 I am still not convinced yet that get the app developer get involved in the choice of mobility scheme is a good idea. 
 But even here we assume that would be acceptable. then there are still additional considerations.

Q1. Whether it is suitable for app to select different types of IP address 
 (1)What information should be communicated from application to the host.
 One option is the app only indicates whether it could cope with mobility or not, another option is the app indicates specific type of
 IP address type. Also there might be some other options.
  (2)In which level the option should be set by setsockopt().
 I think at least there are two choices, the first one is in SOL_SOCKET, and the second one is IPPROTO_IPV6.
 Not only the network layer could provide mobility support but also other layers such as transport layer.
 
 Q2. Whether the IP address defined here is ok?
 For example, if  nomadic address is defined, and then  application developer is told that the nomadic address "provides neither IP session continuity nor IP address reachability", then how the developr will think of it. I am sure they will never want to use such an address.
 For the definition of fixed address and sustained address, I don't see the reason why we need both of them in a network.
  
Q3. How should the network side support the solution is not quite clear. Is the current architecture defined in other work group could support this needs to be clarified.
Q4. People should be aware of there is an IPR in this doc. 

-Xinpeng

________________________________________
发件人: dmm [[email-masked]] 代表 Jouni Korhonen [[email-masked]]
发送时间: 2015年4月4日 8:03
收件人: [email-masked]; Jouni; Dapeng Liu; [email-masked]
主题: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03

Folks,

- Jouni & Dapeng

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Thu, 9 Apr 2015 17:24:27 -0400

I support the adoption of this I-D.

Byoung-Jo "J" Kim
[email-masked]
AT&T Labs - Research

http://sites.google.com/site/macsbug/

>> From: Jouni Korhonen <[email-masked]>
>> Date: April 4, 2015 3:03:57 AM GMT+03:00
>> To: "[email-masked]" <[email-masked]>, Jouni <[email-masked]>, Dapeng Liu <[email-masked]>, [email-masked]
>> 
>> Folks,
>> 
>> Express your support or opposition to the mailing list. During the IETF92 meeting we got 10 voices for the adoption and 3 against. we expect at least the same amount of expressed opinions on the list.
>>

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 9 Apr 2015 23:34:39 +0100

Hi DMMers,

I support the adoption of this draft as a WG document in the sense that the
three types of IP addresses are needed.
But the use of the defined APIs is not clear in the context of the existing
source address selection rules defined in RFC 6724, as I had discussed it
with Danny several times. Definitely, it should be reviewed through use
cases study.

Best Regards,
Seil Jeon

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Saturday, April 04, 2015 1:04 AM
To: [email-masked]; Jouni; Dapeng Liu;
[email-masked]
Subject: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03

Folks,

Express your support or opposition to the mailing list. During the
IETF92 meeting we got 10 voices for the adoption and 3 against. we expect at
least the same amount of expressed opinions on the list.

- Jouni & Dapeng

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 9 Apr 2015 22:59:49 +0000

I support the adoption of this draft as a starting point of a WG document. 

I also agree with Seil's comment that the WG document has to resolve the currently identified open issues; Specially there has to be clear explanation on how SAS Rules fit in here, or how the address properties defined here interwork with the RFC 6274 Rules. I tag this as a open issue.

Sri

> On Apr 10, 2015, at 4:04 AM, "Seil Jeon" <[email-masked]> wrote:
> 
> Hi DMMers,
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 09 Apr 2015 17:45:52 -0700

<as an individual contributor - so opinions are just my personal ones>

I support the adoption of this I-D.. as a basis for further work done by 
the WG. We obviously need to address the valid concerns raised on the 
list by few people. Also, we need to evaluate what parts are covered by 
the declared IPR and whether the WG agrees to keep those in the solution 
(the licencing terms are OK, though).

- Jouni

---

From: "Z.W. Yan" <[email-masked]>
Date: Fri, 10 Apr 2015 08:49:11 +0800

I support the adoption of this draft as a WG document. 

Zhiwei Yan
2015-04-10 

发件人： Sri Gundavelli (sgundave) 
发送时间： 2015-04-10  07:00:17 
收件人： Seil Jeon 
抄送： [email-masked]; [email-masked] 
主题： Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-mobility-03

---

From: John Kaippallimalil <[email-masked]>
Date: Fri, 10 Apr 2015 13:43:03 +0000

I support the adoption of this draft.

We need more work to see how these addresses are selected and handled over their lifetimes, as well as how this relates to mechanisms between the host network stack and router.

John

> Sent: Thursday, April 09, 2015 7:46 PM
> To: [email-masked]; Dapeng Liu; draft-yegin-dmm-ondemand-
> [email-masked]
> Subject: Re: [DMM] Call for adoption: draft-yegin-dmm-ondemand-
> mobility-03
> 
> I support the adoption of this I-D.. as a basis for further work done
> by the WG. We obviously need to address the valid concerns raised on
> the list by few people. Also, we need to evaluate what parts are
> covered by the declared IPR and whether the WG agrees to keep those in
> the solution (the licencing terms are OK, though).
> 
> - Jouni
> 
> 
>

---

From: Sérgio Figueiredo <[email-masked]>
Date: Fri, 10 Apr 2015 15:33:44 +0100

Hi all,

I support the adoption of this I-D as a WG document, given it provides a 
good technical starting point for the expected relationship between an 
application and the IP stack in DMM environments. In my opinion, next 
steps should include the clarification of MN's default behavior, namely 
what IP addresses (types) should be configured at boot and after 
handover, and what exactly is left for the MN / Application decision and 
action (by usage of the defined API).

Best regards,

-- 
Sérgio Figueiredo

> https://datatracker.ietf.org/ipr/2309/

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

---

From: <[email-masked]>
Date: Fri, 10 Apr 2015 16:19:20 +0000

Hi,

I support adoption of this I-D, it is a good starting point.

Pierrick

---

_________________________________________________________________________________________________________________________

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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 13 Apr 2015 03:27:16 +0200

Hi,

I support adoption of this I-D. I think it is good as a starting point.

Carlos

---

From: Dapeng Liu <[email-masked]>
Date: Thu, 16 Apr 2015 23:21:42 +0800

[as an individual contributor]

I support the idea of “Exposing mobility state to mobile nodes and network nodes” as described in our charter.

For this particular draft, after some offline discussion with the authors, I still have the following comments/suggestions:

1. Definition and distinction of "Fixed IP” and “Sustained IP” should be clear, more clarification text would be helpful.
2. Since we are trying to define API, opinion from application developers or OS vendors would be helpful. We can invite some of those experts to join the discussion.

3. Agree with Jouni’s opinion regarding the IPR, the group need to evaluate it.

--  
Dapeng Liu

---

From: Dapeng Liu <[email-masked]>
Date: Thu, 16 Apr 2015 23:34:35 +0800

--  
Dapeng Liu

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Apr 2015 00:20:01 +0300

Hi Dapeng,

> 1. Definition and distinction of "Fixed IP” and “Sustained IP” should be clear, more clarification text would be helpful.

After rounds of online and offline discussions, I'm still not clear where the issue is.
Could you please explain what exactly is this issue with the current definitions? 
So that we can understand the residual unclarity in your mind, and we let other people also weigh in on the matter.

> 2. Since we are trying to define API, opinion from application developers or OS vendors would be helpful. We can invite some of those experts to join the discussion.

Sure. 

> 3. Agree with Jouni’s opinion regarding the IPR, the group need to evaluate it.

I really don't understand what exact "IPR evaluation" process you are referring to.
I'm not familiar with such a thing in IETF.

Alper

---

From: Dapeng Liu <[email-masked]>
Date: Fri, 17 Apr 2015 15:04:36 +0800

Hi Alper,

> Could you please explain what exactly is this issue with the current definitions?  

Some information is not obvious from the draft text. More explanatory text will at least help the application developer to know whether this is useful for them.
For example, as you said, HoA can either be “fixed IP” or “sustained IP”, then when HoA become "fixed IP" and when it becomes "sustained IP"?

Another example/question: Is there any “fixed IP” that does not belong to the type of HoA?   

In section 3.1:
“ The mobile host is configures a HoA from a centrally-located Home..”,  do you mean “The mobile host is configured a HoA from a centrally-located Home..”?

In section 3.1:
“Applications running as servers at a published IP address require a Fixed IP Address.”..  
Is there any real-life example for this requirement?  Most server only need static public IP address instead of “fixed IP address” (providing mobility) ?

In section 3.1:
“Enterprise applications that connect to an enterprise network via virtual LAN require a Fixed IP Address.” can you explain the reason?

> I'm not familiar with such a thing in IETF.

[quote from Jouni’s mail]
“we need to evaluate what parts are covered by the declared IPR and whether the WG agrees to keep those in the solution”..

--
Dapeng
  
> > [email-masked] (mailto:[email-masked])

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Apr 2015 10:50:05 +0300

Hi Dapeng,

> For example, as you said, HoA can either be “fixed IP” or “sustained IP”, then when HoA become "fixed IP" and when it becomes "sustained IP"?

When a HoA is called "fixed" vs "sustained" is already provided by the respective definitions in the I-D:

- Fixed IP Address

   This is what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP
   address of the mobile host.

   - Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.

   A sustained IP address may be configured and maintained by using
   access network anchoring, corresponding network anchoring, or some
   other solution.

If these definitions are not clear, please recommend improvement.

If you are asking about "how the IP stack on the mobile node" configures such IP addresses, as you know this is not in the scope of this API document, but that'll be addressed by the protocol solutions in DMM.

If you are asking about something else, please clarify that too. I tried to answer your question based on my understanding of what it might be.

> Another example/question: Is there any “fixed IP” that does not belong to the type of HoA?  

What do you mean?

> “ The mobile host is configures a HoA from a centrally-located Home..”,  do you mean “The mobile host is configured a HoA from a centrally-located Home..”?

Yes, it's a typo. (is configured with, or configures).

> Is there any real-life example for this requirement?  

This is by definition, right?
If you are running a server, you need need to publish its IP address (in DNS, for example).
And you want that address to be "fixed" (i.e., not changing). And that's what we call "Fixed IP address" in this I-D.

Please see the below links for real-life examples of how operators are already marketing such things:

https://www.wireless.att.com/businesscenter/popups/general/custom-ip-addressing.jsp

http://www.verizonwireless.com/businessportals/support/faqs/DataServices/faq_static_ip.html

> Most server only need static public IP address instead of “fixed IP address” (providing mobility) ?
> 

Please see the examples on the links above.

> “Enterprise applications that connect to an enterprise network via virtual LAN require a Fixed IP Address.” can you explain the reason?

This is about Enterprise APN.
Or, for example, what AT&T refers to as "customer-provided IP addresses". See the above link, and the below text:

Customer-provided IP addresses: If you decide to provide your own IP address block for your mobile data configuration, you will essentially extend your company's wide area network to include the AT&T cellular network. This allows for simpler firewall configuration, as well as mobile device identification.

> “we need to evaluate what parts are covered by the declared IPR and whether the WG agrees to keep those in the solution”..

Yeah, I know. I also told Jouni that I don't know what exact process he's referring to.
Anyways, if any of the chairs are referring to some IETF process, I'd like to know what that is.

I'm not familiar with it. If there's such a thing, we need to make sure it's an official IETF process, and it'll be applied to all docs across the DMM, and already being applied across the IETF. 

Regards,

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 19 Apr 2015 17:24:47 -0700

Folks,

The call for this I-D has ended and the document will be adopted as a WG 
item. Note that there were still few concerns expressed and it is WG's 
duty to fix and/or reach a rought concensus on those. As usual, the I-D 
serves as a starting point for the WG approved solution.

- Jouni & Dapeng

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Apr 2015 21:59:53 +0200

Le 17/04/2015 09:50, Alper Yegin a écrit :
>>>> I support the idea of “Exposing mobility state to mobile nodes and
>>>> network nodes” as described in our charter.
>>>>
>>>> For this particular draft, after some offline discussion with the
>>>> authors, I still have the following comments/suggestions:
>>>>
>>>> 1. Definition and distinction of "Fixed IP” and “Sustained IP”
>>>> should be clear, more clarification text would be helpful.
>>>
>> Some information is not obvious from the draft text. More explanatory
>> text will at least help the application developer to know whether this
>> is useful for them.
>
>> For example, as you said, HoA can either be “fixed IP” or “sustained
>> IP”, then when HoA become "fixed IP" and when it becomes "sustained IP"?
>

But fixed IP addresses are also provided locally as link-local addresses 
not only by MIP, so that could be integrated as such.

Fixed IP addresses are also provided by VPN and DHCP.

So maybe we could say that a "Fixed Global IP Address is provided by 
MIP, VPN and DHCP".

Alex

> If you are asking about "how the IP stack on the mobile node" configures
> such IP addresses, as you know this is not in the scope of this API
> document, but that'll be addressed by the protocol solutions in DMM.
>
> If you are asking about something else, please clarify that too. I tried
> to answer your question based on my understanding of what it might be.
>
>> “The mobile host is configures a HoA from a centrally-located Home..”,
>>  do you mean “The mobile host is configured a HoA from a
>> centrally-located Home..”?
>>
>
>> “Applications running as servers at a published IP address require
>> aFixed IP Address.”..
> And you want that address to be "fixed" (i.e., not changing). And that's
> what we call "Fixed IP address" in this I-D.
>
>> “Enterprise applications that connect to an enterprise network via
>> virtual LAN require a Fixed IP Address.” can you explain the reason?
>>
>
> Or, for example, what AT&T refers to as "customer-provided IP
> addresses". See the above link, and the below text:
>
> *Customer-provided IP addresses:* If you decide to provide your own IP
> address block for your mobile data configuration, you will essentially
> extend your company's wide area network to include the AT&T cellular
> network. This allows for simpler firewall configuration, as well as
> mobile device identification.
>
>
>>
>>> So that we can understand the residual unclarity in your mind, and we
>>> let other people also weigh in on the matter.
>>>
>>>> 2. Since we are trying to define API, opinion from application
>>>> developers or OS vendors would be helpful. We can invite some of
>>>> those experts to join the discussion.
>>>
>>> Sure.
>>>
>> “we need to evaluate what parts are covered by the declared IPR and
>> whether the WG agrees to keep those in the solution”..
>>
>
> I'm not familiar with it. If there's such a thing, we need to make sure
> it's an official IETF process, and it'll be applied to all docs across
> the DMM, and already being applied across the IETF.
>
> Regards,
>
> Alper
>
>
>
>
>
>
>>
>> --
>> Dapeng
>>>
>>> Alper
>>>
>>>
>>>>
>>>> --
>>>> Dapeng Liu
>>>>
>>>> [email-masked] <mailto:[email-masked]>