Subject: [Mip4] FMIPv4

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 19 Jan 2007 14:28:37 -0500

In San Diego at IETF 67 we saw a presentation of the 
changes in draft-ietf-mip4-fmipv4-02.txt.  However,
we have not had any list discussion on whether the
changes were adequate.

Can I ask all those who made comments to review the
current draft, available at:

http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-02.txt

If there are no further issues I will send the draft
up for publication next week.

-Pete

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Jan 2007 18:50:03 +0100

McCann Peter-A001034 wrote:
> In San Diego at IETF 67 we saw a presentation of the changes in 
> draft-ietf-mip4-fmipv4-02.txt.  However, we have not had any list 
> discussion on whether the changes were adequate.
> 
> Can I ask all those who made comments to review the current draft, 
> available at:
> 

REviewing it...

BAsically I'm fine with it, here's a few minor editorial.

> Optimizations have been proposed and are being standardized in IEEE 
> however.

... for example IEEE 802.11r (Fast Roaming, Fast BSS Transition) and to
a certain extent 802.21; probably worth mentioning.

> The design of the protocol is the same as for Mobile IPv6 [2]. 
> Readers should consult [2] for details, and here we provide a 
> summary.
[...]
> [2] R. Koodli (Editor).  Fast Handovers for Mobile IPv6 (work in 
> progress).  Internet Draft, Internet Engineering Task Force. 
> draft-ietf-mipshop-fast-mipv6-03.txt, October 2005.

Editing nit.  The draft referred as [2] no longer exists I believe.  I
think there may be plans in the mipshop WG to take RFC4068 on a Stds
Track.  So maybe RFC4068 and RFC3775 should be referred for the moment,
or any other update more up to date.  This '[2]' is cited several times
in the draft.

> 5.3. Router Solicitation for Proxy Advertisement (RtSolPr)

Is this an RS carried as ICMP (RFC1256) or as ICMPv6.  Encoding is 
different.  Remark that existing implementations of ICMPv4 RS could be 
re-used for minimal modifications, or otherwise ICMPv6 could be re-used. 
  It's a choice.  But in a FMIPv4 deployment one wouldn't assume 
availability of ICMPv6... or maybe yes (?).  Also it's strange to use 
Checksum field as computed from rfc1256 but the format from ICMPv6.

Same for Proxy Router Advertisement.

Alex

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 14:05:45 -0600

Hi Alex,

thank you for your review.
 
>... for example IEEE 802.11r (Fast Roaming, Fast BSS 
>Transition) and to a certain extent 802.21; probably worth mentioning.
>

Ok.

>> Readers should consult [2] for details, and here we provide 
>a summary.
>[...]
>Editing nit.  The draft referred as [2] no longer exists I 
>believe.  I think there may be plans in the mipshop WG to take 
>RFC4068 on a Stds Track.  So maybe RFC4068 and RFC3775 should 
>be referred for the moment, or any other update more up to 
>date.  This '[2]' is cited several times in the draft.
>

That should be RFC 4068. Thanks for catching it!

>Is this an RS carried as ICMP (RFC1256) or as ICMPv6.  
>Encoding is different.  Remark that existing implementations 
>of ICMPv4 RS could be re-used for minimal modifications, or 
>otherwise ICMPv6 could be re-used. 
>  It's a choice.  But in a FMIPv4 deployment one wouldn't 
>assume availability of ICMPv6... or maybe yes (?).  Also it's 
>strange to use Checksum field as computed from rfc1256 but the 
>format from ICMPv6.
>

It _should_ be ICMPv4, with the allowance for ICMPv6 I guess. 
Will revise.

Regards,

-Rajeev