Hi Jari, We are doing revision according to the comments we received. What do you suggest as our next step?
Thanks! Zhenkai On Mar 7, 2011, at 1:48 PM, Richard L. Barnes wrote: > 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
