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

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Oct 2009 16:41:04 -0400

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

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 6 Oct 2009 13:52:50 -0700

> with what people would expect and what other "precedence" fields

I agree that it would be good to say in that paragraph what the
order is.

I don't agree with your objection to the chosen ordering, however.

To me, it does not mean "low precendence is high precedence". Rather, 
"a low numeric value for precendence indicates high precedence",
which is subtly different -- and not contradictory.

In my experience it is quite common to have "low values indicate
higher priority/precedence" because that way everybody knows what
the highest possible priority is (0, or 1). If it goes the other
way, how do you choose a value for "really high priority"? 100?
1,000? 10,000? So, I think this is a reasonable choice.

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

I tend to agree that unless there is a compelling reason to forbid zero,
zero should simply be the highest precedence.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 13:53:38 -0700

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

Yes, they should be UTF-8.

> indicate higher precedence.

Yup.

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

First, second, third, fourth...

> mapped to an IPv4 server if that worked...)

That makes sense.

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

> 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

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.

> this would allow other scripts/languages.)

Yes.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 13:55:06 -0700

> zero should simply be the highest precedence.

The precedence value is used in two types of option.   In one of  
these, it's a wild card.   In the other, a wild card is not  
appropriate, hence it's forbidden.

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 6 Oct 2009 14:05:30 -0700

> appropriate, hence it's forbidden.

Oops. :) Alright, that's a good reason.

Regards,
Stephen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 14:08:22 -0700

The precedence stuff was my idea, so don't blame the authors.   The  
reason I proposed that they add it is that the draft as written prior  
to my comments depended on the order that the options appeared in the  
packet.   This seemed like a bad idea to me, since it placed a new  
requirement on servers and a new requirement on clients.

The new requirement it placed on servers was that the administrator be  
able to specify the order that options appear in the packet.   In  
particular, it would have been necessary not only that the bootfile  
options appear in a particular order, but also that the bootfile  
parameters options appear in a particular order.   Not only that, but  
the relative order in which the bootfile options and bootfile  
parameters options appeared was relevant, and would have to be  
specifiable by the administrator.

The new requirement placed on clients was that the client process  
options in the order they appeared in the packet.   This may not seem  
like a particularly onerous requirement, but it's not clear to me how  
to implement it, since the packet is a tree.   Is the order the  
options are processed depth-first, or breadth-first?   It also  
precludes storing the options in a hash table.

By using a precedence number, these problems are eliminated.   The  
administrator simply chooses the precedence, and this reaches the  
client in whatever order it reaches the client.   The precedence  
numbers present a clear map for the client to follow in choosing the  
order in which it processes the options, independent of their order  
within the packet.

The other solution to this problem, which is what the authors  
initially proposed, was just to make the boot parameters option a  
single option with suboptions, and to make the order of the suboptions  
in that option determine the processing order of the packets.   This  
has the same order-preserving requirement, although preserving order  
is arguably easier in this case.   We argued against the suboption  
method at the time because it seemed unnecessary, but perhaps we were  
premature.

Or perhaps the right thing to do is to have two options that don't  
recur: a bootfile-list option, and a bootfile-parameters-list  
option.   We already require the server and client to preserve the  
order of fields within options, so this would work fine.   The only  
problem is that the administrator now has to count fields in the  
options to ensure that the correspondence between fields is maintained.

Stephen Jacob proposed eliminating the wildcard bootfile-parameters  
option precedence, with the idea that this would remove some  
complexity.   In the two-option case it does remove complexity, and so  
is worth considering.   In the multiple-option or multiple-suboption  
cases I don't think it removes any real complexity, though.

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 6 Oct 2009 18:53:15 -0700

> cases I don't think it removes any real complexity, though.

It is true that I was unclear in stating what I thought should
replace it.

I was arguing for Damien's second suggestion, in which he went
back on his original objection to multiple option occurences
and suggested that each boot file be an occurrence of the option,
but that the option contain both boot file URL and parameters.

I.e. now the draft has, I believe:

	boot file URL:	<precedence><url>
	boot params:	<precedence><options>

	(Each allowing multiple occurrences).

I am suggesting one option:

	boot file/params: [<precedence>]<url><options>

	(Allowing multiple occurrences for multiple URLs).

With this scheme, "precedence" is no longer rather kludgily
performing 2 entirely separate tasks ((1) precedence and (2)
linking of URLs with parameters) and you get to decide whether
it is important to retain it or not.

I really have no particular objection to the <precedence>
field. I just strongly dislike its use as a way to link
2 separate options (url and params).

Regards,
Stephen

---

From: Damien Neil <[email-masked]>
Date: Tue, 6 Oct 2009 19:12:18 -0700

> 	(Allowing multiple occurrences for multiple URLs).

A possible alternative to this, that allows for multiple boot files  
associated with the same params:

	boot file/params: <precedence><encapsulation>

The <encapsulation> may contain two option codes:

	boot file: <url>[<url>...]
	boot params: <param>[<param>...]

In this case, the encapsulating file/params option may have multiple  
instances. The encapsulated options may not.  The boot file option is  
required, while the boot parameters option is not.  Each URL given  
will be tried in order, using all parameters each time.

Although I still don't like allowing multiple instances of an option.   
I'm hoping implementors of other servers will weigh in on this.  I'd  
feel a lot better about multiple-instance options if other  
implementors actively indicated that they didn't mind supporting them.

(It's possible that there has been debate on this in the past that  
resulted in a consensus that I'm not aware of.  I haven't managed to  
turn up anything, however.)

              - Damien

---

From: Thomas Huth <[email-masked]>
Date: Sat, 10 Oct 2009 15:07:03 +0200

> Yes, they should be UTF-8.

Sorry, but if I've got RFC 3986 right, URIs should be encoded with US-ASCII
(and special characters should be specified with the percent-encoding) ?

> > mapped to an IPv4 server if that worked...)

Ok.>

> > this would allow other scripts/languages.)

Ok, agreed, for the parameters, UTF-8 might be a good idea (since there is
no percent-encoding as with the URLs).

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.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294