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

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 3 Oct 2008 19:18:21 -0400

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.
> 
> - 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).
> 
> - 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].
> 
> - 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).
> 
> - 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.) 
> 
> 
> - 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.
> 
> - 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.
> 
> 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)?
> 
> - 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?
> 
> 
> That's at least some comments from a quick look at this work, without
> fully understanding what it is used for.
> 
> - 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

---

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

>> Don't we usually just say "DHCPv4 and DHCPv6"? MINOR.
              Yes.
>>    or the option code. The option layout is depicted below:
          Will correct it.
>> use this format [future suboptions may or may not].     
     We can state it clearly if that helps.

>> 255 bytes long (regardless of whether RFC3396 is used). 
      Agree. Do you think we need to add some clarifying text here?

>> because one can't have multiple instances of a DHCPv4 option -- see
	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.

>> [RFC3315]" as that states that compression is NOT used.
        Ok.
>> OPTION-IPv6-MoSINF options.   
     Ok, we'll drop this option and keep only the other one (just like in
     DHCPv4)

>> request specific values, so why is this needed in DHCPv6 (as it isn't
     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.

>> 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.

>> fully understanding what it is used for.
       Thanks for your review.