Re: clarifications of SNMPv2 related RFCs.

Keith McCloghrie <kzm@cisco.com> Fri, 31 January 1997 12:56 UTC

Received: from cnri by ietf.org id aa12419; 31 Jan 97 7:56 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa08237; 31 Jan 97 7:56 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25620 for snmpv2-outgoing; Fri, 31 Jan 1997 07:46:46 -0500 (EST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <199701310737.XAA02768@foxhound.cisco.com>
Subject: Re: clarifications of SNMPv2 related RFCs.
To: snmpv2@tis.com
Date: Thu, 30 Jan 1997 23:37:43 -0800
In-Reply-To: <199701302231.RAA21343@portal.ex.tis.com> from "owner-snmpv2@ex.tis.com" at Jan 30, 97 05:31:07 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-snmpv2@ex.tis.com
Precedence: bulk

> > Dave Perkins reacted to a discussion on OwnerString in the if-mib and
> > disman WG mailing lists about issues w.r.t. it being allowed to do
> > new TC as a efinement of an existing TC .
> > ...
> ...
> 
> Refinement of TCs would seem to be a reasonable and useful thing.
> It's not hard to support refinement of TC syntax in a compiler.  (In my
> experience, enforcing the prohibition is more complex than supporting
> refinement.)  RFC 1902 suggest that it is possible, a number of MIBs do
> it, but RFC 1903 clause 3.5 doesn't support it.
 
I suggest we need to be careful about creating too many levels of
nesting of dependence, i.e., one MIB dependent on another, which is in
turn dependent on another, etc.  MIBs get obsoleted; dependence on
something which is obsolete is not good.  Abiding by RFC 1903 clause
3.5 doesn't overcome the problem, but having TCs defined as
refinements of other TCs makes the problem worse.

Keith.