RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 records.

Status: Verified (2)

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

Source of RFC: mip6 (int)

Errata ID: 3548

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 5 says:

(in the DESCRIPTION clause of the mip6HCNodeOutPkts OBJECT-TYPE
declaration, in the 12th line on page 28)

This object is a 64-bit version of mip6NodeOutOctets.

It should say:

This object is a 64-bit version of mip6NodeOutPkts.

Notes:

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.

Errata ID: 3553

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

 

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.

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

Status: Held for Document Update (5)

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

Source of RFC: mip6 (int)

Errata ID: 3551

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

Section 5 says:

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);
                    [...]

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.

Errata ID: 3549

Status: Held for Document Update
Type: Technical

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

Errata ID: 3550

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

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.

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

Errata ID: 137

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

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

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

Errata ID: 3552

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Held for Document Update by: Brian Haberman
Date Held: 2013-03-16

 

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

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