I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zhu-mobility-survey-03 Reviewer: Richard Barnes Review Date: 2011-02-28 IETF LC End Date: 2011-03-09 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Its discussion of mobility technologies is thorough, but incorrect in some places, and could use some more context. Major issues: General: The document hypothesizes at a few points reasons why IP mobility techniques haven't caught on, without really looking at competitor technologies. In particular, it would be good to spend a little time talking about techniques for mobility at the link layer (such as the 3GPP GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) General: The document does not discuss security considerations at all. While I'm sure these considerations are discussed in individual documents, it could be helpful to pull up common high-level issues up to this document. General: There's not really any mention here of how these technologies interact NATs and firewalls, both of which could seriously limit their scope. S5.3: I found Section 5.3 duplicative of the previous section and mainly full of political, rather than technical content. Suggest removing. S6.2: TCP is not the only transport-layer protocol! In particular, in voice and video calls, the stuff that goes on for a long time is all UDP, and sessions are managed through a separate signaling protocol, which can be UDP or TCP. All of the discussion of session management (especially for VoIP) should take into account the mobility features that are already available at the application layer (e.g., SIP re-INVITEs), and discuss how these features interact with mobility at other layers. Minor issues: none S4.7: How does NEMO relate to normal use of the routing protocols to detach and reattach a network? A couple of sentences would be helpful here. S4.15: It's not really accurate to say that global HAHA avoids "triangle routing", since it actually does make a triangle. In Figure 6, there's a missing arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. So it's not that sufficient density avoids triangle routing, it just makes it less of a big deal because the HAs are close to the endpoints. S4.17 P1: I'm a little mystified as to how something is "published in the DNS, and only accessible to the subscriber". Quick clarification would be helpful. Nits/editorial comments: S2, "Locator": It could be helpful to note here that you're talking about *topological* location, not geolocation.s S4.8 P1: The phrase "universally deployed" is used a couple of times in this paragraph; it inspires unnecessary pessimism in the reader :) You might want to re-scope to say that mobility is naturally supported in domains where multicast is enabled. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
