Subject: Re: [DMM] draft requirement REQ-4: compatibility

From: h chan <[email-masked]>
Date: Tue, 5 Jun 2012 17:26:07 +0000

Replacing REQ-4 with the following:

REQ-4: compatibility
The DMM solution MUST NOT break when being deployed between trusted administrative domains and SHOULD allow inter-working with the security measures deployed between these domains. Existing network deployment and end hosts also SHOULD NOT break.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

An attempt to clean up the text for REQ-4:

REQ-4: compatibility 
The DMM solutions SHALL support existing network deployment with IPv6 (e.g. existing IPv6 address assignment), be compatible with other mobility protocols, and be interoperable with the network or the mobile hosts/routers that do not support the DMM enabling protocol so that the existing network deployments and end hosts are not broken.
REQ-4M (Motivation for REQ-4)
Motivation: The motivation of this requirement is not to break existing network deployments and end hosts. 
OTHER related problem
O-PS3: Complicated deployment with too many variants and extensions of MIP
Deployment is complicated with many variants and extensions of MIP. When introducing new functions which may add to the complicity, existing solutions are more vulnerable to break.

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

jouni korhonen wrote:
> 
> On May 7, 2012, at 9:04 PM, h chan wrote:
> 
>> REQ-4: compatibility
>> The DMM solutions SHALL support existing network deployment with
>> IPv6
>> (e.g. existing IPv6 address assignment), be compatible with other
>> mobility protocols, and be interoperable with the network or the
>> mobile hosts/routers that do not support the DMM enabling protocol so
>> that the existing network deployments are unaffected.
>> 
>> REQ-4M (Motivation for REQ-4)
>> Motivation: The motivation of this requirement is to be able to work
>> with network architectures of both hierarchical networks and flattened
>> networks, so that the mobility management protocol possesses enough
>> flexibility to support different networks, and so that the existing
>> networks and hosts are not affected and do not break.
> 
> Isn't the motivation just "SHALL not break existing network
> deployments and end hosts" ?
> Either the network or the host may not have any idea of the solutions
> developed in DMM.

I think that's a reasonable simplification.  We need a strategy for
backwards compatibility.

-Pete

