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

From: Kaj Tesink <[email-masked]>
Date: Tue, 08 Jul 2003 18:23:26 -0400

mike, you're right but recall 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
- several folks who were present at the time were also active
   participants in the ATMF

i'd be reluctant to do reverse engineering on this; after all,
2515 is alreadfy 4 yrs old; it may do more harm than good. also no request 
has been made
by atmf folks to fix this. however, i can see that this can be rather
annoying so recommending to the atmf to import from ATM TC would be
prudent.

it would also be a good idea to sollicit further implementation feedback
on 2514/2515; kam had made such request on 4/7/03 but i havent noticed 
feedback yet.

kaj

At 02:46 PM 7/8/2003 -0700, C. M. Heard wrote:
>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".
>Return-Path: <[email-masked]>
>Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13])
>         by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h68KRdE28083
>         for <[email-masked]>; Tue, 8 Jul 2003 13:27:39 -0700
>Received: from psmtp.com (exprod6mx8.postini.com [12.158.35.148])
>         by postman.bayarea.net (8.12.8p1/8.12.8) with SMTP id h68KRcKr041503
>         for <[email-masked]>; Tue, 8 Jul 2003 13:27:38 -0700 (PDT)
>Received: from source ([207.106.49.21]) by exprod6mx8.postini.com 
>([12.158.35.251]) with SMTP;
>         Tue, 08 Jul 2003 13:27:38 PDT
>Received: from agitator.ibr.cs.tu-bs.de (ns.ibr.cs.tu-bs.de [134.169.34.18])
>         by wink.pobox.com (Postfix) with ESMTP id 9BCB9FE76
>         for <[email-masked]>; Tue,  8 Jul 2003 16:27:36 -0400 (EDT)
>Received: from agitator.ibr.cs.tu-bs.de (localhost [127.0.0.1])
>         by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP 
> id h68KRZKb012167
>         (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
>         Tue, 8 Jul 2003 22:27:35 +0200
>Received: (from mail@localhost)
>         by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id 
> h68KRZaO012166;
>         Tue, 8 Jul 2003 22:27:35 +0200
>Date: Tue, 8 Jul 2003 22:27:35 +0200
>Message-Id: <[email-masked]>
>X-Authentication-Warning: agitator.ibr.cs.tu-bs.de: mail set sender to 
>'<>' using -f
>From: [email-masked]
>Reply-To: [email-masked]
>Errors-To: [email-masked]
>To: "C. M. Heard" <[email-masked]>
>In-Reply-To: <[email-masked]>
>Subject: Re: smilint -l 4 -i namelength-32 -i index-element-no-range PNNI-MIB
>X-IBRFilter-SpamReport: -3.4 () IN_REP_TO,NO_REAL_NAME,X_AUTH_WARNING
>X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang)
>
>
>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'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

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

On Tue, 8 Jul 2003, Kaj Tesink wrote [re-ordered]:
> 2515 is [already] 4 yrs old; it may do more harm than good.
>
> also no request has been made by atmf folks to fix this.
> however, i can see that this can be rather annoying so
> recommending to the atmf to import from ATM TC would be prudent.

I think that you are right.  But having said that ...

> recall that at the time when this was done

Yes, but looking retrospectively (with 20/20 hindsight) it's not so
clear now that splitting off the TCs and OBJECT-IDENTITY definitions
was actually such a good idea.  For one thing, it does not really
increase the flexibility of using those definitions;  it just
changes the MIB module from where they are imported.  Also, it's
increased the difficulty of getting the ATM-MIB (RFC 2515) to Draft
Standard: it now depends normatively on the ATM-TC-MIB (RFC 2514),
and the latter contains several TCs and OBJECT-IDENTITY definitions
that are noted used in the ATM-MIB, although they are used in the
supplemental MIB.  Since the latter is not yet published (it has
just recently cleared IETF last call), we will have to look
elsewhere to find implmentations of all the stuff in RFC 2514.  
That particular difficulty would not have arisen if we had housed
the TCs and OBJECT-IDENTITY definitions in the first MIB module that
had a need for them.

> it would also be a good idea to sollicit further implementation
> feedback on 2514/2515; kam had made such request on 4/7/03 but i
> havent noticed feedback yet.

Agreed.  I did notice that some of the newer ATM Forum MIB modules
do import from the ATM-TC-MIB;  implementations of those modules
could be used to support the advancement of RFC 2514.  The ATM Forum
MIB modules reside in ftp://ftp.atmforum.com/pub/approved-specs/ and
have "mib" in the file name (usually, but not always, as the suffix).

Mike