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

Brian Haberman <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <[email protected]>
Hi Jouni,

On 1/30/14 7:40 PM, Jouni Korhonen wrote:
> 
> On Jan 29, 2014, at 6:01 AM, Brian Haberman <[email protected]> wrote:
> 
> [snip]
> 
>>> 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?
> 
> Your observation is correct. Maybe slightly better wording would work:
> 
>    REQ5:  Co-existence with deployed networks and hosts
> 
>          The DMM solution may require loose, tight or no integration into
>          existing mobility protocols and host IP stack. Independent of the
>          integration level, the DMM solution MUST be able to co-exist with
>          existing network deployments, end hosts and routers that may or
>          may not implement existing mobility protocols. Furthermore, a DMM
>          solution SHOULD work across different networks, possibly operated
>          as separate administrative domains, when allowed by the trust
>          relationship between them.

I am fine with this formulation.

Regards,
Brian

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
signature.asc (application/pgp-signature, 536 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJS66OGAAoJEBOZRqCi7goqVLQIAIHItJlLLhkPuab6mswZoL8H
GRmuN3hvskvHsthVGpkTkfdZuYuDbutX4U4t/IvApfYZ8I3ObgV8LQqKgvx86o8m
4JKToODXwFZtnoHC9FCIlFJmro4AuLdbUnrI5d+hdNPFpzAVnd5LBWhzlYFrf5/R
54XmV453yzmAlwdplLjaePv+h0MdUDeizmit/fa1pOGqS74wSEVrKkSdtCLOBRCg
qHy4evsfUIV7I0ME451lVbkW+Ujmt3aBJleyDiTHisPOy8Jy6FSLl3BLblYHfzmo
JNdwrjgqXmWPvjqiqpkXGSdxuWB1Zl03Yc0fS7v2k8wgdOqURhfDNYYzNhZT1Jw=
=eb5w
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.