[Hubmib] Re: WGLC - draft-ietf-hubmib-rfc3636bis-01.txt

On Mon, 18 Apr 2005 23:09:44 +0300, "Romascanu, Dan \(Dan\)" wrote:
> This is a Working Group Last Call announcement for the following
> Internet-Draft:
>
> Definitions of Managed Objects for IEEE 802.3 Medium Attachment
> Units (MAUs) - http://www.ietf.cnri.reston.va.us/internet-drafts/
> draft-ietf-hubmib-rfc3636bis-01.txt
>
> The Working Group intents to submit these documents to the IESG for
> consideration as Proposed Standards. Please send your comments to
> the WG mail list until May 2nd, 2005.
>
> This WGLC overwrites the previous WGLC for
> draft-ietf-hubmib-rfc3636bis-00.txt.

Greetings,

As is my custom, I will use the checklist from Appendix A of the
MIB review guidelines to organize my comments.

1.) I-D Boilerplate -- if the draft is respun for any reason I
think you will want to use the updated I-D boilerplate that refers
to RFCs 3978 and 3979 which replace RFCs 3667 and 3668 respectively.

2.) Abstract -- the last sentence is not needed and would customarily
be omitted, since this memo obsoletes RFC 3636 and RFC 3636 has already
obsoleted RFCs 2668 and 1515.  Also, it is rather long.  I would suggest
rewording along the following lines:

OLD:
   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).  This memo obsoletes RFC 3636.  This memo
   extends that specification by moving MAU type object identities and
   some other relevant textual conventions into a separate Internet
   Assigned Number Authority (IANA) maintained MIB module, first version
   of which is defined in this document.  Thus, when the new MAU types
   are defined by IEEE, only the IANA MIB module needs to be modified,
   leaving the MAU MIB module unchanged.  In addition, management
   information is added for the management of Ethernet in the First Mile
   (EFM) and 10GBASE-CX4 MAUs.  This memo also obsoletes RFC 2668 and
   RFC 1515.

NEW:
   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).  This memo obsoletes RFC 3636.  It amends
   that specification by moving MAU type OBJECT-IDENTITY definitions
   and relevant textual conventions into a separate Internet Assigned
   Number Authority (IANA) maintained MIB module.  In addition,
   management information is added to enable support for Ethernet in
   the First Mile (EFM) and 10GBASE-CX4 MAUs.

3.) MIB Boilerplate -- OK

4.) Security Considerations Section -- OK (unchanged from RFC 3636)

5.) IANA Considerations Section -- since the term Expert Review is used,
there should be a reference to RFC 2434.  Also, I don't think that the
term "MAY be added" captures the intent of the WG;  as I understood the
discussion, the intent is that new MAU and/or Jack types defined by the
IEEE 802.3 WG should be added to the IANA-MAU-MIB as soon as they are
approved for publication by the IEEE, with the exception of things that
aren't suitable for being managed by the MAU-MIB (e.g., things like the
isoethernet MAU type known in clause 30 as "802.9a (99) Integrated
Services MAU as defined in IEEE Std 802.9 ISLAN-16T", which was omitted
from earlier revisions of the MAU-MIB).

OLD:
   This document defines first version of the IANA maintaned MIB module.
   When a new MAU type and/or Jack type is defined by the IEEE 802.3
   working group, it MAY be added to the IANA maintaned module via an
   Expert Review.

NEW:
   This document defines first version of the IANA-maintaned MIB module
   IANA-MAU-MIB.  It is intended that each new MAU type and/or Jack
   type defined by the IEEE 802.3 working group and approved for
   publication in a revision of IEEE Std 802.3 will be added to the
   IANA-maintaned module, provided that it is suitable for being
   managed by the base objects in the MAU-MIB.  An Expert Review, as
   defined in RFC 2434 [RFC2434], is REQUIRED.

Similar revisions to the maintenance instructions in the DESCRIPTION
clause of the IANA-maintained MIB module are also needed.  There is a
non-self-contained reference [IEEE 802.3 Std] in that module which
needs to be defined there, and since it also need to be updated when
additions are made, it too is covered in the following proposed text:

