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

[Ted Lemon <[e-mail]>]

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.