Subject: [Mipshop] [Fwd: Re: [IANA #145901] Last Call: draft-ietf-mipshop-3gfh (Mobile IPv6 Fast Handovers for 3G CDMA Networks) to Informational RFC]

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 11 Mar 2008 11:06:27 -0700

FYI

Subject: Re: [IANA #145901] Last Call: draft-ietf-mipshop-3gfh (Mobile IPv6 Fast Handovers for 3G CDMA Networks) to Informational RFC
From: Vijay Devarapalli <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 11 Mar 2008 11:06:01 -0700

Amanda Baber via RT wrote:
> IESG:
> 
> The IANA has reviewed draft-ietf-mipshop-3gfh-05.txt, which is 
> currently in Last Call, and has the following comments regarding 
> its publication:
> 
> Please confirm that the following actions are correct:
> 
> Action #1:
> Upon approval of this document, the IANA will make the following 
> assignments in the "ICMPv6 TYPE NUMBERS" registry located at
> http://www.iana.org/assignments/icmpv6-parameters
> Registry: "IPv6 Neighbor Discovery Option Formats"
> 
> Type   Description                         Reference
> -----  ----------------------------        ---------
> TBD1   Handover Assist Information Option  [RFC-ietf-mipshop-3gfh-05.txt]
> TBD2   Mobile Node ID Option               [RFC-ietf-mipshop-3gfh-05.txt]

This looks good.

> Action #2:
> 
> Upon approval of this document, the IANA will create the following
> sub-registry in the "ICMPv6 TYPE NUMBERS" registry located at
> http://www.iana.org/assignments/icmpv6-parameters
> 
> Sub-registry name: Handover Assist Information Option codes
> Reference: [RFC-ietf-mipshop-3gfh-05.txt]
> Registration Procedures: IETF Review or IESG Consensus
> 
> Value  Description               Reference
> -----  ------------------------  ---------
> 1      ANID                      [RFC-ietf-mipshop-3gfh-05.txt]                
>              
> 2      Sector ID                 [RFC-ietf-mipshop-3gfh-05.txt]

This is correct.

> QUESTION: Is there an upper limit on values that can be assigned 
> (e.g., 255)? Should "0" be marked reserved?

Value '0' should be reserved. 255 is the upper limit.

> Action #3:
> 
> Upon approval of this document, the IANA will create the following
> sub-registry in the "ICMPv6 TYPE NUMBERS" registry located at
> http://www.iana.org/assignments/icmpv6-parameters
> 
> Sub-registry name: MN ID Option codes
> Reference: [RFC-ietf-mipshop-3gfh-05.txt]
> Registration Procedures: IETF Review or IESG Consensus
> 
> Value  Description                                             Reference
> -----  -----------------------------------------------------   ---------
> 1      IMSI ("Mobile Node Identifier Option Subtype" [RFC4283]) 
> [RFC-ietf-mipshop-3gfh-05.txt]                              

This one need some more discussion. I think it is the IANA
considerations section on the draft that is not clear. Apologize
for not catching this earlier. I think the authors' intention
was to re-use the following registry at
http://www.iana.org/assignments/mobility-parameters

Registry Name: Mobile Node Identifer Option Subtypes
Reference: [RFC4283]
Registration Procedures: Standards Action

Registry:
Value  Description                                Reference
-----  -----------------------------------------  ---------
1      NAI                                        [RFC4283]

The value '2' would be the IMSI.

But then I am not sure if it makes sense to use the same registry
for two different options, one is a mobility option defined in
RFC 4283 and the other is an ICMPv6 option defined in
draft-ietf-mipshop-3gfh. Should be go with a separate registry?

> QUESTION: Does section 6.3 require any registrations? If so, 
> which registry is it referring to?

Currently there is no registry for flags in the Binding Update/
Binding Ack messages. We are debating whether we need to create
a new registry as part of IANA assignment for
draft-ietf-netlmm-proxymip6.

Thanks
Vijay

> 
> Thank you.
> 
> Amanda Baber
> (on behalf of IANA)
> 
> 
> 
>> The IESG has received a request from the Mobility for IP: Performance,
>> Signaling and Handoff Optimization WG (mipshop) to consider the
>> following
>> document:
>>
>> - 'Mobile IPv6 Fast Handovers for 3G CDMA Networks '
>>    <draft-ietf-mipshop-3gfh-05.txt> as an Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to
>> the
>> [email-masked] mailing lists by 2008-03-15. Exceptionally,
>> comments may be sent to [email-masked] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-05.txt
>>
>>
>> IESG discussion can be tracked via
>>
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14650&rfc_flag=0
> 
> 
> 

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

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 13 Mar 2008 19:14:19 +0900

Hello Vijay and Amanda,

Thanks for the review. Please see inline:

Vijay Devarapalli wrote:
> FYI
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [IANA #145901] Last Call: draft-ietf-mipshop-3gfh (Mobile IPv6 Fast 
> Handovers for 3G CDMA Networks) to Informational RFC
> From:
> Vijay Devarapalli <[email-masked]>
> Date:
> CC:
> [email-masked], [email-masked], [email-masked], 
> [email-masked]
> 
> 
>> currently in Last Call, and has the following comments regarding its 
>> publication:
>>

Yes.

>> 1      ANID                      
>> [RFC-ietf-mipshop-3gfh-05.txt]                             2      
>> Sector ID                 [RFC-ietf-mipshop-3gfh-05.txt]
> 
> This is correct.

Yes.

> Value '0' should be reserved. 255 is the upper limit.

I agree.

> draft-ietf-mipshop-3gfh. Should be go with a separate registry?

Our intention is if we can reuse "Mobile Node Identifier Option 
Subtypes" defined by RFC4283 for our MN ID option's Option-Code, then 
the needed action is just adding new value "2" for IMSI like the above. 
This is like "overloading" of different fields.

If this is confusing, however, we need to add a new Registry Name for MN 
ID Option and define two values for NAI and IMSI.

I thought the first approach is simpler, but since I don't know the 
convention of IANA assignment, I'll follow its rules.

>> QUESTION: Does section 6.3 require any registrations? If so, which 
>> registry is it referring to?
> 

I also think it would be very convenient if all the flags are listed 
somewhere in the IANA registry. Currently, they are scattered in the 
related RFCs and there are some risks of collision if the authors are 
not fully aware of all flags (like me:-)). We can continue to discuss 
this issue.

Regards,
-- 
Hidetoshi

> ------------------------------------------------------------------------
>