OLD:
         An Expert Review is REQUIRED for the addition of the new
         MAU types, when they are defined in the [IEEE 802.3 Std.].
         Any document that proposes such an addition is REQUIRED to
         note any special properties of the MAU types that it defines
         - for example, side effects on the ifStackTable such as those
         noted in RFC 3636 Section 3.4.1 for 10GBASE-W MAUs.

NEW:
         It is intended that each new MAU type and/or Jack type defined
         by the IEEE 802.3 working group and approved for publication
         in a revision of IEEE Std 802.3 will be added to this MIB
         module, provided that it is suitable for being managed by the
         base objects in the MAU-MIB.  An Expert Review, as defined in
         RFC 2434 [RFC2434], is REQUIRED for such additions.

         The following reference is used throughout this MIB module:

         [IEEE 802.3 Std] refers to:
            IEEE Std 802.3, 2002 Edition: 'IEEE Standard
            for Information technology -
            Telecommunications and information exchange
            between systems - Local and metropolitan
            area networks - Specific requirements -
            Part 3: Carrier sense multiple access with
            collision detection (CSMA/CD) access method
            and physical layer specifications', as
            amended by IEEE Std 802.3ae-2002:
            'Amendment: Media Access Control (MAC)
            Parameters, Physical Layer, and Management
            Parameters for 10 Gb/s Operation', August,
            2002.

         This reference should be updated as appropriate when new
         MAU types and/or Jack types are added to this MIB module.

NOTE: I am not 100% convinced that the awkward phrase "provided that it
is suitable for being managed by the base objects in the MAU-MIB" really
needs to be in the above, and I would shed no tears if it were cut out.

6.) References -- [RFC2434] should be a normative reference, since the
term "Expert Review" that is defined in nthat document needs to be
understood in order to implement the instructions in the IANA
Considerations section.  In the current text this reference is uncited;
that, however, would be fixed by the proposed text in checklist items
#5 and #10.

7.) Copyright Notices -- the copyright notices in the MIB modules need
to have the year updated to 2005.

8.) IPR Notice -- OK

9.) Other issues -- not reviewed.  Since the document has been prepared
with xml2rfc, I have assumed that the "not covered elsewhere" issues
mentioned in http://www.ietf.org/ID-Checklist.html are taken care of.

10.) Technical content -- in this part I cover significant editorial
issues in the text, as well as the content of the MIB modules.

(a) Editorial:  the second and third paragraphs of Section 3.1 could
used some wordsmithing.  Proposed text:

OLD:
   In order to decrease re-issues of this document due to the new MAU
   type introduction, all relevant object identities and textual
   conventions have been moved to a separate, IANA maintained MIB
   module, first version of which is defined in this memo.  Thus when a
   new MAU type is defined by the IEEE 802.3 working group, only the
   IANA maintaned module would be re-issued by IANA, leaving the basic
   MIB module defined in this memo unchanged.

   In addition, the new definitions are added to the IANA maintaned MIB
   module, to support Ethernet in the First Mile (EFM) and 10GBASE-CX4
   interfaces defined in IEEE Std 802.3ah-2004 and IEEE Std 802.3ak-2004
   respectively.

NEW:
   In order to decrease re-issues of this document due to the new MAU
   type and/or Jack type introduction, all relevant object identities
   and textual conventions have been moved to a separate
   IANA-maintained MIB module IANA-MAU-MIB, the first version of which
   is defined in this memo.  Thus when a new MAU type and/or Jack type
   is defined by the IEEE 802.3 working group, only the IANA-maintaned
   module needs to be revised, leaving the basic MAU-MIB module defined
   in this memo unchanged.

   In addition, new definitions are added to the IANA-maintaned MIB
   module to support Ethernet in the First Mile (EFM) and 10GBASE-CX4
   interfaces defined in IEEE Std 802.3ah-2004 [IEEE802.3ah] and IEEE
   Std 802.3ak-2004 [IEEE802.3ak] respectively.

