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

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

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:[e-mail]] 
	Sent: Friday, May 20, 2005 11:41 AM
	To: Bernie Volz (volz); Kostur, Andre;
[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
	
	
	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:[e-mail]]
		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.
		 

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