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

That works for me.

Brian

On 1/28/14 4:58 PM, h chan wrote:
> Regarding the following:
> 
> - Should PS7 mention mobility solutions that operated at other layers of the protocol stack?
> 
> 
> 
> Original
> 
>    PS7:  Deployment with multiple mobility solutions
> 
> 
> 
>          There are already many variants and extensions of MIP.
> 
>          Deployment of new mobility management solutions can be
> 
>          challenging, and debugging difficult, when they co-exist with
> 
>          solutions already deployed in the field.
> 
> 
> 
> We can change to
> 
> 
> 
>    PS7:  Deployment with multiple mobility solutions
> 
> 
> 
>          There are already many variants and extensions of MIP
> 
>          as well mobility solutions at other layers.
> 
>          Deployment of new mobility management solutions can be
> 
>          challenging, and debugging difficult, when they co-exist with
> 
>          solutions already deployed in the field.
> 
> 
> 
> H Anthony Chan
> 
> 
> 
> 
> 
> -----Original Message-----
> From: dmm [mailto:[email protected]] On Behalf Of Brian Haberman
> Sent: Friday, January 24, 2014 11:30 AM
> To: [email protected]; [email protected]; Peter McCann
> Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements
> 
> 
> 
> All,
> 
>      I have performed my AD review, as a part of the publication process, of draft-ietf-dmm-requirements.  The following issues should be addressed prior to moving this draft to IETF Last Call.  Please let me know if you have any questions on these points.
> 
> 
> 
> 1. I would suggest making sure that the Abstract and Introduction explicitly state that these requirements for for network (L3)-layer mobility management.
> 
> 
> 
> 2. Introduction:
> 
> 
> 
> - The EPC acronym needs to be expanded.
> 
> - Do not reference the DMM charter within the document.
> 
> - expand HA and LMA since you are using them before the Terminology section.
> 
> 
> 
> 3. Section 3:
> 
> 
> 
> - It would be nice to ensure that all acronyms used in the figures are expanded somewhere prior to the figures.
> 
> 
> 
> - I am curious as to why there is not any mention in this section about route optimization within the mobility protocols.  This mention should describe why current route optimization is host-based in order to lead into PS1.
> 
> 
> 
> 4. Section 4:
> 
> 
> 
> - To be abundantly clear, I would re-word the start of PS3 to be "Lack of scalability".
> 
> 
> 
> - I am not sure that it benefits the document to label PS6 and PS7 as related.  Those issues are problematic on their own.  If you remove the "(related problem)" label from them, make sure that REQ2 is updated to remove mention of "related problem".
> 
> 
> 
> - Should PS7 mention mobility solutions that operated at other layers of the protocol stack?
> 
> 
> 
> 5. Section 5:
> 
> 
> 
> - Why does this section have sub-section numbers AND REQ numbers?
> 
> 
> 
> - I am not sure I understand what REQ1 is saying when it talks about combining mobility anchors with CDNs.  It *sounds* like mobility management needs to be maintained by CDN providers.
> 
> 
> 
> - I am a little confused by REQ2.  It says that a DMM solution should be transparent to the applications.  However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer.  That doesn't sound transparent to me.  Am I reading this incorrectly?
> 
> 
> 
> - I am wondering if the SHOULD in REQ4 ought to be a MUST.  Why would anyone work on a new protocol without first determining the feasibility of the existing ones?
> 
> 
> 
> - 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 REQ6 is incomplete.  A DMM solution can introduce new vulnerabilities, but it needs to provide ways to cope with those vulnerabilities.
> 
> 
> 
> 6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft.  A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic.
> 
> 
> 
> 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

iQEcBAEBCgAGBQJS6QnMAAoJEBOZRqCi7goqyf4H/A4kC3hB8Yj5zKgj94xeNcf6
gT2tolmL8kUgKhgf8fk6a61AB5I4MFLDtySEC2vULaFVwDLfOxtPk/3tFWOzfwa5
7sMymdnjeJ4FLRXpWbP+y4C3KYkWk5jId8PbeShJak5IRBHpx2TFvn69G71IzJOE
BD9bM8AaHTqDsaczw0hUcAiu5VYue/I5ylO7kjXX98GJyuSxa492Biu53TSp0Urq
Hva0tS+lM1AiTt9dZs1dqQ9mvaMPkDAh5UX4eUhBnp3ExNP4fzsfJkZt1KEj6w6N
uJhQN7ICXPvHVj3NYuGJuHumQRr4Uy+4BkSTaxGFneBA8SIuBPxpDyo25sTpgxs=
=+/95
-----END PGP SIGNATURE-----