Subject: [Mipshop] Comments on draft-ietf-mipshop-mos-dhcp-options-06.txt

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Oct 2008 16:17:41 -0700

Hi Subir, Gabor,

I reviewed draft-ietf-mipshop-mos-dhcp-options again. There are a few 
more minor issues that need to be fixed before the document can be sent 
to the IESG. Please submit a new version after addressing the comments 
below. Apologizes for not sending these comments during the WG last call.

>   Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 
>                     Mobility Server (MoS) discovery 

This should be re-phrased to

   Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
                    IEEE 802.21 Mobility Server (MoS) discovery

There were many comments on the use of the phrase "Mobility Service" in 
AD and IESG review.

>    Mobility Services: comprises of a set of different services provided 
>    by the network to mobile nodes to facilitate handover preparation 
>    and handover decision. 

Expand this to say

   Mobility Services: comprises of a set of different services provided
   by the network to mobile nodes to facilitate handover preparation
   and handover decision. In this document, Mobility Services refer to
   the services defined in IEEE 802.21 specifications [IEEE802.21].

"Mobility Services" is used extensively in this document. So it would be 
good to define what it means very early in the document.

>    This document defines a new dhcpv4 option called MoS option, which 

s/called MoS option/called the MoS option/

> 2. DHCPv4 Option for MoS Discovery
> 
> 
>    This section describes the MoS option for DHCPv4.
>    The MoS option begins with a option code followed by a length and
>    sub-options. The value of the length octet does not include itself
>    or the option code. The option layout is depicted below:
> 
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Option Code   |    length     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                     Sub-Option 1                              |
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       ...                                     |
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                     Sub-Option n                              |
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The above format is odd. It is missing two bytes. It should be

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      | Option Code   |    length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Sub-Option 1                              |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ...                                     |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Sub-Option n                              |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>          Option Code 
>     
>                  OPTION-IPv4-MoS (TBD) - 1 byte  
>     
>             Length 
>     
>                    1 byte

hmm.. you should say what this field is about. Not say it is a 1-byte 
field. For example

       Length

             A 8-bit field indicating the length of the option excluding
             the 'Option Code' and the 'Length' fields.

>    When the total length of a MoS option exceeds 254 octets, the 
>    Procedure outlined in [RFC3396] MUST be employed to split the 

s/Procedure/procedure/

>    A sub-option begins with a sub-option Type followed by a length 
>    and a `enc` field. The value of the length octet does not include 
>    itself or the option code. 

s/or the option code/or the Sub-opt Type field/

>    The sub-option layout is depicted below:
> 
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Sub-opt Type  |    length     |    enc        | FQDN or      .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .              IP Address                                       .
>       .                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is a 8-bit length field sufficient? What if the response needs to carry 
a number of FQDNs, whose total length exceeds 256 bytes?

> *Note: The values `0` '8' to '255' are reserved and MUST NOT be used.
>  Future sub-options may or may not use the above format.

We should delete the sentence "Future sub-options may or may not use the 
above format." What does this mean?

> 3.  DHCPv6 Option for MoS discovery 
>     
>    This section introduces new DHCPv6 option used for MoS discovery. 
>     
>    Whether the MN receives an MoS address from local or home network 
>    will depend on the actual network deployment [MSFD]. 

Is the above sentence specific to only DHCPv6? Wouldn't it apply to 
DHCPv4 also? If yes, why is it here?

>    The MoS option begins with a option code followed by a length and 
>    sub-options. The value of the length octet does not include itself 
>    or the option code. The option layout is depicted below:
> 
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>      |       Option Code             |           length              | 
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>      |                     Sub-Option 1                              | 
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>      |                       ...                                     |
>      .                                                               . 
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>      |                     Sub-Option n                              | 
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>   
>     Option Code 
>     
>                OPTION-IPv6-MoS (TBD) - 2 bytes  
>   
>                Length 
>    
>                    2 bytes 

