Re: server-to-server protocols

Ted Lemon <mellon@hoffman.vix.com> Tue, 15 April 1997 22:59 UTC

Received: from cnri by ietf.org id aa13746; 15 Apr 97 18:59 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa22526; 15 Apr 97 18:58 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA11253; Tue, 15 Apr 1997 18:52:35 -0400
Date: Tue, 15 Apr 1997 18:52:35 -0400
Message-Id: <199704152227.PAA00617@andare.fugue.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Ted Lemon <mellon@hoffman.vix.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: server-to-server protocols
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

> Here I'm looking for guidance.  I think that if a different server offers to 
> rebind the client, it is entirely reasonable to assume that the offer may be 
> slightly different, simply because the original and rebinding servers may, 
> of practical necessity, have slightly different sets of default data and 
> server-specific configuration.  And so, while we wouldn't guarantee an 
> identical binding to a client, we would be proposing a highly similar one. 
>  I think that this may not only be a reasonable approach, it may be the only 
> one that will interoperate.

You hit the nail right on the head.  I agree with this completely.
Having talked to lots of different people at Connectathon about server
design issues, I can say with great conviction that we don't all have
similar server designs, and the way we think about our databases is
subtlely but significantly different in enough cases that I think
trying to synchronize anything beyond actual lease addresses would be
a really bad idea, at least in practical terms.

			       _MelloN_