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

[Thomas Narten <[e-mail]>]

Hi Damien.

> Apologies to the authors for the amount of time it took for me to get  
> to this.

> This draft defines four DHCPv6 options that convey information related  
> to network booting a node.  There is a clear use case for these  
> options, and the information they convey seems reasonable to me.  I  
> have no concerns there.

I concur.

> I do have some concerns about the format of the Boot File URL Option  
> and the Boot File Parameters Option.

> My first issue is the use of multiple occurrences of these options in  
> a single DHCPv6 message.

> This is an issue that is more general than just this draft.  At this  
> time, there are two separate mechanisms used to convey lists of  
> information in DHCPv6: Multiple occurrences of an option (e.g., the IA  
> Address Option), and concatenated values within a single occurrence of  
> an option (e.g., the DNS Recursive Name Server Option).

> To my understanding, there is at this time no consistent policy on  
> which of these approaches should be used in new options.

I agree with the spirit of your concern here, but I think there are
distinctions here that are relevant.

IMO, the IA option is very different from other ones. Each IA option
has its own lifetime field for that instance of the option. You can
have some IAs timing out before others. Each IA option is treated
independently of the others, and they don't need to be processed
"together". You just process the option when you see it in a
message. So putting them in different options doesn't really add
complexity (in terms of processing them).

On the other hand, when you can have multiple instances of an option,
and you have to process them all together at the same time (in order
to process them correctly), that adds complexity and suggests it might
be better to stuff all the info into a single option (so an
implementation doesn't have to hunt around the DHCP message to find
all the relevant options that must be processed together).

> Moving beyond the question of whether permitting multiple occurrences  
> of user-specified options is a good idea or not, I have concerns about  
> the usage of the 'precedence' field in the Boot File URL Option and  
> the Boot File Parameters Option.

I strongly share these concerns.

> Each of these options contains an 8-bit integer 'precedence' value.   
> This value indicates the order in which clients should process these  
> fields.  This value also links the two options together.

Right.

I know of no DHCP option that has ever been defined where you can have
multiple instances of two different options (say 1 and 2), where there
is a key/cookie that ties an instance of option 1 with a specific
instance of option 2 (that is what the precedence field seems to do).

Seems to me that the far cleaner way to do this is to combine the two
options into one. That way, any options that pertain to a particular
BOOTFILE_URL are just included with that option.

You could still define a separate BOOTFILE_PARAM option that would
only be used as a default, when no BOOTFILE_PARAM stuff was included
with a particular URL option. (i.e., to serve the purpose a precedence
of 0 seems to fill). But I'm not sure how important that is.

> Whichever way this goes, however, I think there should be some general  
> policy on when multiple occurrences of an option should be allowed.   
> If we do go down the route of adding this additional protocol  
> complexity, I would prefer that we do so with intention rather than  
> accidentally.

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?

Thomas