Re: server-to-server protocols

Ted Lemon <> Wed, 16 April 1997 01:30 UTC

Received: from cnri by id aa22916; 15 Apr 97 21:30 EDT
Received: from by CNRI.Reston.VA.US id aa25163; 15 Apr 97 21:30 EDT
Received: from by; (5.65v3.2/ id AA04502; Tue, 15 Apr 1997 21:25:22 -0400
Date: Tue, 15 Apr 1997 21:25:22 -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

> We (as a working group) are already working on providing SNMP
> manageability for DHCP servers, so why not reduce our overall work and
> use SNMP for synchronization? SNMP quite clearly is designed as a
> repository of organized information, and is an existing standard that
> many vendors have already implemented. Both push and pull models can be
> implemented, and by using SNMP informs, is also reliable. Since there
> also seemed to be a consensus that client binding information should be
> accessible via SNMP, we're killing two birds with one protocol. :)

I really don't like this idea.   Bad enough that we need to be able to
respond to SNMP queries - why should we have to be able to generate
them as well?   We need to provide SNMP query support because people's
network management tools use SNMP.   AFAIK, that's the only reason.
A DHCP vendor that doesn't care about interoperability with SNMP tools
shouldn't have to implement SNMP just to get the Interserver Protocol

Reuse of technology is a good thing, as long as we don't make the
mistake of trying to reuse technology just for the sake of reusing it.
We should not reuse it just because it's possible to - we should reuse
it because it is the right thing to do.  In this case, as far as I can
see all that using SNMP as a transport for the Interserver Protocol
would do would be to needlessly complicate the Interserver Protocol.