> - JOuni
> 
>> 
>> OTHER related problem O-PS3: Complicated deployment with too many
>> variants and extensions of MIP Deployment is complicated with many
>> variants and extensions of
> MIP. When introducing new functions which may add to the complicity,
> existing solutions are more vulnerable to break.
>> 
>> (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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Jun 2012 15:55:36 -0700

Hello folks,

> The DMM solution MUST NOT break when being deployed between trusted administrative domains and SHOULD allow inter-working with the security measures deployed between these domains. Existing network…

I understand the intent, but specifying that something "SHOULD NOT break"
seems almost like berating the children.

How about:

"The DMM solution is required to work between trusted administrative domains
   and SHOULD allow inter-working with the security measures deployed 
between
   these domains. Furthermore, the DMM solution must preserve backwards
   compatibility with existing network deployment and end hosts."

I have two more issues:

- You cannot guarantee inter-working with completely arbitrary security 
measures.
- I am confident that the DMM solution will require security.  Thus, the 
"SHOULD"
   in the above text is somehow incorrect.

I'm not sure exactly how best to resolve these latter two issues, but 
before I
try to make a resolution, I thought it would be good to raise the issue 
on this
list for possible further discussion.

-- 
Regards,
Charlie P.

---

From: [email-masked]
Date: Wed, 6 Jun 2012 14:14:41 +0800

Hi Anthony:

It seems the REQ-4 is changed a lot. Interworking between trusted 
administrative domains is good to me, and the interworking with existing 
network deployments which are not DMM enablded is also very important. I 
believe we have already have consistency about this.  So, how about 
mergering this two parts as following ?

---------------------------------------------------------------------------------
The DMM solutions SHALL support existing network deployment with IPv6 
(e.g. existing IPv6 address assignment), be compatible with other mobility 
protocols, and be interoperable with the network or the mobile 
hosts/routers that do not support the DMM enabling protocol so that the 
existing network deployments and end hosts are not broken. Furthermore, 
the DMM solution MUST NOT break when being deployed between trusted 
administrative domains and SHOULD allow inter-working with the security 
measures deployed between these domains.
---------------------------------------------------------------------------------

Hope this make sense.

BR
Luowen

h chan <[email-masked]> 
发件人:  [email-masked]
2012/06/06 01:26

收件人
"[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>, 
jouni korhonen <[email-masked]>
抄送

主题
Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility
The DMM solution MUST NOT break when being deployed between trusted 
administrative domains and SHOULD allow inter-working with the security 
measures deployed between these domains. Existing network deployment and 
end hosts also SHOULD NOT break.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h 
chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility 
The DMM solutions SHALL support existing network deployment with IPv6 
(e.g. existing IPv6 address assignment), be compatible with other mobility 
protocols, and be interoperable with the network or the mobile 
hosts/routers that do not support the DMM enabling protocol so that the 
existing network deployments and end hosts are not broken.
REQ-4M (Motivation for REQ-4)
Motivation: The motivation of this requirement is not to break existing 
network deployments and end hosts. 
OTHER related problem
O-PS3: Complicated deployment with too many variants and extensions of MIP
Deployment is complicated with many variants and extensions of MIP. When 
introducing new functions which may add to the complicity, existing 
solutions are more vulnerable to break.

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

---

From: h chan <[email-masked]>
Date: Thu, 7 Jun 2012 23:13:53 +0000

Luo,

I think “existing network deployments which are not DMM enablded” are included in “existing network deployments.

The end result is the compatibility with existing network deployment and end hosts. So whatever the dmm solution needs to do to ensure such compatibility. Do you agree?

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 06, 2012 1:15 AM
To: h chan
Cc: [email-masked]; [email-masked]; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-4: compatibility

Hi Anthony:

It seems the REQ-4 is changed a lot. Interworking between trusted administrative domains is good to me, and the interworking with existing network deployments which are not DMM enablded is also very important. I believe we have already have consistency about this.  So, how about mergering this two parts as following ?

---------------------------------------------------------------------------------
The DMM solutions SHALL support existing network deployment with IPv6 (e.g. existing IPv6 address assignment), be compatible with other mobility protocols, and be interoperable with the network or the mobile hosts/routers that do not support the DMM enabling protocol so that the existing network deployments and end hosts are not broken. Furthermore, the DMM solution MUST NOT break when being deployed between trusted administrative domains and SHOULD allow inter-working with the security measures deployed between these domains.
---------------------------------------------------------------------------------

Hope this make sense.

BR
Luowen

2012/06/06 01:26

收件人

"[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>, jouni korhonen <[email-masked]>

抄送

主题

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

---

From: h chan <[email-masked]>
Date: Fri, 8 Jun 2012 00:07:50 +0000

I think the intention is to allow interworking between 2 operators' network domains if the operators choose to do so. Yet operators may not choose to do that. So the DMM solution can only enable such choice. Also, it can do that only if the security measures allow. 

How about the following:

The DMM solution SHOULD enable working 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. 

H Anthony Chan

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2012 5:56 PM
To: h chan
Cc: [email-masked]; Peter McCann; jouni korhonen
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Hello folks,

How about:

I have two more issues:

-- 
Regards,
Charlie P.

---

From: [email-masked]
Date: Fri, 8 Jun 2012 09:21:06 +0800

Hi Antony,

Yes, I agree, the DMM solution shall be compatibile with the exsiting 
network deployments. But only say "Existing network deployment and end 
hosts also SHOULD NOT break" or "the DMM solution SHOULD preserve 
backwards compatibility with existing network deployment and end hosts" 
may not be very specific.

how about 

The DMM solution SHOULD enable working 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 that do not 
support the DMM enabling protocol. 

And put those description such as  "The DMM solutions SHALL support 
existing network deployment with IPv6 (e.g. existing IPv6 address 
assignment), be compatible with other mobility protocols, and be 
interoperable with the network or the mobile hosts/routers that do not 
support the DMM enabling protocol so that the existing network deployments 
and end hosts are not broken." into the motivation, e.g

Motivation: The motivation of this requirement is to ensure the DMM 
solutions to support existing network deployment with IPv6 (e.g. existing 
IPv6 address assignment), to be compatible with other mobility protocols, 
and to be interoperable with the network or the mobile hosts/routers that 
do not support the DMM enabling protocol, so that the existing network 
deployments and end hosts are not broken.

Does it make sense?

BR
Luowen

2012/06/08 07:13

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, jouni korhonen <[email-masked]>, Peter 
McCann <[email-masked]>
主题
RE: Re: [DMM] draft requirement REQ-4: compatibility

Luo, 
 
I think “existing network deployments which are not DMM enablded” are 
included in “existing network deployments. 
 
The end result is the compatibility with existing network deployment and 
end hosts. So whatever the dmm solution needs to do to ensure such 
compatibility. Do you agree?
 
H Anthony Chan

Hi Anthony: 

Hope this make sense. 

BR 
Luowen 

收件人

主题

REQ-4: compatibility

H Anthony Chan

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

REQ-4: compatibility 

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 03:43:00 +0000

Hi Anthony, Hi Charlie,

Regarding the operation between the trusted administrative domains, I think that the DMM solution SHOULD be able to work between trusted administrative domains, and not only "enable working" between such domains.

So the first sentence can become:
"The DMM solution SHOULD work between trusted administrative domains"

Regarding the  issues posted by Charlie:

>- I am confident that the DMM solution will require security.  Thus, the "SHOULD"

Do you mean that the following sentence:
"SHOULD allow inter-working with the security measures deployed between
   these domains."" should change to:

"MUST allow inter-working with the security measures deployed between
   these domains."" should change to:"?

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens h chan [[email-masked]]
Verzonden: vrijdag 8 juni 2012 2:07
Aan: Charles E. Perkins
CC: Peter McCann; [email-masked]
Onderwerp: Re: [DMM] draft requirement REQ-4: compatibility

How about the following:

H Anthony Chan

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Tuesday, June 05, 2012 5:56 PM
To: h chan
Cc: [email-masked]; Peter McCann; jouni korhonen
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Hello folks,

How about:

I have two more issues:

--
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 8 Jun 2012 04:20:20 +0000

Georgios,

I think "Should be able to work" is good. Whether it will actually work between any two particular inter-operator domains is left to the decision of the particular operators. 

Regarding DMM will require security, I have already rephrased REQ-6 to "shall consider security," which is probably general enough. 

So, my suggested text is the following:

REQ4:  Compatibility
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 backward compatibility with existing network deployment and end hosts.

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 07, 2012 10:43 PM
To: h chan; [email-masked]
Cc: Peter McCann; [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Hi Anthony, Hi Charlie,

Best regards,
Georgios

How about the following:

H Anthony Chan

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Tuesday, June 05, 2012 5:56 PM
To: h chan
Cc: [email-masked]; Peter McCann; jouni korhonen
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Hello folks,

How about:

I have two more issues:

--
Regards,
Charlie P.

---

From: h chan <[email-masked]>
Date: Fri, 8 Jun 2012 04:41:47 +0000

Luowen,

I understand that we earlier had a list of at least 3 requirements bundled inside this REQ-4. We are now adding a 4th and possibly 5th into this list regarding inter-domain. So I try to simplify 3 of them by examining the end result: whether existing network deployment and end hosts will break.

What the dmm solution needs to do will then depend on the environment in which it is deployed.

“Other mobility protocols” can only refer to the existing mobility protocols that are already deployed. It cannot refer to “future protocols” or “any protocol in the literature which has not been deployed in the same environment in which dmm is being deployed.

If you want to be more specific, I suggest to append an explanatory sentence to explain the requirement rather than adding more requirements to the list.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 07, 2012 8:21 PM
To: h chan
Cc: [email-masked]; [email-masked]; jouni korhonen; Peter McCann
Subject: 答复: RE: Re: [DMM] draft requirement REQ-4: compatibility

Hi Antony,

Yes, I agree, the DMM solution shall be compatibile with the exsiting network deployments. But only say "Existing network deployment and end hosts also SHOULD NOT break" or "the DMM solution SHOULD preserve backwards compatibility with existing network deployment and end hosts" may not be very specific.

how about

The DMM solution SHOULD enable working 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 that do not support the DMM enabling protocol.

And put those description such as  "The DMM solutions SHALL support existing network deployment with IPv6 (e.g. existing IPv6 address assignment), be compatible with other mobility protocols, and be interoperable with the network or the mobile hosts/routers that do not support the DMM enabling protocol so that the existing network deployments and end hosts are not broken." into the motivation, e.g

Motivation: The motivation of this requirement is to ensure the DMM solutions to support existing network deployment with IPv6 (e.g. existing IPv6 address assignment), to be compatible with other mobility protocols, and to be interoperable with the network or the mobile hosts/routers that do not support the DMM enabling protocol, so that the existing network deployments and end hosts are not broken.

Does it make sense?

BR
Luowen

2012/06/08 07:13

收件人

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, jouni korhonen <[email-masked]>, Peter McCann <[email-masked]>

主题

Luo,

H Anthony Chan

Hi Anthony:

Hope this make sense.

BR
Luowen

2012/06/06 01:26

收件人

抄送

主题

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

---

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

How about the following:

REQ4:  Compatibility

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.

Motivation: The motivation of this requirement is to allow inter-domain operation if desired and to preserve backwards compatibility so that the existing networks and hosts are not affected and do not break.

H Anthony Chan

From: h chan
Sent: Thursday, June 07, 2012 11:42 PM
To: [email-masked]'
Cc: [email-masked]; [email-masked]; jouni korhonen; Peter McCann
Subject: RE: RE: Re: [DMM] draft requirement REQ-4: compatibility

Luowen,

H Anthony Chan

Hi Antony,

how about

Does it make sense?

BR
Luowen

2012/06/08 07:13

收件人

抄送

主题

Luo,

H Anthony Chan

Hi Anthony:

Hope this make sense.

BR
Luowen

2012/06/06 01:26

收件人

抄送

主题

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

---

From: [email-masked]
Date: Thu, 7 Jun 2012 23:16:38 -0700

Dear Anthony and LuoWen, 

Sorry for jumping in late to this discussion.  If I have missed some prior 
discussion and repeat the same question, please forgive me. 

I agree with Anthony's view that, "“Other mobility protocols” can only 
refer to the existing mobility protocols that are already deployed. It 
cannot refer to “future protocols” or “any protocol in the literature 
which has not been deployed in the same environment in which dmm is being 
deployed.  "

However, when I refer to the current writing of the REQ#4:
REQ4:  Compatibility
 
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.
 
Motivation: The motivation of this requirement is to allow inter-domain 
operation if desired and to preserve backwards compatibility so that the 
existing networks and hosts are not affected and do not break.

First question to ask is that, why the backward compatibility with 
existing network deployment and end hosts is "optional", and not 
"mandatory"?  Wouldn't the compatibility with the existing deployment be 
the "fundamental" requirement?  Hence, the "SHOULD" needs to be changed to 
"SHALL".

Secondly, IMHO, compatibility has two aspects: 
(1) backward compatible with existing deployment that has been discussed 
above, but also
(2) no impact with the mobile host but still able to enable the DMM 
solution at the network

I don't believe that we are proposing the DMM solution requirement that 
must require the mobile node's support, correct? 

If we can agree on these two above fundamental sentiment, then, I would 
like to suggest a friendly amendment to REQ4 as follows:
REQ4:  Compatibility
 
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 SHALL preserve backwards 
compatibility with existing network deployment and end hosts.  For 
example, depending on the environment in which dmm is deployed, the dmm 
solutions SHALL BE compatible with other existing mobility protocols that 
are deployed in that environment or SHOULD BE interoperable with the 
network or the mobile hosts/routers that do not support the dmm enabling 
protocol. In addition, it SHOULD BE feasible to enable DMM network 
solution without the necessity to impact the existing mobile hosts. 
 
Motivation: The motivation of this requirement is to allow inter-domain 
operation if desired and to preserve backwards compatibility so that the 
existing networks and hosts are not affected and do not break.

Hoping that you can accept these changes.  Thanks in advance. 
Tricci 

h chan <[email-masked]> 
Sent by: [email-masked]
06/07/2012 09:41 PM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, Peter McCann <[email-masked]>
Subject
Re: [DMM] draft requirement REQ-4: compatibility

Luowen,
 
I understand that we earlier had a list of at least 3 requirements bundled 
inside this REQ-4. We are now adding a 4th and possibly 5th into this list 
regarding inter-domain. So I try to simplify 3 of them by examining the 
end result: whether existing network deployment and end hosts will break. 
 
What the dmm solution needs to do will then depend on the environment in 
which it is deployed. 
 
“Other mobility protocols” can only refer to the existing mobility 
protocols that are already deployed. It cannot refer to “future protocols
” or “any protocol in the literature which has not been deployed in the 
same environment in which dmm is being deployed. 
 
If you want to be more specific, I suggest to append an explanatory 
sentence to explain the requirement rather than adding more requirements 
to the list. 
 
H Anthony Chan

Hi Antony, 

how about 

Does it make sense? 

BR 
Luowen 

收件人

Luo, 

  
H Anthony Chan 

Hi Anthony: 

Hope this make sense. 

BR 
Luowen 

收件人

主题

REQ-4: compatibility

H Anthony Chan

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

REQ-4: compatibility 

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

--------------------------------------------------------
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, 8 Jun 2012 14:34:54 +0800

Hi Anthony:

     I agree with your statement, so I just suggest add those examples 
into the "Motivation" in my previous email.  But if you want to add those 
examples into the REQ-4, then I am OK with it. Thanks for your effort.

BR
Luowen

2012/06/08 13:06

收件人
h chan <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, jouni korhonen <[email-masked]>, Peter 
McCann <[email-masked]>
主题
RE: RE: Re: [DMM] draft requirement REQ-4: compatibility

How about the following:
 
REQ4:  Compatibility

 
H Anthony Chan
 
From: h chan 
 
Luowen,

 

H Anthony Chan

Hi Antony, 

how about 

Does it make sense? 

BR 
Luowen 

收件人

Luo, 

  
H Anthony Chan 

Hi Anthony: 

Hope this make sense. 

BR 
Luowen 

收件人

主题

REQ-4: compatibility

H Anthony Chan

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

REQ-4: compatibility 

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

---

From: [email-masked]
Date: Fri, 8 Jun 2012 14:48:58 +0800

Hi Tricci:

      Thank you for reminding us such an important aspect, the 
compatibility is a very important feature for the DMM of course. If the 
DMM supports the compatibility, it will help the DMM to be deployed in the 
real world. So ,basically, I agree the "SHOULD" should be change to 
"SHALL".

      Thanks for your suggestion.

BR
Luowen

[email-masked] 
2012/06/08 14:16

收件人
h chan <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [DMM] draft requirement REQ-4: compatibility

Dear Anthony and LuoWen, 

However, when I refer to the current writing of the REQ#4: 
REQ4:  Compatibility 

If we can agree on these two above fundamental sentiment, then, I would 
like to suggest a friendly amendment to REQ4 as follows: 
REQ4:  Compatibility 

To

Luowen, 

  

H Anthony Chan 

Hi Antony, 

how about 

Does it make sense? 

BR 
Luowen 

收件人

Luo, 

 
H Anthony Chan 

Hi Anthony: 

Hope this make sense. 

BR 
Luowen 

收件人

主题

REQ-4: compatibility

H Anthony Chan

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

REQ-4: compatibility 

H Anthony Chan

-----Original Message-----
From: Peter McCann 
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

--------------------------------------------------------
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: Peter McCann <[email-masked]>
Date: Fri, 8 Jun 2012 13:25:45 +0000

In my opinion, the DMM solution should reduce or eliminate the need for
centralized mobility management protocols.  So, I am not sure what it would
mean for DMM to be compatible with them.  It may be a substitute for them
in many cases.

Also, on the question of impact to the MN: I thought it was generally agreed
that we would allow for optimizations that take into account the fact that
some applications and mobile nodes do not need IP address transparency throughout
the lifetime of their packet data session.  I would hope that we can take advantage
of the presence of such mobile nodes, which might have special software in them
to deal with IP address transition issues.

-Pete

[email-masked] wrote:
> compatibility is a very important feature for the DMM of course. If 
> the DMM supports the compatibility, it will help the DMM to be 
> deployed in the real world. So ,basically, I agree the "SHOULD" should 
> be change to "SHALL".
> 
> 2012/06/08 14:16 收件人
> Sorry for jumping in late to this discussion.  If I have missed some 
> prior discussion and repeat the same question, please forgive me.
> 
> which has not been deployed in the same environment in which dmm is 
> being deployed.  "
> 
> 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 
> support the dmm enabling protocol.
> 
> Motivation: The motivation of this requirement is to allow 
> inter-domain operation if desired and to preserve backwards 
> compatibility so that the existing networks and hosts are not affected and do not break.
>>>>>> 
> 
> "mandatory"?  Wouldn't the compatibility with the existing deployment 
> be the "fundamental" requirement?  Hence, the "SHOULD" needs to be 
> changed to "SHALL".
> 
> (1) backward compatible with existing deployment that has been 
> discussed above, but also
> I don't believe that we are proposing the DMM solution requirement 
> that must require the mobile node's support, correct?
> 
> If we can agree on these two above fundamental sentiment, then, I 
> would like to suggest a friendly amendment to REQ4 as follows:
>>>>>> 
> REQ4:  Compatibility
> 
> example, depending on the environment in which dmm is deployed, the 
> dmm solutions SHALL BE compatible with other existing mobility 
> protocols that are deployed in that environment or SHOULD BE 
> support the dmm enabling protocol. In addition, it SHOULD BE feasible 
> to enable DMM network solution without the necessity to impact the 
> existing mobile hosts.
> 
> Motivation: The motivation of this requirement is to allow 
> inter-domain operation if desired and to preserve backwards 
> compatibility so that the existing networks and hosts are not affected and do not break.
>>>>>> 
> 
> Hoping that you can accept these changes.  Thanks in advance. Tricci
> 
> 
> 
> "[email-masked]" <[email-masked]> cc "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, Peter McCann <[email-masked]> Subject
> I understand that we earlier had a list of at least 3 requirements 
> bundled inside this REQ-4. We are now adding a 4th and possibly 5th 
> into this list regarding inter-domain. So I try to simplify 3 of them 
> by examining the end result: whether existing network deployment and 
> end hosts will break.
> 
> protocols that are already deployed. It cannot refer to “future 
> protocols” or “any protocol in the literature which has not been 
> deployed in the same environment in which dmm is being deployed.
> 
> sentence to explain the requirement rather than adding more 
> requirements to the list.
> 
> H Anthony Chan
> 
> From: [email-masked] [mailto:[email-masked] 
> <mailto:[email-masked]> ]
> compatibility with existing network deployment and end hosts that do 
> not support the DMM enabling protocol.
> 
> support the DMM enabling protocol so that the existing network 
> deployments and end hosts are not broken." into the motivation, e.g
> 
> solutions to support existing network deployment with IPv6 (e.g.
> existing IPv6 address assignment), to be compatible with other 
> mobility protocols, and to be interoperable with the network or the 
> mobile hosts/routers that do not support the DMM enabling protocol, so 
> that the existing network deployments and end hosts are not broken.
> 
> Does it make sense?
> 
> BR
> Luowen
> 
> 
> "[email-masked]" <[email-masked]>, "[email-masked]" <dmm- 
> [email-masked]>, jouni korhonen <[email-masked]>, Peter 
> The end result is the compatibility with existing network deployment 
> and end hosts. So whatever the dmm solution needs to do to ensure such 
> From: [email-masked] [mailto:[email-masked] 
> <mailto:[email-masked]> ]
> administrative domains is good to me, and the interworking with 
> existing network deployments which are not DMM enablded is also very 
> important. I believe we have already have consistency about this.  So, 
> how about mergering this two parts as following ?
> 
> ----------------------------------------------------------------------
> -
> ---------- The DMM solutions SHALL support existing network deployment 
> with IPv6 (e.g. existing IPv6 address assignment), be compatible with 
> other mobility protocols, and be interoperable with the network or the 
> that the existing network deployments and end hosts are not broken.
> Furthermore, the DMM solution MUST NOT break when being deployed 
> between trusted administrative domains and SHOULD allow inter-working 
> with the security measures deployed between these domains.
> ----------------------------------------------------------------------
> -
> ----------
> 
> Hope this make sense.
> 
> BR
> Luowen
> 
> administrative domains and SHOULD allow inter-working with the 
> security measures deployed between these domains. Existing network 
> deployment and end hosts also SHOULD NOT break.
> 
> H Anthony Chan
> 
> 
> From: [email-masked] [mailto:[email-masked] <mailto:dmm- 
> [email-masked]> ] On Behalf Of h chan
> REQ-4: compatibility The DMM solutions SHALL support existing network 
> deployment with IPv6 (e.g. existing IPv6 address assignment), be 
> compatible with other mobility protocols, and be interoperable with 
> the network or the mobile hosts/routers that do not support the DMM 
> enabling protocol so that the existing network deployments and end 
> hosts are not broken. REQ-4M (Motivation for REQ-4) Motivation: The 
> motivation of this requirement is not to break existing network deployments and end hosts.
> variants and extensions of MIP. When introducing new functions which 
> may add to the complicity, existing solutions are more vulnerable to break.
> 
> H Anthony Chan
> 
>>> REQ-4: compatibility The DMM solutions SHALL support existing 
>>> network deployment with IPv6 (e.g. existing IPv6 address 
>>> interoperable with the network or the mobile hosts/routers that do 
>>> not support the DMM enabling protocol so that the existing network 
>>> deployments are unaffected.
>>> 
>>> REQ-4M (Motivation for REQ-4) Motivation: The motivation of this 
>>> requirement is to be able to work with network architectures of both 
>>> hierarchical networks and flattened networks, so that the mobility 
>>> management protocol possesses enough flexibility to support 
>>> different networks, and so that the existing networks and hosts are 
>>> not affected and do not break.
>> 
>>> (The above has been drafted with contributions, inputs and 
>>> discussions from various people. Additional contributions and 
>>> comments are most
>>> welcome.)
>>> 
>>> H Anthony Chan
>>> 
>>> 
> <https://www.ietf.org/mailman/listinfo/dmm>
>> 
> <https://www.ietf.org/mailman/listinfo/dmm>
> 
> 
> 
> _______________________________________________ dmm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
> <https://www.ietf.org/mailman/listinfo/dmm>
> _______________________________________________ dmm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
> <https://www.ietf.org/mailman/listinfo/dmm>
> _______________________________________________ dmm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
> <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.
>

---

From: [email-masked]
Date: Fri, 8 Jun 2012 07:24:45 -0700

Dear Peter, 

For your first question regarding the term "compatible", IMHO, it implies: 

(a) the DMM support can be "co-existed" with existing network deployment 
with the centralized mobility management protocol. 

=====> I hope that you are NOT suggesting that, just because the DMM is 
deployed, the network must get rid of all centralized mobility management 
protocol, right? 

(b) the DMM support can interwork and interoperate with network that may 
or may not support DMM; likewise, the DMM support can interwork and 
interoperate with MN that may or may not support DMM

=====> More specifically for the latter part in (b) above related to the 
MN, it shall NOT be mandatory to require the MN to be DMM aware in order 
to enable the DMM support in the network.  Certainly, a given proposed 
solution is allowed to have the MN to be DMM aware.  However, from the 
generic requirement perspective, it SHALL NOT mandate that the UE must be 
DMM aware. 

I believe my latter description above answered your 2nd question also. 

Thanks.
Tricci 

Peter McCann <[email-masked]> 
06/08/2012 06:25 AM

To
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
RE: [DMM] 答复: Re:  draft requirement REQ-4: compatibility

In my opinion, the DMM solution should reduce or eliminate the need for
centralized mobility management protocols.  So, I am not sure what it 
would
mean for DMM to be compatible with them.  It may be a substitute for them
in many cases.

Also, on the question of impact to the MN: I thought it was generally 
agreed
that we would allow for optimizations that take into account the fact that
some applications and mobile nodes do not need IP address transparency 
throughout
the lifetime of their packet data session.  I would hope that we can take 
advantage
of the presence of such mobile nodes, which might have special software in 
them
to deal with IP address transition issues.

-Pete

---

From: Peter McCann <[email-masked]>
Date: Fri, 8 Jun 2012 14:43:48 +0000

Hi, Tricci,

I am fine with co-existence, it should be possible to run DMM in parallel
with an existing centralized solution.

However, when you say "interwork and interoperate" it makes me wonder if
we are requiring a DMM protocol to send and receive GTP-C.  I think that
would be a mistake.

On the question of supporting legacy MNs, I think we can do this in a couple
of different ways.  One is to detect that they are legacy and then hook them
up to the centralized mobility management scheme that is deployed in parallel
to DMM.  Another would be to connect them to the DMM-enabled part of the 
network and give them some degree of IP address transparency; however, if the
MN isn't capable of handling the acquisition and release of addresses during 
its packet data session it may not get the full transparency that it expects.
I want to make sure it is ok to spec out a DMM protocol that does not provide
full IP address transparency to these legacy MNs.

-Pete

[email-masked] wrote:
> (a) the DMM support can be "co-existed" with existing network
> deployment with the centralized mobility management protocol.
> 
> =====> I hope that you are NOT suggesting that, just because the DMM
> is deployed, the network must get rid of all centralized mobility
> management protocol, right?
> 
> (b) the DMM support can interwork and interoperate with network that
> may or may not support DMM; likewise, the DMM support can interwork
> and interoperate with MN that may or may not support DMM
> 
> =====> More specifically for the latter part in (b) above related to
> the MN, it shall NOT be mandatory to require the MN to be DMM aware in
> order to enable the DMM support in the network.  Certainly, a given
> proposed solution is allowed to have the MN to be DMM aware.  However,
> from the generic requirement perspective, it SHALL NOT mandate that
> the UE must be DMM aware.
> 
> 06/08/2012 06:25 AM To
> <[email-masked]> cc "[email-masked]" <[email-masked]> Subject
> In my opinion, the DMM solution should reduce or eliminate the need
> for centralized mobility management protocols.  So, I am not sure what
> it would mean for DMM to be compatible with them.  It may be a
> substitute for them in many cases.
> 
> agreed that we would allow for optimizations that take into account
> the fact that some applications and mobile nodes do not need IP
> address transparency throughout the lifetime of their packet data
> session.  I would hope that we can take advantage of the presence of
> such mobile nodes, which might have special software in them to deal
> with IP address transition issues.
> 
> -Pete
> 
>> DMM supports the compatibility, it will help the DMM to be deployed in
>> the real world. So ,basically, I agree the "SHOULD" should be change to
>> "SHALL".
>> 
>> solutions may need to be compatible with other existing mobility
>> "mandatory"?  Wouldn't the compatibility with the existing
>> deployment be the "fundamental" requirement?  Hence, the "SHOULD"
>> needs to be changed to "SHALL".
>> 
>> solutions SHALL BE compatible with other existing mobility protocols
>> that are deployed in that environment or SHOULD BE interoperable with
>> enabling protocol. In addition, it SHOULD BE feasible to enable DMM
>> network solution without the necessity to impact the existing mobile
>> hosts.
>> 
>> into this list regarding inter-domain. So I try to simplify 3 of
>> them by examining the end result: whether existing network
>> deployment and end hosts will break.
>> 
>> <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]> > ] Sent: Thursday, June 07, 2012 8:21 PM
>> To: h chan Cc: [email-masked]; [email-masked]; jouni korhonen;
>> Peter McCann Subject: 答复: RE: Re: [DMM] draft requirement REQ-4:
>> compatibility
>> 
>> 
>> Hi Antony,
>> 
>> The DMM solution SHOULD enable working 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 that do not support the DMM enabling protocol.
>> 
>> existing IPv6 address assignment), to be compatible with other mobility
>> protocols, and to be interoperable with the network or the mobile
>> hosts/routers that do not support the DMM enabling protocol, so that
>> the existing network deployments and end hosts are not broken.
>> 
>> Does it make sense?
>> 
>> BR
>> Luowen
>> 
>> 
>> I think “existing network deployments which are not DMM enablded”
>> are included in “existing network deployments.
>> 
>> <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]> > ] Sent: Wednesday, June 06, 2012 1:15 AM
>> To: h chan Cc: [email-masked]; [email-masked]; jouni korhonen;
>> Peter McCann Subject: 答复: Re: [DMM] draft requirement REQ-4:
>> compatibility
>> 
>> 
>> Hi Anthony:
>> 
>> -------------------------------------------------------------------- -
>> - - ---------- The DMM solutions SHALL support existing network
>> compatible with other mobility protocols, and be interoperable with the
>> network or the mobile hosts/routers that do not support the DMM
>> hosts are not broken. Furthermore, the DMM solution MUST NOT break when
>> being deployed between trusted administrative domains and SHOULD allow
>> inter-working with the security measures deployed between these
>> domains.
>> -------------------------------------------------------------------- -
>> - - ----------
>> 
>> Hope this make sense.
>> 
>> BR
>> Luowen
>> 
>> 收件人 "[email-masked]" <[email-masked]>, Peter McCann
>> <[email-masked]>, jouni korhonen <[email-masked]> 抄送
>> 主题 Re: [DMM] draft requirement REQ-4: compatibility
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked] <mailto:dmm- [email-masked]> 
>> <mailto:dmm- <mailto:dmm-> [email-masked]> ] On Behalf Of h chan
>> Sent: Wednesday, May 23, 2012 8:02 PM To: Peter McCann; jouni korhonen
>> Cc: [email-masked] Subject: Re: [DMM] draft requirement REQ-4:
>> compatibility
>> 
>> compatible with other mobility protocols, and be interoperable with the
>> network or the mobile hosts/routers that do not support the DMM
>> motivation of this requirement is not to break existing network
>> deployments and end hosts. OTHER related problem O-PS3: Complicated
>> deployment with too many variants and extensions of MIP Deployment is
>> complicated with many variants and extensions of MIP. When introducing
>> new functions which may add to the complicity, existing solutions are
>> more vulnerable to break.
>> 
>> H Anthony Chan
>> 
>>>> management protocol possesses enough flexibility to support different
>>>> networks, and so that the existing networks and hosts are not
>>>> affected and do not break.
>>> 
>>> deployments and end hosts" ? Either the network or the host may not
>>> have any idea of the solutions developed in DMM.
>> 
>>> MIP. When introducing new functions which may add to the
>>> complicity, existing solutions are more vulnerable to break.
>>>> 
>> <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
>> <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> >
>> 
>> 
>> 
>> -------------------------------------------------------- ZTE
>> Information Security Notice: The information contained in this mail
>> (and any attachment transmitted herewith) is privileged and
>> 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: Fri, 8 Jun 2012 15:11:41 +0000

