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.