Subject: Re: [DMM] draft requirement discussions

From: "Shuai Gao" <[email-masked]>
Date: Mon, 2 Jul 2012 11:13:11 +0800

Hi Anthony,
	There is a little typo in page 11.   
    "opti-in or opt-out"  ---> "opt-in or opt-out"

Shuai 

======= 2012-06-15 17:05:10 您在来信中写道：=======

><co-chair mode>
>
>Thanks Anthony. The discussion around the requirements have
>stabilized quite a bit, which is good. This I-D is a good
>basis & candidate for the requirement document we have in our
>milestones.
>
>I encourage folks to start looking at gaps to existing (and
>deployed) technologies based on these requirements. We will
>spend time on those during the WG meeting anyway.
>
>- Jouni
>
>
>
>On Jun 15, 2012, at 5:14 AM, h chan wrote:
>
>> The draft has been updated with the recommended changes.
>> http://www.ietf.org/id/draft-chan-dmm-requirements-02.txt
>> 
>> H Anthony Chan
>> 
>> -----Original Message-----
>> From: jouni korhonen [mailto:[email-masked]] 
>> Sent: Monday, June 11, 2012 8:49 AM
>> To: h chan
>> Cc: [email-masked]
>> Subject: Re: [DMM] draft requirement discussions
>> 
>> 
>> Anthony,
>> 
>> Thanks for the update. While the requirements start shaping up
>> nicely I have few documentation related issues. First, Section 1
>> does not need to repeat DMM WG charter and milestones. Second, 
>> Section 4 does not belong to this requirement document. The draft
>> already has rather lengthy intro, which is more than enough as a
>> background information.
>> 
>> - Jouni
>> 
>> On Jun 8, 2012, at 8:59 AM, h chan wrote:
>> 
>>> A draft of the requirement capturing all the requirements so far together with the problem statements has been uploaded:
>>> 
>>> http://www.ietf.org/id/draft-chan-dmm-requirements-01.txt
>>> 
>>> The following is an explanation of how it is structured. 
>>> 
>>> Out of the large number of problem statements, Session 4 on problem statement listed 5 of them as relevant problems. 
>>> 
>>> In Session 5 on requirements, the first 2 requirements address all the relevant problems. They distinguish dmm from the existing centralized deployments. So I think they are the key requirements. They both use "SHALL"
>>> 
>>> The remaining requirements are not owing to problem statements with existing centralized deployments. So I suggest to use the "SHALL" very sparingly. Else we may not be able to call even some existing mobility protocols a mobility management solution lest they meet all the "SHALL" requirements. 
>>> 
>>> H Anthony Chan
>>> 
>>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
>>> Sent: Thursday, June 07, 2012 4:52 PM
>>> To: Peter McCann
>>> Cc: [email-masked]; Behcet Sarikaya
>>> Subject: Re: [DMM] draft requirement discussions
>>> 
>>> 
>>> Hello Pete,
>>> 
>>> Yes, I am fine with that revision and the new proposed text.
>>> 
>>> I was more worried about the seeming suggestion that the DMM
>>> requirement was to interwork with any arbitrary security
>>> mechanism. But, as I mentioned, I think we are pretty close.
>>> 
>>> Regards,
>>> Charlie P.
>>> 
>>> 
>>> On 6/7/2012 1:53 PM, Peter McCann wrote:
>>>> I thought the new text from Anthony was an attempt to answer your
>>>> comment, Charles.  For instance, he removed the text that said,
>>>> "should not be considered the default."  Are you ok with his new
>>>> proposed text?  If not, can you propose text that you would like?
>>>> 
>>>> -Pete
>>>> 
>>>> Charles E. Perkins wrote:
>>>>> Hello folks,
>>>>> 
>>>>> It seems to me that we may be perhaps arriving at a good point for a 
>>>>> new draft.
>>>>> However, there are still some points of discussion that are perhaps 
>>>>> worthy to be resolved (for example, in my email earlier this week).
>>>>> 
>>>>> Maybe we should fire up the issue tracker...?
>>>>> 
>>>>> Regards,
>>>>> Charlie P.
>>>>> 
>>>>> 
>>>>> On 6/7/2012 12:04 PM, Behcet Sarikaya wrote:
>>>>> 
>>>>> 	Hi Jouni,
>>>>> 
>>>>> 	What are the plans on DMM requirements? I see lots of mails and never 
>>>>> ending discussions.
>>>>> 
>>>>> 	Isn't it the time to get the draft out, thank Anthony for his hard 
>>>>> work and move on?
>>>>> 
>>>>> 	Regards,
>>>>> 
>>>>> 	Behcet
>>>>> 
>>>>> 
>>>>> 	On Wed, Jun 6, 2012 at 11:32 AM, h chan <[email-masked]>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 		Yes, the second and third sentences are not additional requirements, 
>>>>> but rather explanations of the requirement in the first sentence. Does 
>>>>> the rewrite sound better now:
>>>>> 
>>>>> 
>>>>> 
>>>>> 		REQ-2: Transparency to Upper Layers
>>>>> 
>>>>> 		The DMM solutions SHALL provide transparency above the IP layer when 
>>>>> needed. Such transparency is needed, when the mobile hosts or entire 
>>>>> mobile networks change their point of attachment to the Internet, for 
>>>>> the application flows that cannot cope with a change of IP address.
>>>>> Otherwise the support to maintain a stable home IP address or prefix 
>>>>> during handover may be declined.
>>>>> 
>>>>> 
>>>>> 
>>>>> 		H Anthony Chan
>>>>> 
>>>>> 
>>>>> 
>>>>> 		From: [email-masked] [mailto:[email-masked]]
>>>>> 		Sent: Wednesday, June 06, 2012 12:56 AM
>>>>> 		To: h chan
>>>>> 		Cc: [email-masked]; [email-masked]; jouni korhonen; Peter McCann
>>>>> 		Subject: 答复: Re: [DMM] draft requirement REQ-2:
>>>>> Transparency to Upper Layers
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 		Hi Anthony:
>>>>> 
>>>>> 		The last part of the sentence (i.e. but the need to maintain a 
>>>>> stable home IP address or prefix SHOULD NOT be taken as
>>>>> default.) seems a littel strange to me.  REQ-2 just describes under 
>>>>> what circumstances the transparency is needed (i.e. when the mobile 
>>>>> hosts or entire mobile networks change their point of attachment to 
>>>>> the Internet, for the application flows that cannot cope with a change 
>>>>> of IP address), that means automatically, otherwise the transparency 
>>>>> is not needed. So why bother to write the last part of the sentence？
>>>>> 
>>>>> 		Besides, when mobile node attaches to its home network, it will 
>>>>> obviously get a home IP address/prefix from its home network. The IP 
>>>>> address/prefix can be considered as stable IP, as long as the mobile 
>>>>> does not change its point of attachment. The last part of the sentence 
>>>>> will just exclude this scenario.
>>>>> 
>>>>> 		If I make any mistake, please correct me.
>>>>> 
>>>>> 		Thanks
>>>>> 		Luowen
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> h chan <[email-masked]>
>>>>> 发 件人:  [email-masked]
>>>>> 
>>>>> 2012/06/06 01:12
>>>>> 
>>>>> 收件人
>>>>> 
>>>>> "[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>, 
>>>>> jouni korhonen <[email-masked]>
>>>>> 
>>>>> 抄送
>>>>> 
>>>>> 
>>>>> 
>>>>> 主题
>>>>> 
>>>>> Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 		Revise as follows:
>>>>> 
>>>>> 		REQ-2: Transparency to Upper Layers
>>>>> 		The DMM solutions SHALL provide transparency above the IP layer when 
>>>>> needed. Such transparency is needed, when the mobile hosts or entire 
>>>>> mobile networks change their point of attachment to the Internet, for 
>>>>> the application flows that cannot cope with a change of IP address, 
>>>>> but the need to maintain a stable home IP address or prefix SHOULD NOT 
>>>>> be taken as default.
>>>>> 		REQ-2M (Motivation for REQ-2)
>>>>> 		The goal of this requirement is to enable more efficient use of 
>>>>> network resources and more efficient routing by not maintaining a 
>>>>> stable IP home IP address when there is no such need.
>>>>> 
>>>>> 		H Anthony Chan
>>>>> 
>>>>> 
>>>>> 		-----Original Message----- 		From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of h chan 		Sent: Wednesday, May
>>>>> 23, 2012 7:51 PM 		To: Peter McCann; jouni korhonen 		Cc: [email-masked]
>>>>> 		Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper 
>>>>> Layers
>>>>> 
>>>>> 		An attempt to clean up the text so far:
>>>>> 
>>>>> 		REQ-2: Transparency to Upper Layers
>>>>> 		The DMM solutions SHALL provide transparency above the IP layer when 
>>>>> needed. Such transparency is needed, when the mobile hosts or entire 
>>>>> mobile networks change their point of attachment to the Internet, for 
>>>>> the application flows that cannot cope with a change of IP address, 
>>>>> but SHOULD NOT be taken as the default behavior.
>>>>> 
>>>>> 		REQ-2M (Motivation for REQ-2)
>>>>> 		The goal of this requirement is to enable more efficient use of 
>>>>> network resources and more efficient routing when mobility support is 
>>>>> implemented by not invoking it for the application flows and nodes 
>>>>> that do not need it.
>>>>> 
>>>>> 		RELEVANT problem: 		PS5: Wasting resources to support mobile nodes not
>>>>> needing mobility support 		IP mobility support is not always required.
>>>>> For example, some applications do not need a stable IP address during 
>>>>> handover, i.e. IP session continuity. Sometimes, the entire 
>>>>> application session runs while the terminal does not change the point of attachment.
>>>>> In these situations that do not require IP mobility support, network 
>>>>> resources are wasted when including additional info to the mobility 
>>>>> context to support the change the point of attachment. Network 
>>>>> resources are also wasted when the via routes are set up for many MNs that do not
>>>>> require IP mobility support. 		OTHER related problem 		O-PS1: Mobility
>>>>> signaling overhead with peer-to-peer communication 		While mobility
>>>>> management enables a mobile host to be reachable, the hosts may then 
>>>>> communicate directly so that the mobility support is no longer needed.
>>>>> Taking the need of mobility support as the default behavior will waste
>>>>> network resources. 		O-PS2: Lack of user-centricity 		Centralized
>>>>> deployment compared with distributed mobility management may be less 
>>>>> capable to support user-centricity. Example in the lack of 
>>>>> user-centricity is to provide mobility support to all mobile nodes by 
>>>>> default regardless of whether the user needs it or not.
>>>>> 
>>>>> 		H Anthony Chan
>>>>> 
>>>>> 		-----Original Message----- 		From: Peter McCann 		Sent: Friday, May
>>>>> 18, 2012 9:35 AM 		To: jouni korhonen; h chan 		Cc: [email-masked]
>>>>> 		Subject: RE: [DMM] draft requirement REQ-2: Transparency to Upper 
>>>>> Layers
>>>>> 
>>>>> 		Hi, Jouni,
>>>>> 
>>>>> 		jouni korhonen wrote: 		> 		> Few comments/questions here: 		> 		> On
>>>>> May 7, 2012, at 8:58 PM, h chan wrote: 		> 		>> REQ-2: Transparency to
>>>>> Upper Layers 		>> The DMM solutions SHALL enable transparency above the
>>>>> IP layer. Such 		>> transparency is needed for the application flows
>>>>> that cannot cope with 		>> a change of IP address and when mobile hosts
>>>>> or entire mobile networks 		>> change their point of attachment to the
>>>>> Internet, but SHOULD NOT be 		>> taken as the default behavior. 		> 		>
>>>>> "SHALL enable" but "SHOULD NOT be taken as the default behavior" seem
>>>>> 		> to conflict. So, what is really meant here? Does this mean something
>>>>> 		> like "MUST implement, SHOULD use" type of solution? Or can one leave
>>>>> 		> transparency completely away if the applications/hosts just don't
>>>>> care 		> whether IP changes or not?
>>>>> 
>>>>> 		I think the latter.  If the applications don't care about
>>>>> transparency, 		then we don't need to pay for it with state and
>>>>> signaling in the network.
>>>>> 
>>>>> 		However, we know that some applications do care, so it SHALL be
>>>>> possible 		to provide it.
>>>>> 
>>>>> 		>> REQ-2M (Motivation for REQ-2) 		>> The goal of this requirement is
>>>>> to 		>> enable more efficient use of network resources and more
>>>>> efficient 		>> routing by not invoking mobility support when there is no
>>>>> such need. 		> 		> Does this still mean the mobility support must be
>>>>> implement even if it 		> is not used?
>>>>> 
>>>>> 		We need some strategy for keeping an IP address through some amount of
>>>>> 		mobility.  However, we needn't optimize the network for this case as
>>>>> it 		might be rather uncommon to keep an address for a very long period
>>>>> of 		time.
>>>>> 
>>>>> 		>> RELEVANT problem: 		>> PS5: Wasting resources to support mobile
>>>>> nodes not needing mobility 		>> support IP mobility support is not
>>>>> always required. For example, 		>> some 		>> applications do not need a
>>>>> stable IP address during handover, i.e. IP 		>> session continuity.
>>>>> Sometimes, the entire application session runs 		>> while the terminal
>>>>> does not change the point of attachment. In these 		>> situations that
>>>>> do not require IP mobility support, network resources 		>> are wasted
>>>>> when mobility context is set up. Network resources are also 		>> wasted
>>>>> when the via routes are set up for many MNs that do not require 		>> IP
>>>>> mobility support. 		>> 		>> OTHER related problem 		>> O-PS1: Mobility
>>>>> signaling overhead with peer-to-peer communication 		>> While mobility
>>>>> management enables a mobile host to be reachable, the 		>> hosts may
>>>>> then communicate directly so that the mobility support is no 		>> longer
>>>>> needed. Taking the need of mobility support as the default 		>> behavior
>>>>> will waste network resources. 		>> O-PS2: Lack of user-centricity 		>>
>>>>> Centralized deployment compared with distributed mobility management
>>>>> 		>> may be less capable to support user-centricity. Example in the lack
>>>>> of 		>> user-centricity is to provide mobility support to all mobile
>>>>> nodes by 		>> default regardless of whether the user needs it or not.
>>>>> 		> 		> I have issues to parse O-PS2.. the motivation makes sense though
>>>>> but 		> the title "lack of user-centricity" is somewhat confusing.. what
>>>>> does 		> forced/always-on mobility support has to do with user
>>>>> centricity?
>>>>> 
>>>>> 		I think Anthony just meant that we should tailor the mobility
>>>>> management 		to the needs of the user.  I wouldn't mind seeing this
>>>>> explanatory text 		re-worded.
>>>>> 
>>>>> 		-Pete
>>>>> 
>>>>> 		> 		> - Jouni 		> 		> 		>> 		>> (The above has been drafted with
>>>>> contributions, inputs and discussions 		>> from various people.
>>>>> Additional contributions and comments are most 		>> welcome.) 		>> 		>>
>>>>> H Anthony Chan 		>> 		>> 		>>
>>>>> _______________________________________________ 		>> dmm mailing list
>>>>> 		>> [email-masked] 		>> https://www.ietf.org/mailman/listinfo/dmm 		> 		>
>>>>> _______________________________________________ 		> dmm mailing list 		>
>>>>> [email-masked] 		> https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>>>> 
>>>>> 
>>>>> 		_______________________________________________ 		dmm mailing list
>>>>> 		[email-masked] 		https://www.ietf.org/mailman/listinfo/dmm
>>>>> 		_______________________________________________ 		dmm mailing list
>>>>> 		[email-masked] 		https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 		_______________________________________________
>>>>> 		dmm mailing list
>>>>> 		[email-masked]
>>>>> 		https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 	_______________________________________________
>>>>> 	dmm mailing list
>>>>> 	[email-masked]
>>>>> 	https://www.ietf.org/mailman/listinfo/dmm
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Regards,
>>> Charlie P.
>>> 
>>> _______________________________________________
>>> dmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>> _______________________________________________
>>> dmm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dmm
>> 
>
>_______________________________________________
>dmm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmm

= = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

Shuai Gao
National Engineering Lab for Next Generation Internet Interconnection Devices
Beijing Jiaotong University
Beijing, China, 100044
[email-masked]
2012-07-02

---

From: h chan <[email-masked]>
Date: Mon, 2 Jul 2012 15:35:17 +0000

Shuai,

Thanks and I am correcting it in the next version.

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

　　　　　　　　致
礼！

Shuai Gao

---

From: [email-masked]
Date: Thu, 5 Jul 2012 10:55:40 +0800

Dear Antony, 

I finally have a chance to review your latest draft.  Sincerely thanks for 
all the good work that you have done.   Sorry that, I still have a few 
comments. 

(1) Since this draft is a requirement document, may be it is not 
appropriate to explicitly refer to a "solution" draft "I-D.jikim-dmm-pmip" 
at the end of the section 3 at this stage of the draft, especially, when 
we have not done any gap analysis. Could you please take out this explicit 
reference?  Thanks. 

(2) As for PS5, it is still not clear to me if we all have the same view 
regarding the definition of "mobility context"?  Could you please kindly 
either refer to another RFC's reference that has this defined or make a 
recommendation on the definition of mobility to see if we all have the 
same understanding?  Thanks. 

(3) I am a bit confused regarding the first sentence of current 
description of REQ4.  "The DMM solution SHOULD be able to work between 
trusted administrative domains when allowed by the security measures 
deployed between these domains.".   Since you already have the "condition" 
described at the end of this sentence, why would the beginning of the 
sentence is a "SHOULD" rather "SHALL" or "MUST"?  What is the point to 
specify the condition of the requirement, if the requirement itself is 
still optional?  It seems to me that, it seems like a conditional 
requirement over a condition?! What does the requirement mean when the 
given condition is not met then? 

Once again, thank you so much your hard work to pull all these together. 
Well deserve recognition from all of us.  Cheers.
Tricci 

h chan <[email-masked]> 
Sent by: [email-masked]
07/02/2012 08:35 AM

To
Shuai Gao <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [DMM] draft requirement discussions

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

>>> A draft of the requirement capturing all the requirements so far 
together with the problem statements has been uploaded:
>>> Out of the large number of problem statements, Session 4 on problem 
statement listed 5 of them as relevant problems. 
>>> 
>>> In Session 5 on requirements, the first 2 requirements address all the 
relevant problems. They distinguish dmm from the existing centralized 
deployments. So I think they are the key requirements. They both use 
"SHALL"
>>> 
>>> The remaining requirements are not owing to problem statements with 
existing centralized deployments. So I suggest to use the "SHALL" very 
sparingly. Else we may not be able to call even some existing mobility 
protocols a mobility management solution lest they meet all the "SHALL" 
requirements. 

>>>>> May 7, 2012, at 8:58 PM, h chan wrote:                             > 
                                 >> REQ-2: Transparency to
>>>>> efficient                                  >> routing by not 
invoking mobility support when there is no
>>>>> always required. For example,                              >> some   
                 >> applications do not need a
>>>>>                            >                               > I have 
issues to parse O-PS2.. the motivation makes sense though
>>>>> but                                > the title "lack of 
user-centricity" is somewhat confusing.. what
 >> (The above has been drafted with
>>>>> Additional contributions and comments are most  >> welcome.)   >>    
 >>
>>>>> H Anthony Chan                             >>  >>          >>
>>>>>                            >> [email-masked]  >> 
https://www.ietf.org/mailman/listinfo/dmm                                > 
                                 >