I am answering the use of SHALL and SHOULD in a separate email thread on the requirements in general: DMM draft requirement discussions.

H Anthony Chan

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 08, 2012 1:17 AM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Dear Anthony and LuoWen,

Sorry for jumping in late to this discussion.  If I have missed some prior discussion and repeat the same question, please forgive me.

I agree with Anthony's view that, "“Other mobility protocols” can only refer to the existing mobility protocols that are already deployed. It cannot refer to “future protocols” or “any protocol in the literature which has not been deployed in the same environment in which dmm is being deployed.  "

However, when I refer to the current writing of the REQ#4:
REQ4:  Compatibility

First question to ask is that, why the backward compatibility with existing network deployment and end hosts is "optional", and not "mandatory"?  Wouldn't the compatibility with the existing deployment be the "fundamental" requirement?  Hence, the "SHOULD" needs to be changed to "SHALL".

Secondly, IMHO, compatibility has two aspects:
(1) backward compatible with existing deployment that has been discussed above, but also
(2) no impact with the mobile host but still able to enable the DMM solution at the network

I don't believe that we are proposing the DMM solution requirement that must require the mobile node's support, correct?

If we can agree on these two above fundamental sentiment, then, I would like to suggest a friendly amendment to REQ4 as follows:
REQ4:  Compatibility

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 SHALL preserve backwards compatibility with existing network deployment and end hosts.  For example, depending on the environment in which dmm is deployed, the dmm solutions SHALL BE compatible with other existing mobility protocols that are deployed in that environment or SHOULD BE interoperable with the network or the mobile hosts/routers that do not support the dmm enabling protocol. In addition, it SHOULD BE feasible to enable DMM network solution without the necessity to impact the existing mobile hosts.

