RFC Errata
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
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
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
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
Errata ID: 3550
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
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
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
(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
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
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