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

["C. M. Heard" <heard@pobox.com>]

Mreview folks,

I'm forwarding a message that I sent yesterday to the AToM MIB list
because I think it might be of interest here.  In the past we've
discussed and I think come to consensus on the evils of reorganizing
MIB modules in the name of "tidying up".  Unfortunately, I think
that factoring out the TCs and OBJECT-IDENTITY definitions from the
ATM-MIB that was published in RFC 1695 into a separate ATM-TC-MIB
(RFC 2514) and removing them from the ATM-MIB itself (ATM-MIB) is
another example of "tidying up" causing problems.

In his reply to the following message, Kaj Tesink pointed out that
at the time when this was done "there was full consensus to move
certain things to the ATM TC MIB; one of the reasons of doing so was
the flexibility to use the TCs e.g., in ATMF work".  In fact housing
TCs and OIs in a separate MIB module does not do anything for
flexibility of use, it just changes the client's IMPORTS clause; the
real reason to do this would be to make the MIB modules easier to
maintain.  And on the face of it the ease of maintenance argument
did seem to have some validity ... especially since the ATM-TC-MIB
consolidated TCs and OIs used in several other MIB modules (notably
the supplemental ATM2-MIB (see draft-ietf-atommib-atm2-19.txt) as
well as several ATM Forum MIB modules).

However, the reorganization has actually made maintenance more
difficult in one respect now that it has come time for the AToM MIB
WG to advance RFC 2515 to Draft Standard.  RFC 2515 (ATM-MIB)  
depends normatively on RFC 2514 (the ATM-TC-MIB), so the latter
needs to be advanced first, but unfortunately it contains many TCs
and OIs not used in RFC 2515.  So we have to look elsewhere for
adequate implementation experience with RFC 2514.  This is a general
problem with TC MIB modules that have so much stuff defined in them
that no one MIB module uses everything.

For my money, the AToM MIB WG would have been better off leaving the
TCs and OIs needed by the ATM-MIB in that module.  The new ones needed
only by ATM2-MIB could have been put there, or split out separately as
dictated by convenience (the long time-to-approval for ATM2-MIB does
argue for the latter).  But what we actually did was not good.  It
broke backward compatibility and created unnecessary dependencies
that make it more difficult to advance stuff on the standards track.

Of course, all this is hindsight, and I am as much to blame as
anyone, but I'd like to see us avoid this in the future.  So I'd
like to suggest that future MIB doctor reviews should discourage
this sort of thing.

Thanks for listening,

Mike

---------- Forwarded message ----------
Date: Tue, 8 Jul 2003 14:46:12 -0700 (PDT)
From: C. M. Heard <heard@pobox.com>
To: AToM MIB Working Group <atommib@research.telcordia.com>
Subject: Problematic revisions in RFC 2515 (ATM-MIB rev. 9810191200Z)
Resent-Date: Tue, 8 Jul 2003 17:46:19 -0400 (EDT)
Resent-From: atommib@research.telcordia.com

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".