Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol
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 -)
Long Gen-ART comment from Harald, preceded by response from author. Non blocking but probably needs revision. ----- Hi, 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 [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 firstname.lastname@example.org >> -----Original Message----- >> From: Harald Tveit Alvestrand [mailto:email@example.com] >> Sent: Monday, August 08, 2005 7:07 AM >> To: firstname.lastname@example.org; email@example.com; >> firstname.lastname@example.org; 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 documents >> 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, but >> 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) 126.96.36.199 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 Bridge >> 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 -)
My earlier comment was based on misreading the RFC Editor Queue - the bis Bridge MIB will not block this MIB.