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:dmm-boun...@ietf.org] On Behalf Of Brian Haberman > Sent: Friday, January 24, 2014 11:30 AM > To: draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; 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 > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
