RE: Guidelines Document and Optional Groups

["Sharon Chisholm" <schishol@nortelnetworks.com>]

hi

Just to follow up on this portion of the thread in conjunction with the
review of another document ...

It is acceptable/desirable to not include a deprecated OBJECT-GROUP in the
MODULE-COMPLIANCE statement? It sounds like we are in agreement on the
creation of these OBJECT-GROUPS to hold the deprecated objects.

Sharon

-----Original Message-----
From: C. M. Heard [mailto:heard@pobox.com]
Sent: Friday, May 30, 2003 5:38 AM
To: Mreview (E-mail)
Subject: Re: Guidelines Document and Optional Groups

<clip>

> I understand that a module might have deprecated or obsolete
> items, and one probably doesn't want them in the current
> module compliance specification(s). But at some time, those
> objects and/or notifications had to be in a compliance.
> 
> So, would you explain what is going on.

That's generally true for modules that started out in life as SMIv2
modules.  But some of our more important MIB modules started out as
SMIv1 MIB modules, which did not have compliance statements, and
were later converted to SMIv2.  Many if not most retired a number of
objects at the time of the conversion process.  It would have been
useless make-work to write compliance statements covering the
obsolete requirements for the original version of the MIB module,
and the new compliance statements had no need for the retired
objects, so the groups containing them were simply left
unreferenced.  See snmpObsoleteGroup in the SNMPv2-MIB (RFC 3418)
and ifOldObjectsGroup in the IF-MIB (RFC 2863 ... although in
practice I think the ifOldObjectsGroup should have been mandatory
... Mike McFaden can tell you why).

//cmh