06/07/2012 09:41 PM

To

cc

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Peter McCann <[email-masked]>

Subject

Luowen,

H Anthony Chan

Hi Antony,

how about

Does it make sense?

BR
Luowen

2012/06/08 07:13

收件人

抄送

主题

Luo,

H Anthony Chan

Hi Anthony:

Hope this make sense.

BR
Luowen

2012/06/06 01:26

收件人

抄送

主题

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

_______________________________________________
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: [email-masked]
Date: Fri, 8 Jun 2012 23:25:20 +0800

Dear Peter, 

Thank you for your prompt responses. 

I am confused where would the GTP-C come from in the context of interwork 
and interoperate?  DMM today discussion is in the context of IETF, and 
3GPP support both DSMIP and PMIP?  Hence, why would GTP-C consideration 
turn up? 

Regarding to your 2nd suggestions, I have two major concerns: 
(a) You seem to try to adjust the requirements based on implementation 
considerations, and I don't think that we should take this kind of 
approach to craft the requirement
(b) If your concern is regarding to the IP address transparency support, 
may I ask, why the consideration only apply to the network, but not to the 
MN? 

When you suggested that the MN isn't capable of handling the acquisition 
and release of address during its packet data session, you seem to assume 
certain IP address allocation scheme that must be used by the MN (e.g. 
IPv6 Local Prefix). 

