RE: IANA Maintained TC for MAU types

Mike,
I've submitted the first revision of MAU-MIB - draft-ietf-hubmib-rfc3636bis-00
available at: http://www.actelis.com/efm/

As far as I can tell no publically available MIBs import dot3MauType OBJECT-IDENTITIES.
However, if there is a problem, I would suggest to import from IANA-MAU-TC-MIB all OBJECT-IDENTITIES available in todays rfc3636 into the new MAU-MIB.

Also, while changing description of rpMauType and ifMauType, I noticed a text reference to 
unknownMauType OBJECT IDENTIFIER ::= { 0 0 }, which is never defined anywhere in the MIB.
I suggest to import existing zerDotZero object from SNMPv2-SMI (defined as {0 0}), and adding
DEFVAL { zeroDotZero } to rpMauType and ifMauType.

I would appreciate your comments.

Regards,
-Edward

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf
Of C. M. Heard
Sent: Wednesday, August 04, 2004 6:26 PM
To: Hub Mib
Subject: [Hubmib] IANA Maintained TC for MAU types


On Tue, 3 Aug 2004, Romascanu, Dan (Dan) wrote:
> The Ethernet interfaces and hub MIB WG (hubmib) met for one
> session at the 60th IETF. The WG discussed the latest changes,
> comments and open issues for the three chartered WG
> Internet-Drafts related to the Ethernet First Mile (EFM)
> technology.  The participants in the meeting recommended that
> the MAU MIB be re-written to refer to a IANA-maintained Textual
> Convention, which would ease the support for new MAUs in the
> future, without requiring opening of the MAU MIB documents.

I'd like to make a few comments about this idea.  The first point is
that what needs to be extended in the MAU-MIB is not just a single
BITS type definition but rather a BITS type definition that is lined
up with a matched set of OBJECT-IDENTITY definitions.  The affected
definitions in the MAU-MIB are these OBJECT-IDENTITY definitions:

       dot3MauType
           OBJECT IDENTIFIER ::= { snmpDot3MauMgt 4 }

       dot3MauTypeAUI OBJECT-IDENTITY
           STATUS      current
           DESCRIPTION "no internal MAU, view from AUI"
           REFERENCE   "[IEEE 802.3 Std.], Section 7"
           ::= { dot3MauType 1 }

       [ ... ]

       dot3MauType10GigBaseSW OBJECT-IDENTITY
           STATUS      current
           DESCRIPTION "W fiber over 850 nm optics"
           REFERENCE   "[IEEE 802.3 Std.], Section 52"
           ::= { dot3MauType 40 }

and the BITS type in the following OBJECT-TYPE definition:

       ifMauTypeListBits OBJECT-TYPE
           SYNTAX      BITS {
               bOther(0),         -- other or unknown
               bAUI(1),           -- AUI
               [ ... ]
               b10GbaseSW(40)     -- 10GBASE-SW
           }
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION "A value that uniquely identifies the set of
                       possible IEEE 802.3 types that the MAU could be.
                       If auto-negotiation is present on this MAU, this
                       object will map to ifMauAutoNegCapabilityBits.

                       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."
           ::= { ifMauEntry 13 }

The IANA-maintained MIB module would need to contain the
dot3MauType* OBJECT-IDENTITY definitions along with a TC (which
might be called IANAifMauTypeListBits) that whose SYNTAX clause is
what is presently in ifMauTypeListBits.  That, of course, is because
these items have to remain in sync and so have to be maintained in
parallel.  The IANA-maintained module would, of course, import the
base OID descriptor dot3MauType from the MAU-MIB.

One minor backward-compatibility issue is that migrating the
OBJECT-IDENTITY definitions in this way could cause problems if any
existing MIB modules have imported those descriptors from MAU-MIB.
This could be addressed by keeping the existing list of dot3MauType*
descriptors in the MAU-MIB as object identifier value assignments;
while RFC 2578 does not permit two "registrations" of the same OID
value, it does allow a descriptor to be associated with both a
registration and an object identifier value assignment, providing
both are associated with the same OBJECT IDENTIFIER value and
semantics (cf. Section 3.6).

Another issue that needs to be addressed is what rules apply to new
MAU types.  My thinking is that this should be allowed ONLY by a
Standards Action (as defined in RFC 2434) -- or at least IETF
Consensus -- so that any prospective assignments are documented in
an RFC.  Any document that proposes such an assignment should also
be required to note any special properties of the MAU types that it
defines -- for example, side effects on the ifStackTable such as are
noted in RFC 3636 Section 3.4.1 for 10GBASE-W MAUs.

Also to be noted is that the MAU-MIB itself will need some minor
modifications beyond those discussed above, such as the DESCRIPTION
clauses for rpMauType and ifMauType.   A good editor is needed to
ferret all those things out.

One final point:  in his reply to Dan Romascanu's comments on
draft-ietf-hubmib-efm-epon-mib-01.txt, Lior Khermosh said:

> Sorry for being not clear but my intention is that MAU type
> objects in the MAU section should be added to the MAUMIBs as
> with the efm-cu document. If it is not done there then the MAU
> section in the efm-epon mib should contain them (as now).

My position would be that we MUST modify the MAU-MIB -- either
directly or by putting the MAU types into an IANA-maintained module
-- to contain the new MAU type definitions.  It invites catastrophe
(i.e., conflicting OID/bit position assignments) if the values
assigned to MAU types are scattered over several documents.  I do
agree that it is OK to split off MAU-specific stats counters and so
on and put those in a separate module;  in fact there is no
practical alternative to doing so if we don't want to change the
MAU-MIB every time we add an MAU type that requires such things.

Regards,

Mike Heard


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