That's fine, just thought it would be an interesting area to discuss. --Richard
On Mar 7, 2011, at 3:36 PM, Lixia Zhang wrote: > > On Mar 7, 2011, at 12:22 PM, Richard L. Barnes wrote: > >> 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 > > first, I agree that some of the solutions have different properties regarding > security/NAT handling. > > However note that the solution approaches span a very wide range, hence the > relevance degree of security/NAT also varies in a rather wide range (e.g. > consider those routing based solutions like Connexions or WINMO). > > The center issue of mobility support is resolving the location and identity > conflict, that every solution must address. > > We believe it makes a good tradeoff to laser focus on this center issue in a > single survey, to keep it within both a well defined focus and also > reasonable in size. > > Lixia > >> 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
