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

[Damien Neil <[e-mail]>]

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 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.

Speaking as a server implementor, I dislike having two entirely  
different and incompatible ways of defining a list of items in option  
data.  It adds complexity without offering any benefit that I can  
see.  As such, I would prefer to see new options use the traditional  
means of specifying a list of items, concatenating the items within a  
single option data section, rather than allowing multiple  
occurrences.  This follows with existing practice in DHCPv4, as well  
as with DHCPv6 options defined in RFCs 3319, 3636, 3898, 4075, 4280,  
5192, and 5007.

I realize that RFC 3315 makes extensive use of options which may have  
multiple occurrences in a message.  There is, however, one critical  
differences with these options: They are protocol-internal; none of  
them contain data that is likely to be directly specified or  
manipulated by the operator.


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.

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.  To quote  
from the draft:

>    o  If the precedence field of the Bootfile Parameters option is  
> zero,
>       the client SHOULD provide these parameters when it attempts to
>       execute any Bootfile it has loaded using any of the provided
>       Bootfile URL options.
>
>    o  If the precedence field of the Bootfile Parameters option is
>       nonzero, the client SHOULD provide these parameters only when it
>       attempts to execute a Bootfile it loaded using a Bootfile URL
>       option with a precedence field that has the same value.
>
>    o  In the event that the client receives both a Bootfile Parameters
>       option with a precedence field of zero and one with a precedence
>       field that matches a certain Bootfile URL option, the client  
> MUST
>       use the Bootfile Parameters option whose predence matches the
>       precedence of the Bootfile URL option.


I am very dubious about linking options in this fashion.  This seems  
fragile, and potentially difficult to specify in server  
configurations.  I would prefer to see related data simply contained  
within the same option data section.


I'm now going to undercut my first point a bit:

Merging the content of the Boot File URL option and the Boot File  
Parameters Option into a single option will result in a fairly complex  
option structure.  Furthermore moving from multiple occurrences of  
these options to a list contained in a single option will result in a  
yet more complex structure.  I think that one might reasonably  argue  
that multiple occurrences of an option should be allowed when the  
alternative is a list of complex elements.

Myself, I still prefer using a list contained within a single option  
rather than multiple occurrences.  But I do see the opposing argument.

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.


Finally, a nit: The draft is inconsistent about using "boot file" vs.  
"bootfile".  Pick one and stick to it. :>

                - Damien