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

[Ted Lemon <[e-mail]>]

On Oct 6, 2009, at 1:41 PM, Thomas Narten wrote:
> URLs are in ascii... is this state of the art? or should they be in
> UTF-8?

Yes, they should be UTF-8.

> 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.

Yup.

> Also, a lower numbered precedence is
> treated higher precedence? Why?

First, second, third, fourth...

> 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...)

That makes sense.

> 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?

It's not predictable, because if you say it this way, you've placed a  
requirement on both the server and the client that they process these  
options in a particular order.   The precedence field is there because  
there is no such requirement currently.   However, another way to  
treat this problem would be to simply say that in the event that more  
than one option is presented with the same precedence, the order in  
which these options are processed is not defined.

>>   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?

This is because the value 0 has a special meaning, which is described  
in the draft.

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

Good question.   Assuming that we don't decide the precedence model is  
a bad idea, the draft should have additional text that says that any  
such option MUST be ignored by the client.

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

Yes.