Subject: Re: [DMM] draft requirement discussions

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jun 2012 14:04:33 -0500

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 07 Jun 2012 12:15:28 -0700

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:
> 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] 
> <mailto:[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:
>
>     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]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[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 thesentence?
>
>     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.
>
>     *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]>>
>
>     ??
>
>     	
>
>     ??
>
>     	
>
>     Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers
>
>
>     	
>
>
>
>
>     Revise as follows:
>
>     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.
>     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
>
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of h chan
>     Cc: [email-masked] <mailto:[email-masked]>
>     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.
>
>     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
>     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.
>     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
>
>     Cc: [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]>
>     [email-masked] <mailto:[email-masked]>

-- 
Regards,
Charlie P.

---

From: Peter McCann <[email-masked]>
Date: Thu, 7 Jun 2012 20:53:03 +0000

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.
> worthy to be resolved (for example, in my email earlier this week).
> 
> 		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:
> 
> 
> 
> 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？
> 
> 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.
> 
> h chan <[email-masked]>
> 发 件人:  [email-masked]
> 
> 2012/06/06 01:12
> 
> 收件人
> 
> jouni korhonen <[email-masked]>
> 
> 抄送
> 
> 
> 
> 主题
> 
> 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.
> 		-----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]
> 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.
> 
> 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 
> 		-----Original Message----- 		From: Peter McCann 		Sent: Friday, May
> 18, 2012 9:35 AM 		To: jouni korhonen; h chan 		Cc: [email-masked]
> 		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. 		> 		>
> 		> 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?
> 
> 		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 		>>
> 		>> 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
> 
> 
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 07 Jun 2012 14:52:01 -0700

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.

-- 
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 8 Jun 2012 05:59:48 +0000

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,

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 8 Jun 2012 15:08:40 +0000

Let me explain why I picked the use of SHALL and SHOULD in this draft: 

REQ-1 and REQ-2 are requirements of distributed mobility management. They address relevant problems in centralized deployment, which are the reasons for the dmm work. If the solutions does not meet these requirements, they probably may not qualify as a dmm solution. 

The rest of the requirements: REQ-3, REQ-4, REQ-5, REQ-6 are requirements not limited to dmm but are needed in any mobility management. Yet I do not know whether the dmm proposals submitted by various people so far can meet all these requirements. I do not know even if every existing centralized mobility management protocols meet all these requirements. If we insist on using SHALL, we will not be able to name any of them as a mobility management solution if that solution fails any one of them. 

So I guess the use of these later requirements is not to disqualify these solutions, but to enable the user to tell whether which solution meets or does not meet each requirement. Therefore I think that the use of SHOULD is sufficient. 

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Friday, June 08, 2012 1:00 AM
To: Charles E. Perkins; Peter McCann
Cc: [email-masked]; Behcet Sarikaya
Subject: Re: [DMM] draft requirement discussions

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,

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: [email-masked]
Date: Fri, 8 Jun 2012 23:34:00 +0800

Dear Anthony, 

Thank you for clarifying your considerations on how to determine "shall" 
vs. "should". 

