4. Section 4: - 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".
The intention of the name "related problems" was not to suggest they are less problematic, but rather to distinguish them from the other problems directly on mobility management. Although these problems are not directly on mobility management, the DMM solutions can solve these additional problems. They are therefore included. So, as long as this section is not to be interpreted as limited to problems directly on mobility management, we can drop the word "related." 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
