RE: [dhcwg] Parameter list from multiple servers?

["Kevin A. Noll" <[e-mail]>]

I suppose I could have guessed, but didn't realize that this was 
a subject of such notoriety.

Regarding the way a client chooses an OFFER, I completely agree with 
you, Barr. I was not suggesting a method/criteria by which a client 
SHOULD choose between offers, but offering it as an example of how 
one *might* choose given the specific scenario I was laying out.

I agree, we should not attempt to specify the methods/criteria by 
which a client chooses between multiple OFFERs. As you suggest, that 
would be difficult at best, and would unnecessarily limit the client 
implementation.


--kan--


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Richard Barr Hibbs
> Sent: Tuesday, 25 May, 2004 11:08 AM
> To: Dhcwg
> Subject: RE: [dhcwg] Parameter list from multiple servers?
> 
> 
> 
> this is one of our famous (infamous?) "out-of-band" configuration
> suggestions....  obviously, DHCP servers provisioned by different
> authorities but serving the same client population might not be able to
> comply with this behavior.
> 
> I take a small exception to one thing you said:  the RFC implies that a
> client selects from multiple offers based on some unspecified 
> criteria, with
> few guidelines as to what the criteria might be, or how they are
> established.  We've seen clients that (1) always selected the first offer
> received, (2) only selected offers that included all options 
> requested, and
> (3) refused to accept offers differing from the immediately prior lease
> accepted.  My own opinion is that attempting to define "best" choice of
> competing offers in the RFC would be both a thankless task, and 
> unlikely to
> be successful.
> 
> --Barr
> 
> 
> 
> -----Original Message-----
> From: Kevin A. Noll
> Sent: Monday, 24 May, 2004 15:45
> 
> Section 4.3.1 of RFC2131 states (from the paragraph just below
> Table 3):
> 
> "It is important for all DHCP servers to return the same parameters
> (with the possible exception of a newly allocated network address)
> to ensure predictable client behavior regardless of which server the
> client selects."
> 
> I understand the intent of the statement to assure that clients don't
> get confused or what not. I would want to assume that it is referring
> to servers that are "cooperating" (this is not stated) to provide
> parameters to a specific client (or set of clients).
> 
> However, it seems to me that it could be clarified a bit, since it is
> entirely possible (and common practice in my experience) that different
> servers can be configured to service different clients (or sets/types of
> clients) on the same network/segment.
> 
> In the purest protocol sense, the only way for a client to select among
> them is based on the options being returned. In other words, one server
> returns a set of options (set A) and another server returns a set of
> options (set B) in the DHCPOFFER. The client receives both and compares
> set A and B to find that one (A for example) contains the options that
> it requires and the other (B) does not, and therefore chooses the most
> preferred DHCPOFFER.
> 
> In the practical world, the servers should (and typically are)
> configured to only respond to specific sets of clients and remain silent
> when receiving messages from clients not matching the set the server is
> configured to service.
> 
> Perhaps the paragraph needs a small alteration to clarify this? Perhaps
> Barr can include it in his next "implementation" draft?
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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