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

[Thomas Huth <[e-mail]>]

[e-mail] wrote on 06/10/2009 00:29:23:
>
> Speaking as a server implementor, I dislike having two entirely
> different and incompatible ways of defining a list of items in option
> data.  It adds complexity without offering any benefit that I can
> see.  As such, I would prefer to see new options use the traditional
> means of specifying a list of items, concatenating the items within a
> single option data section, rather than allowing multiple
> occurrences.  This follows with existing practice in DHCPv4, as well
> as with DHCPv6 options defined in RFCs 3319, 3636, 3898, 4075, 4280,
> 5192, and 5007.

Damien,

thanks for your feedback. In fact, we used a single-option approach first
(see the early version of our draft, e.g.
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-netboot-01.html), but
then we've been told to better split up this big option into parts, for
simplicity reasons... and honestly, I now also like this new way better
since it's really easier to understand than a nested single option.

> Moving beyond the question of whether permitting multiple occurrences
> of user-specified options is a good idea or not, I have concerns about
> the usage of the 'precedence' field in the Boot File URL Option and
> the Boot File Parameters Option.
>
> Each of these options contains an 8-bit integer 'precedence' value.
> This value indicates the order in which clients should process these
> fields.  This value also links the two options together.  To quote
> from the draft:
>
> >    o  If the precedence field of the Bootfile Parameters option is
> > zero,
> >       the client SHOULD provide these parameters when it attempts to
> >       execute any Bootfile it has loaded using any of the provided
> >       Bootfile URL options.
> >
> >    o  If the precedence field of the Bootfile Parameters option is
> >       nonzero, the client SHOULD provide these parameters only when it
> >       attempts to execute a Bootfile it loaded using a Bootfile URL
> >       option with a precedence field that has the same value.
> >
> >    o  In the event that the client receives both a Bootfile Parameters
> >       option with a precedence field of zero and one with a precedence
> >       field that matches a certain Bootfile URL option, the client
> > MUST
> >       use the Bootfile Parameters option whose predence matches the
> >       precedence of the Bootfile URL option.
>
>
> I am very dubious about linking options in this fashion.  This seems
> fragile, and potentially difficult to specify in server
> configurations.  I would prefer to see related data simply contained
> within the same option data section.

Well, by separating the parameters from the boot file option, it's enough
to specify the parameters once for all boot images (if all take the same
parameters). That's much easier to maintain than if copies of the
parameters would be put into the same options as the boot file name (you
would then have to change all options in your DHCP server configuration
file if you want to change only the parameters).>

All in all, I think we're doing the right approach with the latest version
of our draft already. It's also available for more than half a year now,
and so far nobody complained about this yet.


Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Erich Baier          
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: [phone]          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294