Re: server-to-server protocols
Ted Lemon <mellon@hoffman.vix.com> Wed, 16 April 1997 01:30 UTC
Received: from cnri by ietf.org id aa22916; 15 Apr 97 21:30 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25163; 15 Apr 97 21:30 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA04502; Tue, 15 Apr 1997 21:25:22 -0400
Date: Tue, 15 Apr 1997 21:25:22 -0400
Message-Id: <199704160056.RAA00500@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
> 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 working. 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. _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