RE: IANA Maintained TC for MAU types

Mike,
 
It looks like you've already thought about it. Would you like to do the editing of the MAU MIB?
 
While we are on the subject of MAU MIB I would like to share a little problem I'm having in EFM-CU-MIB:
As of today the IEEE P802.3af/D3.3 specifies oMAU being a sibling of the oPAF under a common oPHYEntity (see Figure 3-3 on page 692), which creates an impression that ifMauType is an attribute of the PHY (PCS) layer. Traditionally MAU is associated with PMA (see figure 4-1 on page 70 of 802.3-2002), which is actually a part of PME in EFMCu PHYs.
 
So, I see 2 main alternatives for EFMCu PHYs:
 
1. Not to use MAU MIB at all and instead use appropriate ifType values (should be defined in IANAifType-MIB) for both PCS and PME ports. Note also that EFMCu ports don't use MAU auto-negotiation, media available, false carriers or jabber, so there really no reason for using MAU-MIB apart from the fact that all EtherLike interfaces are required to use it.
 
2. Use ifMauType for PMEs only (theoretically PMEs can support a number of types so ifMauTypeList can be handy here). The PCS ifType would stay ethernetCsmacd and the real type would be returned in efmCuType and efmCuPortSide.
 
Your comments are appreciated.
 
Regards,
-E.

	-----Original Message----- 
	From: [email protected] on behalf of C. M. Heard 
	Sent: Wed 8/4/2004 7:25 PM 
	To: Hub Mib 
	Cc: 
	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

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