Zhenkai, Thanks for following up. With regard to security/NATs: These could be relevant in your comparison, since I would think that different proposals would have different properties along these lines. For example, it seems like the degree of trust placed in the HA/rendezvous function varies quite a bit, as does the safety of the binding update mechanism (i.e., its ability to prevent an attacker from using spoofed updates to steal traffic).
--Richard On Mar 7, 2011, at 2:52 AM, Zhenkai Zhu wrote: > Thanks for the review. > We plan to briefly mention link layer and application layer mobility > approaches. However, security and how they deal with NAT and firewalls are > separate issues, as this document focuses on how the protocols handle the > mobility. > > For S5.3, we agree that it is "political" and we are willing to remove it. > > We'll also address other minor issues you mentioned. > > Thanks, > Zhenkai > > On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: > >> 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
