[Hubmib] rfc3636bis-02

Mike,

I've submitted the 02 version of rfc3636bis (MAU-MIB). It will probably take a day or two for the official IETF announcement, so I've attached it for your convenience.

Most changes were done according to your comments, see below.

I'd like to ask your advice on 2 issues:

1. Currently the values for the ifMauTypeListBits are defined in the
   IANA-MAU-MIB, while the values for the ifMauAutoNegCapabilityBits,
   ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits objects
   are defined in MAU-MIB.
   While none of the newly added MAU types (10GBASE-CX4, 2BASE-TL,
   10PASS-TS, 100BASE-LX/BX, 1000BASE-LX/BX/PX) supports
   auto-negotiation, this may change in the future (e.g. I don't see
   a reason not to support it on P2P (-LX/BX) optical links as well as
   for some new types). I suggest to put TC for these objects in the
   IANA-MAU-MIB as well.

2. I left ianaMauMIB and dot3MauType location as it was in v01,
   adding the relevant ASN comments in the MIB.
   I do agree however with your past argument about moving
   ianaMauMIB under mib-2 (and subsequently dot3MauType under
   ianaMauMIB). If the working group agrees I would do the
   change in the next draft.

Regards,
-Edward

---------------------------------------------------------------------------
> From:  	 hubmib-bounces@ietf.org on behalf of C. M. Heard
> Sent:  	 Sun 4/24/2005 7:29 AM
> To:		 Hub Mib
> Subject:  	 [Hubmib] Re: WGLC - draft-ietf-hubmib-rfc3636bis-01.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.

[EB] Done.

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

[EB] Done.

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

[EB] Done, with an ommition of "provided that it is suitable for being
     managed by the base objects in the MAU-MIB"

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

[EB] Done, with addition of 802.3ak and ommition of "provided that it
     is suitable for being managed by the base objects in the MAU-MIB"

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

[EB] RFC2434 has been moved to the Normative References section.

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

[EB] Done.

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

[EB] Correct.

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

[EB] Done.

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

[EB] Great text. Done.

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

[EB] Done.

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

[EB] Done.

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

[EB] Done.
     I do agree however with your past argument about moving
     ianaMauMIB under mib-2 (and subsequently dot3MauType under
     ianaMauMIB). If the working group agrees I would do the
     change in the next draft.

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

[EB] Done.

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

[EB] Done.
     Actually your comment has caused me to look at 
     ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits and 
     ifMauAutoNegCapReceivedBits objects defined in MAU-MIB - while
     none of the newly added MAU types (10GBASE-CX4, 2BASE-TL,
     10PASS-TS, 100BASE-LX/BX, 1000BASE-LX/BX/PX) supports
     auto-negitiation, this may change in the future (e.g. I don't see
     a reason not to support it on P2P optical links as well as for
     some new types). I suggest to put TC for these objects in the
     IANA-MAU-MIB as well.

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

[EB] Done, changed also for IANAifJackType.

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

[EB] Done.

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

[Hubmib] rfc3636bis-02

Attachment: draft-ietf-hubmib-rfc3636bis-02.txt

Attachment: draft-ietf-hubmib-rfc3636bis-02.html