Subject: [Mipshop] ICMPv6/Mobility options in draft-yokota-mipshop-pfmipv6-03.txt

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 13 Oct 2008 19:34:52 -0400

Yokota-san, Rajeev,

draft-yokota-mipshop-pfmipv6-03.txt currently does not have an IANA
considerations section. The options defined in section 5.5, 5.7 and 5.8,
I assume are new ICMPv6 options. The document should say so. 

For the MN-ID option, the draft says 

   MN ID     This identifier can be the link-layer address of the MN or
             any other type of information that can uniquely identify
             the MN.  If the link-layer address is used as the MN ID,
             the Link-Layer Address (LLA) option defined in [3] MUST be
             used.

If the MN ID is not a link layer address, but instead something like an
NAI, you might want to refer to RFC 5271 that defines an ICMPv6 option
for carrying the NAI information. See section 6.2 of RFC 5271.

What is the tunnel ID (section 5.4)? Is it the GRE key? Why don't we say
it explicitly?

Getting a vendor specific ICMPv6 option (section 5.8) might be hard. I
am not sure how receptive the IESG will be towards this. Is this option
absolutely required?

Section 6 does not which mobility options are used in the HI and HACK
messages. 

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

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 13 Oct 2008 19:55:50 -0400

Vijay,

The draft is being revised for submission as WG ID.
We will take the following (as well as the resolution of ICMP vs MH)
into consideration in the revision. 

Thanks,

-Rajeev

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Monday, October 13, 2008 4:35 PM
> To: Hidetoshi Yokota; Koodli, Rajeev
> Cc: [email-masked]; Basavaraj Patil
> Subject: ICMPv6/Mobility options in
draft-yokota-mipshop-pfmipv6-03.txt

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 14 Oct 2008 22:37:20 +0900

Hi Vijay,

As Rajeev suggested, rest assured that we will submit a more complete
version once everything is settled.

> I assume are new ICMPv6 options. The document should say so. 

Right. IANA considerations section will be added in the next version
(after MH vs. ICMPv6 issue is resolved :-)).

> for carrying the NAI information. See section 6.2 of RFC 5271.

I appreciate your insight. That is also my intention. If MH is adopted,
however, RFC4283 will be used instead...

> What is the tunnel ID (section 5.4)? Is it the GRE key? Why don't we say

A GRE key is one instance of the tunnel ID. That section was written
before GRE was adopted for identifying the tunnel. We will revise it.

> am not sure how receptive the IESG will be towards this. Is this option

As you know, RFC3115 is often used in 3GPP2. I don't say this is
absolutely required at this point, but I think this option will be
useful and wanted sooner or later.

> Section 6 does not which mobility options are used in the HI and HACK

I'm also aware that this section is not complete. Basically, any
mobility options defined so far can be used. We will clarify it in the
next version.

Regards,
-- 
Hidetoshi