RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

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

Source of RFC: mip6 (int)

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 <..>):

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


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

Advanced Search