Found 2 records.

Status: Held for Document Update (1)

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

Errata ID: 3321
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-16

(1)  erratum: disfigured object name

In the DESCRIPTION clause of the isisCircLevelType OBJECT-TYPE macro
instance, on mid-page 32, the sentence

                                        [...].  Thus, if the
             isisSysTpe is level2 and the isisCircLevelType
             for a circuit is level1, the circuit will not send
             or receive IS-IS packets.  [...]

should say:
                    vvvvvvvvv
                                        [...].  Thus, if the
|            isisSysLevelType is level2 and the isisCircLevelType
             for a circuit is level1, the circuit will not send
             or receive IS-IS packets.  [...]

(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.1)

The DESCRIPTION clause of the isisManAreaAddrExistState OBJECT-TYPE
macro instance, on page 18, says:

        DESCRIPTION
            "The state of the isisManAreaAddrEntry.  If the
             isisSysAdminState for this Intermediate System is 'on' and
             an attempt is made to set this object to the value
             'destroy' or 'notInService' when this is the only
             isisManAreaAddrEntry in state 'active' for this
             Intermediate System should return inconsistentValue.
|
|            A row entry cannot be modified when the value of this
|            object is 'active'."

The last sentence is void, because the conceptual table rows of the
IsisManAreaAddrTable do not contain any other accessible objects
than the RowStatus object proper, isisManAreaAddrExistState.
Therefore, this clause should be shortened to say:

        DESCRIPTION
            "The state of the isisManAreaAddrEntry.  If the
             isisSysAdminState for this Intermediate System is 'on' and
             an attempt is made to set this object to the value
             'destroy' or 'notInService' when this is the only
             isisManAreaAddrEntry in state 'active' for this
             Intermediate System should return inconsistentValue."

(5.2)

The DESCRIPTION clause of the isisRedistributeAddrExistState
OBJECT-TYPE macro instance, on pp. 23/24, says:

        DESCRIPTION
            "The existence state of this summary address.  Support
<page break>
             for createAndWait and notInService is not required.
|
|            A row entry cannot be modified when the value of this
|            object is 'active'."

The last sentence is void, because the conceptual table rows of the
IsisRedistributeAddrTable do not contain any other accessible objects
than the RowStatus object proper, isisRedistributeAddrExistState.
Therefore, this clause should be shortened to say:

        DESCRIPTION
            "The existence state of this summary address.  Support
|            for 'createAndWait' and 'notInService' is not required."

(6)  erratum (typo)

The DESCRIPTON clause of the isisRASNPAMask OBJECT-TYPE declaration,
on page 61, says:

        DESCRIPTION
            "A bit mask with 1 bit indicating the positions in the
             effective destination address from which embedded SNPA
             information is to be extracted.  [...]

It should say:
                                 vvv
        DESCRIPTION
|           "A bit mask with 1 bits indicating the positions in the
             effective destination address from which embedded SNPA
             information is to be extracted.  [...]


(7)  erratum: disfigured object names

The last paragraph on page 62, within the DESCRIPTION clause of the
isisIPRAEntry OBJECT-TYPE declaration says:

             Implementers need to be aware that if the total number
             of elements (octets or sub-identifiers) in
             isisIPRADestr, isisIPRADestPrefixLen, and
             isisIPRANextHopIndex is too great, then OIDs of column
             instances in this table will have more than 128
             subidentifiers and cannot be accessed using SNMPv1,
<page break>
             [...]

It should perhaps say:

             Implementers need to be aware that if the total number
             of elements (octets or sub-identifiers) in
|            isisIPRADestType, isisIPRADest, isisIPRADestPrefixLen,
             and isisIPRANextHopIndex is too great, then OIDs of
             column instances in this table will have more than 128
             subidentifiers and cannot be accessed using SNMPv1,
             [...]

Notes:

This Errata Note is duplicated from EID 87 to separate out issues of different categories.

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.

Status: Rejected (1)

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