(b) As discussed on the mailing list, the changes made since RFC 3636
do not strictly follow the restrictions on MIB module revisions
specified in RFC 2578 Section 10 and are not guaranteed to be 100%
backward compatible.  In particular, any MIB modules that import the
MAU type OBJECT-IDENTITY descriptors from the MAU-MIB and any management
tools that process those OBJECT-IDENTITY values (e.g., to present the
DESCRIPTION text to a user) will need to be modified to import those
definitions from the IANA-MAU-MIB instead.  Because there is a good
reason for making these changes, the rules can be waived;  however,
the MIB review guidelines do require that both the change and the
justification be properly documented (cf. next-to-last paragraph of
Section 4.9 of <draft-ietf-ops-mib-review-guidelines-04.txt>).  So I
would like to recommend that the following text be added at the end of
Section 3.1, "Relationship to RFC 3636":

NEW:
   It should be noted that the changes made in this revision will not be
   entirely backward-compatible with MIB modules that currently import
   MAU type object identity descriptors from the MAU-MIB;  such modules
   will need to be revised to import those DESCRIPTORS from the
   IANA-MAU-MIB.  Similarly, any management applications that process
   the object identity definitions (e.g., to present the DESCRIPTION
   text to a user) will need to be get those definitions from the
   IANA-MAU-MIB instead of the MAU-MIB.  While it is true that changes
   that require such adjustments are not strictly compliant with the
   SMIv2 rules governing MIB module revisions (see [RFC2578] Section
   10), in this case continued high maintenance costs that would result
   from not making these changes maked the deviation from the rules
   justified.  It should be noted that the working group was not able
   to find any examples of MIB modules or management applications that
   would actually be negatively affected by the changes.

(c)  Section 3.2, "Relationship to RFC 2668", needs to have its text
brought up-to-date (it looks like it was copied without change from
RFC 3636).  Proposed changes:

OLD:
   This MIB is intended to be a superset of that defined by RFC 2668
   [RFC2668].  This MIB includes all of the objects contained in that
   MIB, with new and updated definitions which provide support for
   additional capabilities.  Implementors are encouraged to support all
   applicable conformance groups in order to make the best use of the
   new functionality provided by this MIB.  The new and updated
   definitions provide management support for 10 Gb/s devices.

NEW:
   RFC 3636 was a replacement for RFC 2668 [RFC2668].  RFC 3636
   included all of the objects contained in RFC 2668, but it also
   included new and updated definitions to provide management support
   for 10 Gb/s devices.

(d) Section 3.8.1 could benefit from some wordsmithing.  The
next-to-last paragraph needs a reference to RFC 2434, and the last
paragraph seems to be left over from an earlier proposal to require
a Standards Action to add new MAU/Jack types.  Proposed changes:

OLD:
   An Expert Review is REQUIRED for the addition of the new MAU and Jack
   types.

   Any document that proposes such an addition is REQUIRED to note any
   special properties of the MAU types that it defines - for example,
   side effects on the ifStackTable as noted for 10GBASE-W MAUs.

NEW:
   An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for
   the addition of the new MAU and/or Jack types.

   In some cases new MAU types may require additional managed objects
   or may have side effects on the behavior of existing managed objects.
   In such cases a standards-track specification (which may be a new
   document or a revision of this document) is also REQUIRED.  Any such
   document is REQUIRED to note any special properties of the MAU types
   that it defines - for example, side effects on the ifStackTable as
   noted in this document for 10GBASE-W MAUs.

(e) The IANA-MAU-MIB uses two branches of the OID subtree assigned to
the MAU-MIB.  It is essential that future maintenance activities to
the MAU-MIB not assign any OIDs from these branches.  In order to
help prevent that error, I strongly recommend that there be some
ASN.1 comments in the MAU-MIB to alert maintainers.  Here are the
suggested revisions:

OLD:
      dot3RpMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 }
      dot3IfMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 }
      dot3BroadMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 }

      dot3IfMauAutoNegGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 }

