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 precedencefield that matches a certain Bootfile URL option, the client MUSTuse 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