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