May be it is just my lack of understanding for the motivation for defining 
the requirement. :(

Should the requirements be defined based on the realistic use cases and 
not based on individual proposals?  I sincerely hope that all of our 
proposals are targeting to solve the real problem in today network 
deployment scenarios. 

What do you think?  Thanks.
Tricci 

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

To
"Charles E. Perkins" <[email-masked]>, Peter McCann 
<[email-masked]>
cc
"[email-masked]" <[email-masked]>, Behcet Sarikaya <[email-masked]>
Subject
Re: [DMM] draft requirement discussions

REQ-1 and REQ-2 are requirements of distributed mobility management. They 
address relevant problems in centralized deployment, which are the reasons 
for the dmm work. If the solutions does not meet these requirements, they 
probably may not qualify as a dmm solution. 

The rest of the requirements: REQ-3, REQ-4, REQ-5, REQ-6 are requirements 
not limited to dmm but are needed in any mobility management. Yet I do not 
know whether the dmm proposals submitted by various people so far can meet 
all these requirements. I do not know even if every existing centralized 
mobility management protocols meet all these requirements. If we insist on 
using SHALL, we will not be able to name any of them as a mobility 
management solution if that solution fails any one of them. 

So I guess the use of these later requirements is not to disqualify these 
solutions, but to enable the user to tell whether which solution meets or 
does not meet each requirement. Therefore I think that the use of SHOULD 
is sufficient. 

H Anthony Chan

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

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. 

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,

Regards,
Charlie P.

On 6/7/2012 1:53 PM, Peter McCann wrote:
>>               On Wed, Jun 6, 2012 at 11:32 AM, h chan 
<[email-masked]>
>> wrote:
>>                               Subject: Re: [DMM] draft requirement 
REQ-2: Transparency to Upper 
>> Layers
>>                               Subject: RE: [DMM] draft requirement 
REQ-2: Transparency to Upper 
>> Layers
>> May 7, 2012, at 8:58 PM, h chan wrote:                                > 
                                 >> REQ-2: Transparency to
>> such need.                            >                               > 
Does this still mean the mobility support must be
>> always required. For example,                                 >> some   
                 >> applications do not need a
>>                               >                               > I have 
issues to parse O-PS2.. the motivation makes sense though
 >> (The above has been drafted with
>>                               >> [email-masked]  >> 
https://www.ietf.org/mailman/listinfo/dmm                                > 
                                 >
>> _______________________________________________  > dmm mailing list    
>
>> [email-masked]                                  > 

-- 
Regards,
Charlie P.

--------------------------------------------------------
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: jouni korhonen <[email-masked]>
Date: Mon, 11 Jun 2012 15:48:57 +0300

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

---

From: h chan <[email-masked]>
Date: Mon, 11 Jun 2012 16:41:40 +0000

Dear Tricci,

In the current text, only the first 2 sentences are requirements. The remaining sentences are not additional requirements but are explanations and examples of the requirements. The explanatory sentences says: depending on the environment. It is anticipating some are needed and some are not needed depending on the specific network environment they are deployed. In this sense, is it sufficient to use should?

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 08, 2012 11:34 AM
To: h chan
Cc: Charles E. Perkins; [email-masked]; Peter McCann; Behcet Sarikaya
Subject: Re: [DMM] draft requirement discussions

Dear Anthony,

Thank you for clarifying your considerations on how to determine "shall" vs. "should".

May be it is just my lack of understanding for the motivation for defining the requirement. :(

Should the requirements be defined based on the realistic use cases and not based on individual proposals?  I sincerely hope that all of our proposals are targeting to solve the real problem in today network deployment scenarios.

06/08/2012 08:08 AM

To

"Charles E. Perkins" <[email-masked]>, Peter McCann <[email-masked]>

cc

Subject

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Friday, June 08, 2012 1:00 AM
To: Charles E. Perkins; Peter McCann
Cc: [email-masked]; Behcet Sarikaya
Subject: Re: [DMM] draft requirement discussions

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,

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: [email-masked]
Date: Tue, 12 Jun 2012 04:07:07 +0800

Dear Anthony, 

Sincerely thank you for your kind feedback.  I would be ok with the rest 
of the text as you suggested.  However, for the 2nd secntence as you have 
in current text for REQ4...
> 
> The DMM solution SHOULD be able to work between trusted administrative 
> domains when allowed by the security measures deployed between these 
> domains.  Furthermore, the DMM solution SHOULD preserve backwards 
> compatibility with existing network deployment and end hosts.  For 
> example, depending on the environment in which dmm is deployed, the 
> dmm solutions may need to be compatible with other existing mobility 
> protocols that are deployed in that environment or may need to be 
> interoperable with the network or the mobile hosts/routers that do not 
> support the dmm enabling protocol.

Should we replace the "SHOULD" to "SHALL"?   Backward compatibility should 
not be optional, right? 

Thanks in advance for your kind consideration. 
Tricci 

06/11/2012 09:41 AM

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

Dear Tricci,
 
In the current text, only the first 2 sentences are requirements. The 
remaining sentences are not additional requirements but are explanations 
and examples of the requirements. The explanatory sentences says: 
depending on the environment. It is anticipating some are needed and some 
are not needed depending on the specific network environment they are 
deployed. In this sense, is it sufficient to use should? 
 
H Anthony Chan

Dear Anthony, 

To

H Anthony Chan

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

H Anthony Chan

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

Hello Pete,

Regards,
Charlie P.

>>                                   Cc: [email-masked]; 
[email-masked]; jouni korhonen; Peter McCann
>> 发 件人:  [email-masked]
enable more efficient use of 
>>                                   The goal of this requirement is to 
enable more efficient use of 
>>                                   RELEVANT problem:               PS5: 
Wasting resources to support mobile nodes not
              >> The goal of this requirement is
>> but                                   > the title "lack of 
user-centricity" is somewhat confusing.. what
>> explanatory text                                   re-worded.
- Jouni                                   >    >         >>      >> (The 
above has been drafted with
>> Additional contributions and comments are most          >> welcome.)    
                         >>                                   >>
>> H Anthony Chan                                   >>               >>    
                         >>
https://www.ietf.org/mailman/listinfo/dmm  >     >

-- 
Regards,
Charlie P.

--------------------------------------------------------
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: "Charles E. Perkins" <[email-masked]>
Date: Mon, 11 Jun 2012 13:28:51 -0700

Hello folks,

I also prefer to mandate backwards compatibility, although I fear there
is some
ambiguity about exactly what it means.

I'd also greatly prefer using "MUST" instead of "SHALL" to specify mandated
behavior.

Regards,
Charlie P.

On 6/11/2012 1:07 PM, [email-masked] wrote:
> Dear Anthony,
>
> Sincerely thank you for your kind feedback. I would be ok with the
> rest of the text as you suggested. However, for the 2nd secntence as
> you have in current text for REQ4...
> >
> Should we replace the "SHOULD" to "SHALL"? Backward compatibility
> should not be optional, right?
>
> <[email-masked]>, Peter McCann <[email-masked]>, Behcet
> Sarikaya <[email-masked]>
> Subject
> remaining sentences are not additional requirements but are
> explanations and examples of the requirements. The explanatory
> sentences says: depending on the environment. It is anticipating some
> are needed and some are not needed depending on the specific network
> environment they are deployed. In this sense, is it sufficient to use
> should?
>
> H Anthony Chan
>
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* Friday, June 08, 2012 11:34 AM*
> To:* h chan*
> Cc:* Charles E. Perkins; [email-masked]; Peter McCann; Behcet Sarikaya*
> Subject:* Re: [DMM] draft requirement discussions
>
> Dear Anthony,
>
> Should the requirements be defined based on the realistic use cases
> and not based on individual proposals? I sincerely hope that all of
> our proposals are targeting to solve the real problem in today network
> deployment scenarios.
>
> REQ-1 and REQ-2 are requirements of distributed mobility management.
> They address relevant problems in centralized deployment, which are
> the reasons for the dmm work. If the solutions does not meet these
> requirements, they probably may not qualify as a dmm solution.
>
> The rest of the requirements: REQ-3, REQ-4, REQ-5, REQ-6 are
> requirements not limited to dmm but are needed in any mobility
> management. Yet I do not know whether the dmm proposals submitted by
> various people so far can meet all these requirements. I do not know
> even if every existing centralized mobility management protocols meet
> all these requirements. If we insist on using SHALL, we will not be
> able to name any of them as a mobility management solution if that
> solution fails any one of them.
>
> So I guess the use of these later requirements is not to disqualify
> these solutions, but to enable the user to tell whether which solution
> meets or does not meet each requirement. Therefore I think that the
> use of SHOULD is sufficient.
>
> H Anthony Chan
>
> From: [email-masked] [_mailto:[email-masked]] On Behalf
> Of h chan
> 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_
>
> 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]]
> >> [_mailto:[email-masked]] On Behalf Of h chan Sent:
> Wednesday, May
> >> >> [email-masked] >> _https://www.ietf.org/mailman/listinfo/dmm_> >
> >> [email-masked] > _https://www.ietf.org/mailman/listinfo/dmm_
> >>
> >>
> >>
> >> [email-masked] _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_
> >>
> >>
> >>
> >
> >
>
>
> -- 
> Regards,
> Charlie P.
>
> [email-masked]
> __https://www.ietf.org/mailman/listinfo/dmm_
> [email-masked]
> __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: Thu, 14 Jun 2012 13:18:55 +0000

Dear Tricci,

Yes we need requirements on what are absolutely needed but we don’t want to shut off innovations in the solutions.
Let me try to look at the compatibility issue with an example.

If the operator has never deployed the old solution, it may choose not to support the old solution. So, what the operator wants to support depends on the environment in which the new solution is to be used.

If a solution is already deployed in a network, and a new solution is to be deployed in the same network. What is needed is that the operator is able to continue to support the existing solution while providing the new solution.  So the new solution is able to enable to operator to continue to use the old solution. That is, the new solution does not cause the old solution to break. It is therefore able to co-exist with the old solution in a manner that the old solution can continue to be supported.

How about the following text:

The DMM solution SHOULD be able to work between trusted administrative domains when allowed by the security measures
deployed between these domains.
Furthermore, the DMM solution MUST be able to co-exist
with existing network deployment and end hosts so that the existing deployment can continue to be supported.
For example, depending on the environment in which dmm is deployed,
the dmm solutions may need to be compatible with other existing mobility protocols that are deployed in that environment
or may need to be interoperable with the network or the mobile hosts/routers that do not support the dmm enabling protocol.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 11, 2012 4:07 PM
To: h chan
Cc: Charles E. Perkins; [email-masked]; Peter McCann; Behcet Sarikaya
Subject: RE: [DMM] draft requirement discussions

Dear Anthony,

Sincerely thank you for your kind feedback.  I would be ok with the rest of the text as you suggested.  However, for the 2nd secntence as you have in current text for REQ4...
> support the dmm enabling protocol.

Should we replace the "SHOULD" to "SHALL"?   Backward compatibility should not be optional, right?

06/11/2012 09:41 AM

To

cc

"Charles E. Perkins" <[email-masked]>, "[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>, Behcet Sarikaya <[email-masked]>

Subject

Dear Tricci,

H Anthony Chan

Dear Anthony,

06/08/2012 08:08 AM

To

cc

Subject

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Friday, June 08, 2012 1:00 AM
To: Charles E. Perkins; Peter McCann
Cc: [email-masked]; Behcet Sarikaya
Subject: Re: [DMM] draft requirement discussions

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,

Regards,
Charlie P.

--
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 15 Jun 2012 02:14:18 +0000

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,

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Fri, 15 Jun 2012 12:04:53 +0300

<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