RFC Errata
RFC 4502, "Remote Network Monitoring Management Information Base Version 2", May 2006
Source of RFC: rmonmib (ops)See Also: RFC 4502 w/ inline errata
Errata ID: 77
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-28
(1) clarification
The RFC 4502 text in Section 2.2, under bullet 3), on page 5,
says:
Bit Definition
6 For WAN media, this bit is set for packets
coming from one direction and cleared for
packets coming from the other direction.
It is an implementation-specific matter
| as to which bit is assigned to which
direction, but it must be consistent for
all packets received by the agent. [...]
This text certainly is intended to always (and only) cover bit #6.
Therefore, the wording, "which bit is assigned" is misleading;
it should be "which [bit] value is assigned".
Thus, the above snippit sould better say:
Bit Definition
6 For WAN media, this bit is set for packets
coming from one direction and cleared for
packets coming from the other direction.
It is an implementation-specific matter
| as to which bit value is assigned to which
direction, but it must be consistent for
all packets received by the agent. [...]
(2) Ref. issue
In Section 3.2, the third paragraph on page 9 says:
In the RMON MIB [RFC2819], the EntryStatus textual convention was
introduced to provide this mutual exclusion function. Since then,
this function was added to the SNMP framework as the RowStatus
textual convention. The RowStatus textual convention is used for the
definition of all new tables.
This text unfortunately has turned wrong by updating the (obsolete)
reference "[RFC1757]" (in RFC 2102) to "[RFC2819]".
(-- A very unusual event! --)
The text in RFC 2102 was correct, because RFC 1757 predates the
invention of the 'RowStatus' TC which was finalized in STD 58.
But STD 58 predates RFC 2819, and therefore, the clause,
vvvvvvvvvv
| Since then,
this function was added to the SNMP framework
as the RowStatus textual convention.
has turned wrong by the replacement of the Ref.!
(NOTE: RFC 2819 in fact still makes use of the 'EntryStatus' TC,
which already had been introduced in RFC 1271, the predecessor
of RFC 1757 !)
To correct this issue without causing a need to update the
References of RFC 4502 as well, I propose the following substitute
text as an Erratum for the text snippit above:
vvvvvvvvvvvvvvvvvvvv
| In the predecessors of the RMON MIB [RFC2819], the EntryStatus
textual convention was introduced to provide this mutual exclusion
function. Since then, this function was added to the SNMP framework
as the RowStatus textual convention. The RowStatus textual
convention is used for the definition of all new tables.
(3) outdated Ref.
The DESCRIPTION clause of the protocolDirID OBJECT-TYPE,
on page 21/22 of RFC 4502, says:
DESCRIPTION
"A unique identifier for a particular protocol. Standard
identifiers will be defined in such a manner that they
<< page break >>
can often be used as specifications for new protocols - i.e.,
a tree-structured assignment mechanism that matches the
protocol encapsulation 'tree' and that has algorithmic
assignment mechanisms for certain subtrees. See RFC 2074 for
more details.
[...]
RFC 2074 has been obsoleted by RFC 2895 and RFC 2896.
Therefore, the last sentence of this paragraph should better say:
[...]. See RFC 2895 and
RFC 2896 for more details.
(4) MIB indexing issue #1
As stated in the text added by RFC 4502 to the DESCRIPTION clause
of the addressMapEntry OBJECT-TYPE, the addressMapTable might run
in problems due to the cumulative length of its index object
instances.
Therefore, I suspect that it might have been better to replace the
last index object, addressMapSource, by an object mirroring the
addressMapControlIndex object (direct use of addressMapControlIndex
as the *last* index object might not be considered a valid option).
NOTE:
I know that it it too late now for any change, unfortunately.
(5) MIB indexing issue #2
The DESCRIPTION clause of the TimeFilter TEXTUAL-CONVENTION,
on page 16, explains that an index object of type TimeFilter
should be included as the *first* INDEX component for a time-
filtered table:
A time-filtered conceptual table is created by inserting a
single object of SYNTAX TimeFilter as the first INDEX component
in a copy of an existing basic conceptual table (i.e., any
SEQUENCE without a TimeFilter INDEX component). [...]
The RMON2 MIB does not follow this rule for the following tables:
- nlHostTable,
- nlMatrixSDTable,
- nlMatrixDSTable,
- alHostTable,
- alMatrixSDTable, and
- alMatrixDSTable.
Since there are arguably good reasons for the present indexing
structure of these tables, it might perhaps have been better
to have the above DESCRIPTION of the TC modified to accommodate
for the existing practice.
(6) textual issue
The first paragraph of the DESCRIPTION clause for the
alMatrixTopNControlRateBase OBJECT-TYPE, on page 78, says:
"This object controls which alMatrix[SD/DS] entry that the
alMatrixTopNEntries are sorted by, which view of the matrix
table that will be used, as well as which table the results
will be reported in.
It should perhaps better say (deleting 2 x 'that'):
| "This object controls which alMatrix[SD/DS] entry the
alMatrixTopNEntries are sorted by, which view of the matrix
| table will be used, as well as which table the results
will be reported in.
(7) wrong numerical limits in ASN.1 comment
The ASN.1 comments on the User History Collection Group,
in the second paragraph on page 86, says:
-- A sample value is stored in two objects - an absolute value and
-- a status object. This allows numbers from -(2G-1) to +4G to be
-- stored. The status object also indicates whether a sample is
-- valid. This allows data collection to continue if periodic
-- retrieval of a particular instance fails for any reason.
Based on the specification of usrHistoryAbsValue and
usrHistoryValStatus (on page93/94), I strongly suspect that the
specified limits are wrong, and that this text should say:
-- A sample value is stored in two objects - an absolute value and
-- a status object. This allows numbers from -(4G-1) to +(4G-1) to
-- be stored. The status object also indicates whether a sample is
-- valid. This allows data collection to continue if periodic
-- retrieval of a particular instance fails for any reason.
(8) inappropriate semantics specified in DESCRIPTION text
for objects in the usrHistoryControlTable
The DESCRIPTION clause of the usrHistoryControlBucketsRequested and
usrHistoryControlBucketsGranted objects (on page 87/88) seem to be
garbled a bit.
The latter contains the (3rd) paragraph:
The associated usrHistoryControlBucketsRequested object
should be set before or at the same time as this object
to allow the probe to accurately estimate the resources
required for this usrHistoryControlEntry.
This makes no sense here, because the usrHistoryControlBucketsGranted
object is read-only, and hence cannot be set.
I strongly suspect that a similar coupling in fact is needed
for the usrHistoryControlObjects object in relation to the
usrHistoryControlBucketsRequested object:
The probe cannot estimate the internal resource requirements,
and hence determine the value of usrHistoryControlBucketsGranted
without knowing the values of both the usrHistoryControlObjects
and the usrHistoryControlBucketsRequested objects in a row.
Therefore, I suspect that the above paragraph should be deleted,
and re-inserted with a slight modification as the new second
paragraph into the usrHistoryControlBucketsRequested DESCRIPTION
clause, saying:
vvvvvvv
| The associated usrHistoryControlObjects object
should be set before or at the same time as this object
to allow the probe to accurately estimate the resources
required for this usrHistoryControlEntry.
(I intentionally have omitted the appropriate line re-folding
here for clarity.)
(9) two typos
The DESCRIPTION clause of the ControlString TEXTUAL-CONVENTION,
on page 95, contains two typos:
The paragraph:
^w Wait for the reply string that follows, which is
terminated by the next command or the end of string.
Partial and case-insensitive matching is applied, i.e.,
if the reply string (any case combination) is found
anywhere in the received string, then the a match is
found. If the current timeout elapses without a match,
then the remaining control string is ignored.
should say (deleting 'the' in 'the a') :
^w Wait for the reply string that follows, which is
terminated by the next command or the end of string.
Partial and case-insensitive matching is applied, i.e.,
if the reply string (any case combination) is found
| anywhere in the received string, then a match is found.
If the current timeout elapses without a match, then
the remaining control string is ignored.
The 4th-to-last line of page 95,
^ 0x1C
should say:
^\ 0x1C
(10) textual clarification
In the Appendix of RFC 4502 (Section 8), the paragraph below
the pseudo-code on page 133 says:
The agent applies this function regardless of the lastActivationTime
of the conceptual row in question. In other words, counter
discontinuities are ignored (i.e., a conceptual row is deleted and
then re-created later). An agent should consider an object instance
'changed' when it is created (either at restart time for scalars and
static objects, or row-creation-time for dynamic tables).
It should better say:
The agent applies this function regardless of the lastActivationTime
of the conceptual row in question. In other words, counter
| discontinuities (e.g., a conceptual row is deleted and then re-
| created later) are ignored. An agent should consider an object
instance 'changed' when it is created (either at restart time for
scalars and static objects, or row-creation-time for dynamic tables).
Notes:
from pending