As I mentioned in my previous email, I believe that the DMM generic 
requirement could allow the MN to be DMM aware; however, it SHALL NOT 
mandate that the MN must be DMM aware.   IMHO, this is not practical to 
support many legacy MN out there? 

What do you think?  Thanks
Tricci 

06/08/2012 07:43 AM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject
RE: [DMM] 答复: Re:  draft requirement REQ-4: compatibility

Hi, Tricci,

On the question of supporting legacy MNs, I think we can do this in a 
couple
of different ways.  One is to detect that they are legacy and then hook 
them
up to the centralized mobility management scheme that is deployed in 
parallel
to DMM.  Another would be to connect them to the DMM-enabled part of the 
network and give them some degree of IP address transparency; however, if 
the
MN isn't capable of handling the acquisition and release of addresses 
during 
its packet data session it may not get the full transparency that it 
expects.
I want to make sure it is ok to spec out a DMM protocol that does not 
provide
full IP address transparency to these legacy MNs.

-Pete

---

From: Peter McCann <[email-masked]>
Date: Fri, 8 Jun 2012 15:40:16 +0000

Hi, Tricci,

Please see inline.

[email-masked] wrote:
> I am confused where would the GTP-C come from in the context of
> interwork and interoperate?  DMM today discussion is in the context of
> IETF, and 3GPP support both DSMIP and PMIP?  Hence, why would GTP-C
> consideration turn up?

