Re: AD Evaluation: draft-ietf-dmm-requirements

Anthony,
     I am fine with that.  I would like feedback from the rest of the WG
on these changes.

Brian

On 1/29/14 1:53 PM, h chan wrote:
> Delete those explanatory sentences then.
> 
>    REQ5:  Co-existence with deployed networks and hosts
> 
>           The DMM solution MUST be able to co-exist with existing
>           network deployments and end hosts.  
>           Furthermore, a DMM solution SHOULD work across different
>           networks, possibly operated as separate administrative
>           domains, when allowed by the trust relationship between them.
> 
> H Anthony Chan
> 
> 
> -----Original Message-----
> From: Brian Haberman [mailto:[email protected]] 
> Sent: Wednesday, January 29, 2014 8:01 AM
> To: h chan; [email protected]; [email protected]; Peter McCann
> Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
> 
> 
> 
> On 1/28/14 4:33 PM, h chan wrote:
>> Regarding the following:
>>
>> - What is meant by co-exist in REQ5?  Does this mean that a DMM solution does not break an existing one?  Or does it mean that it must inter-operate with existing ones?  Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network?  Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)?
>>
>>
>>
>> I think the bottom line is that the existing ones do not break.
>>
>>
>>
>> Original
>>
>>    REQ5:  Co-existence with deployed networks and hosts
>>
>>
>>
>>           The DMM solution MUST be able to co-exist with existing
>>
>>           network deployments and end hosts.  For example, depending 
>> on
>>
>>           the environment in which DMM is deployed, DMM solutions may
>>
>>           need to be compatible with other deployed mobility protocols
>>
>>           or may need to co-exist with a network or mobile 
>> hosts/routers
>>
>>           that do not support DMM protocols.  The mobile node may also
>>
>>           move between different access networks, where some of them 
>> may
>>
>>           support neither DMM nor another mobility protocol.
>>
>>           Furthermore, a DMM solution SHOULD work across different
>>
>>           networks, possibly operated as separate administrative
>>
>>           domains, when allowed by the trust relationship between them.
>>
>>
>>
>> We can change to:
>>
>>    REQ5:  Co-existence with deployed networks and hosts
>>
>>
>>
>>           The DMM solution MUST be able to co-exist with existing
>>
>>           network deployments and end hosts without breaking them.  
>> For example, depending on
>>
>>           the environment in which DMM is deployed, DMM solutions may
>>
>>           need to be compatible with other deployed mobility protocols
>>
>>           or may need to co-exist with a network or mobile 
>> hosts/routers
>>
>>           that do not support DMM protocols.  The mobile node may also
>>
>>           move between different access networks, where some of them 
>> may
>>
>>           support neither DMM nor another mobility protocol.
>>
>>           Furthermore, a DMM solution SHOULD work across different
>>
>>           networks, possibly operated as separate administrative
>>
>>           domains, when allowed by the trust relationship between them.
> 
> The "without breaking" is fine.  However, the "need to be compatible with" phrasing is still problematic.  Is that inferring that in some situations that a DMM solution would need to interact with, for example, PMIP?
> 
> Regards,
> Brian
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJS6luXAAoJEBOZRqCi7goqDEgIAKC96wls6qBXWzELz6Lk4uWj
VS2icnsAGELqnbImvN/Lfcvukz3peXY2J8X60664ZsOlp4d4WhdFYudiZ/Zf480e
lnimbTbqgP0agC9DtHE39gKnc+CGah2oWH6pyZr8D1HqsLa5QLCh4c9/BSTq1HgL
sPhL46AOfQvgpcg88H8oRlztUEuRGoqhQsHSKri+w+W0as65IMg//icvV7reS7uv
ScpHacpdCd1nMus76qiiEthZtHI2kVrtVPLFmIW2k+oFMkiLhhPv3tYsmemWrIc2
ZGeQ/mjnvJjLIsr04YEJWI0KUcwLHKxVurGICh0Q4Wz4N39Ptw5/D0jES5yisbI=
=3f37
-----END PGP SIGNATURE-----