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

From: Rajeev Koodli <[email-masked]>
Date: Fri, 18 Jun 2010 14:54:17 -0700

Dear IRSG,

I have not heard any responses on this Poll yet. Could you please respond by
June 30?

Please use one of the poll responses defined below.

The possible poll responses are:

    o  'Ready to publish' -- requires a thorough read and reasonably
        detailed review

    o  'Not ready to publish' -- requires a thorough read, reasonably
       detailed review, and actionable comments.

    o  'No objection' -- I don't object if this document goes forward;
       I've read the document (perhaps quickly); I have some small
       comments which are not show stoppers; I don't have great
       expertise in the area.

    o  'Request more time to review' -- a commitment to provide a
       thorough review in a specified period of time.

Document URL:  
http://tools.ietf.org/html/draft-irtf-mobopts-mpa-framework-07

Thanks,

-Rajeev
(Document Shepherd)

On 5/28/10 4:04 PM, "Rajeev Koodli" <[email-masked]> 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
> 
> 
> 
> _______________________________________________
> IRSG mailing list
> [email-masked]
> http://mailman.isi.edu/mailman/listinfo/irsg

---

From: "John R. Levine" <[email-masked]>
Date: 18 Jun 2010 22:38:23 -0400

I took a look at it.

>       comments which are not show stoppers; I don't have great

There's a few typos but nothing that the RFC editor can't fix.

I'd suggest mentioning in the abstract that you implemented this and 
report experimental performance results, which makes this document 
considerably more interesting than a pure paper design.

R's,
John, ASRG chair

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 Jun 2010 19:29:49 +0200

On Fri, Jun 18, 2010 at 11:54:17PM +0200, Rajeev Koodli wrote:
> 
> Dear IRSG,
> 
> I have not heard any responses on this Poll yet. Could you please respond by June 30?
> 
> Document URL:  http://tools.ietf.org/html/draft-irtf-mobopts-mpa-framework-07

I give it a 'Ready to publish' vote.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Aaron Falk <[email-masked]>
Date: Sun, 20 Jun 2010 16:48:22 -0400

IRSG-

As a reminder, documents require at least one 'Ready to Publish'
response to progress.

--aaron

On 6/18/10 5:54 PM, Rajeev Koodli wrote:
>     The IRSG review by Juergen Schoenwaelder resulted in a major
>     revision, followed by another editorial revision.
>
>     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
>
>
>     ------------------------------------------------------------------------

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Sun, 27 Jun 2010 21:05:22 -0400

Hi Aaron,

we have a Ready to Publish (from Juergen) and a No Objection (from John L).
So, I think we can move forward. However, I will wait until the June 30th, as mentioned in the Poll message below.
I will request authors to make any editorial revisions based on the input received until then (e.g., the feedback from John L to mention the experimental work in the Introduction).

Thanks,

-Rajeev

-----Original Message-----
From: Aaron Falk [mailto:[email-masked]]
Sent: Sun 6/20/2010 1:48 PM
To: [email-masked]
Cc: Koodli, Rajeev; [email-masked]
Subject: Re: [IRSG] Poll to publish draft-irtf-mobopts-mpa-framework-07
 
IRSG-

As a reminder, documents require at least one 'Ready to Publish' response to progress.

--aaron

	Dear IRSG,

	

	

	
	Thanks,
	
	-Rajeev
	(Document Shepherd)

		
		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.

		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

________________________________

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 Jun 2010 13:02:05 -0700

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:
> 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.
>
> Mobopts mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/mobopts

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 29 Jun 2010 22:42:35 -0400

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 SIP Mobility

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