If we require interworking and interoperation, that seems to imply that
the DMM protocol must somehow be connected to the centralized mobility
management scheme.  One interpretation is to require the DMM elements
to speak the same tunnel set-up protocol used by the centralized mobility
management scheme, which as you say could be GTP-C, PMIP, or DSMIP depending
on the scenario.

I think it would be a mistake to require any such signaling from the 
DMM-enabled elements.

> approach to craft the requirement

If we require something that is un-implementable or that requires a very
complex implementation then we aren't doing a very good job specifying 
requirements.

> (b) If your concern is regarding to the IP address transparency
> support, may I ask, why the consideration only apply to the network,
> but not to the MN?

I'm not sure I understand your point (b).  Can you re-state it?
 
> When you suggested that the MN isn't capable of handling the
> acquisition and release of address during its packet data session, you
> seem to assume certain IP address allocation scheme that must be used
> by the MN (e.g. IPv6 Local Prefix).

No, I'm not assuming any particular scheme.  Whatever protocol is used
to allocate an address (DHCP, IPCP, SLAAC), some MNs might not be capable
of handling a change in the assigned address.  That was all I was trying
to say.

> mandate that the MN must be DMM aware.   

That's ok as long as we don't require the DMM solution to provide total
IP address transparency to any MN, whether DMM-aware or not.

> IMHO, this is not practical to

Couldn't quite parse this sentence.  What is the "this" in the above?

-Pete

> 06/08/2012 07:43 AM To "[email-masked]" <[email-masked]> cc
> Subject RE: [DMM] 答复: Re:  draft requirement REQ-4: compatibility
> 
> 
> 
> 
> 
> 
> Hi, Tricci,
> 
> I am fine with co-existence, it should be possible to run DMM in
> parallel with an existing centralized solution.
> 
> However, when you say "interwork and interoperate" it makes me wonder
> if we are requiring a DMM protocol to send and receive GTP-C.  I think
> that would be a mistake.
> 
> couple of different ways.  One is to detect that they are legacy and
> then hook them up to the centralized mobility management scheme that
> is deployed in parallel to DMM.  Another would be to connect them to
> the DMM-enabled part of the network and give them some degree of IP
> address transparency; however, if the MN isn't capable of handling the
> acquisition and release of addresses during its packet data session it
> may not get the full transparency that it expects.
> provide full IP address transparency to these legacy MNs.
> 
> -Pete
> 
> [email-masked] wrote:
>> Dear Peter,
>> 
>> from the generic requirement perspective, it SHALL NOT mandate that the
>> UE must be DMM aware.
>> 
>> would mean for DMM to be compatible with them.  It may be a substitute
>> for them in many cases.
>> 
>> Also, on the question of impact to the MN: I thought it was
>> generally agreed that we would allow for optimizations that take
>> into account the fact that some applications and mobile nodes do not
>> need IP address transparency throughout the lifetime of their packet
>> data session.  I would hope that we can take advantage of the
>> presence of such mobile nodes, which might have special software in
>> them to deal with IP address transition issues.
>> 
>> -Pete
>> 
>>> Sorry for jumping in late to this discussion.  If I have missed
>>> some prior discussion and repeat the same question, please forgive me.
>>> 
>>> <mailto:[email-masked]> > <mailto:[email-masked]
>>> <mailto:[email-masked]> > > ] Sent: Thursday, June 07, 2012 8:21
>>> PM To: h chan Cc: [email-masked]; [email-masked]; jouni korhonen;
>>> backwards compatibility with existing network deployment and end
>>> hosts" may not be very specific.
>>> 
>>> how about
>>> 
>>> deployed between these domains. Furthermore, the DMM solution
>>> SHOULD preserve backwards compatibility with existing network
>>> deployment and end hosts that do not support the DMM enabling protocol.
>>> 
>>> <mailto:[email-masked]> > <mailto:[email-masked]
>>> <mailto:[email-masked]> > > ] Sent: Wednesday, June 06, 2012 1:15
>>> AM To: h chan Cc: [email-masked]; [email-masked]; jouni korhonen;
>>> ------------------------------------------------------------------- -
>>> - - - ---------- The DMM solutions SHALL support existing network
>>> hosts are not broken. Furthermore, the DMM solution MUST NOT break
>>> when being deployed between trusted administrative domains and SHOULD
>>> allow inter-working with the security measures deployed between these
>>> domains.
>>> ------------------------------------------------------------------- -
>>> - - - ----------
>>> 
>>> Hope this make sense.
>>> 
>>> BR
>>> Luowen
>>> 
>>> [mailto:[email-masked] <mailto:[email-masked]>
>>> <mailto:dmm- <mailto:dmm->  [email-masked]> <mailto:dmm-
>>> <mailto:dmm->  <mailto:dmm- <mailto:dmm-> > [email-masked]> ] On
>>> Behalf Of h chan Sent: Wednesday, May 23, 2012 8:02 PM To: Peter
>>> McCann; jouni korhonen Cc: [email-masked] Subject: Re: [DMM] draft
>>> requirement REQ-4: compatibility
>>> 
>>>>> interoperable with the network or the mobile hosts/routers that
>>>>> do not support the DMM enabling protocol so that the existing
>>>>> network deployments are unaffected.
>>>>> 
>>>> deployments and end hosts" ? Either the network or the host may
>>>> not have any idea of the solutions developed in DMM.
>>> 
>>>>> variants and extensions of MIP Deployment is complicated with
>>>>> many variants and extensions of

---

From: [email-masked]
Date: Sat, 9 Jun 2012 00:10:10 +0800

Dear Peter, 

For your first comment, I sincerely believe that you mis-interpret of what 
I meant. Interworking and interoperable, IMHO, imply the DMM network 
solution SHALL NOT interfere the existing network's already deployed 
centralized mobility management scheme.  Do you agree? 

As of co-existence, IMHO, as it is written, implies that both solutions 
can be co-existed, however, it does not imply that the given solution does 
not need to make change in order to be co-existed with the other solution. 

Hence, the wording "compatible" applies to DMM is a perfect term because, 
IMHO, compatible means "both" co-existence and 
interworkable/interoperable.   Hoping that you can agree with this 
sentiment from me also. 

As for your 2nd comment, I believe that we already have the agreement, 
i.e. 

Hence, I prefer not to lead us into another lengthy discussions on this 
specific point. 

