Re: [Mobopts] Poll to publish draft-irtf-mobopts-mpa-framework-07

Hello folks,

I think the document needs at least one more
revision.  Below, please find my first installment
of editorial suggestions and clarifications.
Some are more important than others.

I'll try to finish this review within the
next day.  Please excuse the delay.

- "describes a framework of Media-independent Pre-
    Authentication (MPA), a new handover optimization mechanism"
   But, a framework is not a mechanism.  Maybe it would be
   better to just delete "a framework of".

- "some of the fast-handover scheme"
   --> "some of the fast-handover schemes"

- Cite RFC 2003 instead of RFC 1853.
   And, for IPv6 cite RFC 2473.

- "An access router is a router that is responsible for the other part
    of pre-configuration"
   == I don't have a good suggestion for improvement right now, but
      "access router" is well-established terminology for something
      that doesn't necessarily have the stated responsibility.

- Figure 2 looks wrong; Core network figure typo??
   = The diagram attempts to depict the range of communication
     for the MN but (a) it's mostly confusing and
     (b) many other documents successfully depict wireless
         connectivity without employing ASCII ellipses.

- Any interaction with HMIP?

- "maybe equipped with different"
   --> "may be equipped with a different"

- "scenarios in details"
   --> "scenarios in detail"

- "not limited to MIP type
    mobility protocol only and in addition, this scheme"
    --> "not limited to Mobile IP; this scheme"
    <unless it's desired to describe what "MIP type" means>
    <note the duplication of "in addition" in existing text>

- "develop an optimization framework"
   --> This document seems to describe a mechanism, not
       a framework.  But I agree that it's not a
       protocol specification either way.

- "without any underlying constraints or security related
    assumption."
    --> "without any underlying constraints or security related
         assumptions."
    But this is really debatable, if true at all.   There is
    a constraint of reachability, as a first example.
    Moreover, there is an assumption that security CAN be
    pre-established before arrival.  It would be easy to
    identify quite a few other assumptions and constraints.
    The text should be changed to identify at least one
    constraint and at least one assumption, without
    making such absolute claims.

- Relationship with HoKey?  I guess this shows up in
   more detail later in the document, but a little more
   description would be nice at the first reference.

- Section 5, first paragraph
   --- nevertheless even if prediction accuracy is 99%, it
       is still required that MPA is robust against failures
       when there are millions of mobile devices.

- "In other words, MPA is most"  (doesn't parse)
   --> "In other words, MPA is the most"  (unlikely claim)
   --> "In other words, MPA is more viable as a solution..."

- Use cases?
   = describe use with MIP
   = describe use with FMIP
   = describe use with HMIP
   = describe use with SIP Mobility
   (maybe this comes later)

- "Details of discovery mechanism"
   --> "Details about discovery mechanisms"

- "several policies"
   --> several factors

- "data packet loss should not occur except for the period during
    the switching procedure in Step 5, and it is the responsibility of
    link-layer handover to minimize packet loss during this period."
    = Buffering at the target access router can alleviate this problem.
      I think this is mentioned later, but it does mean that the
      quoted sentence needs revision.

- Step 2: the same considerations hold here
	which could indicate preconfiguration
	with several target networks

- Notice also that here MPA isn't quite compatible
	with the FMIP model, because when the MN
	initiates the configures nCoA it does
	not have a tunnel with NAR

- Step 4 (secure proactive handover pre-switching phase)
    "The buffering module at the next access router buffers the packets
     once the tunnel interface is deleted."
   Shouldn't NAR be buffering packets even if the tunnel is
   not explicitly deleted, until the mobile shows up at nCoA?

- Figure 4: "TIA" == ??  <tunnel interface accessability?>

- "provide an optimized handover"
   --> "provide optimized handovers"

- "rapid subnet and domain handover"
   --> "rapid movement between subnets and/or domains"

- "These issues include ..."
   This would work a lot better as an itemized list.

- "choosing the right network to connect"
   --> "connecting to the right network"

- "in details"
   --> "in detail"

- Section 7.1:
   "Discovery ... help"
   --> "Discovery ... helps"

- "during a mobile's rapid movement"
   But: it helps even if the movement is not rapid.

- "SLP"
   Sadly, SLP seems to be mostly irrelevant these days.
   But, if included, a citation should be indicated.

- "There is some proposal"
   --> "Some proposals"

- "When the mobile's movement is imminent, it starts"
   --> "When movement is imminent, the mobile node starts"

- "although a mobile decides"
   --> "although a mobile selects"

- "time-bound tunnels"  <interesting idea!>
   --> "transient tunnels"

- "that could incur"
   --> "that could occur"

- "the mobile is provisioning resources"
   --> "the mobile is reserving resources"

- "big problem.  However, it"
   --> "big problem; it"

- "The mobile uses pre-authentication"
   --> "The mobile uses a pre-authentication"

- "MN may hold some"
   --> "the MN may retain some"

- "Two solutions can take care of this problem."
   --> "There are two solutions to this problem."

- "The mobile can take advantage of the simultaneous mobility binding
    and send multiple binding updates to the corresponding host or HA.
    Thus, the corresponding host or HA forwards the traffic to multiple
    IP addresses assigned to the virtual interfaces for a specific period
    of time."
    ... Should this document really be recommending such signaling
        to correspondent nodes during handover?  Do you have citations
        for this?  I can see it for the home agent (maybe), but
        for CNs also?

- "wakikawa-mobileip-multiplecoa" --> expired...
   Is it still in progress after expiring 4 years ago?

- Section 7.3 should also include FMIP PrRtrAdv
   From RFC 5268:
    Through the RtSolPr and PrRtAdv messages, the MN also formulates a
    prospective new CoA (NCoA) when it is still present on the PAR's
    link.  Hence, the latency due to new prefix discovery subsequent to
    handover is eliminated.  <... continuing with more details ...>

- "Most commonly a mobile can configure itself statically"
   Is this really the most common case?  I find that surprising.

- "169.254.0.0/16"
   I don't think that Zeroconf addressing techniques help MPA
   at all -- at least I don't see how to make that work.

- "In a wide area networking environment, the mobile uses PPP"
   This is not true in all wide-area networks.

- "Each of these processes takes of the order of few hundred
    milliseconds to few seconds ..."
    --> "few" --> "a few"
    IPv6 stateless address autoconfiguration with optimistic
    DAD can be faster.

- "In the following paragraph we describe few ways"
   --> "In the following sections we describe a few ways"

More soon.

Regards,
Charlie P.

On 5/28/2010 4:04 PM, Rajeev Koodli wrote:
>
> Dear IRSG,
>
> This is a poll requesting your vote on the ID.
> The IRSG review by Juergen Schoenwaelder resulted in a major revision,
> followed by another editorial revision.
>
> The tracker URL: http://trac.tools.ietf.org/group/irtf/trac/ticket/27
>
> Please note that the ticket says “reopened doc review”. This was due to
> my error in submitting the changes incorrectly on the wiki. The document
> was not closed earlier on.
>
> Appreciate your prompt consideration of the vote (after the holiday
> weekend in the US).
>
> Regards,
>
> -Rajeev
>
>
>
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> http://www.irtf.org/mailman/listinfo/mobopts