Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

[Damien Neil <[e-mail]>]

On Oct 6, 2009, at 12:18 PM, Thomas Narten wrote:
> Would a resonable criteria be that multiple options are OK if you can
> process them in whatever order you find them easily, without having to
> go through the entire message and find other related options that must
> be processed together?

I think that ordering of options should not be significant, although  
I'm not convinced that non-significant ordering is sufficient reason  
to use multiple instances of an option.

One of my concerns is the complexity of presenting option data to a  
user--to a server administrator specifying what to send to a client,  
or to a network configuration script executed by a client.

With DHCPv4 single-instance options, you can say "the value of option  
<foo> is <bar>".  For example, in ISC dhcpd:

   option domain-name-servers = 10.0.0.1, 10.0.0.2;

When you introduce multiple-instance options, this becomes more  
complicated.  There are various means of presenting this to the user,  
but I don't find any of them truly satisfactory.

I note that ISC dhcpd doesn't appear to support defining multiple  
instances of an option at this time.  The dhcp-options(5) manpage  
states, "normally [multiply-instanced options] are options which are  
digested by the DHCP protocol software, and not by users or  
applications."  (If I'm wrong about this, and such support does exist  
in ISC dhcpd, my apologies.)

I'm not absolutely opposed to multiply-instanced options, but I do  
think there's more implementation complexity to them than may first  
meet the eye.  The existing multiple-instanced IA* options don't  
trigger that complexity as much, since they don't need to be directly  
exposed to users.

I'd be very interested to hear what other implementors of generic  
servers or clients think; it's possible that my view is an outlier, in  
which case I withdraw the objection.

               - Damien