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.