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

[Thomas Narten <narten at us.ibm.com>]

Ted Lemon <Ted.Lemon at nominum.com> writes:

> Nope, I'm still not getting it.  How is it more complicated than
> unpacking the data out of an individual option?  Don't you have to
> go through the entire packet to find that individual option?  You
> already have code that knows how to unpack options, so it seems like
> it's actually more general to encapsulate the data in options than
> to define an option format that has to be parsed specially.

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.

The way the netboot options are defined, you can't do that. Before you
process the BOOTFILE_URL option, you have to scan the entire rest of
the DHCP message to find the corresponding BOOTFILE_PARAM option. (And
more specifically, the one with the same precedence key.)

That seems like gratuitous complexity, if we can avoid it.

Hence, I was suggesting that one possible way to decide whether to
encode stuff in one option vs. multiple instances (with different data
in it) would be the following. if an implementation could just process
them one at at time without having to find them all before processing,
encoding them as multiple options is fine.  But if you needed to have
all the instances of that option together, before being able to
process one of them, perhaps then it would be better to just encode
all the data in one option so its all in one place. That way the
client doesn't have to hunt around for it.

Thomas