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

[Thomas Narten <[e-mail]>]

I would like to see this document progress (it is needed), but it
needs some additional work.

I've already responded in another message with my misgivings about
using the precedence field to tie two options together.

Here are my remaining comments.

URLs are in ascii... is this state of the art? or should they be in
UTF-8? 

>    precedence        A single unsigned octet indicating the order in
>                      which this URL should be processed, if more than
>                      one URL appears in the message.

Later, we learn that lower numbered precedence actually means "use
first".  It would be good to add text here saying lower precedences
indicate higher precedence. Also, a lower numbered precedence is
treated higher precedence? Why? this seems counter-intuitive to
me. (Not a big deal, but let's pick an ordering that is consistent
with what people would expect and what other "precedence" fields
mean.)

>    The node identifier in the URL must be reachable using IPv6.

Huh? this makes no sense and is unenforceable. Remove as not
necessary? (indeed, there would be nothing wrong with a URL that
mapped to an IPv4 server if that worked...)

>    Multiple occurrences of OPT_BOOTFILE_URL MAY be present in a single

Better:

       Multiple occurrences of the OPT_BOOTFILE_URL option MAY be
       present in a single

>    Servers SHOULD NOT send two Bootfile URL options with the same
>    precedence.  Clients receiving more than one OPT_BOOTFILE_URL option
>    with the same precedence SHOULD discard any extra such options.  The
>    order in which the client processes options is not specified, and
>    therefore server implementations cannot assume that the client will
>    discard a particular such option.

The semantics of the precedence field seem complicated to me. Servers
are not supposed to send two options with the same precendent, but
client behavior when this happens is undefined. That is a bad way to
get interoperability. Can't we just say the client processes the first
one and discards the others at the same precedence? or something
simple/predictable like that?

Also, I assume the semantics of this option is that you only use one
instance, and if that somehow fails, you don't try the other options
as a fallback? (It might be good to come out and say that.)

>    The value of the precedence field MUST NOT be zero.

Again, this is not good for interoperability. What happens when it is?
Is the value effectively reserved?  Why and for what?

And what does an implementation do if it receives an option with such
a value?

> 3.2.  Boot File Parameters Option
> 
>    This option consists of multiple US-ASCII strings.  They are used to
>    specify parameters for the boot file (e.g. parameters for the kernel
>    or boot loader program).

Shouldn't the parameters be UTF-8? (US-ASCII is a proper subset, but
this would allow other scripts/languages.)

Thomas