Found 1 record.

Status: Held for Document Update (1)

RFC 3970, "A Traffic Engineering (TE) MIB", January 2005

Note: This RFC has been updated by RFC 9141

Errata ID: 734
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-25
Held for Document Update by: joel jaeggli
Date Held: 2017-03-29

Section 5, page 16 says:

   teTunnelLPOctets OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of octets that have been forwarded over
                    the Tunnel.

                    Discontinuities in the value of this counter can
                    occur at re-initialization of the management system
                    and at other times, as indicated by the value of
                    teTunnelDiscontinuityTimer.
                   "
       ::= { teTunnelEntry 14 }

   teTunnelLPPackets OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of packets that have been forwarded over
                    the Tunnel.
                    Discontinuities in the value of this counter can
                    occur at re-initialization of the management system
                    and at other times, as indicated by the value of
                    teTunnelDiscontinuityTimer.
                   "
       ::= { teTunnelEntry 15 }

It should say:

[not submitted]

Notes:

The DESCRIPTION clauses of
- teTunnelOctects and teTunnelLPOctects
- teTunnelPackets and teTunnelLPPackets
are pairwise identical, respectively.

There is no precise description of the precise meaning of
these "teTunnelLPxxx" objects.
Admittedly, one might guess from the SYNTAX clauses of these
objects that "LP" stands for 'lower part' -- meaning that the
value of a "teTunnelLPOctets" object should always equal the
value of the corresponding "teTunnelOctets" object MODULO 2^32
(and similarly for the "...Packets" objects), but this is not
stated in the text.

Furthermore, unfortunately the naming of these objects does
not conform to the conventional naming style used in (almost)
all IETF standards track MIB modules with High Capacity
counters, e. g. "xxxOctets" and "xxxHCOctets" .
The above interpretation would be more manifest if this
standard naming convention would have been followed.

Now, given that the naming of the objects cannot be changed
any more, it would certainly be useful to have a textual
clarification of these DESCRIPTIONs posted on the RFC Editor's
RFC-Errata web page.

[from pending]

Report New Errata