Found 1 record.

Status: Held for Document Update (1)

RFC 4188, "Definitions of Managed Objects for Bridges", September 2005

Errata ID: 786
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-10-17
Held for Document Update by: Dan Romascanu

(1)

There is a significant inconsistency in the newly introduced
conformance information with respect to the new
'dot1dStpPortPathCost32' object:

The  bridgeCompliance4188 MODULE-COMPLIANCE  macro
(at the bottom of page 37 and the top of page 38) says:

    GROUP   dot1dStpPortGroup2
        DESCRIPTION
           "Implementation of this group is mandatory for
            bridges that support the Spanning Tree Protocol."

    GROUP   dot1dStpPortGroup3
        DESCRIPTION
           "Implementation of this group is mandatory for bridges
            that support the Spanning Tree Protocol and 32-bit path
            costs.  In particular, this includes devices supporting
            IEEE 802.1t and IEEE 802.1w."

Now (see upper half of page 34), both dot1dStpPortGroup2 and
dot1dStpPortGroup3 contain the object 'dot1dStpPortPathCost32'.
Thus the net result of the above text is that we have two
overlapping but different requirements for that object, and
that the object 'dot1dStpPortPathCost' is not covered by
the bridgeCompliance4188 statement at all.

But, looking at the description clauses for dot1dStpPortPathCost
(on top of page 22) and dot1dStpPortPathCost32 (on page 23)
I conjecture that the original intent was to ALWAYS have
dot1dStpPortPathCost instantiated in rows of the
dot1dStpPortTable (as before, per RFC 1493), and to take
(the new semantics of) the special (max.) value 65535 for
that object as an indication that dot1dStpPortPathCost32 has
also been instantiated in the respective row; therefore, I
expect that dot1dStpPortPathCost should be included in the
conditionally mandatory groups named in bridgeCompliance4188.

The easiest way to remedy this inconsistency would be to modify
the OBJECTS list of the OBJECT-GROUP dot1dStpPortGroup2 by
replacing 'dot1dStpPortPathCost32' by 'dot1dStpPortPathCost'.
But then the definition of dot1dStpPortGroup2 would-be-word
by word identical to the definition of dot1dStpPortGroup (!)
and it might be better to replace 'dot1dStpPortGroup' for
'dot1dStpPortGroup2' on the first line of the text fragment
cited above (bottom of page 37).

Perhaps, an OBJECT clause mentioning the new semantics of the
max. value for dot1dStpPortPathCost in the past-RFC1493
context migth be appropriate as well.

I think that a correction is needed for this issue and would
like to receive your comment before formally submitting an
errata note to the RFC editor.

a) Replace:

    dot1dTpPortInFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been received by this
            port from its segment.  Note that a frame received on the
            interface corresponding to this port is only counted by
            this object if and only if it is for a protocol being
            processed by the local bridging function, including
            bridge management frames."

   by:

    dot1dTpPortInFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been received by this
            port from its segment.  Note that a frame received on
            the interface corresponding to this port is counted by
            this object if and only if it is consumed by the local
            bridging function, including bridge management frames."

b) Replace:

    dot1dTpPortOutFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been transmitted by this
            port to its segment.  Note that a frame transmitted on
            the interface corresponding to this port is only counted
            by this object if and only if it is for a protocol being
            processed by the local bridging function, including
            bridge management frames."
   by:

    dot1dTpPortOutFrames OBJECT-TYPE
        ...
        DESCRIPTION
           "The number of frames that have been transmitted by this
            port to its segment.  Note that a frame transmitted on
            the interface corresponding to this port is counted by
            this object if and only if it originates from a local
            bridging function, including bridge management frames."

It should say:

[see above]

Notes:

Please correct me if this proposal does not match the original
intent of these DESCRIPTIONs.
(Concern: If the bridge is manageable, the management agent might
reside on the bridge that in this case would have an IP address and
perform the SNMP protocol stack and/or other IP protocols as well.
It might be the case that it was intended to include such locally
destined/originated packets of non-IEEE802.1D functions into the
above counters as well.
Important remark: IEEE802.1D clause 14.6.1.1.3, e.g., includes
"BPDUs, frames addressed to the Bridge as an end station, and
frames that were submitted to the forwarding process" into the
'Frames Received' count! Therefore, the REFERENCE clauses pointing
to that 802.1D clause might be considered inappropriate as well,
for both objects.)


from pending

Report New Errata