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

Charles,
         Thank you very much for your detailed and thoughtful review 
comments. We will incorporate these into the next version of the draft 
along with the comments from others.

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

With respect to your comments on the use cases above, we had some these 
use cases listed in version 5 of the draft. However, based on the review 
comments on version 5 of the draft, we were advised to take those uses 
cases out to reduce the size of the draft. Instead we were advised to 
put these uses cases in a separate document or refer to any paper that 
describes these use cases.

Look forward to your next set of reviews on the draft.

Regards
Ashutosh Dutta
Editor of the draft

On 6/29/2010 4:02 PM, Charles E. Perkins wrote:
>
> 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
>
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> http://www.irtf.org/mailman/listinfo/mobopts