Subject: Problematic revisions in RFC 2515 (ATM-MIB rev. 9810191200Z)

From: "C. M. Heard" <[email-masked]>
Date: Tue, 8 Jul 2003 14:46:12 -0700 (PDT)

Hello everyone,

It has recently came to my attention that certain revisions in RFC
2515 make the version of the ATM-MIB that it contains not backward
compatible with the version that was published in RFC 1695.  The
specific revisions that cause the problems are the removal of the
following TEXTUAL-CONVENTION and OBJECT-IDENTITY definitions from
the ATM-MIB in order to put them into the ATM-TC-MIB (RFC 2515):

rfc1695.mi2:58 [1] {type-removed} type `IfIndex' has been deleted
rfc1695.mi2:70 [1] {type-removed} type `AtmTrafficDescrParamIndex'
has been deleted
rfc1695.mi2:77 [1] {node-removed} node `atmTrafficDescriptorTypes'
has been deleted
rfc1695.mi2:85 [1] {node-removed} node `atmNoTrafficDescriptor' has
been deleted
rfc1695.mi2:94 [1] {node-removed} node `atmNoClpNoScr' has been
deleted
rfc1695.mi2:110 [1] {node-removed} node `atmClpNoTaggingNoScr' has
been deleted
rfc1695.mi2:125 [1] {node-removed} node `atmClpTaggingNoScr' has
been deleted
rfc1695.mi2:141 [1] {node-removed} node `atmNoClpScr' has been
deleted
rfc1695.mi2:157 [1] {node-removed} node `atmClpNoTaggingScr' has
been deleted
rfc1695.mi2:172 [1] {node-removed} node `atmClpTaggingScr' has been
deleted

The problem is that many of the older ATM Forum MIB modules import
these items -- some of them, anyway -- from the ATM-MIB.  Now, one
of our rules is that it should always be possible to freely
substitute a new version of a MIB module for an old one without
changing the semantics of an existing implementation -- including
the ability of an existing MIB module to compile(*).  This
unfortunately is not possible for the ATM Forum MIB modules that
import any of the above items from the ATM-MIB rather than the
ATM-TC-MIB.  To give one example, the PNNI-MIB (a URL for which is
ftp://ftp.atmforum.com/pub/approved-specs/af-cs-0102.000.mib)
imports AtmTrafficDescrParamIndex from ATM-MIB.  smilint will
compile it correctly (provided that Unsigned32 is properly imported,
not defined locally, and that level 5 and 6 warning and info
messages are suppressed) if the version of the ATM-MIB in the MIB
module library is the RFC 1695 version, but not if it is the RFC
2515 version.  See the attached smilint output for details.

The question arises what, if anything, should be done about this.

One way out would be to let the ATM Forum know, through a liason or
perhaps a less formal mechanism, that some of their older MIB
modules need to be revised to import from the ATM-TC-MIB rather than
the ATM-MIB.  This way is probably the easiest, and in the long term
it probably should be done anyway.

Another way out would be to put the removed TC definitions back into
the ATM-MIB with a STATUS value of deprecated or obsolete and to put
the removed OBJECT-IDENTITY definitions back in but as object
identifier value assignments instead of OBJECT-IDENTITY definitions
(this avoids an illegal duplicate registration).  One would then
also import the "real" definitions from ATM-TC-MIB into ATM-MIB and
use the dot notation (e.g., ATM-TC-MIB.AtmTrafficDescrParamIndex) to
disambiguate.  This is formally the correct solution, and there is
some precedent for it: the IF-MIB has a deprecated definition of
OwnerString for a similar reason.  However, I'm reluctant to
recommend this, because the dot notation seems to be seldom used and
some MIB compilers might choke on it.  Thus, that cure might be
worse than the disease for some users.

In closing, let me hasten to say "mea culpa" because I was a WG
member when the AToM MIB WG issued RFCs 2514 and 2515, and I could
have caught this problem then had I paid proper attention.  Sorry
about that.

Mike Heard

----
(*) RFC 2578 Section 10 says:

   Also note that obsolete definitions must not be removed from MIB
   modules since their descriptors may still be referenced by other
   information modules, and the OBJECT IDENTIFIERs used to name them
   must never be re-assigned.

See also <draft-ietf-ops-mib-review-guidelines-01.txt> Section 4.9,
specifically the discussion of "compilation compatibility".

Subject: Re: smilint -l 4 -i namelength-32 -i index-element-no-range PNNI-MIB
From: [email-masked]
To: "C. M. Heard" <[email-masked]>
Date: Tue, 8 Jul 2003 22:27:35 +0200

This is an automatically generated mail message in response to a mail message
you (or someone else who used your address) sent to <[email-masked]>.
If you want to learn more about this mail service, send a mail message with
the "Subject: help" to <[email-masked]>.

This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)
has been processed to get the following results:
smilint -m -s -l 4 -i namelength-32 -i index-element-no-range PNNI-MIB

PNNI-MIB:13: [2] {} identifier `AtmTrafficDescrParamIndex' cannot be imported from module `ATM-MIB'
PNNI-MIB:1245: [2] {basetype-unknown} type `AtmTrafficDescrParamIndex' of node `pnniNodeSvccTrafficDescriptorIndex' does not resolve to a known base type
PNNI-MIB:1849: [2] {basetype-unknown} type `AtmTrafficDescrParamIndex' of node `pnniIfRccTrafficDescrIndex' does not resolve to a known base type
PNNI-MIB:1185: [2] {} unknown type `AtmTrafficDescrParamIndex'