RFC 4444, "Management Information Base for Intermediate System to Intermediate System (IS-IS)", April 2006

Errata ID: 87
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Rejected by: Adrian Farrel
Date Rejected: 2012-08-16

(2)  issue: non-use of appropriate TC (?)

The isisCircLevelIDOctet OBJECT-TYPE macro instance, on page 36,
contains the SYNTAX clause:

    isisCircLevelIDOctet OBJECT-TYPE
        SYNTAX Unsigned32(0..255)

After comparison with similar context in the RFC, I suspect that it
would be appropriate to use the IsisUnsigned8TC TEXTUAL-CONVENTION
in this place as well:

    isisCircLevelIDOctet OBJECT-TYPE
|       SYNTAX IsisUnsigned8TC


(3)  issue: unexpected indexing

As described in the SMIv2 RFCs, RFC 4444 extends various tables
by "reusing" of common index objects.  Surprisingly, there are
two deviations from this practice I cannot detect any reason for:

(3.1)
The isisSystemCounterTable (page 39 ff.) is indexed by the fresh,
independant index object, "isisSysStatLevel", while IMHO it would
have been logical to use the already defined index object of the
isisSysLevelTable (page 25 ff.), "isisSysLevelIndex", for this
purpose as well.

(3.2)
The isisPacketCounterTable (page 46 ff.) is indexed in the 2nd place
by the fresh, independant index object, "isisPacketCountLevel",
while IMHO it would have been logical to use the full index structure
of the isisCircLevelTable (page 34 ff.), including the index object,
"isisCircLevelIndex" in the second place, for this purpose as well.


(4)  issue: many unusual UNITS clauses

The UNITS clause is intended a to contains a textual definition of
the units associated with the object (according to RFC 2578, Section
7.2).  Network management systems usually provide for narrow label
space in their display screens - expecting usual [physical] unit
names like "bytes", "kilobytes", "seconds", "centiseconds", "Mbps",
"packets", "frames", "cells", "percent", etc.

For most packet counters, RFC 4444 specifies very unusual, lengthy
texts in the UNITS clauses that duplicate the text given in the
respective DESCRIPTION clauses.
This style should better have been avoided and might be noted as
an issue for any potential future update to RFC 4444.

For example, the isisPacketCountCSNP OBJECT-TYPE declaration, on
page 49 :

    isisPacketCountCSNP OBJECT-TYPE
        SYNTAX Counter32
|       UNITS "Number of IS-IS CSNP frames seen in this direction at
|            this level"
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of IS-IS CSNPs seen in this
             direction at this level."
        REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}"
    ::= { isisPacketCounterEntry 7 }

should perhaps better say:

    isisPacketCountCSNP OBJECT-TYPE
        SYNTAX Counter32
|       UNITS "frames"
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of IS-IS CSNPs seen in this
             direction at this level."
        REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}"
    ::= { isisPacketCounterEntry 7 }


(5)  errata(?): overly restrictive RowStatus object descriptions

Some tables with conceptual rows that can be dynamically added
or deleted, contain a control object with SYNTAX RowStatus
and other control objects, e.g. with SYNTAX IsisAdminState.

I expect that the latter objects have been intended to control
the activity of "live" table rows, without the need to deactivate
these rows via the RowStatus object before setting the AdminState
to "on" or "off", so much the more the support for the
'notInServcie' state of the RowStatus objects is explicitely
"not required".  Therefore, I strongly suspect that some RowStatus
object DESCRIPTION clauses have unintentionally been worded overly
restrictive and should been corrected to allow AdminStatus changes.

Some other such clauses contain statements that are void due to the
lack of accessible objects in those tables they could be applied to.

I have identified the following instances of these issues:

(5.3)

The DESCRIPTION clause of the isisCircExistState OBJECT-TYPE macro
instance, on page 31, says:

        DESCRIPTION
            "The existence state of this circuit.  Setting the state
             to 'notInService' halts the generation and processing of
             IS-IS protocol PDUs on this circuit.  Setting the state
             to destroy will also erase any configuration associated
             with the circuit.  Support for 'createAndWait' and
             'notInService' is not required.

|            A row entry cannot be modified when the value of this
|            object is 'active'."

