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:
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
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
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
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
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
The DESCRIPTION clause within the RowStatus type definition in RFC 2579 refers to "Section 7.7.1 of " where  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\./
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.