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

["Bernie Volz \(volz\)" <[e-mail]>]

Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options.
They are not for vendor use.
 
I'm not saying that option 60 is the trigger for 125, just that it could
be. As could any number of other things - such as the mac address or
client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they aren't general purpose
clients? If that is the case, using Option 60 is certainly possible and
should not cause any issues since you're doing what that option is
intended for - identifying the vendor of the client making the request.
 
- Bernie


________________________________

	From: [e-mail]
[mailto:[e-mail]] 
	Sent: Friday, May 20, 2005 12:41 PM
	To: Bernie Volz (volz)
	Cc: Kostur, Andre; [e-mail]
	Subject: 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)" <[e-mail]> 

20.05.05 10:28 


        
        To:        "Kostur, Andre" <[e-mail]>,
<[e-mail]> 
        cc:        <[e-mail]>, <[e-mail]> 
        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:[e-mail]] 
	Sent: Friday, May 20, 2005 10:16 AM
	To: '[e-mail]'; Bernie Volz (volz)
	Cc: [e-mail]; [e-mail]
	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: [e-mail]
[mailto:[e-mail] <mailto:[e-mail]>
] 
	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 ;-) 

	

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