It should perhaps instead say:

        DESCRIPTION
            "The existence state of this circuit.  Setting the state
             to 'notInService' halts the generation and processing of
             IS-IS protocol PDUs on this circuit.  Setting the state
             to destroy will also erase any configuration associated
             with the circuit.  Support for 'createAndWait' and
             'notInService' is not required.

|            Any other accessible object in this table row, except
|            isisCircAdminState, cannot be modified when the value
|            of this object is 'active'."

(5.4)

The DESCRIPTION clause of the isisRAExistState OBJECT-TYPE macro
instance, on page 58, says:

        DESCRIPTION
            "The existence state of this Reachable Address.  This
             object follows the ManualOrAutomatic behaviors.  Support
             for 'createAndWait' and 'notInService' is not required.

|            A row entry cannot be modified when the value of this
|            object is 'active'."

It should perhaps instead say:

        DESCRIPTION
            "The existence state of this Reachable Address.  This
             object follows the ManualOrAutomatic behaviors.  Support
             for 'createAndWait' and 'notInService' is not required.

|            Any other accessible object in this table row, except
|            isisRAAdminState, cannot be modified when the value
|            of this object is 'active'."

(5.5)

The DESCRIPTION clause of the isisIPRAExistState OBJECT-TYPE macro
instance, on page 65, says:

        DESCRIPTION
            "The state of this IP Reachable Address.  This object
             follows the ExistenceState and ManualOrAutomatic
             behaviors.  Support for 'createAndWait' and
             'notInService' is not required.

|            A row entry cannot be modified when the value of this
|            object is 'active'."

It should perhaps instead say:

        DESCRIPTION
            "The state of this IP Reachable Address.  This object
             follows the ExistenceState and ManualOrAutomatic
             behaviors.  Support for 'createAndWait' and
             'notInService' is not required.

|            Any other accessible object in this table row, except
|            isisIPRAAdminState, cannot be modified when the value
|            of this object is 'active'."


(8)  issue: on-the-wire inefficiency in notifications

While admittedly the indexing structure of the MIB tables,
and the resulting lack of suitable accessible objects, apparently has
forced the introduction of the unusual and unusually large collection
of special objects with 'MAX-ACCESS accessible-for-notify'
(on pp. 71..74), some redundancies and inefficiencies in the
object groupings for notifications remain.  Repeatedly, the
number of objects could have been reduced by including properly
indexed objects into the notifications object groups instead of
separate "special" objects.  But this might have been considered
acceptable for the sake of a consistent object grouping style.

But there is one redundancy that could easily have been avoided.
The isisDatabaseOverload NOTIFICATION-TYPE declaration, on page 74,

    isisDatabaseOverload NOTIFICATION-TYPE
        OBJECTS {
            isisNotificationSysLevelIndex,
            isisSysLevelState
        }

includes the object, "isisSysLevelState", that already carries
the required SysLevelIndex in the index part of its OID, because
it is contained in the isisSysLevelTable.
Therefore, without any loss of information for the receiver of the
notification, this declaration could have been simplified to specify:

    isisDatabaseOverload NOTIFICATION-TYPE
        OBJECTS {
            isisSysLevelState
        }

Notes:

This Errata Note has been split with some elements moved to EID 3321.

All excerpts from the RFC text are taken literally, keeping their
original formatting, and modified text is formatted in conformance
with RFC guidelines again.

I use change bars ('|' in column 1) and casual up/down pointing
tags ('^^^' / 'vvv' marks in extra lines) to emphasize the location
of textual issues and/or proposed textual enhancements/corrections.

Naturally, items (3) and (8) cannot be addressed any more
"after the fact" (i.e. publication of the RFC), and item (4)
should be addressed in a future update.

from pending
--VERIFIER NOTES--
(2) Rejected. Too late for this change. No functional effect.
(3) Rejected. This is discussion not errata.
(4) Rejected. Nothing wrong with original text.
(5.3) Rejected. Pointless wordsmithing.
(5.4) Rejected. Pointless wordsmithing.
(5.5) Rejected. Pointless wordsmithing.
(8) Rejected. This is discussion not errata.

Report New Errata