NEW:
      dot3RpMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 }
      dot3IfMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 }
      dot3BroadMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 }

      -- OIDs under the following
      -- branch are reserved for
      -- the IANA-MAU-MIB to assign
      -- as MAU type values:    { snmpDot3MauMgt 4 }

      dot3IfMauAutoNegGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 }

      -- the following OID is the
      -- MODULE-IDENTITY value
      -- for this MIB module:   { snmpDot3MauMgt 6 }

      -- the following OID is the
      -- MODULE-IDENTITY value
      -- for the IANA-MAU-MIB:  { snmpDot3MauMgt 7 }

(f) smidiff tells me that the following DEFVAL clause has been added
to both rpMauType and ifMauType:

        DEFVAL      { zeroDotZero }

This clause implies that zeroDotZero is an acceptable default value
to populate into these objects when the agent creates them.  But
that is not so.  The DESCRIPTION clause states that the values of
these objects must be equal to the actual MAU type, unless that is
unknown to the agent; then, and only then, should it use zeroDotZero.

I respectfully request that these DEFVAL clauses be removed.

For discussion see RFC 2578 Section 7.9.

(g) The DESCRIPTION clause of ifMauTypeListBits needs a small
adjustment owing to the introduction of the IANAifMauTypeListBits TC:

OLD:
                      Note that this MAU may be capable of operating
                      as a MAU type that is beyond the scope of this
                      MIB.  This is indicated by returning the
                      bit value bOther in addition to any bit values
                      for capabilities that are listed above."
NEW:
                      Note that this MAU may be capable of operating
                      as a MAU type that is beyond the scope of this
                      MIB.  This is indicated by returning the
                      bit value bOther in addition to any bit values
                      for standard capabilities that are listed in the
                      IANAifMauTypeListBits TC."

(h) Moving on to the IANA-MAU-MIB, the following text appears in the
DESCRIPTION clauses of both rpMauType and ifMauType :

         The definition of this textual convention with the addition of
         newly assigned values is published periodically by the IANA,
         in either the Assigned Numbers RFC, or some derivative of it
         specific to Internet Network Management number assignments.
         (The latest arrangements can be obtained by contacting the
         IANA.)

This is not entirely appropriate since the Assigned Numbers RFC is no
longer being published (and has not been for over a decade ... see
RFC 3232).  I propose the following replacement:

         The most recent version of this textual convention is
         available in the on-line version of this MIB module
         on the IANA web site.

(i) The REFERENCE clauses for  dot3MauType2BaseTL and
dot3MauType10PassTS contain the citation [EFM-CU-MIB], which is not
defined in the MIB module (or, for that matter, anywhere else in the
document).  Since we require that MIB modules be self-contained, this
reference either needs to be defined or needs to be removed.  I
recommend the latter.  Here is the recommended text:

OLD:
     dot3MauType2BaseTL OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Voice grade UTP copper, up to 2700m "
       REFERENCE   "[IEEE 802.3 Std.], Sections 61 and 63; [EFM-CU-MIB]"
       ::= { dot3MauType 42 }

     dot3MauType10PassTS OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Voice grade UTP copper, up to 750m"
       REFERENCE   "[IEEE 802.3 Std.], Sections 61 and 62; [EFM-CU-MIB]"
       ::= { dot3MauType 43 }
NEW:
     dot3MauType2BaseTL OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Voice grade UTP copper, up to 2700m "
       REFERENCE   "[IEEE 802.3 Std.], Sections 61 and 63"
       ::= { dot3MauType 42 }

     dot3MauType10PassTS OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Voice grade UTP copper, up to 750m"
       REFERENCE   "[IEEE 802.3 Std.], Sections 61 and 62"
       ::= { dot3MauType 43 }

(j) For completeness, I have attached the smilint and smidiff reports
for the IANA-MAU-MIB and MAU-MIB.  I have reviewed them and believe
that all issues are accounted for above, but I would urge WG members
and the document editor to double check.  NOTE: the complaints about
not starting new BITS values on a byte boundary should be IGNORED,
text in RFC 2578 to the contrary notwithstanding.  It does not matter
for this object, which is read-only and where the absence of a bit
means the same thing as its having the value zero, namely, that the
corresponding MAU type is not offered/supported.

Thanks for your patience.

Regards,

Mike Heard