Isn't the text clear enough without this addition.
Let me think about this a little more.
Thanks,
/Danny
From: Seil Jeon [mailto:seilj...@gmail.com]
Sent: Sunday, June 26, 2016 11:21
To: Moses, Danny
Cc: dmm@ietf.org
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:danny.mo...@intel.com]
Sent: Sunday, June 26, 2016 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05
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:seilj...@gmail.com]
Sent: Thursday, June 23, 2016 13:33
To: Moses, Danny
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
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:danny.mo...@intel.com]
Sent: Thursday, June 23, 2016 7:06 PM
To: Seil Jeon; dmm@ietf.org<mailto:dmm@ietf.org>
Cc: '"???(??)"'
Subject: RE: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05
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 �C
"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)�C
" 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:dmm-boun...@ietf.org] On Behalf Of Seil Jeon
Sent: Tuesday, June 21, 2016 12:52
To: dmm@ietf.org<mailto:dmm@ietf.org>
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.
"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:dmm-boun...@ietf.org] On Behalf Of Jouni
Sent: Thursday, June 16, 2016 2:16 AM
To: dmm@ietf.org<mailto:dmm@ietf.org>
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.
WGLC #2 Starts: 6/15/2016
WGLC #2 Ends: 6/29/2016 EOB PDT
Regards,
Jouni & Dapeng
_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
