Subject: RE: [dhcwg] dhc WG last call on "DHCP PrebooteXecutionEnvironment(PXE) Options"

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 1 Jun 2005 16:19:23 -0400

> I don't think the document presumes that 128-135 are PXE 
> options (and I
> think you recognize this later in your comments); in fact, section 3.4
> includes this text (where "these options" are options 128-135):

Yeah, but the document states:

   All compliant PXE clients MUST include a request for DHCP options 128
   through 135 in all DHCP and PXE packets.  The format and contents of

So, the point is that PXE clients will request these options. Thus, if
they are used for a different purpose, they may be requested by clients
that are not intending to use them for that purpose. Hence, I think we
must take steps to eliminate these options from the list from which IANA
can assign options from.

Also, what if option X (where X is one value from 128 to 135) is defined
as something that PXE might want to use a few years down the road, then
when X needs to be defined BOTH for PXE *AND* for that other purpose,
which is returned? Both can't be because then the data would be
concatenated by the rules of RFC 3396.

- Bernie 

> -----Original Message-----
> From: Ralph Droms (rdroms) 
> Sent: Wednesday, June 01, 2005 3:08 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; 'Ted Lemon'
> Subject: RE: [dhcwg] dhc WG last call on "DHCP 
> PrebooteXecutionEnvironment(PXE) Options"
> 
> Following up on comments from previous last call on this document.
> 
> - Ralph
> 
> On Thu, 2005-03-24 at 16:53 -0500, Bernie Volz wrote:
> > Ralph:
> > 
> > >Bernie - what do you mean by 'use something other than
> > >"Site Specific Options"'?  Do you mean the title for
> > >the section?
> > 
> > Correct, change the title of the section (and use of "site 
> specific" if used
> > anywhere else).
> 
> OK.
> 
> > >Also, options 128-125 aren't actually defined in this
> > >document; they are just listed as requested by the PXE
> > >client.
> > 
> > Correct, but it does say that a (PXE) client should request 
> them. And, what
> > if a PXE client sends this Parameter Request List to a server that
> > implements option 132 as something completley different 
> (not a PXE option)?
> > 
> > This document presumes that 128-135 are PXE options, which 
> may not be the
> > case today and certainly hasn't been done officially. But, 
> there's nothing
> > we can really do about that as implementations exist today 
> and this is
> > attempting to document existing usage.
> 
> I don't think the document presumes that 128-135 are PXE 
> options (and I
> think you recognize this later in your comments); in fact, section 3.4
> includes this text (where "these options" are options 128-135):
> 
>    The format and contents of
>    these options are NOT defined by the PXE specification.
> 
> > I guess a good question to ask is what changes would I 
> recommend post the
> > first RFC 3942 date, especially given that we're already 
> aware of conflicts
> > (PXE and Etherboot).
> > 
> > I would guess that we'll have IANA remove 128-135 for 
> possible assignment to
> > future options.
> > 
> > Perhaps adding:
> >    As options 128-135 are not officially assigned for PXE 
> use (previous to
> > November 2004
> >    they were considered site-specific options [RFC 3942]), 
> use of these
> > options may
> >    conflict with other uses of these options.
> > 
> > Feel free to improve the wording.
> 
> Yeah, I think since you wrote this response we heard 
> something about how
> options 128-135 have been used.  Do you have additional 
> information now
> about options 128-135?
> 
> > Later this year, we might be able to add "Because options 
> 128-135 are used
> > by PXE implementations and for other uses, such as 
> [Etherboot], they have no
> > official designation but will not be used for future 
> options assigned in
> > accordance with [RFC 2939]."
> 
> OK.
> 
> > - Bernie
> 
> - Ralph
> 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] 
> > > On Behalf Of Ralph Droms
> > > Sent: Thursday, March 24, 2005 4:08 PM
> > > To: Bernie Volz
> > > Cc: [email-masked]; 'Ted Lemon'
> > > Subject: RE: [dhcwg] dhc WG last call on "DHCP 
> > > PrebooteXecutionEnvironment (PXE) Options"
> > > 
> > > Bernie - what do you mean by 'use something other than 
> "Site Specific
> > > Options"'?  Do you mean the title for the section?
> > > 
> > > While there's no particular reason to publish this document 
> > > quickly, it is
> > > intended to be an Informational RFC, documenting existing 
> > > practice.  As
> > > such, I don't know if there is any value in postponing 
> > > publication until the
> > > RFC 3942 deadline in May.
> > > 
> > > Also, options 128-125 aren't actually defined in this 
> > > document; they are
> > > just listed as requested by the PXE client.
> > > 
> > > - Ralph
> > > 
> > > 
> > > At 03:38 PM 3/24/2005 -0500, Bernie Volz wrote:
> > > >Shouldn't section 3.4 use something other than "Site 
> > > Specific Options"?
> > > >Perhaps it should just be "Options Requested By PXE 
> > > Clients"? Though a note
> > > >about the possible conflict of these previously 
> site-specific options
> > > >(128-135) and conflicts with future work might be worth it too?
> > > >
> > > >3.4  Site Specific Options Being Requested By PXE Client
> > > >
> > > >    All compliant PXE clients MUST include a request for 
> > > DHCP options 128
> > > >    through 135 in all DHCP and PXE packets.  The format and 
> > > contents of
> > > >    these options are NOT defined by the PXE 
> specification.  These
> > > >    options MAY be present in the DHCP and PXE boot server 
> > > replies and
> > > >    are meant for use by the downloaded network 
> bootstrap programs.
> > > >    These options are NOT used by the PXE boot ROMs.
> > > >
> > > >
> > > >It may be good to hold this work up for a few more months 
> > > (until the RFC
> > > >3942 May deadline) as then we might have a better sense of 
> > > the possible
> > > >conflicts and whether 128-135 will be "reserved" for PXE. 
> > > Etherboot also
> > > >uses 128, 129, and 130 so we already have a conflict. It may 
> > > well be that
> > > >PXE and Etherboot are mutually exclusive, in which case the 
> > > presense of
> > > >option 93 and 94 can be used to determine whether options 
> > > 128, 129, and 130
> > > >are PXE or Etherboot?
> > > >
> > > >We'll have to exclude 128-135 from future IANA assignments 
> > > to new options.
> > > >
> > > >- Bernie
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > On Behalf Of Ralph Droms
> > > > > Sent: Thursday, March 24, 2005 10:52 AM
> > > > > To: Ted Lemon
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [dhcwg] dhc WG last call on "DHCP Preboot
> > > > > eXecutionEnvironment (PXE) Options"
> > > > >
> > > > > Informational.
> > > > >
> > > > > - Ralph
> > > > >
> > > > > At 08:49 AM 3/24/2005 -0700, Ted Lemon wrote:
> > > > > >Dumb question: is this a standards-track document or an
> > > > > informational
> > > > > >draft?   The reason I ask is that it consumes option 
> > > codes 128-135.
> > > > >
> > > > > _______________________________________________
> > > > > dhcwg mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/dhcwg
> > > > >
> > > >
> > > >_______________________________________________
> > > >dhcwg mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/dhcwg
> > > 
> > > _______________________________________________
> > > dhcwg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dhcwg
> > > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 01 Jun 2005 16:24:01 -0400

Bernie - I wasn't clear; the document assumes that options 128-135 are
defined, just not as "PXE options".  So, yes, we have to record options
128-135 as "already in use" and negotiate their definition through the
mechanism in RFC 3942.

- Ralph