Subject: [dhcwg] DHCPv6 Remote Boot Options draft...

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Nov 2008 23:26:43 -0600

Reading over the draft, I have a couple of observations that would  
probably be better shared here than at the microphone.

First, in section 2.2, it described a "Next Server" option.   This is  
not a good name.   It was always confusing in DHCPv4, and this would  
be a good time to fix the confusion.   How about "boot load server" or  
"boot server"?

Secondly, why is this option needed?   The Root Path option specifies  
a URI (not a URL, as the draft currently states) which includes the  
hostname or IP address of the boot server.

Actually, I just noticed that the Root Path option specifies that the  
root path is a NUL-terminated string. This is wrong.   The option  
contains a length.   There is no need for NUL termination, and this  
will create interoperability problems, as it has in the past in  
DHCPv4.   So any mention of NUL termination needs to be excised from  
the draft.

Why is the boot file size specified in blocks?   Wouldn't it make more  
sense to specify it in bytes?

With those caveats, the draft looks fine.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Nov 2008 00:44:41 -0500

I was going to bring up many of these same issues at the DHC WG meeting,
but might as well chime in now as well.

I suspect that the "Next Server" option (which I agree is badly named)
is there so that clients that don't have DNS resolver code can skip the
"host" portion of the URL and just use the address option. If that is
correct (or even if not), it should be made clear how this option works
with the ROOT_PATH option.

I also think this draft needs to be clear that a client needs to request
these options in the ORO in order to get them back. This also then works
nicely with the "Next Server" option as clients that have a DNS resolver
would not need to ask for it.

I think some additional text in some sections to clarify who sends the
option to whom in all cases can't hurt.

I also question whether the SLP options should be in a separate draft
(essentially produce a RFC 2610 version for DHCPv6). I'm just concerned
that someone looking for SLP options might not find the draft as booting
and SLP aren't an obvious connection (at least to me?). Yes, if they
look at the option list at IANA they'd find the SLP option numbers once
assigned, but not sure if everyone knows to look there.

I also think that these folks should get together with the
draft-ietf-dhc-dhcpv6-opt-netboot-02.txt folks and work out a common
design for the booting issue. (I have some other issues with this draft,
which I'll either discuss at the meeting and/or post to the list).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Thursday, November 20, 2008 12:27 AM
To: [email-masked] WG
Subject: [dhcwg] DHCPv6 Remote Boot Options draft...

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Nov 2008 10:22:58 -0500

Probably best to rename the Root Path option to Boot URL? Or at least
get Boot into the name.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Thursday, November 20, 2008 12:45 AM
To: Ted Lemon; [email-masked]
Subject: Re: [dhcwg] DHCPv6 Remote Boot Options draft...

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Nov 2008 09:28:23 -0600

> Probably best to rename the Root Path option to Boot URL? Or at least

Makes sense.   Should be URI, not URL.   We all know what we mean when  
we say URL, but we're using URL to mean URI, and all the standards say  
URI, so we really ought to follow the standards.

---

From: Thomas Huth <[email-masked]>
Date: Thu, 20 Nov 2008 16:32:11 +0100

> with the ROOT_PATH option.

In my opinion, this also does not make much sense. If a client does not
support DNS at all (what is very unlikely nowadays), it is still possible
to encode the IPv6 address directly in the URL (according to RFC 3986).
Defining this option could also lead to ambiguous situations (what shall
the client do if it supports DNS, but the resolved hostname from the
ROOT_PATH option does not match the IPv6 address from the next-server
option?). So I think it is best to drop this option completely.

> Sent: Thursday, November 20, 2008 12:27 AM
[...]
> sense to specify it in bytes?

Why is there a need for a boot file size option at all? You can easily
determine the size of the boot file with the transport protocol. For
example TFTP, there is the "Transfer Size Option" (see RFC 2349). So in my
opinion, this option is redundant.

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