Dear Juan Carlos, Carlos, Telemaco, All, I went over draft-zuniga-dmm-gap-analysis-01 and, although I understand that this draft is a reasonable first shot, at times it reads as if it was written very hastily. Overall, much work lies ahead. Please find below my comments and suggestions after a cursory review.
Section 1: Intro ---------------- There is no need to repeat what's in the reqs ID nearly in verbatim. Besides the fact that most interested readers would be familiar with this already, you may end up with synchronization and consistency issues, which need to be taken care of on a continuous basis till -reqs becomes an RFC. Even so, I propose to rewrite the intro so that it matches the scope and target of this document, and remove the repetition of the reqs text. Section 2: "Practices" ---------------------- The term "DMM environment" is not actually defined; ditto the term "DMM mode of operation". If you refer to dynamically, on-demand change of the anchor point, then it's better to say so explicitly. If, on the other hand, this latter term refers to core offload (as in "thus providing some form of distribution, since the traffic is locally route[d]"), alternative paths, etc. then it's better to say so as well, in the respective paragraphs. With respect to Figures 1-4, I like that you tried to visually display various solutions. Unfortunately, they mostly fail to convey the inherent differences. Moreover, the text does not take advantage of these figures whatsoever after they are introduced. Further, I am not sure what exactly does the cloud-like container for the (different) HA (flavors) and LMA is supposed to tell me. In short, I would consider improving the figures significantly as they can be powerful in clearly showing what are the "gaps" we're after. But left as-is, they provide little value; we're better off, for instance, with a ref to RFC 6301. Fig. 2 could be merged with Fig. 1, as it adds little further info. Somewhere midway in section 2.2.x, the text gets a bit rough. I hope the next version will take care of this. Then, somehow the text starts talking about possible solutions while still in the "Practices" part (for example the recurring references to an inter-LMA mobility protocol). I'm also a bit puzzled about the sudden appearance of 3GPP stuff in section 2.2.2 onwards. Forget about how it actually comes together as smooth text (it does not). I'm more interested in how it provides a coherent line of argumentation in each 2.x subsection and how this relates to the gap analysis in section 3. Also, there is a bit of mix-and-match going on, e.g. section 2.2.5: how's multihoming related with the previous stuff? Section 3: "Gap analysis" ------------------------- >From section 3.1.2 onwards, the text is, at times, just rough/copy-paste >notes. This is particularly the case for 3.1.3-6 and 3.2.3-6. The format >adopted for section 3 is also more like a sketch of a gap analysis. Overall comments ---------------- The document is over-structured and does not lead to new insights esp. in section 3. A conclusions section that pulls everything together is clearly missing. Finally, in the references section, I'm not sure why certain RFCs are considered "normative" for this draft, esp. since no requirements language is specified (there's no ref to RFC 2119 for that matter). A ref that perhaps should be included is RFC 6301. Ditto, refs for DIDA, OPIIS, and MAPCON are missing. Are all listed refs actually used? A couple of nits and editorial suggestions follow: --- s/the MN two different temporal/the MN has two different temporary s/used the RCoA/uses the RCoA s/locally router at/locally routed at s/a point of view of routing/the routing point of view s/considered as a mean to/considered as means to s/provides a better/provides for better s/anchored and a/anchored at a s/[REF to flow mob draft]/ <actual reference> s/signaling overhead/signaling overhead s/only performed/only be performed s/This approach include/This approach includes/g Define acronyms on first appearance. Not all readers are familiar with them. ---- Best Regards, Kostas _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
