Subject: RFC4444 errata and issues

From: Alfred Hönes <[email-masked]>
Date: Mon, 29 May 2006 23:15:17 +0200 (MESZ)

Hello,

studying the recently published RFC 4444 authored/edited by you
I found a couple of issues I'd like to report.

(Admittedly, there is a remarkably small number of issues left in
RFC 4444, when compared with other RFCs of similar size.  Well done!)

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.

The subsequent items are listed mostly in RFC text order.
I omit mentioning all those apparently spurious blank lines perhaps
introduced in the publication process.

(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.  [...]

(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.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."

(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'."

(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,
             [...]

(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
        }

This concludes my notes on RFC 4444.
Please comment.

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.

I propose to post to the RFC Editor's RFC Errata web page
an Errata Note covering the remaining issues.
I recommend that you submit an Author's Errata Note, making use
of the material presented above; but if you prefer, I can compile
a condensed version and submit it on my own, upon your approval.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+