As for your last question, the "this" that I am referring to is the DMM 
solution.  IMHO, the DMM solution should not neglect the legacy MNs out 
there and NOT to provide them the DMM support just because that they are 
NOT DMM-aware.  Could we also agree on this one? 

Thank you for your time for discussing this subject with me. 
Tricci 

06/08/2012 08:40 AM

To

Hi, Tricci,

Please see inline.

management scheme, which as you say could be GTP-C, PMIP, or DSMIP 
depending
on the scenario.

 

-Pete

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 08 Jun 2012 12:10:21 -0700

Hello folks,

Why don't we use "MUST" and not "SHALL" when specifying mandatory features?

There are a lot of people who might interpret "SHALL" to mean "SHOULD", 
and I
don't see any reason to choose language that might be confusing.

Regards,
Charlie P.

On 6/8/2012 8:11 AM, h chan wrote:
>
> I am answering the use of SHALL and SHOULD in a separate email thread 
> on the requirements in general: DMM draft requirement discussions.
>
> H Anthony Chan
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Friday, June 08, 2012 1:17 AM
> *To:* h chan
> *Cc:* [email-masked]
> *Subject:* Re: [DMM] draft requirement REQ-4: compatibility
>
> Dear Anthony and LuoWen,
>
> I agree with Anthony's view that, ""Other mobility protocols" can only 
> cannot refer to "future protocols" or "any protocol in the literature 
> domains.  Furthermore, the DMM solution *_SHALL_*preserve backwards 
> dmm solutions *_SHALL BE_*compatible with other existing mobility 
> protocols that are deployed in that environment or *_SHOULD BE 
> _*interoperable with the network or the mobile hosts/routers that do 
> not support the dmm enabling protocol. *_In addition, it SHOULD BE 
> feasible to enable DMM network solution without the necessity to 
> impact the existing mobile hosts._*
>
> *h chan <[email-masked]>*
> "Other mobility protocols" can only refer to the existing mobility 
> protocols that are already deployed. It cannot refer to "future 
> protocols" or "any protocol in the literature which has not been 
> *From:[email-masked] [mailto:[email-masked]] *
> Sent:* Thursday, June 07, 2012 8:21 PM*
> To:* h chan*
> Cc:* [email-masked]; [email-masked]; jouni korhonen; Peter McCann*
> Subject:* ??: RE: Re: [DMM] draft requirement REQ-4: compatibility
>
>
> Hi Antony,
>
> *h chan <[email-masked]>*
>
> 2012/06/08 07:13
>
> 	
>
> ???
>
> 	
>
> ??
> ??
> I think "existing network deployments which are not DMM enablded" are 
> included in "existing network deployments.
>
> *
> From:[email-masked] [mailto:[email-masked]] *
> Sent:* Wednesday, June 06, 2012 1:15 AM*
> To:* h chan*
> Cc:* [email-masked]; [email-masked]; jouni korhonen; Peter McCann*
> Subject:* ??: Re: [DMM] draft requirement REQ-4: compatibility
>
>
> Hi Anthony:
>
> administrative domainsis good to me, and the interworking with 
> *h chan <[email-masked]>*
> ???:  [email-masked]
>
> 2012/06/06 01:26
>
> 	
>
> ???
>
> 	
>
> ??
> ??
> Motivation: The motivation of this requirement is not to break 
> existing network deployments and end hosts.
> OTHER related problem
> Deployment is complicated with many variants and extensions of MIP. 
> When introducing new functions which may add to the complicity, 

-- 
Regards,
Charlie P.

---

From: Peter McCann <[email-masked]>
Date: Fri, 8 Jun 2012 20:51:32 +0000

Hi, Tricci,

I think the words "interoperate" and "interwork" are stronger than
just "non-interference" or "co-existence" and the former imply some 
kind of protocol messages between DMM and centralized mobility management.
We should avoid words like "interoperate" and "interwork".  If we mean 
co-existence or non-interference we should say so.

I agree that DMM can be specified so as to support DMM-unaware MNs.
However, we should be clear that those DMM-unaware MNs may not get the
same service they were used to receiving with centralized mobility
management.

-Pete

