Found 1 record.

Status: Verified (1)

RFC 4502, "Remote Network Monitoring Management Information Base Version 2", May 2006

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

Report New Errata