RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

[I assume IANA does not need the noise, so removed from thread.]

Thanks for the feedback. 

Just to be clear, what we had discussed was to only pass back options in 
the site range based on having received option 60 containing the vendor 
info.  Interpretation is, for a given site, here are the options for this 
application.  Agree this is not preferred, just another thing we had 
looked at.  It appear you folks would be stronger than "not preferred". 

Any feedback on using option options 60 / 43?  It is a bit flawed for 
multiple vendors in the same exchange, I know.  But is it well supported 
in the field today is the real question.

Issue with using options 124/125 exchanges remains it is not out there 
very widely now, and deployment always takes time ... so we have a gap. 
Administrative pain to construct the data, likely for several different 
flavors of server, is just that ... a pain.  But a pain we'd rather avoid 
or at least minimize.  Forcing upgrades to the DHCP environment in the 
field is also a pain, and a cost that many will not be happy to suck up if 
there are other means.

   > ... One thing that isn't as clear as it could be in RFC 3925 is how a client 
communication interested in a certain vendor option set.  
Hmmm, perhaps I need to re-read.  My understanding was option 124 is used 
to pass a vendor unique ID (or several), along with any specific data 
(opaque to the DHCP process), and the server returns info in 125 against 
the same vendor ID.  Why would option 60 be used as a trigger at all. 

-- Peter

"Bernie Volz (volz)" <volz@cisco.com>
20.05.05 10:28

        To:     "Kostur, Andre" <akostur@incognito.com>, <peter_blatherwick@mitel.com>
        cc:     <dhcwg@ietf.org>, <iana@iana.org>
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

Yup, using the site specific option range is really a bad idea (whatever 
that range is).

You can expect servers to start supporting RFC 3925 ... and the more 
people that want to start using this, the more likely the server vendors 
will start supporting it. Even if a server doesn't explicitly support it, 
most of them allow you to enter an arbitrary option number and data to 
return -- while having to construct the option data by hand is very 
tricky, at least it provides a means for supporting the option on older 
servers. (Perhaps it requires a tool where you configure the vendor 
specific data and it spits out some ASCII binary form that is usable to be 
cut and pasted into most server's configurations.)

One thing that isn't as clear as it could be in RFC 3925 is how a client 
communication interested in a certain vendor option set. Part of the 
reason for this is that it really is up to each vendor to determine that. 
But that does make it more difficult for server vendors to provide 
appropriate triggers. Likely most servers will require you to classify the 
incoming request in some way and then the options configured for that 
class are returned. A common trigger for this might be option 60.

- Bernie

From: Kostur, Andre [mailto:akostur@incognito.com] 
Sent: Friday, May 20, 2005 10:16 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

Re: Options 224+ 
Hold on... from the RFC: 
   Some vendors have made use of site-specific option codes that violate 
   the intent of the site-specific options, as the options are used to 
   configure features of their products and thus are specific to many 
   sites.  This usage could potentially cause problems if a site that 
   has been using the same site-specific option codes for other purposes 
   deploys products from one of the vendors, or if two vendors pick the 
   same site-specific options. 

If you start using options 224+, you're just going to end up in the same 
boat that we're in now.  Those options are for site-specific options.  If 
your phones are going to be using those options (and, BTW, we have some of 
these phones....) then it's no longer a site-specific option!
-----Original Message----- 
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] 
Sent: Friday, May 20, 2005 7:05 AM 
To: Bernie Volz (volz) 
Thanks Bernie, 
Will generate the I-D. 
No, nothing to do with PXE.  We were aware of that one, and believe there 
are other conflicting usages as well. 
We have looked at RFC 3925 (options 124 / 125) of course, and I certainly 
like it -- very clean.  However we do have a strong concern that it may 
take some time before it becomes well deployed, since it is still quite 
new (October 04).   Instead (or possibly supplementally) we are looking at 
using options 60 / 43 to exchange vendor info, or option 60 alone to 
identify the vendor with retuned info in other options in the site range 
(224 and above) scoped based on the vendor in the request. 
Is there a BCP or anything to give good advice on "best" approaches? Since 
there are no doubt about a zillion other vendors in the same position, it 
would be good if we all did at least roughly the same thing ;-) 