Subject: Re: [dhcwg] [Mipshop] FW: Review of draft-ietf-mipshop-mos-dhcp-options-05.txt

From: Subir Das <[email-masked]>
Date: Tue, 07 Oct 2008 00:13:11 -0400

Bernie,
Thanks for your review and it is very helpful.
Pl. see our answers inline. We plan to reflect your
comments and submit another version soon.

-Subir and Gabor

Vijay Devarapalli wrote:
> FYI
>
> Bernie Volz (volz) wrote:
>   
>> Here's my comments after m a quick look at this work, without fully
>> understanding what it is used for:
>>
>> - Abstract
>>
>>    This document defines a number of Dynamic Host Configuration
>>    Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a
>>
>> Don't we usually just say "DHCPv4 and DHCPv6"? MINOR.
>>     
              Yes.
>> - 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                              |
>>      .                                                               .
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>    Option Code
>>
>>                  OPTION-IPv4-MoS (TBD) - 2 bytes
>>
>>             Length
>>
>>                  2 bytes
>>
>>             Sub-options
>>
>>                A series of DHCPv4 sub-options.
>>
>> DHCPv4 options have a *1-octet* option code and length, not a 2-octet.
>>
>> - Later in this section, the sub-opt format is also wrong (1-octet
>> length is used by DHCPv4).
>>     
          Will correct it.
>> - Later in this section, while the presently defined suboptions (1-7)
>> use this format with the "enc" byte, perhaps future sub-options will
>> not need this? So, I'd suggest they clearly state that suboptions 1-7
>> use this format [future suboptions may or may not].     
>>     
     We can state it clearly if that helps.

>> - And, in this section, note that the maximum length of a DNS label is
>> 254 bytes because of the 1 enc byte and sub-options can only be up to
>> 255 bytes long (regardless of whether RFC3396 is used). 
>>     
      Agree. Do you think we need to add some clarifying text here?

>> - And, perhaps a simplication if they just need the existing
>> suboptions would be to define the option as follows:
>>
>> 	Option Code (1 octet) - TBD
>> 	Option Length (1 octet)
>> 	Service Name flags (1 octet) - Name 1
>> 		Bit 0 - IS service name
>> 		Bit 1 - ES service name
>> 		Bit 2 - CS service name
>> 		Bit 3-7 - MBZ
>> 	Encoding flag (1 octet)
>> 	Data length (1 octet)
>> 	Data (depending on encoding)
>> 	Service Name flags (1 octet) - Name 2
>> 		Bit 0 - IS service name
>> 		Bit 1 - ES service name
>> 		Bit 2 - CS service name
>> 		Bit 3-7 - MBZ
>> 	Encoding flag (1 octet)
>> 	Data length (1 octet)
>> 	Data (depending on encoding)
>> 	...
>>
>> Note that the service name/encoding/data length/data can appear
>> multiple times to allow names for different services to be
>> communicated. If this is not necessary then the "data length" field
>> is not needed. (If it is needed, the data length field  is required
>> because one can't have multiple instances of a DHCPv4 option -- see
>> RFC 3396.)  
>>     
	Agree that we can use your proposed approach and get rid of sub-options.
	We believe that your suggested one and the sub-option format we
	currently have in the draft are functionally almost equivalent. Or do
	you see any drawbacks in using the sub-option style format? If not, we
	would prefer to keep the sub-options.

>>
>> - 2.1 Domain Name List:
>>
>> They state that DNS wire encoding is to be used by never state whether
>> compression is or is not allowed. Perhaps it would be better from them
>> to change the "Section 3.1 of [RFC1035]" reference to "Section 8 of
>> [RFC3315]" as that states that compression is NOT used.
>>     
        Ok.
>> - 3.1 IPv6 MoS Identifier Option
>>
>>    This option is included in the Information-request message and used
>>
>> Why only in Information-Request? What about Solicit and
>> Request/Renew/Rebind?
>>
>> Note also that this means that a server must have very special
>> processing capabilities for this new feature. It may be just simpler
>> to drop this option and place the OPTION-IPv6-MoSINF in the ORO. The
>> server can then include all instances of the configured
>> OPTION-IPv6-MoSINF options.   
>>     
     Ok, we'll drop this option and keep only the other one (just like in
     DHCPv4)

>> In the DHCPv4 case, no option was sent in the client request to
>> request specific values, so why is this needed in DHCPv6 (as it isn't
>> needed in DHCPv4)?    
>>     
     We assumed that in DHCPv4, the client can insert in a request a
     sub-option with a specific sub-opt type  if it desires to ask for a
     specific MoS sub-type. Since we are going to remove the MoS Identifier
     dhcpv6 Option defined in section 3.1, the Dhcpv4 and Dhcpv6 behaviors
     will be consistent.

>> - Section 3.2
>>
>> For DHCPv6, I'd use a similar option as in the DHCPv4 case above but
>> there's no need for the data-length because each INSTANCE of the
>> option can define one set of services. So, the DHCPv6 option is:
>>
>> 	Option Code (2 octets) - TBD (OPTION-IPv6-MoSINF)
>> 	Option Length (2 octets)
>> 	Service Name flags (1 octet)
>> 		Bit 0 - IS service name
>> 		Bit 1 - ES service name
>> 		Bit 2 - CS service name
>> 		Bit 3-7 - MBZ
>> 	Encoding flag (1 octet)
>> 	Data (depending on encoding)
>>
>> Note: The "service name flags" could be an enumeration as they have
>> it. But it seems a bit map would be simpler?   
>>     
     As mentioned above we would prefer to keep the sub-options style, unless
     there would be some loss of functionality by keeping it.

>>
>> That's at least some comments from a quick look at this work, without
>> fully understanding what it is used for.
>>     
       Thanks for your review.
>> - Bernie
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of John Jason Brzozowski
>> Sent: Friday, October 03, 2008 9:21 AM
>> To: dhc WG
>> Cc: dhc Chairs; Stefano Faccin; Vijay Devarapalli
>> Subject: [dhcwg] Review of draft-ietf-mipshop-mos-dhcp-options-05.txt
>>
>> Folks,
>>
>> The MIPSHOP WG is working on extensions for discovering IEEE 802.21
>> MIH (Media Independent Handovers) severs. The draft at the URL below
>> defines DHCP options for discovering these mobility servers.
>>
>>
>>     
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mos-dhcp-options-
>   
>> 05.t
>> xt
>>
>> The MIPSHOP WG has requested a review of this draft by the dhc WG.
>> Please
>> review this draft and forward comments the dhc WG mailing list and the
>> authors of the draft.
>>
>> Thanks,
>>
>> Ralph and John
>>
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>     
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>   

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