Re: [dhcwg] way forward for the mipshop-mos-dhcp document

["Bernie Volz (volz)" <volz at cisco.com>]

I'm OK with this.

There are some other issues with the
draft-ietf-mipshop-mos-dhcp-options-11.txt draft though that I found in
a quick review:

Section 3:

   The Sub-option begins with a sub-option code followed by a length 
   and a sequence of labels that are encoded according to Section 8 of 
   [RFC3315]. 
  
   [RFC1035] encoding was chosen to accommodate future international-
   lized domain name mechanisms. The minimum length for this encoding 
   is 3.  

I don't understand why the minimum length of RFC 1035 encoding is 3? If
you wanted to send "." it would be 1 octet (or a. which would be 2).
Perhaps "this encoding" refers to the suboption/suboption-length/data
but it is not clear in this text. Also, the switch between RFC 3315 to
RFC 1035 is a bit odd unless one actually looks at RFC 3315, Section 8.

In secton 6.1.1 (and 6.1.2), both DHCPDISCOVER and DHCPREQUEST (and
DHCPOFFER and DHCPACK) should contain these options. The DHCPACK is what
gives the client the 'final' configuration.

Also, later in section 6.1.2 and 6.2.2:

   In case that the server cannot find any Mobility Server satisfying 
   the requested Sub-opt Code, the server MUST return the MoS Option 
   with a sub-option by setting the Sub-opt Code to the requested
   Sub-opt Code and the length of the sub-option to 1.

I could understand this if the sub-option length was 0, but 1? If 1,
what should the data byte contain?

Also, as this client/server behavior requires SPECIAL processing in the
server, I suspect adoption will be slow. You really should simplify this
to allow the client to request those that it wants and the server to
optionally use that in what it returns, but the server could just return
a static list and the client needs to match them up? Of course, if
there's more than just sending back these options that the server needs
to do, perhaps it is OK to require the complexity but again uptake will
be slow.

For DHCPv6, don't you want to allow these for RENEW or REBIND messages
as well? And, probably they should be allowed in a SOLICIT as then the
server can tell the client what it would give it later?

- Bernie

-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of Jari Arkko
Sent: Monday, March 09, 2009 4:57 PM
To: Dhcwg; draft-ietf-mipshop-mos-dhcp-options at tools.ietf.org; Mipshop
Chairs
Subject: [dhcwg] way forward for the mipshop-mos-dhcp document

Hi all,

There's a new version. This version completely removes the problems we 
had with the variable encoding.

The version does keep the ability to provide both addresses and FQDNs 
for the mobility servers, however, using separate options. I personally 
think this issue was far less pressing than the above one; if servers 
can't deal with the encoding that's a serious deployment barrier. If 
there's multiple formats to deliver information, that is an extra 
implementation burden and a potential interoperability issue for nodes 
that choose to disobey the RFC and not implement both. However, folks 
who want to deploy this could overcome these easily. As a result, I'm 
fine with the document moving forward as it is. However, the two WGs 
need to be OK with them as well, and when we talked about this in DHC 
there were concerns about providing both addresses and FQDNs. Can we try

to close that issue and move on?

In my mind the question is whether the two formats are justified. I have

been thinking about this today and I can see an excellent argument for 
why FQDNs need to be supported. There are some, but not quite as 
convincing arguments for why addresses need to be supported.

The FQDNs need to be supported because DHCP simply delivers information 
about the server, but has no understanding of further details. For 
instance, 802.21 mobility servers may operate using multiple transport 
protocols (UDP, TCP, maybe SCTP). There are SRV record mechanisms in 
place to discover what transport protocols are available and at which 
port they run on. However, the transport protocol information is not 
carried in DHCP (nor would it make sense to do so). And it does not help

if the DHCP server resolves some of these queries, because IMHO it would

not make sense for the DHCP server to be aware of all the details of 
client capabilities. As a result, it seems that if we want to enable 
dynamic negotiation of transport protocols or ports, you have to support

FQDNs.

The arguments for the pure address delivery are that (1) its the common 
way to deliver information in DHCP, so it could be supported as a "base"

mechanism for networks that do not need any SRV mechanisms and (2) there

may be networks that do not have DNS names for all entities.

I personally think these reasons are sufficient to let the documents 
move forward (or to be more exact, insufficient for us to block the 
802.21 folks from introducing additional complexity if they really 
insist on it). I do acknowledge that the arguments for pure address 
delivery are on the weak side. But what does the DHC WG think? Is the 
above analysis correct? Are there other means to do this that I missed?

Jari

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg