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

Correct.

If you're IP phone is doing DHCP, then it would be up to it to
intreprete this data.

If you're using Windows or Linux, it isn't necessarily clear how you
would get this data though it is always possible that there is some
place that these clients store "unknown" options and and you could get
access to the data in your application.

- Bernie

________________________________

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

	... but if the returned data is keyed by vendor unique id, no
matter how triggered, then it is up to the vendor app at the client to
sort out how to interpret it. No?   
	-- Peter 

	"Bernie Volz (volz)" <volz@cisco.com> 

20.05.05 11:55 

        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

	Ah, that's sort of what I thought, but it turns out that there
isn't anything in the spec that says that. And, in speaking to Josh,
there's valid reasons not to require this at all! A server might be
configured to send these options always or for a certain "class" of
clients (however that class is determined). 

	- Bernie 

________________________________

	From: Kostur, Andre [mailto:akostur@incognito.com] 
	Sent: Friday, May 20, 2005 11:41 AM
	To: Bernie Volz (volz); Kostur, Andre;
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

	Isn't that the point of 124/125?  The client sends in 124 with
all of the vendor IDs it's interested in/supports, and a 3925 aware
server would key off of that (instead of 60) to choose what to fill 125
with? 
	-----Original Message-----
	From: Bernie Volz (volz) [mailto:volz@cisco.com]
	Sent: Friday, May 20, 2005 7:29 AM 

	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. 