[email-masked] wrote:
> Dear Peter,
> 
> For your first comment, I sincerely believe that you mis-interpret of
> what I meant. Interworking and interoperable, IMHO, imply the DMM
> network solution SHALL NOT interfere the existing network's already
> deployed centralized mobility management scheme.  Do you agree?
> 
> As of co-existence, IMHO, as it is written, implies that both
> solutions can be co-existed, however, it does not imply that the given
> solution does not need to make change in order to be co-existed with
> the other solution.
> 
> Hence, the wording "compatible" applies to DMM is a perfect term
> because, IMHO, compatible means "both" co-existence and
>> requirement could allow the MN to be DMM aware; however, it SHALL
>> NOT mandate that the MN must be DMM aware.
> 
> That's ok as long as we don't require the DMM solution to provide
> total IP address transparency to any MN, whether DMM-aware or not.
>>>>>> 
> Hence, I prefer not to lead us into another lengthy discussions on
> this specific point.
> 
> As for your last question, the "this" that I am referring to is the
> DMM solution.  IMHO, the DMM solution should not neglect the legacy
> MNs out there and NOT to provide them the DMM support just because
> that they are NOT DMM-aware.  Could we also agree on this one?
> 
> Thank you for your time for discussing this subject with me. Tricci
> 
> 
> 
> 
> 
> 06/08/2012 08:40 AM To
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]> Subject
> If we require interworking and interoperation, that seems to imply
> that the DMM protocol must somehow be connected to the centralized
> mobility management scheme.  One interpretation is to require the DMM
> elements to speak the same tunnel set-up protocol used by the
> centralized mobility management scheme, which as you say could be
> GTP-C, PMIP, or DSMIP depending on the scenario.
> 
>> Regarding to your 2nd suggestions, I have two major concerns: (a) You
>> seem to try to adjust the requirements based on implementation
> If we require something that is un-implementable or that requires a
> very complex implementation then we aren't doing a very good job
> specifying requirements.
> 
> to allocate an address (DHCP, IPCP, SLAAC), some MNs might not be
> capable of handling a change in the assigned address.  That was all I
> was trying to say.
> 
>> requirement could allow the MN to be DMM aware; however, it SHALL
>> NOT mandate that the MN must be DMM aware.
> 
> That's ok as long as we don't require the DMM solution to provide
> total IP address transparency to any MN, whether DMM-aware or not.
> 
>> "[email-masked]" <[email-masked]>, "[email-masked]"
>> <[email-masked]> Subject RE: [DMM] 答复: Re:  draft requirement
>> REQ-4: compatibility
>> 
>> 
>> 
>> 
>> 
>> 
>> Hi, Tricci,
>> 
>> then hook them up to the centralized mobility management scheme that is
>> deployed in parallel to DMM.  Another would be to connect them to the
>> DMM-enabled part of the network and give them some degree of IP address
>> transparency; however, if the MN isn't capable of handling the
>> may not get the full transparency that it expects. I want to make sure
>> it is ok to spec out a DMM protocol that does not provide full IP
>> address transparency to these legacy MNs.
>> 
>> -Pete
>> 
>> [email-masked] wrote:
>>> Dear Peter,
>>> 
>>> =====> I hope that you are NOT suggesting that, just because the
>>> DMM is deployed, the network must get rid of all centralized
>>> mobility management protocol, right?
>>> 
>>> (b) the DMM support can interwork and interoperate with network
>>> that may or may not support DMM; likewise, the DMM support can
>>> interwork and interoperate with MN that may or may not support DMM
>>> 
>>> into account the fact that some applications and mobile nodes do
>>> not need IP address transparency throughout the lifetime of their
>>> packet data session.  I would hope that we can take advantage of
>>> the presence of such mobile nodes, which might have special
>>> software in them to deal with IP address transition issues.
>>> 
>>> -Pete
>>> 
>>>> deployed in the real world. So ,basically, I agree the "SHOULD"
>>>> should be change to "SHALL".
>>>> 
>>>> I agree with Anthony's view that, "“Other mobility protocols” can
>>>> only refer to the existing mobility protocols that are already
>>>> deployed. It cannot refer to “future protocols” or “any protocol in
>>>> the literature which has not been deployed in the same environment in
>>>> which dmm is being deployed.  "
>>>> 
>>>> 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
>>>> 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.
>>>> 
>>>> 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 SHALL preserve
>>>> hosts.  For example, depending on the environment in which dmm is
>>>> deployed, the dmm solutions SHALL BE compatible with other existing
>>>> mobility protocols that are deployed in that environment or SHOULD BE
>>>> not support the dmm enabling protocol. In addition, it SHOULD BE
>>>> impact the existing mobile hosts.
>>>> 
>>>> h chan <[email-masked]> Sent by: [email-masked]
>>>> 
>>>> 06/07/2012 09:41 PM
>>>> 
>>>> To
>>>> bundled inside this REQ-4. We are now adding a 4th and possibly
>>>> 5th into this list regarding inter-domain. So I try to simplify 3
>>>> of them by examining the end result: whether existing network
>>>> If you want to be more specific, I suggest to append an
>>>> explanatory sentence to explain the requirement rather than adding
>>>> more requirements to the list.
>>>> 
>>>> H Anthony Chan
>>>> 
>>>> <mailto:[email-masked]> > > <mailto:[email-masked]
>>>> <mailto:[email-masked]> > > > ] Sent: Thursday, June 07, 2012
>>>> 8:21 PM To: h chan Cc: [email-masked]; [email-masked]; jouni
>>>> korhonen; Peter McCann Subject: 答复: RE: Re: [DMM] draft requirement
>>>> REQ-4: compatibility
>>>> 
>>>> 
>>>> Hi Antony,
>>>> 
>>>> network deployments. But only say "Existing network deployment and
>>>> end hosts also SHOULD NOT break" or "the DMM solution SHOULD preserve
>>>> mobile hosts/routers that do not support the DMM enabling protocol,
>>>> so that the existing network deployments and end hosts are not broken.
>>>> 
>>>> Does it make sense?
>>>> 
>>>> BR
>>>> Luowen
>>>> 
>>>> 
>>>> and end hosts. So whatever the dmm solution needs to do to ensure
>>>> such compatibility. Do you agree?
>>>> 
>>>> H Anthony Chan
>>>> 
>>>> <mailto:[email-masked]> > > <mailto:[email-masked]
>>>> <mailto:[email-masked]> > > > ] Sent: Wednesday, June 06, 2012
>>>> 1:15 AM To: h chan Cc: [email-masked]; [email-masked]; jouni
>>>> korhonen; Peter McCann Subject: 答复: Re: [DMM] draft requirement
>>>> REQ-4: compatibility
>>>> 
>>>> 
>>>> Hi Anthony:
>>>> 
>>>> ------------------------------------------------------------------ -
>>>> - - - - ---------- The DMM solutions SHALL support existing network
>>>> ------------------------------------------------------------------ -
>>>> - - - - ----------
>>>> 
>>>> Hope this make sense.
>>>> 
>>>> BR
>>>> Luowen
>>>> 
>>>> The DMM solution MUST NOT break when being deployed between
>>>> trusted administrative domains and SHOULD allow inter-working with
>>>> the security measures deployed between these domains. Existing
>>>> network deployment and end hosts also SHOULD NOT break.
>>>> 
>>>> H Anthony Chan
>>>> 
>>>> 
>>>> <mailto:[email-masked] <mailto:[email-masked]> >
>>>> <mailto:dmm- <mailto:dmm->  <mailto:dmm- <mailto:dmm-> >
>>>> [email-masked]> <mailto:dmm- <mailto:dmm-> <mailto:dmm-
>>>> <mailto:dmm-> >  <mailto:dmm- <mailto:dmm-> <mailto:dmm-
>>>> <mailto:dmm-> > > [email-masked]> ] On Behalf Of h chan Sent:
>>>> Wednesday, May 23, 2012 8:02 PM To: Peter McCann; jouni korhonen Cc:
>>>> [email-masked] Subject: Re: [DMM] draft requirement REQ-4: compatibility
>>>> 
>>>> complicated with many variants and extensions of MIP. When
>>>>>> requirement is to be able to work with network architectures of
>>>>>> both hierarchical networks and flattened networks, so that the
>>>>>> mobility management protocol possesses enough flexibility to
>>>>>> support different networks, and so that the existing networks and
>>>>>> hosts are not affected and do not break.
>>>>> 
>>>> I think that's a reasonable simplification.  We need a strategy
>>>> for backwards compatibility.
>>>> 
>>>> -Pete
>>>> 
>>>>> - JOuni
>>>>> 
>>>>>> 
>>>>>> OTHER related problem O-PS3: Complicated deployment with too
>>>>>> many variants and extensions of MIP Deployment is complicated
>>>>>> with many variants and extensions of

---

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

Clean up text:
   REQ4:  Compatibility

          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.

          Motivation: The motivation of this requirement is to allow
          inter-domain operation if desired and to preserve backwards
          compatibility so that the existing networks and hosts are not
          affected and do not break.

   This requirement addresses the following other related problem O-PS2.

   O-PS2:  Complicated deployment with too many variants and extensions
           of MIP Deployment is complicated with many variants and
           extensions of MIP.  When introducing new functions which may
           add to the complicity, existing solutions are more vulnerable
           to break.

H Anthony Chan

From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, June 08, 2012 3:10 PM
To: h chan
Cc: [email-masked]; [email-masked]
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Hello folks,

There are a lot of people who might interpret "SHALL" to mean "SHOULD", and I
don't see any reason to choose language that might be confusing.

Regards,
Charlie P.

H Anthony Chan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, June 08, 2012 1:17 AM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] draft requirement REQ-4: compatibility

Dear Anthony and LuoWen,

However, when I refer to the current writing of the REQ#4:
REQ4:  Compatibility

If we can agree on these two above fundamental sentiment, then, I would like to suggest a friendly amendment to REQ4 as follows:
REQ4:  Compatibility

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

06/07/2012 09:41 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]>, Peter McCann <[email-masked]><mailto:[email-masked]>

Subject

Luowen,

H Anthony Chan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, June 07, 2012 8:21 PM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; jouni korhonen; Peter McCann
Subject: 答复: RE: Re: [DMM] draft requirement REQ-4: compatibility

Hi Antony,

how about

Does it make sense?

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

2012/06/08 07:13

收件人

"[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]>, jouni korhonen <[email-masked]><mailto:[email-masked]>, Peter McCann <[email-masked]><mailto:[email-masked]>

主题

Luo,

H Anthony Chan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, June 06, 2012 1:15 AM
To: h chan
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-4: compatibility

Hi Anthony:

Hope this make sense.

BR
Luowen
h chan <[email-masked]><mailto:[email-masked]>
发件人:  [email-masked]<mailto:[email-masked]>

2012/06/06 01:26

收件人

"[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Peter McCann <[email-masked]><mailto:[email-masked]>, jouni korhonen <[email-masked]><mailto:[email-masked]>

抄送

主题

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] draft requirement REQ-4: compatibility

REQ-4: compatibility

H Anthony Chan

-----Original Message-----
From: Peter McCann
Sent: Friday, May 18, 2012 10:00 AM
To: jouni korhonen; h chan
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [DMM] draft requirement REQ-4: compatibility

Hi, Jouni,

-Pete

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

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm_______________________________________________
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.