RE: MIB Doctor Review of draft-ietf-hubmib-rfc3636bis-05 .txt

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:[email protected]]
> Sent: Monday, October 16, 2006 20:40
> To: Edward Beili
> Cc: David Kessens; Wijnen, Bert (Bert); Hub Mib; Romascanu, Dan (Dan)
> Subject: RE: [Hubmib] MIB Doctor Review of
> draft-ietf-hubmib-rfc3636bis-05.txt
> 
> 
> On Mon, 16 Oct 2006, Edward Beili wrote:
> > I would make 2 editorial changes you specified (s/There is a
> > number of/There are a number of/ and s/Management of IEEE 802.3
> > Managed Objects/Mapping of IEEE 802.3 Managed Objects) and
> > submit and updated draft shortly.
> 
> These could also be handled as RFC Editor notes ... I guess it's
> up to David, Bert, and Dan to say what they'd rather have you do.
> 

I agree with Mike here. Certainly if we do not get any more comments
during IETF Last Call, which of course we donot yet know.

And the changes are so minimal, that I'd actaully prefer that Dan adds
a note-to-RFC-Editor to make these changes. 

> Mike
> 

Further Edward asks:
> David/Bert,
> Anything else I should do?
> 

I personally prefer it if we add OBJECT clauses to the MODULE-COMPLIANCE
to list the old enumerations as minimal requirement (i.e. the newly
added labels will not yet be supported by earlier implementations
who claimed compliance with current MODULE-COMPLIANCE statements.

I know that Mike believes such is not needed for read-only objects.
I agree that it is not a fatal flaw if we do not add them for the
read-only objects. The WG has seen this document several times now,
so I assume WG consensus is to leave MODULE-COMPLIANCE as is.

I will re-ask our AD to consider this document for PS.
A PROTO-write-up was done by Dan already and copied to the HUBMIB WG
mailing list on sept 28, copied below for your convenience.

David/Dan, I think you ought to change the Document Shepherd
from Dan to me (Bert).

Bert
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email protected]]
Sent: Thursday, September 28, 2006 11:35
To: David Kessens
Cc: IETF Hub MIB Working Group
Subject: [Hubmib] Submission of draft-ietf-hubmib-rfc3636bis-05 for
consideration as Proposed Standard



David,

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

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?  

Dan Romascanu

          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. 

   (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 MIB Doctor review, Security Directorate review
and GenArt review should be performed. 

   (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.

No. 

   (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 MIB Doctor review. We also received comments from
participants who are active in ITU-T Q10/4 and IEEE 802.3 Working Group.