Paul A Vixie: Re: Sean Goller: Re: server-to-server protocols

Ted Lemon <mellon@hoffman.vix.com> Wed, 16 April 1997 19:46 UTC

Date: Wed, 16 Apr 1997 15:37:33 -0400
Message-Id: <199704161900.MAA01058@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: Paul A Vixie: Re: Sean Goller: Re: server-to-server protocols

I asked Paul Vixie to weigh in on the subject of using SNMP as a
transport for the Interserver Protocol, because he's actually used it
rather than just having looked at the spec.   I've included his
comments below.

------- Forwarded Message

To: Ted Lemon <mellon@hoffman.vix.com>
cc: mlovell@vix.com
Subject: Re: Sean Goller: Re: server-to-server protocols 
In-reply-to: Your message of "Tue, 15 Apr 1997 17:59:31 PDT."
             <199704160059.RAA00509@andare.fugue.com> 
Date: Wed, 16 Apr 1997 10:02:10 -0700
From: Paul A Vixie <paul@vix.com>

SNMP is a hierarchical index to per-node dynamic data.  As such, if you could
express DHCP's server state as a MIB that was useful for both GET and PUT, and
SNMP's security had been advanced to the point where PUT was reasonable, and
if there was a standard SMUX-like rendezvous standard so that multible daemons
could all answer for their own MIBs even though only one of them could bind()
to UDP port 161, this would be an acceptable approach.

However, "acceptable" doesn't mean "good" in this case.  Since DHCP is itself
a protocol, and since server-to-server is more easily expressable inside the
protocol you're already supporting, there is no advantage to implementors in
using yet another protocol (assuming that we figured out the rendezvous issues)
for DHCP management.  OK, forget about implementors -- is there any advantage
for network managers, or end users?  Again I'd say "no."  Network managers
using HP OpenView or SunNetManager or whatever are not going to be setting any
DHCP management variables -- the most they would do would be to look at them,
and since they are (you say) synchronization related they will not be usable
in raw form to anyone except debugging implementors.

SNMP has become a dumping ground for things noone else wants to bother with.
I think SNMP's strengths would be wasted on DHCP server-to-server management;
it solves no problems which don't have easier solutions elsewhere (for both
implementors and users) and it adds design cost.

You can fwd this note as you see fit.

------- End of Forwarded Message

Paul A Vixie: Re: Sean Goller: Re: server-to-serv… Ted Lemon