On Oct 6, 2009, at 12:41 PM, Thomas Narten wrote:
The issue that I see is that a simple implementation might want to process DHCP options one at a time in order. Find first option, process, discard. Go to next option, repeat.
Okay, I can see your point, and this (netboot) would certainly be the case where that would be most likely to be desired. However, when I think about how I'd implement this in practice, I'm skeptical that your observation holds, because it seems unlikely to me that the client would, in practice, also be the thing evaluating these options.
In practice, I would expect the client to be one module, and the boot loader to be another module. The client would probably parse all the options and store them somewhere, and then trigger whatever other modules needed to run after first acquiring an IP address. One of these would be the boot loader.
I would not expect the DHCP client to invoke the boot loader in the middle of the option parsing process. In fact it's impossible that it could, since there's no guarantee that the IP address, which must be processed prior to doing the boot loading, would appear prior to the netboot option.
Practically speaking, what's going to happen is that each module that has to run prior to the boot loader is, like the boot loader, going to have to make one or more passes across the list of options received by the client. Then the boot loader will have to do the same thing. So the client is going to have to present the options in such a way that it's easy to iterate across them.
This means that by the time the boot loader is triggered, the code iterating across client options is going to have been run several times. It's no problem for the boot loader to run it several more times, once for each possible netboot object. It's certainly not a performance problem, and I don't think it adds to code complexity.
So while I agree in principle that the way this works feels a little weird, in practice I don't see this as a problem with the protocol.