Publication request: draft-ietf-hubmib-rfc3636bis-05 for consider ation as Proposed Standard RFC

[bcc to iesg-secretary]

Dan/David,

Dan has already submitted a request like this on Sept 28.
But the ID tracker does not show it as "publication requested" yet.
Not sure if Dan copied iesg-secretary, which, if I recall correctly,
is required so they can put document in "publication requested".

Since I am now the HUBMIB WG chair, I am re-requesting publication,
just to make sure it gets properly recorded in the ID-tracker.

On behalf of the HUBMIB WG, please accept a publication request for
draft-ietf-hubmib-rfc3636bis-05 for consideration as Proposed Standard RFC. 

Bert
-------------------
Here is the proto write-up according to
draft-ietf-proto-wgchair-doc-shepherding-07. 

   (1.a)  Who is the Document Shepherd for this document?  

Bert Wijnen

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Yes. 

There were a couple of comments entered after the WGLC and publication
of version 05, and the recommendation of the WG is that they be
considered initial comments in the IETF LC. 
For your info, here are those comments:

- in Security Considerations Section -- the following editorial
  change to 2nd paragraph:

  s/There is a number of/There are a number of/

- Title change for Section 3.4:
  OLD:
     3.4.  Management of IEEE 802.3 Managed Objects
  NEW:
     3.4.  Mapping of IEEE 802.3 Managed Objects


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

The document went through several editing cycles in the WG and received
a number of comments for improvement. Mike Heard from the MIB Doctors
team performed a early review and during WGLC it was announced for early
review on the MIB Doctors list. Comments were also received from
participants who are active in ITU-T Q10/4 and IEEE 802.3 Working Group.

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No special concerns, but Security Directorate review and GenArt 
review should be performed. 

MIB doctor Review of final document has happened. Mike Heard did another
final MIB docor review and submitted it on Oct 16th, 2006. His assesment:

   After re-reading this version of the document, here is my bottom
   line: apart from minor editorial issues that can easily be fixed by
   the RFC Editor, I think that it is ready for publication as a
   proposed standard, and I recommend that it be approved by the IESG.


   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the document,
          detail those concerns here.

Changes were made to teh MIB modules that mildly violate the SMIv2 rules
for updating/modifying MIB modules, as documented in RFC2578. However,
both the WG as well as the MIB doctors consider this violation
acceptable in the given circumstances. This fact is also documented
in the 3rd paragraph of section 3.1.

   (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 WG is not large in numbers nowadays. However, the number and nature
of the contribution and comments show strong consensus and constructive
collaboration behind this document.

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire will
          be entered into the ID Tracker.)

No.

   (1.g)  Has the Document Shepherd verified that the document satisfies
          all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.

Yes.

   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, no references holes or problems. 

   (1.i)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
             Relevant content can frequently be found in the abstract
             and/or introduction of the document.  If not, this may be
             an indication that there are deficiencies in the abstract
             or introduction.

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing IEEE 802.3 Medium
   Attachment Units (MAUs).

   The previous version of this memo, RFC 3636 [RFC3636], defined a
   single MIB module.  This memo splits the original MIB module into
   two, putting frequently updated object identities and textual
   conventions into a separate, IANA-maintained MIB module, in order to
   decrease the need of updating the basic MAU MIB module.

   The first version of the IANA-maintained MIB module also extends the
   list of managed objects to support Ethernet in the First Mile (EFM)
   and 10GBASE-CX4 interfaces.

 
          Working Group Summary
             Was there anything in WG process that is worth noting?  For
             example, was there controversy about particular points or
             were there decisions where the consensus was particularly
             rough?

The document went through several editing cycles in the WG, WGLC and
received a number of comments for improvement. The WG is not large in
numbers nowadays. However, the number and nature of the contribution and
comments show strong consensus and constructive collaboration behind
this document.

          Document Quality
             Are there existing implementations of the protocol?  

We are aware about at least one implementation in progress. 

             Have a
             significant number of vendors indicated their plan to
             implement the specification?  

At the initiation of this work around twelve individuals representing
different vendors organizations expressed interest for this work, and
potential intentions to implement it. 

             Are there any reviewers that
             merit special mention as having done a thorough review,
             e.g., one that resulted in important changes or a
             conclusion that the document had no substantive issues?

Mike Heard did a early and final MIB Doctor review. We also received 
comments from participants who are active in ITU-T Q10/4 and 
IEEE 802.3 Working Group.

Bert Wijnen
WG-chair for the HUBMIB WG.