Subject: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-02.txt

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

For the most part this looks good, but I have a few observations.    
First of all, why is the option defined as an encapsulation?   I don't  
see any need for this - it adds complexity without adding value.

Secondly, section six makes recommendations as to the boot filem  
download protocol that should be used, which I guess is okay, but what  
it recommends is bad.   Speaking as a long-time user of network  
booting, I can say with some authority that tftp is a *lousy* protocol  
for net booting, not only because of its file size limitations and  
security issues, but because existing implementations are very  
difficult to use.   I've never used iSCSI, and don't see any reason to  
either.

If you must recommend a protocol to use, recommend http.   Http  
servers are well understood and easy to set up, manage and debug.    
Modern firmware that supports IPv6 will not have any difficulty  
supporting http - for example, my OLPC XO supports netbooting via  
http, and it's *so* much easier than tftp.   Some firmware may be too  
constrained for http, but it should be considered the exception, not  
the rule, and tftp should not under any circumstances be *recommended*  
as a boot file download protocol.

So I would like to either see this section removed from the draft, or  
else changed to recommend http.

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

---

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

Add to this why the vendor option? We already have vendor options which
could easily be used to communicate any vendor specific booting
information?

Again, I think this work and the
draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt work should be
combined.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Thursday, November 20, 2008 12:35 AM
To: [email-masked] WG
Subject: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-02.txt

---

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

> see any need for this - it adds complexity without adding value.

With the encapsulation, you can for example easily specify more than one
boot server within the NET_BOOT option. This is helpful for load balancing
or backup scenarios if one of the boot servers is overloaded or completely
down.

> difficult to use.
[...]
> else changed to recommend http.

I agree that TFTP is a lousy protocol in terms of performance and security,
but it has also two big advantages:
1) TFTP is easy to implement, especially in firmware where you often have
to deal with size and complexity constraints. You don't need a full blown
TCP stack in firmware, UDP is sufficient.
2) You can also do multicast-TFTP which is very handy if you have a lot of
computers in your network that boot the same image at the same time.

Anyway, we could change the wording of that section a little bit to also
stress the value of TCP based protocols like HTTP (better flow control,
easier to use, etc.).

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

---

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

> or backup scenarios if one of the boot servers is overloaded or  

Right, but you can do that by simply repeating the option, so there's  
no need for the encapsulation.   DHCPv6 doesn't do option aggregation.

> TCP stack in firmware, UDP is sufficient.
Right, but that's irrelevant, because we're talking about modern  
machines here, not ten-year-old printers.   The only exception would  
be a very small device, and such a device can use TFTP.   We just  
shouldn't recommend that people with more capable devices use it.

> computers in your network that boot the same image at the same time.

This would be another reason to go against the recommendation for  
certain classes of device, but it's not a reason to recommend tftp -  
just a reason for a particular implementor to go against the  
recommendation of using http.

> stress the value of TCP based protocols like HTTP (better flow  

Okay, but if you want to do it that way I think you should change the  
document so that rather than making a single recommendation, it gives  
the reasons why an implementor might choose each protocol, and doesn't  
recommend a specific protocol.   I think it makes a certain amount of  
sense to put this in a netboot document, but you might have to change  
the focus of the document if you want to go into that much detail.

---

From: Thomas Huth <[email-masked]>
Date: Thu, 20 Nov 2008 14:58:49 +0100

> could easily be used to communicate any vendor specific booting

Actually, the vendor suboption has been requested here on the mailing list
after we published version 00 of our draft (which did not contain this
suboption yet). It can be used to bundle vendor specifc boot information
together with the other boot information.

> draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt work should be

It certainly does not make sense to maintain two drafts for the same topic.
So I hope you come to a decision during the IETF WG meeting which one of
the two drafts should be used for future work.

---

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

The two drafts do fairly different things, so if you want to combine  
them it's going to be a lot of work.   I tend to agree that the two  
drafts are in the same problem space, but the PXE draft is heavily  
freighted with history, so I am not convinced that the two drafts  
should be in a battle to the death.