>>>>> _______________________________________________  > dmm mailing list  
                 >
>>>>> [email-masked]                               > 

　　　　　　　　致
礼！

Shuai Gao
National Engineering Lab for Next Generation Internet Interconnection 
Devices
Beijing Jiaotong University
Beijing, China, 100044
[email-masked]
2012-07-02

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: h chan <[email-masked]>
Date: Thu, 5 Jul 2012 16:54:01 +0000

Dear Tricci,

Regarding your comment:

(1) Since this draft is a requirement document, may be it is not appropriate to explicitly refer to a "solution" draft "I-D.jikim-dmm-pmip" at the end of the section 3 at this stage of the draft, especially, when we have not done any gap analysis. Could you please take out this explicit reference?  Thanks.

I will delete the paragraph on I-D.jikim-dmm-pmip in the next version.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 04, 2012 9:56 PM
To: h chan
Cc: [email-masked]; Shuai Gao
Subject: Re: [DMM] draft requirement discussions

Dear Antony,

I finally have a chance to review your latest draft.  Sincerely thanks for all the good work that you have done.   Sorry that, I still have a few comments.

(1) Since this draft is a requirement document, may be it is not appropriate to explicitly refer to a "solution" draft "I-D.jikim-dmm-pmip" at the end of the section 3 at this stage of the draft, especially, when we have not done any gap analysis. Could you please take out this explicit reference?  Thanks.

(2) As for PS5, it is still not clear to me if we all have the same view regarding the definition of "mobility context"?  Could you please kindly either refer to another RFC's reference that has this defined or make a recommendation on the definition of mobility to see if we all have the same understanding?  Thanks.

(3) I am a bit confused regarding the first sentence of current description of REQ4.  "The DMM solution SHOULD be able to work between trusted administrative domains when allowed by the security measures deployed between these domains.".   Since you already have the "condition" described at the end of this sentence, why would the beginning of the sentence is a "SHOULD" rather "SHALL" or "MUST"?  What is the point to specify the condition of the requirement, if the requirement itself is still optional?  It seems to me that, it seems like a conditional requirement over a condition?! What does the requirement mean when the given condition is not met then?

Once again, thank you so much your hard work to pull all these together.  Well deserve recognition from all of us.  Cheers.
Tricci

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: h chan <[email-masked]>
Date: Thu, 5 Jul 2012 18:22:46 +0000

Tricci,

Regarding your suggestion to clarify “mobility context,” I guess you are pointing to the problem that the term “mobility context,” although already used by some people, has not been properly defined in ietf. Is that right?

If so：

I guess what has been defined in ietf is “context” (associated with a MN) in RFC 3753 which I am copying them below. I guess “mobility context” in this requirements draft simply means “context” as defined in RFC3753.

If so, we can either:

(1) Reference to RFC3753 for context and clarify that this requirements draft calls it “mobility context” to be more explicit.

Or

(2) Change “mobility context” to “context of a MN” throughout the draft.

What do you think?

Context:
The information on the current state of a routing-related service required to re-establish the routing-related service on a new subnet without having to perform the entire protocol exchange with the MN from scratch.

Feature context:
The collection of information representing the context for a given feature.  The full context associated with a MN is the collection of one or more feature contexts.

Context transfer:
The movement of context from one router or other network entity to another as a means of re-establishing routing-related services on a new subnet or collection of subnets.

