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

[Jarrod Johnson <jarrod.b.johnson at gmail.com>]

On Sat, Oct 10, 2009 at 10:16 AM, Thomas Huth <THUTH at de.ibm.com> wrote:
> Bud Millwood <budm at weird-solutions.com> wrote on 07/10/2009 21:39:12:
>> The way our GUI works, for example, you define a subencoded option,
>> then "inside it" you can only define the suboptions declared for that
> parent.
>> So the list of data you can put in the suboption is short and easy to
>> comprehend.
>
> Ok, these "sub-options" might work fine with a GUI, but I think the plain
> text configuration files of the DHCP server gets more complicated with
> sub-options. The settings then have to specified in a nested way like:
>
> option netboot = {
>   url = http://...
>   params = "acpi = off ..."
>   ...
> }

FYI, at least in ISC dhcpd, the convention for encapsulated options
that I'm familiar would look more like:
netboot.url="http://....";
netboot.params="acpi = off ..."

The downside that could occur to me is it could be a little awkward if
two fields are linked together by spec that ultimately could be
interpreted by different pieces of client code.  For example, presume
that you had 'netboot.ipl='http://some/kernel/' and
'netboot.rootpath='iscsi:etc'.  It may be conceivable that disparate
code is used to get that rootpath ready from the code that is
responsible for executing the kernel.  Still wouldn't be
insurmountable, but it's the largest downside I could come up with
since I think the textual option declaration could look pretty much
the same as separate options.