Subject: [Hubmib] Re: rfc3636bis-02

From: "C. M. Heard" <[email-masked]>
Date: Mon, 24 Oct 2005 06:57:51 -0700 (PDT)

On Mon, 24 Oct 2005, Edward Beili wrote:
> 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.

Thanks, I'll look it over and provide comments as soon as I am able.

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

The WG of course has the last word but this suggestion does seem logical
to me.  Since the SYNTAX clauses for the three above-mentioned objects
are identical, a single new IANA-maintained TC would suffice.

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

I can live with it the way it is, now that we have the ASN.1 comments
to help prevent duplicate assignments, but I would still prefer to
see it moved.  But as you say the WG has the last word.

Thanks again for getting this version posted.

Mike

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Edward Beili" <[email-masked]>
Date: Mon, 24 Oct 2005 14:07:33 +0200

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.

Regards,
-Edward

---------------------------------------------------------------------------
> From:  	 [email-masked] 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.

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 29 Oct 2005 22:37:22 -0700 (PDT)

> Thanks, I'll look it over and provide comments as soon as I am able.

I've finally been able to read the document, and the only thing that
I have to add to my message of 24 October is that there is a typo on
the 2nd sentence on page 5:  s/maked/make/.  This typo was present
in the suggested text in my WGLC comments on -01;  sorry about that.

//cmh

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 30 Oct 2005 11:47:25 +0200

This is a Working Group Last Call announcement for the following
Internet-Drafts:
 
Ethernet in the First Mile Copper (EFMCu) Interfaces MIB  -
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-
cu-mib-04.txt
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units
(MAUs) -
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-rfc3
636bis-02.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 November 13, 2005. 
 
Thanks and Regards,
 
Dan

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 30 Oct 2005 10:41:31 -0800 (PST)

>>>>> On Sun, 30 Oct 2005, Romascanu, Dan (Dan) wrote:
Dan> This is a Working Group Last Call announcement for the following
Dan> Internet-Drafts:
Dan>
Dan> Ethernet in the First Mile Copper (EFMCu) Interfaces MIB  -
Dan> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-cu-mib-04.txt
Dan> Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units
Dan> (MAUs) -
Dan> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-rfc3636bis-02.txt
Dan>
Dan> The Working Group intents to submit these documents to the IESG for
Dan> consideration as Proposed Standards. Please send your comments to the WG
Dan> mail list until November 13, 2005.

Hi Dan, I have two comments about 3636bis.  These should not in any way be
construed as "blocking" comments -- I would be OK with the document going
forward as is -- but I do think that the WG might want to consider them.

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

>>>>> On Mon, 24 Oct 2005, C. M. Heard replied:
C> The WG of course has the last word but this suggestion does seem logical
C> to me.  Since the SYNTAX clauses for the three above-mentioned objects
C> are identical, a single new IANA-maintained TC would suffice.

If there is a realistic possibility that future MAU types will support
auto-negotiation, then it is probably advantageous to put the capability
list under IANA maintenance so that it (like the MAU types) can be
expanded quickly upon approval of a new 802.3 standard.  The main
counter-argument would be that doing this would lengthen an already
protracted process.  In making a decision it might be useful to solicit
input from the 802.3 WG regarding the likelihood of the introduction of
new auto-negotiation capabilities.

2.) The second comment concerns the following issue from RFC 2578
Section 7.1.4:

   As part of updating an information module, for an object defined
   using the BITS construct, new enumerations can be added or existing
   enumerations can have new labels assigned to them.  After an
   enumeration is added, it might not be possible to distinguish between
   an implementation of the updated object for which the new enumeration
   is not asserted, and an implementation of the object prior to the
   addition.  Depending on the circumstances, such an ambiguity could
   either be desirable or could be undesirable.  The means to avoid such
   an ambiguity is dependent on the encoding of values on the wire;
   however, one possibility is to define new enumerations starting at
   the next multiple of eight bits.  (Of course, this can also result in
   the enumerations no longer being contiguous.)

For the TCs in the IANA-MAU-MIB -- including the one for auto-negotiation
capabilities, if it is added -- there is clearly no reason to allocate new
enumerations at multiples of 8 bits.  The only use of IANAifMauTypeListBits 
is in defining the read-only object ifMauTypeListBits, which advertises
capabilities of the MAU.  If new enumerations are defined but the
corresponding bits are not set by an agent, it has exactly the same meaning
to a management application as if the enumerations didn't exist to the
agent, namely, that the MAU cannot be set for those types.  And if bits
are set by the agent that the manager does not know about, it just means
that the MAU supports modes that the mamager does not know about;  it is
irrelevant whether the extra bits occur on a new octet boundary or not.

The situation with ifMauAutoNegCapabilityBits and ifMauAutoNegCapReceivedBits
is the same and with ifMauTypeListBits.  It is a little different with
ifMauAutoNegCapAdvertisedBits because the object is read-write, but the
action that needs to be taken by a manager to modify the value is already
prescribed by the DESCRIPTION clauses:  it needs to read
ifMauAutoNegCapabilityBits, clear the bits for capabilities it wishes to
turn off, and then write the value back to ifMauAutoNegCapAdvertisedBits.
Allocation of newly-defined bits on 8-bit boundaries does not offer any
help in this process.

I am belaboring this point because the smidiff tool always gives a
level [3] {named-bit-added-old-byte} error message for new named bits
that are allocated in an existing byte, and some people might be
convinced by this that they need to put gaps into bit allocations for
IANAifMauTypeListBits.  We might therefore want to consider including
the following in the DESCRIPTION clause for that TC:

  New enumerations need not be allocated on a multiple of 8 bits.

The same should be done for the proposed auto-negotiation capabilities TC
if it is implemented.

Let me reiterate once again that I would have no objection of the WG
chooses not to implement either of these suggestions.  Having the
document move forward in its present form would be OK by me.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 30 Oct 2005 17:11:16 -0800 (PST)

On Sun, 30 Oct 2005, I wrote, regarding Edward Beili's proposal to
add a TC for auto-negotiation capabilities to the IANA-MAU-MIB and
use it in the definitions of ifMauAutoNegCapabilityBits,
ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits:

> If there is a realistic possibility that future MAU types will
> support auto-negotiation, then it is probably advantageous to
> put the capability list under IANA maintenance so that it (like
> the MAU types) can be expanded quickly upon approval of a new
> 802.3 standard.  The main counter-argument would be that doing
> this would lengthen an already protracted process.  In making a
> decision it might be useful to solicit input from the 802.3 WG
> regarding the likelihood of the introduction of new
> auto-negotiation capabilities.

I just went poking around on the 802.3 web site and found the
following document that was presented at the Oct. 17 - 18, 2005
interim meeting of the P802.3an (10GBASE-T) Task Force:

http://grouper.ieee.org/groups/802/3/an/public/oct05/vandoorn_1_1005.pdf

It discusses auto-negotiation registers for 10GBASE-T.  I think that
is pretty strong evidence that there is indeed a realistic
possibility that future MAU types will support auto-negotiation.

Regards,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 31 Oct 2005 13:52:04 -0800 (PST)

> auto-negotiation capabilities.

I just noticed that there is (at least) one more object in the MAU-MIB
that has MAU-type-specific values, and that is the enumerated INTEGER
object ifMauMediaAvailable.  Additional enumerated values for this
object may well be required for future MAU types, so there may be
reason to put its enumerations under IANA maintenance as well.

Edward, are there any more such objects lurking in the MAU-MIB?

Mike