Re: server-to-server protocols

Ted Lemon <> Wed, 16 April 1997 09:08 UTC

Received: from cnri by id aa11394; 16 Apr 97 5:08 EDT
Received: from by CNRI.Reston.VA.US id aa06375; 16 Apr 97 5:08 EDT
Received: from by; (5.65v3.2/ id AA22919; Wed, 16 Apr 1997 05:00:26 -0400
Date: Wed, 16 Apr 1997 05:00:26 -0400
Message-Id: <>
Precedence: bulk
From: Ted Lemon <>
To: Multiple recipients of list <>
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.