Dratf-ietf=bridge=bridgemib-smiv2

Publication Request for darft-ietf-bridge-bridgemib-smiv2.txt as Proposed Standard

Shepherding WG Chair: David Harrington

1.a) Have the chairs personally reviewed this version of the ID and
        do they believe this ID is sufficiently baked to forward to the
        IESG for publication?

Yes. Both chairs have reviewed the document.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document was reviewed and discussed by several WG members, including several MIB Doctors and several persons active in the IEEE 802.1 WG, as well as by Bert Wijnen, the Operations and Management Area Director. 

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

Although among the reviewers of the document there are several 'MIB Doctors' and the editor of the latest version is a MIB Doctor himself, no independent MIB Doctor review was performed on the latest revision. 


   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it, etc.  If your issues have been discussed in the WG and the
        WG has indicated it wishes to advance the document anyway, note
        if you continue to have concerns.

The scope of the work was discussed on the mailing list and at IETF-61, and the decision was that this MIB module should update RFC 1493 into a SMIv2 version, and include a very limioted number of changes needed for dependent documents of the WG, but will not provide updates relative to the ongoing evolution of the IEEE 802.1 standards. This decision is supported by the consensus of the WG, and was also communicated with IEEE 802.1. As result of the discussions between the IETF and IEEE 802.1 it was agreed that new MIB modules or changes in the existing standards that reflect the evolution of the IEEE 802.1 technology will be taken over by the IEEE 802.1 WG. 


   1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The Working Group today does not number too many participants. There seems to be strong consensus between the few active participants concerning this document. 


   1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise what are they upset about.

No. 


   1.g) Have the chairs verified that the document adheres to _all_ of
        the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes. No nits found. 


   1.h) Does the document a) split references into normative/
        informative, and b) are there normative references to IDs, where
        the IDs are not also ready for advancement or are otherwise in
        an unclear state? (Note: the RFC editor will not publish an RFC
        with normative references to IDs, it will delay publication
        until all such IDs are also ready for publication as RFCs.)

a) yes b) no


   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a writeup section with the following
        sections:


   1.j) Please provide such a writeup.  (We will hopefully use it as is,
        but may make some changes.) For recent examples, have a look at
        the "protocol action" announcements for approved documents.

        *    Technical Summary

This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP based internets.
   In particular it defines objects for managing MAC bridges based on
   the IEEE 802.1D-1998 standard between Local Area Network (LAN)
   segments.  Provisions are made for support of transparent bridging.
   Provisions are also made so that these objects apply to bridges
   connected by subnetworks other than LAN segments.

   The MIB module presented in this memo is a translation of the
   BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax, updated 
   slightly to accommodate higher speed links.


        *    Working Group Summary

The Bridge MIB Working Group discussed this document and approved its content 
in a Working Group Last Call process. All issues raiseds during the WG Last Call have been
resolved, maintained in the RT system, and a summary of the resolutions was published to 
the mailing list for comment. The WG recommends that this document be forwarded to the IESG for consideration as a Proposed Standard.

It is the intention of the WG that subsequent mib module work for IEEE 802.1 technologies will be done by the IEEE 802.1 WG. There are some concerns about the quality of work likely to 
result from SNMP non-experts, but the IETF is providing MIB Doctor review of their mib module work during the transition.

        *    Protocol Quality

The document was reviewed in detail by John Flick, and discussed by several other MIB experts.  
A number of IEEE 802.1 WG members, including the vice chair, were involved in discussions. 
The discussions and clarifications resulted in editorial changes in the document. 
The MIB module proposed by this document is the SMIv2 version of RFC 1493, which is 
implemented by many vendors in the industry. Backwards compatibility has been maintained, 
and most of the protocol data is identical between versions. It is expected that at least some of these vendors will implement the new version incarnated by this document, and other may 
choose to implement it in the future, because of the growing acceptance of the IEEE 802.1 protocol in the industry. It is our belief that the document is at the appropriate quality 
for consideration as proposed standard.