Re: server-to-server protocols
Ted Lemon <mellon@hoffman.vix.com> Wed, 16 April 1997 09:08 UTC
Received: from cnri by ietf.org id aa11394; 16 Apr 97 5:08 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa06375; 16 Apr 97 5:08 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA22919; Wed, 16 Apr 1997 05:00:26 -0400
Date: Wed, 16 Apr 1997 05:00:26 -0400
Message-Id: <199704160844.BAA00564@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
> I guess I don't see where implementing a new, untested protocol can be > significantly better than using something that's been in production use > for years, has been implemented by most of the major vendors (at least > in other products), and has extensive existing libraries that can be > reused. SNMP doesn't *do* database synchronization. So the fact that it's been around for years and lots of people implement it doesn't help us at all. The hard part of this protocol isn't whacking bits around - it's synchronizing the database in such a way that DHCP service can continue in the presence of network partitions. SNMP has *nothing* to do with this. So even if we used it as a transport, we'd still essentially be implementing a new, untested protocol. > SNMP certainly isn't simple, but it's also not very complex, > particularly when the reference implementations and libraries are > already available. Again, just because something is available doesn't mean it's good. SNMP is a hairball. I accept that we have to use it for network management, but that's about as much as I'm willing to concede. > I just don't see why SNMP isn't a reasonable answer to the problem. Think of SNMP as SQL, and the Interserver Protocol as a distributed database backend, if that helps. Sure, you can implement pieces of the distributed database back end in SQL if you want, but that doesn't mean you should. _MelloN_
- server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Robert G. Cole
- Re: server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Kim Kinnear
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Sean Goller
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Erikas Aras Napjus
- Re: server-to-server protocols Erikas Aras Napjus
- Re: server-to-server protocols Mark Sirota
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Kim Kinnear
- Re: server-to-server protocols Kim Kinnear