It doesn't say if the value in the Length field includes the 'Option 
Code' and 'Length' fields.

>    The sub-options follow the same format (except the length value) and 
>    'enc' rules as described in Section 2. The sub-option layout is 
>    Depicted below: 
> 
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>  
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       | sub-opt Type  |     Length                    |     enc       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |                                                               | 
>       .                     FQDN or IP Address                        . 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
> 

The description of the Length field is missing. Does it exclude the 
"sub-opt Type" and "Length" fields?

> 6. IANA Considerations 
> 
>   This document defines one new DHCPv4 option as described in section 
>   2. 
> 
>    MoS Option for DHCPv4 (OPTION-IPv4-MoS)                 TBD
>   
>    This document creates a new registry for the Sub-Option field in the
>    MoS DHCPv4 option called the "MoS Service Type" (Section 2).

Should be call this "IEEE 802.21 Service Type"?

>       IS                       1
>       ES                       2
>       IS and ES                3  
>       CS                       4
>       IS and CS                5
>       ES and CS                6
>       IS, CS and ES            7
> 
>   The values '0', '8' to '255' are reserved and MUST NOT be used. New
>   values can be allocated by Standards Action or IESG approval.
> 
>   This document also defines new DHCPv6 options as described in 
>   section 3
> 
>    MoS Option for DHCPv6 (OPTION-IPv6-MoS)                TBD
>                      	
>    This document creates a new registry for the sub-option field in 
>    the MoS DHCPv6 option called the ?MoS Service Type?(section 3).

Same as above.

