Subject: Re: [Gen-art] Ge-ART LC review of draft-zhu-mobility-survey-

From: Zhenkai Zhu <[email-masked]>
Date: Sun, 6 Mar 2011 23:52:17 -0800

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.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 7 Mar 2011 15:22:49 -0500

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

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 7 Mar 2011 12:36:20 -0800

> 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.…

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 7 Mar 2011 16:48:51 -0500

That's fine, just thought it would be an interesting area to discuss.
--Richard

---

From: Zhenkai Zhu <[email-masked]>
Date: Mon, 7 Mar 2011 22:26:50 -0800

Hi Jari,

We are doing revision according to the comments we received. What do you suggest as our next step?

Thanks!
Zhenkai