Subject: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

From: Thomas Huth <[email-masked]>
Date: Sat, 19 Dec 2009 22:15:06 +0100

Ted,

   to push our netboot draft further, I spent some time today and
   incorporated your feedback into the text.
   I think all open issues are now closed, so could you do another last
   call for it now?

   Thanks!

Ted Lemon <[email-masked]> wrote on 20/11/2009 06:32:47:
>
> 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.  :')

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       
                                    Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294