>    8.2 Informative References 
>     
>    [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 
>       Networks: Media Independent Handover Services 
>     
  >     [MoS-DNS] Bajko, G., "Locating Mobility Servers",
>       draft-ietf-mipshop-mos-dns-discovery, (Work in Progress), 
>       May 2008. 
>  
>     [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)",
>       draft-ietf-mipshop-mstp-solution, (Work in Progress)

Shouldn't MSFD be listed as a normative reference?

Vijay

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

---

From: Subir Das <[email-masked]>
Date: Mon, 20 Oct 2008 20:32:58 -0400

Vijay,
Thanks for your review. Will reflect them in a new version.
Some answers inline.

-Subir

Vijay Devarapalli wrote:
> more minor issues that need to be fixed before the document can be 
> sent to the IESG. Please submit a new version after addressing the 
> comments below. Apologizes for not sending these comments during the 
> WG last call.
>
> There were many comments on the use of the phrase "Mobility Service" 
> in AD and IESG review.
      Ok.
>
>>    Mobility Services: comprises of a set of different services 
>> provided    by the network to mobile nodes to facilitate handover 
>> preparation    and handover decision. 
>
> Expand this to say
>
> "Mobility Services" is used extensively in this document. So it would 
> be good to define what it means very early in the document.
     OK
> s/called MoS option/called the MoS option/
    Fine.
> The above format is odd. It is missing two bytes. It should be
      Ok.
>
>>          Option Code                      OPTION-IPv4-MoS (TBD) - 1 
>> byte                  Length                        1 byte
>
    Ok but it is mentioned in the text.
>> Procedure outlined in [RFC3396] MUST be employed to split the 
    Ok.
> s/or the option code/or the Sub-opt Type field/
     Ok.
> Is a 8-bit length field sufficient? What if the response needs to 
> carry a number of FQDNs, whose total length exceeds 256 bytes?
     We followed the DHCP options guidelines. For DHCP option the length 
is 1-octet.
> We should delete the sentence "Future sub-options may or may not use 
> the above format." What does this mean?
     There was comment from Bernie. May be we can add this in the above 
paragraph.
>
>> 3.  DHCPv6 Option for MoS discovery        This section introduces 
>> new DHCPv6 option used for MoS discovery.        Whether the MN 
>> receives an MoS address from local or home network    will depend on 
>> the actual network deployment [MSFD]. 
>
     Yes, you are correct. We should add the same clause in DHCPv4 as well.
>>      |       Option Code             |           length              
>> |      
>>      |                     Sub-Option 1                              
>> |      .                                                               .
>>      .                                                               
>> .      
>>      |                     Sub-Option n                              
>> |      .                                                               .
>>       Option Code                    OPTION-IPv6-MoS (TBD) - 2 bytes  
>>                  Length                       2 bytes 
>
   I believe the text does say that and if not will include it.
>
>>    The sub-options follow the same format (except the length value) 
>> and    'enc' rules as described in Section 2. The sub-option layout 
>> is    Depicted below:
>>       |                                                               
>> |       .                     FQDN or IP 
>> Address                        .       
     Ok.
> Should be call this "IEEE 802.21 Service Type"?
     Actually we have used MoS through out the document to be consistent 
with the MSTP document.
>>       IS and ES                3        CS                       4
    Ok.
>
>>    8.2 Informative References        [IEEE802.21] IEEE 802.21 
>> Standard for Local and Metropolitan Area       Networks: Media 
>> Independent Handover Services     
    Yes.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Oct 2008 18:12:57 -0700

>     We followed the DHCP options guidelines. For DHCP option the length 

So what happens when the set of FQDNs that are sent in the response turn 
out to be more than 256 bytes? Should the MoS send a reduced list of 
FQDNs so that they fit into one sub option? If so, it might be good to 
say this explicitly.

>     There was comment from Bernie. May be we can add this in the above 

I don't understand. What future sub-options? Sub-options related to MoS 
discovery?

>     Actually we have used MoS through out the document to be consistent 

But this is going to appear as the name of a registry on the IANA DHCP 
page. So I think it should be named clearly. Having a registry by the 
name "MoS Service Type" is very cryptic.

Vijay

---

From: Subir Das <[email-masked]>
Date: Wed, 22 Oct 2008 08:47:39 -0400

Vijay Devarapalli wrote:
>>>>       .              IP 
>>     We followed the DHCP options guidelines. For DHCP option the 
>> length is 1-octet.
>
> So what happens when the set of FQDNs that are sent in the response 
> turn out to be more than 256 bytes? Should the MoS send a reduced list 
> of FQDNs so that they fit into one sub option? If so, it might be good 
> to say this explicitly.
   Ok.
>>     There was comment from Bernie. May be we can add this in the 
>> above paragraph.
>
> I don't understand. What future sub-options? Sub-options related to 
> MoS discovery?
     Yes, sub-options related to MoS discovery? 
>
>>>> 6. IANA Considerations
>>>>   This document defines one new DHCPv4 option as described in 
>>>> section   2.
>>     Actually we have used MoS through out the document to be 
>> consistent with the MSTP document.
>
    In that case we can rename it to IEEE 802.21 service type.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Oct 2008 10:38:09 -0700

>     Yes, sub-options related to MoS discovery?

I expect future sub-options related to MoS discovery to follow the exact 
same format. Why would the format change for sub-options that we might 
define later in the future? I think the following sentence should be 
removed.

>    In that case we can rename it to IEEE 802.21 service type.

Thanks.

Vijay

---

From: Subir Das <[email-masked]>
Date: Fri, 24 Oct 2008 09:53:23 -0400

Vijay Devarapalli wrote:
>>>>> We should delete the sentence "Future sub-options may or may not 
>>>>> use the above format." What does this mean?
> I expect future sub-options related to MoS discovery to follow the 
> exact same format. Why would the format change for sub-options that we 
> might define later in the future? I think the following sentence 
> should be removed.
>
   Ok. I will update the draft accordingly.
>>> But this is going to appear as the name of a registry on the IANA 
>>> DHCP page. So I think it should be named clearly. Having a registry 
>>> by the name "MoS Service Type" is very cryptic.