Re: Community strings/IP Addr

gallagher@quiver.enet.dec.com Tue, 21 July 1992 15:26 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA09885; Tue, 21 Jul 92 11:26:55 -0400
Received: from inet-gw-2.pa.dec.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA09880; Tue, 21 Jul 92 11:26:51 -0400
Received: by inet-gw-2.pa.dec.com; id AA27856; Tue, 21 Jul 92 08:26:47 -0700
Received: by us1rmc.bb.dec.com; id AA25267; Tue, 21 Jul 92 11:21:16 -0400
From: gallagher@quiver.enet.dec.com
Message-Id: <9207211521.AA25267@us1rmc.bb.dec.com>
Received: from quiver.enet; by us1rmc.enet; Tue, 21 Jul 92 11:25:16 EDT
Date: Tue, 21 Jul 92 11:25:16 EDT
To: chassismib@cs.utk.edu
Cc: gallagher@quiver.enet.dec.com
Apparently-To: chassismib@cs.utk.edu
Subject: Re: Community strings/IP Addr


>Since we are moving in the direction of party based SNMP and there will
>be a limited number of implementations of the MIB using community
>based SNMP.  I vote to remove the community string and the IP address
>from the chasEntityTable as Keith suggested.
>
>Any complaints/ comments from anybody else?
>

I agree that Parties are the future.  We can't be sure just how far out
in the future though.  Supporting both the Community/IP and Party 
approaches provides a good migration path.

I vote for retaining the Community/IP approach and easing into Party
based S[N]MP.
							-Shawn