Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-opt-netboot-06.txt

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Nov 2009 00:32:47 -0500

I finally had time to give the new netboot draft a thorough read.   It's basically ready for last call, although I do have a few suggestions and a few required changes, which I've included below.   Do you want me to do the last call now, or wait until you've addressed the changes I propose below?

From Section 3.2:

   The firmware MUST pass these parameters in the order they appear in
   the OPT_BOOTFILE_PARAM option to the boot file which has been
   specified in the OPT_BOOTFILE_URL option.

This text is hard to parse; suggest the following change:

   When the boot firmware executes the boot file which has been
   specified in the OPT_BOOTFILE_URL option, it MUST pass these
   parameters in the order that they appear in the OPT_BOOTFILE_PARAM
   option.

In section 3.3, this option appears to specify more than one
architecture type.  However, RFC4578 specifies architecture types that
are all mutually exclusive.  It doesn't make sense to me that any
client would ever send more than one architecture type.  Also, you
don't specify the length of the architecture type specifier here -
RFC4578 says it's 16 bits per type code, but this draft does not
repeat that specification.  The fact that RFC4578 allows only one
architecture type to be specified further muddies the issue.

So the draft should be updated either to limit this to a single
architecture type, or to (a) explain precisely how more than one
architecture type is specified and (b) explain what it means when
there is more than one architecture type.

Furthermore, RFC4578 is an informational RFC, and does not specify how
additional architecture types would be allocated and documented.
Since the list of architecture types given in RFC4578 is not
exhaustive, and since RFC4578 doesn't specify a registry for these
types, this document must do so.  I can send some suggested text if
you would like - you would need to say something here, and also add
something to the IANA considerations section.

Likewise in section 3.4, there is no registry for UNDI types.
Referencing RFC4578 here is again the wrong thing to do - either there
needs to be an IANA registry for these types, or else the types need
to come from some other standard's body.

Section 3.4 specifies that the option is only sent by the client.
However, sections 3.3, 3.2 and 3.1 do not specify whether the option
is sent by the client or the server.  While of course it should be
obvious who sends these options, it would be better to say so
explicitly, as is done in section 3.4.  Also, it's actually not
completely clear to me that a server wouldn't send an architecture
type back to the client to indicate which architecture the bootfile
URL applies to, if in fact you allow the client to advertise that it
supports more than one architecture; if that's what you intended, you
need to say so explicitly.

In section 5, you refer to http like this:

   hypertext transfer protocol (HTTP, see [RFC2616]) for downloading.

I suggest that you instead do the reference like this:

   hypertext transfer protocol [RFC2616] for downloading.

It's understood that people should read document referenced if they
are not familiar with the protocol being mentioned.

Oops, I see you actually did define an IANA registry for the
architecture type.  That looks good - you should mention it in section
3.3.  :')

---

From: "Zimmer, Vincent" <[email-masked]>
Date: Fri, 20 Nov 2009 08:55:18 -0800

Great feedback.   Thanks Ted.

I would advocate having the last call now.   Then we can pick up any final input responsive to that last-call action and also roll-up below-listed updates together.

---

From: Thomas Huth <[email-masked]>
Date: Sat, 21 Nov 2009 15:11:15 +0100

"Zimmer, Vincent" <[email-masked]> wrote on 20/11/2009 17:55:18:
> I would advocate having the last call now.   Then we can pick up any
> final input responsive to that last-call action and also roll-up
> below-listed updates together.

I second that! Let's have the last call now, then merge all the final
feedback for a final update.

> architecture type to be specified further muddies the issue.

As far as I understand RFC4578, chapter 2.1, there can be more than one
architecture type:

 Octet "n" gives the number of octets containing "architecture types"
 (not including the code and len fields).  It MUST be an even number
 greater than zero.  Clients that support more than one architecture
 type MAY include a list of these types in their initial DHCP and PXE
 boot server packets.

IMHO this also makes perfectly sense. For example imagine a x86_64 computer
with an EFI compliant firmware. The EFI firmware then could handle "EFI
x86-64" executables, but also "EFI x86-32" in a 32-bit compatibility layer.
It even might have a BIOS legacy layer, so it could also still handle
"Intel x86PC" executables...

> to come from some other standard's body.

Vincent, since this option has been requested by you, maybe you could
comment on this?

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: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294

---

From: "Zimmer, Vincent" <[email-masked]>
Date: Sat, 21 Nov 2009 09:04:01 -0800

I think having a single architecture type is sufficient.   Although the UEFI specification allows for several architecture types/binding (ARM, x64, Itanium, IA32), most system boards support only a single one for booting the loader (e.g.,64-bit UEFI supports 64-bit OS loaders).   We also support an interpreted byte-code (EBC) in addition to the native architecture type, but EBC is for locally-loaded drivers in adaptor cards & is ignorable for the network load case.