SMIv2 Errata Page

This Web page is an unofficial collection of issues that have been identified with the current SMIv2 specification.

The meaning of the status values is as follows:

submitted means that the issue was submitted but no decision has been made whether the problem is indeed a problem.
accepted means that the problem was accepted to be an SMIv2 problem. Note that this applies only to the problem description and the solution might be completely different than the proposed solution.
rejected means that the problem was reject as not being an SMIv2 problem.

Please refer to http://www.rfc-editor.org/errata.html, seeking for RFCs 2578, 2579, and 2580, to find additional "officially" posted RFC errata.

#1 - OBJECTS clause forbids not-accessible

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

The following statement in section 3.1 in RFC 2580 is problematic:

The OBJECTS clause, which must be present, is used to specify each
object contained in the conformance group.  Each of the specified
objects must be defined in the same information module as the
OBJECT-GROUP macro appears, and must have a MAX-ACCESS clause value
of "accessible-for-notify", "read-only", "read-write", or "read-
create".

The last sentence forbids to put a not-accessible INDEX object into an OBJECT-GROUP. Hence, you can not refine its syntax in a compliance definition. For more details, see this email.

RFC 4181 section 4.8 gives some guidelines how to express refinements for not-accessible index objects.

#2 - Conformance statements and IMPORT

From: heard@pobox.com
Status: submitted

In RFC 2580, it is stated that the objects specified in an OBJECT clauses of a MODULE-COMPLIANCE invocation or in a VARIATION clause of an AGENT-CAPABILITIES invocation do not need to be imported:

5.4.3.  Mapping of the OBJECT clause
[ ... ]
   By definition, each object specified in an OBJECT clause follows a
   MODULE clause which names the information module in which that object
   is defined.  Therefore, the use of an IMPORTS statement, to specify
   from where such objects are imported, is redundant and is not
   required in an information module.

6.5.2.  Mapping of the VARIATION clause
[ ... ]
   By definition, each object specified in a VARIATION clause follows a
   SUPPORTS clause which names the information module in which that
   object is defined.  Therefore, the use of an IMPORTS statement, to
   specify from where such objects are imported, is redundant and is not
   required in an information module.

The same reasoning that applies to objects referenced by an OBJECT clause or a VARIATION clause also applies to notifications referenced by a VARIATION clause and to object groups and notification groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or a SUPPORTS clause. However, RFC 2580 does not explicitly say that notifications, object groups, and notification groups do not need to be imported in order to be used in these contexts. I would guess that this is an inadvertent omission. If so, it might be worth putting into a "technical corrigendum" document, if one is issued someday to update the SMIv2 documents.

The original posting from Mike is here.

RFC 4181 section 4.4 suggests that explicit IMPORTs should be used in all cases to make module dependencies explicit.

#3 - DateAndTime year range

From: KChapman@unispherenetworks.com
Status: accepted

RFC 2579 says on page 18 that the range for the year is 0..65536 which is obviously not possible with 2 octets. The correct range for the year is 0..65535.

#4 - INTEGER/BITS object updates and OBJECT clauses

From: heard@pobox.com
Status: accepted

RFC 2580 should - but does not - require that appropriate OBJECT clauses be added (if not already present) to a compliance definition when enumerated INTEGER objects or BITS objects that are referenced by the compliance definition have new enumerations added, because that is the only way to avoid changing the requirements specified by that definition.

The original posting from Mike is here.

RFC 4181 section 4.9 suggests that object clauses are added to compliance statements when enumerations are extended.

#5 - DESCRIPTION of RowStatus TC refers to an obsolete RFC Section

From: strauss@ibr.cs.tu-bs.de
Status: submitted

The DESCRIPTION clause within the RowStatus type definition in RFC 2579 refers to "Section 7.7.1 of [2]" where [2] is RFC 2578 but it does not have a section with that number. This probably happened due to a copy from the predecessor documents (RFC 1442, 1443) where RFC 1442 had a Section 7.7.1 on "Creation and Deletion of Conceptual Rows".

#6 - s/i\.e\./e\.g\./

From: bwijnen@lucent.com
Status: submitted

An explanation in RFC 2578 says on page 29 in section 7.7 contains an example which is intruduced by "i.e.", which should be an "e.g.".

The original posting from Bert is here.