Routing-related service:
A modification to the default routing treatment of packets to and from the MN.  Initially establishing routing-related services usually requires a protocol exchange with the MN.  An example of a routing-related service is header compression.  The service may also be indirectly related to routing, for example, security.  Security may not affect the forwarding decision of all intermediate routers, but a packet may be dropped if it fails a security check (can't be encrypted, authentication failed, etc.).  Dropping the packet is basically a routing decision.

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: [email-masked]
Date: Fri, 6 Jul 2012 05:58:02 +0800

Dear Antony, 

Sincerely thanks for your kind and prompt responses to my question. 

Thank you very much for your reference which does help me a lot. 

I appreciate your suggestion to replace the "mobility context" by "context 
of MN".  May be also adding the qualification [x] after "context of MN" to 
refer to RFC 3753 would be useful. 

Given this latest understanding, and if we all agree that "context of MN" 
is referring to "all" the contexts as defined in RFC 3753, then, I believe 
some of the current statement in the PS5 is not quite true.  It is 
because, even without the mobility, some of the contexts, i.e. security 
and routing contexts, are still needed, isn't it? 

Please kindly consider my question.  Sincerely thanks again for your info 
again.  Cheers.
Tricci 

07/05/2012 11:22 AM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>, Shuai Gao <[email-masked]>
Subject
RE: [DMM] draft requirement discussions

Tricci,
 
Regarding your suggestion to clarify “mobility context,” I guess you are 
pointing to the problem that the term “mobility context,” although 
already used by some people, has not been properly defined in ietf. Is 
that right?
 
If so：
 
I guess what has been defined in ietf is “context” (associated with a 
MN) in RFC 3753 which I am copying them below. I guess “mobility context
” in this requirements draft simply means “context” as defined in 
RFC3753. 
 
If so, we can either:
 
(1) Reference to RFC3753 for context and clarify that this requirements 
draft calls it “mobility context” to be more explicit.
 
Or
 
(2) Change “mobility context” to “context of a MN” throughout the 
draft. 
 
What do you think?
 
Context:
The information on the current state of a routing-related service required 
to re-establish the routing-related service on a new subnet without having 
to perform the entire protocol exchange with the MN from scratch.
 
Feature context:
The collection of information representing the context for a given 
feature.  The full context associated with a MN is the collection of one 
or more feature contexts.
 
Context transfer:
The movement of context from one router or other network entity to another 
as a means of re-establishing routing-related services on a new subnet or 
collection of subnets.
 
Routing-related service:
A modification to the default routing treatment of packets to and from the 
MN.  Initially establishing routing-related services usually requires a 
protocol exchange with the MN.  An example of a routing-related service is 
header compression.  The service may also be indirectly related to 
routing, for example, security.  Security may not affect the forwarding 
decision of all intermediate routers, but a packet may be dropped if it 
fails a security check (can't be encrypted, authentication failed, etc.). 
Dropping the packet is basically a routing decision.

H Anthony Chan

Dear Antony, 

To

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

>>>>>                                   Yes, the second and third 
sentences are not additional requirements, 

>>>>>                                   Cc: [email-masked]; 
[email-masked]; jouni korhonen; Peter McCann

>>>>>                                   -----Original Message-----     
From: [email-masked]

>>>>>                                   -----Original Message-----     
From: Peter McCann                                   Sent: Friday, May
>>>>>                                   jouni korhonen wrote:          >   
                             > Few comments/questions here:      >     > 
On
                             >> The goal of this requirement is
>>>>> such need.                                   >             > Does 
this still mean the mobility support must be
>>>>> when the via routes are set up for many MNs that do not require      
              >> IP
>>>>> mobility support.                                   >>        >> 
OTHER related problem                                   >> O-PS1: Mobility
>>>>>                                   >  > I have issues to parse 
O-PS2.. the motivation makes sense though
>>>>>                                   >  > - Jouni             >     >   
https://www.ietf.org/mailman/listinfo/dmm  >     >

　　　　　　　　致
礼！

Shuai Gao

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail 
(and any attachment transmitted herewith) is privileged and confidential 
and is intended for the exclusive use of the addressee(s).  If you are not 
an intended recipient, any disclosure, reproduction, distribution or other 
dissemination or use of the information contained is strictly prohibited. 
If you have received this mail in error, please delete it and notify us 
immediately.

---

From: [email-masked]
Date: Fri, 6 Jul 2012 05:58:40 +0800

Dear Antony, 

BIG THANKS! 

Tricci 

07/05/2012 09:54 AM

To

Dear Tricci,
 
Regarding your comment:

 
H Anthony Chan

Dear Antony, 

To

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

On

　　　　　　　　致
礼！

Shuai Gao

---

From: h chan <[email-masked]>
Date: Thu, 5 Jul 2012 22:43:58 +0000

Dear Tricci,

Regarding the first sentence in REQ4:
The DMM solution SHOULD be able to work between trusted administrative domains when allowed by the security measures deployed between these domains.

The intention of the current text is:

The DMM solutions should be able to work between trusted administrative domains.
(Yet it is up to the operators whether they want the DMM solutions to work between them.)
Yet even when they can do so, the security measures deployed between these domains may not allow.

How about the following:

The DMM solutions SHOULD be able to work between trusted administrative domains, but are subject to the security measures deployed between these domains.

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: h chan <[email-masked]>
Date: Thu, 5 Jul 2012 23:21:49 +0000

Dear Tricci,

Yes I agree that some contexts are needed whether the MN is going to change its POA or not.

Then there are two categories of contexts (of an MN): those that are needed only when the MN changes its POA and those that are needed regardless. Is that right?

If so, I would agree with one of your earlier suggestions in trying to define “mobility context”

Definition of “context (of an MN)” is according to that defined in RFC 3753

Definition of “mobility context”
Is the context of an MN, which is only needed owing to a mobility event.

What do you think?

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 05, 2012 4:58 PM
To: h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement discussions

Dear Antony,

I appreciate your suggestion to replace the "mobility context" by "context of MN".  May be also adding the qualification [x] after "context of MN" to refer to RFC 3753 would be useful.

Given this latest understanding, and if we all agree that "context of MN" is referring to "all" the contexts as defined in RFC 3753, then, I believe some of the current statement in the PS5 is not quite true.  It is because, even without the mobility, some of the contexts, i.e. security and routing contexts, are still needed, isn't it?

Please kindly consider my question.  Sincerely thanks again for your info again.  Cheers.
Tricci

07/05/2012 11:22 AM

To

cc

Subject

Tricci,

If so：

If so, we can either:

Or

What do you think?

Context:

Feature context:

Context transfer:

Routing-related service:

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: [email-masked]
Date: Fri, 6 Jul 2012 07:27:56 +0800

Dear Anthony, 

Sincerely thanks for your kind and prompt responses once again for my 
question, it helps me much better for your motivation on this requirement.

May I suggest a friendly amendment to your sentence as below, please: 
The DMM solutions SHOULD be able to work between trusted administrative 
domains which must have underlying security measures deployed between 
these domains.
My thinking is that, if the DMM is deployed between two trusted 
administrative domains, then, the two domains must have some sort of 
security environment built between them. correct? 

Great thanks!
Tricci 

07/05/2012 03:43 PM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "Charles E. Perkins" <[email-masked]>, 
"[email-masked]" <[email-masked]>, Jouni 
<[email-masked]>
Subject
RE: [DMM] draft requirement discussions

Dear Tricci,
 
Regarding the first sentence in REQ4:
The DMM solution SHOULD be able to work between trusted administrative 
domains when allowed by the security measures deployed between these 
domains.

The DMM solutions should be able to work between trusted administrative 
domains. 
(Yet it is up to the operators whether they want the DMM solutions to work 
between them.) 
Yet even when they can do so, the security measures deployed between these 
domains may not allow. 
 
How about the following:
 
The DMM solutions SHOULD be able to work between trusted administrative 
domains, but are subject to the security measures deployed between these 
domains.
 
H Anthony Chan

Dear Antony, 

To

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

On

　　　　　　　　致
礼！

Shuai Gao

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Jul 2012 17:32:38 -0700

Hello folks,

Actually, I pretty much prefer Anthony's original formulation. Somehow, 
mandating security
measures to be in place in the domains themselves seems likely to unduly 
restrict the space
of possible solutions.

Regards,
Charlie P.

On 7/5/2012 4:27 PM, [email-masked] wrote:
> The DMM solutions SHOULD be able to work between trusted 
> administrative domains which must have underlying security measures 
> deployed between these domains.
> >>>>>
> *h chan <[email-masked]>*
>
> 07/05/2012 03:43 PM
>
> 	
> To
> <[email-masked]>, "Charles E. Perkins" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Jouni <[email-masked]>
> Subject
> The DMM solutions SHOULD be able to work between trusted 
> administrative domains, but are subject to the security measures 
> deployed between these domains.
>
> H Anthony Chan
>
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* Wednesday, July 04, 2012 9:56 PM*
> To:* h chan*
> Cc:* [email-masked]; Shuai Gao*
> Subject:* Re: [DMM] draft requirement discussions
>
> Dear Antony,
>
> I finally have a chance to review your latest draft.  Sincerely thanks 
> for all the good work that you have done.   Sorry that, I still have a 
> few comments.
>
> appropriate to explicitly refer to a "solution" draft 
> "I-D.jikim-dmm-pmip" at the end of the section 3 at this stage of the 
> draft, especially, when we have not done any gap analysis. Could you 
> please take out this explicit reference?  Thanks.
>
> (2) As for PS5, it is still not clear to me if we all have the same 
> view regarding the definition of "mobility context"?  Could you please 
> kindly either refer to another RFC's reference that has this defined 
> or make a recommendation on the definition of mobility to see if we 
> all have the same understanding?  Thanks.
>
> deployed between these domains.".   Since you already have the 
> "condition" described at the end of this sentence, why would the 
> beginning of the sentence is a "SHOULD" rather "SHALL" or "MUST"? 
>  What is the point to specify the condition of the requirement, if the 
> requirement itself is still optional?  It seems to me that, it seems 
> like a conditional requirement over a condition?! What does the 
> requirement mean when the given condition is not met then?
>
> Once again, thank you so much your hard work to pull all these 
> together.  Well deserve recognition from all of us.  Cheers.
> Tricci
>
> *h chan <[email-masked]>*
> From: Shuai Gao [_mailto:[email-masked]]
> ======= 2012-06-15 17:05:10 ???????:=======
>
> ><co-chair mode>
> >
> >> _http://www.ietf.org/id/draft-chan-dmm-requirements-02.txt_
> >>
> >> H Anthony Chan
> >>
> >> From: jouni korhonen [_mailto:[email-masked]]
> >>> _http://www.ietf.org/id/draft-chan-dmm-requirements-01.txt_
> >>>
> >>> Out of the large number of problem statements, Session 4 on 
> problem statement listed 5 of them as relevant problems.
> >>>
> >>> In Session 5 on requirements, the first 2 requirements address all 
> the relevant problems. They distinguish dmm from the existing 
> centralized deployments. So I think they are the key requirements. 
> They both use "SHALL"
> >>>
> >>> The remaining requirements are not owing to problem statements 
> with existing centralized deployments. So I suggest to use the "SHALL" 
> very sparingly. Else we may not be able to call even some existing 
> mobility protocols a mobility management solution lest they meet all 
> the "SHALL" requirements.
> >>>
> >>> H Anthony Chan
> >>>
> >>>
> >>> From: [email-masked] [_mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> >>>>>                   From: [email-masked] 
> [_mailto:[email-masked]]
> >>>>>                   Subject: ??: Re: [DMM] draft requirement REQ-2:
> >>>>> is not needed. So why bother to write the last part of the sentence?
> >>>>>
> >>>>> ? ??:  [email-masked]
> >>>>>
> >>>>> 2012/06/06 01:12
> >>>>>
> >>>>> ???
> >>>>>
> >>>>> ??
> >>>>> ??
> >>>>> [_mailto:[email-masked]] On Behalf Of h chan             
>       Sent: Wednesday, May
> >>>>> do not require IP mobility support, network resources           
>   >> are wasted
> >>>>> when mobility context is set up. Network resources are also     
>             >> wasted
> >>>>> management enables a mobile host to be reachable, the           
>     >> hosts may
> >>>>> then communicate directly so that the mobility support is no     
>           >> longer
> >>>>> needed. Taking the need of mobility support as the default       
>           >> behavior
> >>>>>                   >           > - Jouni     >                   
> _https://www.ietf.org/mailman/listinfo/dmm_            >     >
> >>>>> [email-masked] > _https://www.ietf.org/mailman/listinfo/dmm_
> >>>>>
> >>>>>
> >>>>>
> _https://www.ietf.org/mailman/listinfo/dmm_
> _https://www.ietf.org/mailman/listinfo/dmm_
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _https://www.ietf.org/mailman/listinfo/dmm_
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _https://www.ietf.org/mailman/listinfo/dmm_
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Charlie P.
> >>>
> >>> _https://www.ietf.org/mailman/listinfo/dmm_
> >>> _https://www.ietf.org/mailman/listinfo/dmm_
> >>
> >
> >_https://www.ietf.org/mailman/listinfo/dmm_
>
> ?
> ?!
> [email-masked]
> __https://www.ietf.org/mailman/listinfo/dmm_
>
>
> ZTE Information Security Notice: The information contained in this 
> mail (and any attachment transmitted herewith) is privileged and 
> confidential and is intended for the exclusive use of the 
> addressee(s).  If you are not an intended recipient, any disclosure, 
> reproduction, distribution or other dissemination or use of the 
> information contained is strictly prohibited.  If you have received 
> this mail in error, please delete it and notify us immediately.
>
>

-- 
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 6 Jul 2012 14:55:50 +0000

Dear Tricci,

I checked earlier email discussions again to recall that Charles had pointed out it is not possible to interwork with any arbitrary security mechanism. That is the reason for the text in the current draft:

The DMM solution SHOULD be able to work between trusted administrative domains when allowed by the security measures deployed between these domains

H Anthony Chan

From: Charles E. Perkins [mailto:[email-masked]]
Sent: Thursday, July 05, 2012 7:33 PM
To: [email-masked]; h chan
Cc: [email-masked]
Subject: Re: [DMM] draft requirement discussions

Hello folks,

Actually, I pretty much prefer Anthony's original formulation.  Somehow, mandating security
measures to be in place in the domains themselves seems likely to unduly restrict the space
of possible solutions.

Regards,
Charlie P.

On 7/5/2012 4:27 PM, [email-masked]<mailto:[email-masked]> wrote:
Dear Anthony,

Sincerely thanks for your kind and prompt responses once again for my question, it helps me much better for your motivation on this requirement.

May I suggest a friendly amendment to your sentence as below, please:
The DMM solutions SHOULD be able to work between trusted administrative domains which must have underlying security measures deployed between these domains.
My thinking is that, if the DMM is deployed between two trusted administrative domains, then, the two domains must have some sort of security environment built between them. correct?

Great thanks!
Tricci

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

07/05/2012 03:43 PM

To

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

cc

"[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "Charles E. Perkins" <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Jouni <[email-masked]><mailto:[email-masked]>

Subject

Dear Tricci,

How about the following:

H Anthony Chan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, July 04, 2012 9:56 PM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>; Shuai Gao
Subject: Re: [DMM] draft requirement discussions

Dear Antony,

Once again, thank you so much your hard work to pull all these together.  Well deserve recognition from all of us.  Cheers.
Tricci
h chan <[email-masked]><mailto:[email-masked]>
Sent by: [email-masked]<mailto:[email-masked]>

07/02/2012 08:35 AM

To

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

cc

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

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

>> Cc: [email-masked]<mailto:[email-masked]>
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Charles E. Perkins
>>> Cc: [email-masked]<mailto:[email-masked]>; Behcet Sarikaya
>>>>>                  On Wed, Jun 6, 2012 at 11:32 AM, h chan <[email-masked]><mailto:[email-masked]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>                                   From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
>>>>>                                   Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; jouni korhonen; Peter McCann
>>>>> h chan <[email-masked]><mailto:[email-masked]>
>>>>> 发 件人:  [email-masked]<mailto:[email-masked]>
>>>>>
>>>>> 2012/06/06 01:12
>>>>>
>>>>> 收件人
>>>>>
>>>>> "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Peter McCann <[email-masked]><mailto:[email-masked]>,
>>>>> jouni korhonen <[email-masked]><mailto:[email-masked]>
>>>>>
>>>>> 抄送
>>>>>
>>>>>
>>>>>
>>>>> 主题
>>>>>
>>>>>                                   -----Original Message-----                                   From: [email-masked]<mailto:[email-masked]>
>>>>> 23, 2012 7:51 PM                                   To: Peter McCann; jouni korhonen                                   Cc: [email-masked]<mailto:[email-masked]>
>>>>> 18, 2012 9:35 AM                                   To: jouni korhonen; h chan                                   Cc: [email-masked]<mailto:[email-masked]>
>>>>>                                   >> [email-masked]<mailto:[email-masked]>                                   >> https://www.ietf.org/mailman/listinfo/dmm                                   >                                   >
>>>>> [email-masked]<mailto:[email-masked]>                                   > https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>
>>>>>
>>>>>                                   [email-masked]<mailto:[email-masked]>                                   https://www.ietf.org/mailman/listinfo/dmm
>>>>>                                   [email-masked]<mailto:[email-masked]>                                   https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                                   [email-masked]<mailto:[email-masked]>
>>>>>                  [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

　　　　　　　　致
礼！

Shuai Gao
National Engineering Lab for Next Generation Internet Interconnection Devices
Beijing Jiaotong University
Beijing, China, 100044
[email-masked]<mailto:[email-masked]>
2012-07-02

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

dmm mailing list

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

--

Regards,

Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 6 Jul 2012 15:25:12 +0000

Dear Tricci,

We can add a definition of “mobility context” in the future version. The definition is based on the definitions of “context” and “feature context” in RFC 3753

Context (from RFC 3753)

      The information on the current state of a routing-related service
      required to re-establish the routing-related service on a new
      subnet without having to perform the entire protocol exchange with
      the MN from scratch.

Feature context (from RFC 3753)

     The collection of information representing the context for a given
      feature.  The full context associated with a MN is the collection
      of one or more feature contexts.

Then “mobility context” can be understood in terms of a feature context and can be explicitly defined as follows:

Mobility context (definition)

     The context required to provide mobility support.

What do you think?

H Anthony Chan

From: h chan
Sent: Thursday, July 05, 2012 6:22 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [DMM] draft requirement discussions

Dear Tricci,

What do you think?

H Anthony Chan

Dear Antony,

07/05/2012 11:22 AM

To

cc

Subject

Tricci,

If so：

If so, we can either:

Or

What do you think?

Context:

Feature context:

Context transfer:

Routing-related service:

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: [email-masked]
Date: Mon, 9 Jul 2012 16:27:28 +0800

Dear Anthony, 

Thank you for your kind suggestions.   Sorry for my late responses. Please 
my comments inline below. 

Thanks
Tricci 

07/06/2012 08:25 AM

To

Dear Tricci,
 
We can add a definition of “mobility context” in the future version. The 
definition is based on the definitions of “context” and “feature 
context” in RFC 3753
 
Context (from RFC 3753)

 
 
Then “mobility context” can be understood in terms of a feature context 
and can be explicitly defined as follows:

 
What do you think?

Tricci > May be I mistaken your proposal.  The contexts that you referred 
obtained from RFC 3753, IMHO, regardless the mobility is enabled on the MN 
or not, those contexts will be existed for the UE.  For example, as soon 
as the MN attaches to the network, there should be Security Context and 
Feature Context associated with the MN.   The security context is needed 
because, all the Security Association (including the Security Index, Keys 
etc.) would have a lifetime regardless the MN is moving or not.  Once the 
lifetime is going to expired, the network will need to trigger the 
re-authentication.  Likewise, if the Network needs to determine how to 
apply the service policy towards the MN, the feature context associated 
with MN will assist the network to make the proper decision.  Even the 
location context of the MN would be needed for the network so that the 
network would know how to policy and charging based on the location info 
of the MN. 

Tricci > All in all, I would think that the mobility context has to be 
something specifically triggered by the mobility event.  What do you 
think? 

Thanks.
Tricci 
 
H Anthony Chan
 
From: h chan 
 
Dear Tricci,
 
Yes I agree that some contexts are needed whether the MN is going to 
change its POA or not. 
 
Then there are two categories of contexts (of an MN): those that are 
needed only when the MN changes its POA and those that are needed 
regardless. Is that right?
 
If so, I would agree with one of your earlier suggestions in trying to 
define “mobility context”
 
Definition of “context (of an MN)” is according to that defined in RFC 
3753

What do you think?
 
H Anthony Chan

Dear Antony, 

To

Tricci, 

If so： 

If so, we can either: 

Or 

What do you think? 
  
Context: 
  
Feature context: 
  
Context transfer: 
  
Routing-related service: 

H Anthony Chan 

Dear Antony, 

To

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

On

　　　　　　　　致
礼！

Shuai Gao

---

From: <[email-masked]>
Date: Mon, 9 Jul 2012 09:35:15 +0000

Hi Anthony,

May I suggest the following definition for Mobility context:

     Collection information required to provide mobility support for a given MN.

Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de h chan
Envoyé : vendredi 6 juillet 2012 17:25
À : [email-masked]
Cc : [email-masked]
Objet : Re: [DMM] draft requirement discussions

Dear Tricci,

Context (from RFC 3753)

What do you think?

H Anthony Chan

From: h chan

Dear Tricci,

What do you think?

H Anthony Chan

Dear Antony,

07/05/2012 11:22 AM

To

cc

Subject

Tricci,

If so：

If so, we can either:

Or

What do you think?

Context:

Feature context:

Context transfer:

Routing-related service:

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: h chan <[email-masked]>
Date: Tue, 10 Jul 2012 20:52:06 +0000

Dear Tricci,

I agree that the different feature contexts in the RFC 3753 definition are not mutually exclusive of each other.

For example,
The information needed to support mobility are: a, b, c
The information needed to support security service are: b, d
The information needed to provide location-based service: c, d, e

It may be possible to define mobility context to include a only:
The collection of information required only to provide mobility support.

Yet it may be more intuitive to define the feature contexts such that their information are not mutually exclusive of each other, i.e,
The collection of information required to provide mobility support.

Mobility context includes a,b,c
Security context includes b,d
Location-based context includes c,d,e

Then, when we say that mobility context is not needed, we do not mean that we also do not need security context.
So, we need to make sure PS5 is indeed worded to be interpreted this way. (I think this is what you mean when referring to PS5?)
How about changing the title of PS5 to:

PS5: Wasting resources to provide mobility support to nodes (or mobile nodes) not needing it

(Original PS5: Wasting resources to support mobile nodes not needing mobility support)

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 09, 2012 3:27 AM
To: h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement discussions

Dear Anthony,

Thank you for your kind suggestions.   Sorry for my late responses.  Please my comments inline below.

Thanks
Tricci

07/06/2012 08:25 AM

To

cc

Subject

Dear Tricci,

Context (from RFC 3753)

What do you think?

Tricci > May be I mistaken your proposal.  The contexts that you referred obtained from RFC 3753, IMHO, regardless the mobility is enabled on the MN or not, those contexts will be existed for the UE.  For example, as soon as the MN attaches to the network, there should be Security Context and Feature Context associated with the MN.   The security context is needed because, all the Security Association (including the Security Index, Keys etc.) would have a lifetime regardless the MN is moving or not.  Once the lifetime is going to expired, the network will need to trigger the re-authentication.  Likewise, if the Network needs to determine how to apply the service policy towards the MN, the feature context associated with MN will assist the network to make the proper decision.  Even the location context of the MN would be needed for the network so that the network would know how to policy and charging based on the location info of the MN.

Tricci > All in all, I would think that the mobility context has to be something specifically triggered by the mobility event.  What do you think?

Thanks.
Tricci

H Anthony Chan

From: h chan

Dear Tricci,

What do you think?

H Anthony Chan

Dear Antony,

07/05/2012 11:22 AM

To

cc

Subject

Tricci,

If so：

If so, we can either:

Or

What do you think?

Context:

Feature context:

Context transfer:

Routing-related service:

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: h chan <[email-masked]>
Date: Thu, 19 Jul 2012 01:29:37 +0000

Pierrick,
Thanks and I have put it into the 01 version.
H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 09, 2012 2:35 AM
To: h chan; [email-masked]
Cc: [email-masked]
Subject: RE: [DMM] draft requirement discussions

Hi Anthony,

Pierrick

Dear Tricci,

Context (from RFC 3753)

What do you think?

H Anthony Chan

From: h chan

Dear Tricci,

What do you think?

H Anthony Chan

Dear Antony,

07/05/2012 11:22 AM

To

cc

Subject

Tricci,

If so：

If so, we can either:

Or

What do you think?

Context:

Feature context:

Context transfer:

Routing-related service:

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

Thank you.

---

From: h chan <[email-masked]>
Date: Thu, 19 Jul 2012 23:00:56 +0000

Seeing no objection, I am making the change in the title of PS5 as the basis for further discussion.
PS5: Wasting resources to provide mobility support to nodes not needing such support

H Anthony Chan

From: h chan
Sent: Tuesday, July 10, 2012 1:52 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [DMM] draft requirement discussions

Dear Tricci,

For example,

H Anthony Chan

Dear Anthony,

Thanks
Tricci

07/06/2012 08:25 AM

To

cc

Subject

Dear Tricci,

Context (from RFC 3753)

What do you think?

Thanks.
Tricci

H Anthony Chan

From: h chan

Dear Tricci,

What do you think?

H Anthony Chan

Dear Antony,

07/05/2012 11:22 AM

To

cc

Subject

Tricci,

If so：

If so, we can either:

Or

What do you think?

Context:

Feature context:

Context transfer:

Routing-related service:

H Anthony Chan

Dear Antony,

07/02/2012 08:35 AM

To

cc

Subject

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]]
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai

　　　　　　　　致
礼！

Shuai Gao

---

From: [email-masked]
Date: Fri, 20 Jul 2012 07:41:27 +0800

Dear Anthony, 

I feel extremely bad for not responding to you earlier.  I just returned 
from attending a different SDO meeting last week which is very hectic for 
me, and I have received so many emails that your past email to me have 
lost in somewhere in my pile. 

Thank you for your kind support to address my concern.  With your revised 
PS5, I presume that all the corresponding "mobility context" arguments 
will be removed as well.   Correct?

Sincerely thanks.
Tricci 

07/19/2012 04:00 PM

To

Seeing no objection, I am making the change in the title of PS5 as the 
basis for further discussion. 
PS5: Wasting resources to provide mobility support to nodes not needing 
such support
 
H Anthony Chan
 
From: h chan 
 
Dear Tricci,
 
I agree that the different feature contexts in the RFC 3753 definition are 
not mutually exclusive of each other. 
 
For example, 

Yet it may be more intuitive to define the feature contexts such that 
their information are not mutually exclusive of each other, i.e,
The collection of information required to provide mobility support.

Then, when we say that mobility context is not needed, we do not mean that 
we also do not need security context. 
So, we need to make sure PS5 is indeed worded to be interpreted this way. 
(I think this is what you mean when referring to PS5?)
How about changing the title of PS5 to:
 
PS5: Wasting resources to provide mobility support to nodes (or mobile 
nodes) not needing it
 
(Original PS5: Wasting resources to support mobile nodes not needing 
mobility support)
 
H Anthony Chan

Dear Anthony, 

Thanks 
Tricci 

To

Dear Tricci, 

Context (from RFC 3753) 

  

  
  
What do you think? 

Thanks. 
Tricci 
  
H Anthony Chan 
  
From: h chan 
  
Dear Tricci, 

  

  
What do you think? 
  
H Anthony Chan 

Dear Antony, 

To

Tricci, 

If so： 

If so, we can either: 

Or 

What do you think? 
 
Context: 
 
Feature context: 
 
Context transfer: 
 
Routing-related service: 

H Anthony Chan 

Dear Antony, 

To

Shuai,

H Anthony Chan

-----Original Message-----
From: Shuai Gao [mailto:[email-masked]] 
Sent: Sunday, July 01, 2012 10:13 PM
To: h chan
Cc: [email-masked]
Subject: Re: Re: [DMM] draft requirement discussions

Hi Anthony,

Shuai 

On

　　　　　　　　致
礼！

Shuai Gao

---

From: [email-masked]
Date: Tue, 31 Jul 2012 10:42:55 -0700

Dear Antony, 

Thanks again for your hard work to put this DMM requirements draft 
together. 

Per my promise to you to suggest the definitions for the trusted and 
untrusted network access, here is my proposal: 

For a trusted network access, the communication between the MN and the 
network is trusted to secure. For an untrusted network access, the 
communication between the MN and the network is not trusted to be secure.

For a trusted network access, all communication between the network 
administrative domains is transferred over pre-established secure links. 
For an untrusted network access, a secured tunnel (e.g. IPSec) needs to be 
established on a per access basis, if required, to secure communication 
between the MN and the access network.

Please feel free to comment and modify.  Cheers.
Tricci