Subject: RFC 4295 (MOBILEIPV6-MIB) errata and issues

From: Alfred Hönes <[email-masked]>
Date: Sat, 8 Jul 2006 10:25:53 +0200 (MESZ)

Hello,
after studying the recently published RFC 4295 (MOBILEIPV6-MIB)
authored by you, I would like to submit a few comments, pointing
out some issues I found with the RFC text, and supplying material
for an appropriate RFC Errata Note.

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.

(1)  MIB object naming scheme broken

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

(2)  wrong object name in cloned DESCRIPTION clause

The DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, on page 28 of RFC 4295, apparently has been
cloned from another object without proper editing, and thus
refers to a wrong object, mip6NodeOutOctets, where it should
refer to the object, mip6NodeOutPkts.
Thus, the DESCRIPTION text (in the 12th line on page 28),

                   [...]
|                  This object is a 64-bit version of mip6NodeOutOctets.
                   [...]
should say:
                   [...]
|                  This object is a 64-bit version of mip6NodeOutPkts.
                   [...]

(3)  clarification (text too much abbreviated)

The DESCRIPTION clause of the mip6MnHomeAddressState OBJECT-TYPE,
on page 30, suffers from a couple of word omissions.

The text:

                    home        -- mobile node is on the home network.
                    registered  -- mobile node is on a foreign network
                                   and is registered with the home
                                   agent.
                    pending     -- mobile node has sent registration
                                   request to the home agent and is
                                   waiting for the reply.
                    isolated    -- mobile node is isolated from network,
                                   i.e., it is not in its home network,
                                   it is not registered, and no
                                   registration ack is pending.

should perhaps better say:

|                   home        -- the mobile node is on the home
                                   network.
|                   registered  -- the mobile node is on a foreign
                                   network and is registered with the
                                   home agent.
|                   pending     -- the mobile node has sent a
                                   registration request to the home
                                   agent and is waiting for the reply.
|                   isolated    -- the mobile node is isolated from its
|                                  home network, i.e., it is not in its
                                   home network, it is not registered,
                                   and no registration ack is pending.

(4)  typo

The DESCRIPTION clause of the mip6MnBLAcceptedTime OBJECT-TYPE,
on page 39, says:
                                                             v
|                  "The time at which the mobile node receives a binding
                    acknowledgment indicating that Binding Update has
                    been accepted (status code 0 or 1);
                    [...]

It should say:
                                                             v
|                  "The time at which the mobile node received a binding
                    acknowledgment indicating that Binding Update has
                    been accepted (status code 0 or 1);
                    [...]

or even better (similar to the mip6MnBLAccepted DESCRIPTION on the
same page):
                                                      vvvv       v
|                  "The time at which the mobile node has received a
                    binding acknowledgment indicating that Binding
                    Update has been accepted (status code 0 or 1);
                    [...]

(5)  punctuation

The DESCRIPTION clause of the mip6MnCompliance2 MODULE-COMPLIANCE,
on page 93, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring of the mobile node
|                  functionality specifically the Discovery- and
|                  Registration-related statistics,
                   There are a number of INDEX objects [...]

It should say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring of the mobile node
|                  functionality, specifically the Discovery- and
|                  Registration-related statistics.
                   There are a number of INDEX objects that cannot be

(6)  description too unspecific

The DESCRIPTION clause of the mip6CnCompliance MODULE-COMPLIANCE,
on page 94, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
|                  support monitoring of the basic correspondent node
|                  functionality.

This is the same description text as supplied for the
mip6CnCoreCompliance (on the same page), and hence does not
suffice to distinguish these two compliance statements.

The above text perhaps should say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and support
                   monitoring of the basic correspondent node
|                  functionality and per-MN BU traffic.

(7)  description too unspecific, and punctuation

The DESCRIPTION clause of the mip6HaCompliance2 MODULE-COMPLIANCE,
on page 95, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring of the home agent
|                  functionality specifically the Home Agent List
|                  and the home-agent-registration-related statistics,
                   There are a number of INDEX objects [...]

for reasons as in item (5) and item (6) above,
it should better say:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
|                  support detailed monitoring of the home agent
|                  functionality, specifically the Home Agent List
|                  and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]

(8)  punctuation, and extraneous blank line

The DESCRIPTION clause of the mip6HaCompliance3 MODULE-COMPLIANCE,
on page 96, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring and control of the home agent
|                  functionality specifically the Home Agent List
|                  and the home-agent-registration-related statistics,
|
                   There are a number of INDEX objects [...]

It should say (see above items for rationale and similarity):

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB and
                   support monitoring and control of the home agent
|                  functionality, specifically the Home Agent List
|                  and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]

(9)  punctuation, and extraneous blank line

The DESCRIPTION clause of the mip6HaReadOnlyCompliance2
MODULE-COMPLIANCE, on page 99, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
                   support monitoring of the home agent
|                  functionality specifically the Home Agent List
                   and the home-agent-registration-related statistics.
|
                   There are a number of INDEX objects [...]

It should say (see above items for rationale and similarity):

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
                   support monitoring of the home agent
|                  functionality, specifically the Home Agent List
                   and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]

(10) punctuation, and extraneous blank line

The DESCRIPTION clause of the mip6HaReadOnlyCompliance3
MODULE-COMPLIANCE, on page 101, says:

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
?                  support monitoring and control of the home agent
|                  functionality specifically the Home Agent List
|                  and the home-agent-registration-related statistics,
|
                   There are a number of INDEX objects [...]

It should say (see above items for rationale and similarity):

                  "The compliance statement for SNMP entities
                   that implement the MOBILEIPV6-MIB without support
                   for read-write (i.e., in read-only mode) and
                   support monitoring and control of the home agent
|                  functionality, specifically the Home Agent List
|                  and the home-agent-registration-related statistics.
                   There are a number of INDEX objects [...]

Furthermore, arguably the words "and control" should better be
deleted since write access is not required.

Please comment.
All but item (1) seems to be appropriate for an Errata Note.
Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

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]                     |
+------------------------+--------------------------------------------+