RFC 4295, "Mobile IPv6 Management Information Base", April 2006

Errata ID: 3549
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

It is accepted consensus in the IETF to use a common, mnemonic scheme
for the naming of tables, table rows, and columnar objects within
these rows, namely (variable text to be instantiated shown as <..>):

          <tableName>Table
            <tableName>Entry
              <tableName><Object1>
              <tableName><Object2>
               ...
              <tableName><Objectn>
or:
          <tableName>Table
            <tableName>Entry
              <tableNameShort><Object1>
              <tableNameShort><Object2>
               ...
              <tableNameShort><Objectn>
where
  <tableNameShort> is an abbreviated version of <tableName> .

Unfortunately, the mip6NodeTraffic counter table breaks this scheme.
Page 24 of RFC 4295 specifies:

        Mip6NodeTrafficEntry ::=
           SEQUENCE {
                 mip6NodeInOctets             Counter32,
|                mip6HCNodeInOctets           Counter64,
                 mip6NodeInPkts               Counter32,
|                mip6HCNodeInPkts             Counter64,
                 mip6NodeOutOctets            Counter32,
|                mip6HCNodeOutOctets          Counter64,
                 mip6NodeOutPkts              Counter32,
|                mip6HCNodeOutPkts            Counter64,
                 mip6NodeCtrDiscontinuityTime TimeStamp
           }

As can be seen, the irregularity is in the 'HC' (Counter64) names;
"mip6HCNodeXxx" should have been replaced by "mip6NodeHCXxx", i.e.,

        Mip6NodeTrafficEntry ::=
           SEQUENCE {
                 mip6NodeInOctets             Counter32,
|                mip6NodeHCInOctets           Counter64,
                 mip6NodeInPkts               Counter32,
|                mip6NodeHCInPkts             Counter64,
                 mip6NodeOutOctets            Counter32,
|                mip6NodeHCOutOctets          Counter64,
                 mip6NodeOutPkts              Counter32,
|                mip6NodeHCOutPkts            Counter64,
                 mip6NodeCtrDiscontinuityTime TimeStamp
           }

As the published irregular object names cannot be changed easily
after the fact, I hereby propose to introduce the regular object
names in a future update to the MIB module as *aliases* to the
irregular ones, bound to the same OIDs.
Of course,
-  the OBJECT-TYPE declarations of the four affected MIB objects,
   on page 25..28, and
-  the definition of the mip6NodeTrafficGroup OBJECT-GROUP,
   on page 81
would have to be adjusted accordingly.

( Perhaps, it would be best to change the symbolic object names
  in the above SEQUENCE definition, and in the OBJECT-TYPE and
  OBJECT-GROUP definitions, and add new OBJECT IDENTIFIER
  definitions to introduce the old, irregular names again,
  with the same OIDs, for backwards compatibility.)

Notes:

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

from pending

Report New Errata