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

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

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]] 
	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