Re: server-to-server protocols
Erikas Aras Napjus <erikas+@cmu.edu> Wed, 16 April 1997 02:09 UTC
Received: from cnri by ietf.org id aa24131; 15 Apr 97 22:09 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25802; 15 Apr 97 22:09 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA18168; Tue, 15 Apr 1997 22:03:45 -0400
Date: Tue, 15 Apr 1997 22:03:45 -0400
Message-Id: <cnJ36JW00UM1FRoTdg@andrew.cmu.edu>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Erikas Aras Napjus <erikas+@cmu.edu>
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
> 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. 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. (For CMU's DHCP server, we stole most of the SNMP code from the MBONE SNMP agent, for example.) SNMP certainly isn't simple, but it's also not very complex, particularly when the reference implementations and libraries are already available. With that said, I'm not going to beat a dying horse over this, either. If we want to develop something from scratch or use a protocol that's under development in another area, it's not unreasonable. I just don't see why SNMP isn't a reasonable answer to the problem. --- Erikas
- 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