[dhcwg] Why the precedence stuff is in draft-ietf-dhc-dhcpv6-netboot-05

[Ted Lemon <[e-mail]>]

The precedence stuff was my idea, so don't blame the authors.   The  
reason I proposed that they add it is that the draft as written prior  
to my comments depended on the order that the options appeared in the  
packet.   This seemed like a bad idea to me, since it placed a new  
requirement on servers and a new requirement on clients.

The new requirement it placed on servers was that the administrator be  
able to specify the order that options appear in the packet.   In  
particular, it would have been necessary not only that the bootfile  
options appear in a particular order, but also that the bootfile  
parameters options appear in a particular order.   Not only that, but  
the relative order in which the bootfile options and bootfile  
parameters options appeared was relevant, and would have to be  
specifiable by the administrator.

The new requirement placed on clients was that the client process  
options in the order they appeared in the packet.   This may not seem  
like a particularly onerous requirement, but it's not clear to me how  
to implement it, since the packet is a tree.   Is the order the  
options are processed depth-first, or breadth-first?   It also  
precludes storing the options in a hash table.

By using a precedence number, these problems are eliminated.   The  
administrator simply chooses the precedence, and this reaches the  
client in whatever order it reaches the client.   The precedence  
numbers present a clear map for the client to follow in choosing the  
order in which it processes the options, independent of their order  
within the packet.

The other solution to this problem, which is what the authors  
initially proposed, was just to make the boot parameters option a  
single option with suboptions, and to make the order of the suboptions  
in that option determine the processing order of the packets.   This  
has the same order-preserving requirement, although preserving order  
is arguably easier in this case.   We argued against the suboption  
method at the time because it seemed unnecessary, but perhaps we were  
premature.

Or perhaps the right thing to do is to have two options that don't  
recur: a bootfile-list option, and a bootfile-parameters-list  
option.   We already require the server and client to preserve the  
order of fields within options, so this would work fine.   The only  
problem is that the administrator now has to count fields in the  
options to ensure that the correspondence between fields is maintained.

Stephen Jacob proposed eliminating the wildcard bootfile-parameters  
option precedence, with the idea that this would remove some  
complexity.   In the two-option case it does remove complexity, and so  
is worth considering.   In the multiple-option or multiple-suboption  
cases I don't think it removes any real complexity, though.