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

From: John Jason Brzozowski <[email-masked]>
Date: Fri, 03 Oct 2008 09:20:54 -0400

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 3 Oct 2008 16:20:07 -0400

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,

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