Subject: [Mipshop] WG Last Call on draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 08 Jul 2007 15:17:22 -0700

Hello,

This is a two week working group last call for
draft-ietf-mipshop-fmipv6-rfc4068bis. You can find the
document at the following URL.

http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt

The last call expires on July 23 2007.

Please post any issues or comments on this document to
the MIPSHOP WG mailing list. In case you have reviewed
the document and found no issues, please send an email
saying you support advancing this document.

The intended status for this document is Standards Track.

This document has normative dependency on
draft-ietf-mipshop-handover-key-00.txt. We plan to send
the two documents together when sending them to the IESG
for publication. draft-ietf-mipshop-handover-key however
has an open issue which we will try to resolve in the
next few weeks. Meanwhile lets complete the WG last call
on the FMIPv6 specification.

Vijay

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Frank Xia <[email-masked]>
Date: Mon, 09 Jul 2007 10:53:00 -0500

Hi  Vijay

It looks good  that a  "Prefix Management " section is added in the new version.

In this section, the solution is similar to the solution 2 of  the draft 
http://tools.ietf.org/wg/mipshop/draft-xia-mipshop-fmip-ptp-01.txt.

In our draft,  three solutions are proposed, and solution 2 is not the best one.

BR
Frank

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 11 Jul 2007 11:59:06 -0700

Hi Vijay,
This is not sufficient time given that it is right before the IETF.  I'd
appreciate if the deadline is extended to end at the end of the week
after the IETF.  

Thanks,
Vidya 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Sunday, July 08, 2007 3:17 PM
> To: [email-masked]
> Subject: [Mipshop] WG Last Call 
> ondraft-ietf-mipshop-fmipv6-rfc4068bis-02.txt
> 
> Hello,
> 
> Please post any issues or comments on this document to the 
> MIPSHOP WG mailing list. In case you have reviewed the 
> document and found no issues, please send an email saying you 
> support advancing this document.
> 
> draft-ietf-mipshop-handover-key-00.txt. We plan to send the 
> two documents together when sending them to the IESG for 
> publication. draft-ietf-mipshop-handover-key however has an 
> open issue which we will try to resolve in the next few 
> weeks. Meanwhile lets complete the WG last call on the FMIPv6 
> specification.
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 20 Jul 2007 15:12:14 -0700

Folks,

The WG last call is expiring on the 23rd. Please review and send your 
comments to the mailing list.

Vijay

---

From: Ashutosh Dutta <[email-masked]>
Date: Sat, 21 Jul 2007 23:06:34 -0400

Rajeev,
        I assume the statement below from rfc4068bis-02 (1st paragraph, 
page 11) applies to reactive handover only?

Thanks
Ashutosh

" When further protocol action is necessary, some implementations may
choose to provide buffering support at PAR to address the scenario
in which a MN leaves without sending an FBU message from the PAR's
link.   While the protocol does not forbid such an implementation
support, care must be taken to ensure that the PAR continues
forwaring packets to the PCoA (i.e., uses a buffer and forward
approach).   The PAR should also stop buffering once it processes
the FBU message."

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Jul 2007 08:12:53 -0700

Yes, the particular scenario where buffering at PAR is useful appears to be
reactive handovers.

Regards,

-Rajeev

-- 
http://people.nokia.net/~rajeev

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 24 Jul 2007 11:23:42 -0400

Hi Vijay,
   I believe that this document is ready to go forward.

Cheers
Suresh

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 24 Jul 2007 16:57:35 -0400

Rajeev, thanks for the clarification.

Unlike proactive handover, I guess the typical mechanism regarding how 
to buffer the packets in PAR in case of reactive handover is probably 
beyond the scope of FMIPv6. However, in some cases, buffering maybe 
useful to reactive handover scenario as well to prevent the packet loss. 
Thus, it is good to see that this following paragraph covers this 
possible scenario and leaves out the possible details of buffering to 
specific implementation method.

Regards
Ashutosh