Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol
RFC 4318

Note: This ballot was opened for revision 09 and is now closed.

(Bert Wijnen) (was Discuss, Yes) Yes

(Brian Carpenter) No Objection

Comment (2005-08-15 for -)
No email
send info
Long Gen-ART comment from Harald, preceded by response from author. Non blocking but probably needs revision.



The references issue went through a long discussion in the Bridge WG,
with input from members of the IEEE 802.1 WG. The document represents
WG consensus for how to handle a difficult situation.

I agree the documentation can be confusing and am willing to modify it
for clarity.
I suggest that the document be changed by moving the 802.1D-2004
reference into "Informative References", and modifying the sentence
"Following are the references for the above objects in 802.1D-2004
Suggested text:
"Following are the references for the above objects in 802.1D-2004
[802.1D-2004]. The 802.1t and 802.1w references are normative; the
802.1D-2004 references are only informative."

Would that be satisfactory?

David Harrington

>> -----Original Message-----
>> From: Harald Tveit Alvestrand [] 
>> Sent: Monday, August 08, 2005 7:07 AM
>> To:;; 
>>; Dan Romascanu; David Harrington
>> Cc: Wijnen, Bert (Bert)
>> Subject: Gen-ART review of draft-ietf-bridge-rstpmib-08 (Last 
>> Call review)
>> Background for those who may be unaware of GenART:
>> GenART is the Area Review Team for the General Area of the IETF.
>> We advise the General Area Director (i.e. the IETF/IESG chair) by
>> providing more in depth reviews than he could do himself of


>> that come up for final decision in IESG telechat.  I was selected
>> as the GenART member to review this document.  Below is my review,
>> which was written specifically with an eye to the GenART process,


>> since I believe that it will be useful to have these comments more
>> widely distributed, others outside the GenART group are included.
>> This review was done as part of IETF Last Call.
>> Review criteria for WG submissions: "Is this document a reasonable
>> contribution to the area of Internet engineering which it covers? If
>> not, what changes would make it so?"
>> Summary: This document seems ready to go technically, but has 
>> nits that 
>> should be fixed before publication - in particular, it may need 
>> clarification of its references to other documents.
>> Details:
>> This is a relatively small MIB, and it focuses on management, not 
>> monitoring; it is basically a set of "switches" to flip the value of

>> various per-port parameters that are used in RSTP and "lamps" 
>> that allow 
>> you to monitor these parameters' states.
>> Where I get confused is in the technology it builds on.
>> It claims to refer to IEEE 802.1D-1998 as amended by P802.1t 
>> and P802.1w, 
>> adopted in 2001 according to the reference list, but also 
>> claims to refer 
>> to IEEE 802.1D-2004. It extends the RFC 1493 MIB, but also 
>> refers to the 
>> 1493bis MIB, which is in the RFC Editor's queue.
>> All of these documents (2 standards, 2 amendments, 1 RFC and 
>> 1 draft) are 
>> in the "normative references" section.
>> It's possible that IEEE 802.1D-2004 failed to incorporate the 
>> amendments, 
>> but this seems unlikely, since section 3 gives mapppings of 
>> the variables 
>> to 802.1D-2004 section numbers; it's also possible that 
>> people are so used 
>> to referring to P802.1t and P802.1w that those references are 
>> valuable and 
>> should be retained. But it's confusing to me, and may be to others.
>> Suggested fix:
>> Move IEEE 802.1D-1998, P802.1t, P802.1w and RFC 1493 to the 
>> "Informative 
>> references" section.
>> Change section 3 to read:
>>    This document defines managed object for the Rapid Spanning Tree
>>    Protocol defined by the IEEE 802.1D-2004 standard.
>>    Following are the references for the above objects in 802.1D-2004
>>    [802.1D-2004].
>>    RSTP-MIB Name                       IEEE 802.1D-2004 Reference
>>    dot1dStp
>>      dot1dStpVersion                   17.13.4  ForceVersion
>>      dot1dStpTxHoldCount               17.13.12 TxHoldCount
>>      dot1dStpExtPortTable
>>        dot1dStpPortProtocolMigration   17.19.13 mcheck
>>        dot1dStpPortAdminEdgePort       17.13.1  adminEdgePort
>>        dot1dStpPortOperEdgePort        17.19.17 operEdgePort
>>        dot1dStpPortAdminPointToPoint   6.4.3    adminPointToPointMAC
>>        dot1dStpPortOperPointToPoint    6.4.3    operPointToPointMAC
>>        dot1dStpPortAdminPathCost       17.13.11 Path Cost
>>    This extension was initially defined in P802.1t[] and P802.1w[].
>>    For reference, here are the section numbers in those documents:
>>    RSTP-MIB Name                       IEEE 802.1 Reference
>>    dot1dStp
>>      dot1dStpVersion                   (w) 17.16.1  ForceVersion
>>      dot1dStpTxHoldCount               (w) 17.16.6  TxHoldCount
>>      dot1dStpExtPortTable
>>        dot1dStpPortProtocolMigration   (w) 17.18.10 mcheck
>>        dot1dStpPortAdminEdgePort       (t) 18.3.3   adminEdgePort
>>        dot1dStpPortOperEdgePort        (t) 18.3.4   operEdgePort
>>        dot1dStpPortAdminPointToPoint   (w) 6.4.3    
>> adminPointToPointMAC
>>        dot1dStpPortOperPointToPoint    (w) 6.4.3    
>> operPointToPointMAC
>>        dot1dStpPortAdminPathCost       (D)  Path Cost
>> Modify the document to consistently refer to IEEE 802.1D-2004 
>> and 1493bis 
>> as the documents it builds on. RFC 1493 and the older 802.1D 
>> version may 
>> need to be mentioned as background material.
>> I think section 4 would be clearer if the sentence
>>    The objects in the RSTP-MIB supplement those defined in the


>>    MIB [RFC1493bis].
>> started the section, rather than following the description of the 
>> relationship between 1493 and 1493bis.
>> Apart from this, I see no issues.
>> No nits found!

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2005-08-25 for -)
No email
send info
My earlier comment was based on misreading the RFC Editor Queue - the bis
Bridge MIB will not block this MIB.

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Alex Zinin) No Objection