--- 1/draft-ietf-hubmib-mau-mib-v2-00.txt 2006-02-04 23:26:16.000000000 +0100 +++ 2/draft-ietf-hubmib-mau-mib-v2-01.txt 2006-02-04 23:26:16.000000000 +0100 @@ -6,26 +6,26 @@ K. de Graaf Argon Networks D. Romascanu LANNET Ltd. D. McMaster Cisco Systems, Inc. K. McCloghrie Cisco Systems, Inc. S. Roberts Farallon Computing, Inc. - May 1998 + November 1998 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 - + Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any @@ -37,254 +37,222 @@ Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract - This memo defines an experimental portion of the Management - Information Base (MIB) for use with network management protocols in - the Internet community. In particular, it defines objects for - managing 10, 100 and 1000Mb/second Medium Attachment Units (MAUs) - based on IEEE Draft P802.3/D4.2 Section 30, "10, 100 & 1000 Mb/s - Management," March 1998. + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + + This memo obsoletes RFC 2239, ''Definitions of Managed Objects for + IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2''. This memo + extends that specification by including management information useful + for the management of 1000 Mb/s MAUs. + + Ethernet technology, as defined by the 802.3 Working Group of the + IEEE, continues to evolve, with scalable increases in speed, new + types of cabling and interfaces, and new features. This evolution + may require changes in the managed objects in order to reflect this + new functionality. This document, as with other documents issued by + this working group, reflects a certain stage in the evolution of + Ethernet technology. In the future, this document might be revised, + or new documents might be issued by the Ethernet Interfaces and Hub + MIB Working Group, in order to reflect the evolution of Ethernet + technology. - This memo does not specify a standard for the Internet community. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. Table of Contents 1. Introduction ............................................... 2 - 2. The SNMP Network Management Framework ...................... 3 - 2.1. Object Definitions ....................................... 3 - 3. Change Log ................................................. 3 - 4. Overview ................................................... 4 - 4.1. Relationship to RFC 2239 ................................. 4 - 4.2. Relationship to RFC 1515 ................................. 5 - 4.3. MAU Management ........................................... 5 - 4.4. Relationship to Other MIBs ............................... 5 - 4.4.1. Relationship to the Interfaces MIB ..................... 6 - 4.4.2. Relationship to the 802.3 Repeater MIB ................. 6 - 4.5. Management of Internal MAUs .............................. 6 - 5. Definitions ................................................ 6 - 6. Intellectual Property ...................................... 47 - 7. Acknowledgements ........................................... 47 - 8. References ................................................. 48 - 9. Security Considerations .................................... 50 - 10 Authors' Addresses ......................................... 50 - 11. Full Copyright Statement .................................. 51 + 2. The SNMP Management Framework .............................. 3 + 3. Overview ................................................... 4 + 3.1. Relationship to RFC 2239 ................................. 4 + 3.2. Relationship to RFC 1515 ................................. 4 + 3.3. MAU Management ........................................... 4 + 3.4. Relationship to Other MIBs ............................... 5 + 3.4.1. Relationship to the Interfaces MIB ..................... 5 + 3.4.2. Relationship to the 802.3 Repeater MIB ................. 5 + 3.5. Management of Internal MAUs .............................. 5 + 4. Definitions ................................................ 6 + 5. Intellectual Property ...................................... 47 + 6. Acknowledgements ........................................... 48 + 7. References ................................................. 48 + 8. Security Considerations .................................... 51 + 9. Authors' Addresses ......................................... 51 + A. Change Log ................................................. 53 + B. Full Copyright Statement ................................... 54 1. Introduction 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 also includes a MIB module. This MIB module extends the list of managed objects specified in the earlier version of this MIB: - RFC 2239 [18]. + RFC 2239 [21]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [17]. - -2. The SNMP Network Management Framework - - The SNMP Network Management Framework presently consists of six major - components. They are: - - o the overall architecture, described in RFC 2271 [12]. - - o the SMI, described in RFC 1902 [7], - the mechanisms used for - describing and naming objects for the purpose of management. - - o the MIB-II, STD 17, RFC 1213 [5], - the core set of managed - objects for the Internet suite of protocols. + document are to be interpreted as described in [20]. - o the protocol, RFC 1157 [11] and/or RFC 1905 [10] and/or - RFC 2272 [13] -- the protocol for accessing managed - information. +2. The SNMP Management Framework - o the user-based security model defined in RFC 2274 [15]. + The SNMP Management Framework presently consists of five major + components: - o the view-based access control model defined in RFC 2275 [16]. + o An overall architecture, described in RFC 2271 [1]. - Textual conventions are defined in RFC 1903 [8], and conformance - statements are defined in RFC 1904 [9]. Common applications are - defined in RFC 2273 [14]. + o Mechanisms for describing and naming objects and events for the + purpose of management. The first version of this Structure of + Management Information (SMI) is called SMIv1 and described in + RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, + called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC + 1904 [7]. - The Framework permits new objects to be defined for the purpose of - experimentation and evaluation. + o Message protocols for transferring management information. The + first version of the SNMP message protocol is called SNMPv1 and + described in RFC 1157 [8]. A second version of the SNMP message + protocol, which is not an Internet standards track protocol, is + called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. + The third version of the message protocol is called SNMPv3 and + described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. - This memo specifies a MIB module that is compliant to the SNMPv2 SMI. - A semantically identical MIB conforming to the SNMPv1 SMI can be - produced through the appropriate translation. + o Protocol operations for accessing management information. The + first set of protocol operations and associated PDU formats is + described in RFC 1157 [8]. A second set of protocol operations + and associated PDU formats is described in RFC 1905 [13]. -2.1. Object Definitions + o A set of fundamental applications described in RFC 2273 [14] and + the view-based access control mechanism described in RFC 2275 + [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are - defined using the subset of Abstract Syntax Notation One (ASN.1) [4] - defined in the SMI. In particular, each object type is named by an - OBJECT IDENTIFIER, an administratively assigned name. The object - type together with an object instance serves to uniquely identify a - specific instantiation of the object. For human convenience, we - often use a textual string, termed the descriptor, to refer to the - object type. - -3. Change Log - This section enumerates the changes made to RFC 2239 to produce this - document. - - (1) The MODULE-IDENTITY has been updated to reflect the changes - in the MIB. - - (2) OBJECT-IDENTITY definitions have been added for gigabit MAU - types. - - (3) The ifMauTypeList, ifMauAutoNegCapability, - ifMauAutoNegCapAdvertised and ifMauAutoNegCapReceived - objects have been deprecated and replaced by - ifMauTypeListBits, ifMauAutoNegCapabilityBits, - ifMauAutoNegCapAdvertisedBits and - ifMauAutoNegCapReceivedBits. - - (4) Two new objects, ifMauAutoNegRemoteFaultAdvertised and - ifMauAutoNegRemoteFaultReceived have been added. - - (5) Enumerations for 'offline' and 'autoNegError' have been - added for the rpMauMediaAvailable and ifMauMediaAvailable - objects. - - (6) The mauIfGrp100Mbs and mauIfGrpAutoNeg object groups have - been deprecated and replaced by mauIfGrpHighCapacity and - mauIfGrpAutoNeg2. - - (7) A new object group, mauIfGrpAutoNeg1000Mbps, has been added. - - (8) The mauModIfCompl compliance has been deprecated and - replaced by mauModIfCompl2. - - (9) Added section on relationship to RFC 2239. - - (10) Updated the SNMP Network Management Framework boilerplate. - - (11) Refer to the Interfaces MIB, rather than the interfaces - group of MIB-II. + defined using the mechanisms defined in the SMI. - (12) An intellectual property notice was added, as required by - RFC 2026. + This memo specifies a MIB module that is compliant to the SMIv2. A + MIB conforming to the SMIv1 can be produced through the appropriate + translations. The resulting translated MIB must be semantically + equivalent, except where objects or events are omitted because no + translation is possible (use of Counter64). Some machine readable + information in SMIv2 will be converted into textual descriptions in + SMIv1 during the translation process. However, this loss of machine + readable information is not considered to change the semantics of the + MIB. -4. Overview +3. Overview -4.1. Relationship to RFC 2239 +3.1. Relationship to RFC 2239 This MIB is intended to be a superset of that defined by RFC 2239 - [18], which will go to historic status. This MIB includes all of the + [21], which will go to historic status. This MIB includes all of the objects contained in that MIB, plus several new ones which provide 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 objects provide management support for: - o management of 1000 Mb/s interface devices + o management of 1000 Mb/s devices o management of PAUSE negotiation o management of remote fault status -4.2. Relationship to RFC 1515 +3.2. Relationship to RFC 1515 - RFC 2239 was a replacement for RFC 1515 [19], which is now historic. + RFC 2239 was a replacement for RFC 1515 [22], which is now historic. RFC 2239 defined a superset of RFC 1515 which contained all of the objects defined in RFC 1515, plus several new ones which provided additional capabilities. The new objects in RFC 2239 provided management support for: o management of 100 Mb/s devices o auto-negotiation on interface MAUs o jack management -4.3. MAU Management +3.3. MAU Management Instances of these object types represent attributes of an IEEE 802.3 MAU. Several types of MAUs are defined in the IEEE 802.3 CSMA/CD - standard [1] and [2]. These MAUs may be connected to IEEE 802.3 - repeaters or to 802.3 (Ethernet-like) interfaces. For convenience - this document refers to these devices as "repeater MAUs" and - "interface MAUs." + standard [16]. These MAUs may be connected to IEEE 802.3 repeaters + or to 802.3 (Ethernet-like) interfaces. For convenience this document + refers to these devices as "repeater MAUs" and "interface MAUs." The definitions presented here are based on Section 30.5, "Layer Management for 10, 100 & 1000 Mb/s Medium Attachment Units (MAUs)", - and Annex 30A, "GDMO Specifications for 802.3 managed objects" of - IEEE Draft P802.3z/D4.2 [2]. That specification includes definitions - for 10Mb/s, 100Mb/s and 1000Mb/s devices. This specification is - intended to serve the same purpose: to provide for management of all - types of Ethernet/802.3 MAUs. + and Annex 30A, "GDMO Specifications for 802.3 managed object classes" + of IEEE Std. 802.3, 1998 edition [16]. That specification includes + definitions for 10Mb/s, 100Mb/s and 1000Mb/s devices. This + specification is intended to serve the same purpose: to provide for + management of all types of Ethernet/802.3 MAUs. -4.4. Relationship to Other MIBs +3.4. Relationship to Other MIBs It is assumed that an agent implementing this MIB will also implement - (at least) the 'system' group defined in MIB-II [5]. The following + (at least) the 'system' group defined in MIB-II [18]. The following sections identify other MIBs that such an agent should implement. -4.4.1. Relationship to the Interfaces MIB. +3.4.1. Relationship to the Interfaces MIB. The sections of this document that define interface MAU-related - objects specify an extension to the Interfaces MIB [6]. An agent + objects specify an extension to the Interfaces MIB [19]. An agent implementing these interface-MAU related objects MUST also implement the relevant groups of Interface MIB. The value of the object ifMauIfIndex is the same as the value of 'ifIndex' used to instantiate the interface to which the given MAU is connected. It is expected that an agent implementing the interface-MAU related objects in this MIB will also implement the Ethernet-like Interfaces - MIB, [20]. + MIB, [23]. (Note that repeater ports are not represented as interfaces in the Interface MIB.) -4.4.2. Relationship to the 802.3 Repeater MIB +3.4.2. Relationship to the 802.3 Repeater MIB The section of this document that defines repeater MAU-related objects specifies an extension to the 802.3 Repeater MIB defined in - [3]. An agent implementing these repeater-MAU related objects MUST + [17]. An agent implementing these repeater-MAU related objects MUST also implement the 802.3 Repeater MIB. The values of 'rpMauGroupIndex' and 'rpMauPortIndex' used to - instantiate a repeater MAU variable shall be the same as the values + instantiate a repeater MAU variable SHALL be the same as the values of 'rptrPortGroupIndex' and 'rptrPortIndex' used to instantiate the port to which the given MAU is connected. -4.5. Management of Internal MAUs +3.5. Management of Internal MAUs In some situations, a MAU can be "internal" -- i.e., its functionality is implemented entirely within a device. For example, a managed repeater may contain an internal repeater-MAU and/or an internal interface-MAU through which management communications originating on one of the repeater's external ports pass in order to reach the management agent associated with the repeater. Such internal MAUs may or may not be managed. If they are managed, objects describing their attributes should appear in the appropriate MIB subtree: dot3RpMauBasicGroup for internal repeater-MAUs and dot3IfMauBasicGroup for internal interface-MAUs. -5. Definitions +4. Definitions MAU-MIB DEFINITIONS ::= BEGIN + IMPORTS Counter32, Integer32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF; @@ -282,22 +250,23 @@ Counter32, Integer32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF; mauMod MODULE-IDENTITY - LAST-UPDATED "9805122217Z" -- May 12, 1998 - ORGANIZATION "IETF IEEE 802.3 Hub MIB Working Group" + LAST-UPDATED "9811060040Z" -- November 6, 1998 + ORGANIZATION "IETF Ethernet Interfaces and Hub MIB + Working Group" CONTACT-INFO "WG E-mail: hubmib@hprnd.rose.hp.com To subscribe: hubmib-request@hprnd.rose.hp.com Chair: Dan Romascanu Postal: LANNET Ltd. Atidim Technology Park, Bldg. 3 Tel Aviv 61131 Israel Tel: +972 3 645 8414, 6458458 @@ -324,53 +293,49 @@ Kathryn de Graaf Postal: Argon Networks 25 Porter Road Littleton, MA 01460 USA Tel: +1 978 486 0665 x163 Fax: +1 978 486 9379 E-mail: kdegraaf@argon.com" DESCRIPTION "Management information for 802.3 MAUs. - The following references are used throughout + The following reference is used throughout this MIB module: - [IEEE 802.3 Std] - refers to IEEE 802.3/ISO 8802-3 Information - processing systems - Local area networks - - Part 3: Carrier sense multiple access with - collision detection (CSMA/CD) access method - and physical layer specifications (1993), - and to IEEE Draft P802.3z/D4.2 - MAC - Parameters, Physical Layer, Repeater and - Management Parameters for 1000 Mb/s - Operation, Supplement to IEEE Std 802.3, - March 1998. + [IEEE 802.3 Std] refers to + IEEE Std 802.3, 1998 Edition: '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', + September 1998. - [IEEE 802.3 Mgt] - refers to IEEE Draft P802.3z/D4.2 - 10 Mb/s, - 100 Mb/s & 1000 Mb/s Management, Section 30 - - Supplement to IEEE Std 802.3." + Of particular interest is Clause 30, '10Mb/s, + 100Mb/s and 1000Mb/s Management'." - REVISION "9805122217Z" + REVISION "9811060040Z" -- November 6, 1998 DESCRIPTION "Updated to include support for 1000 Mb/sec MAUs and flow control negotiation." - REVISION "9710310000Z" + REVISION "9710310000Z" -- October 31, 1997 DESCRIPTION "Version published as RFC 2239." ::= { snmpDot3MauMgt 6 } snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 } -- textual conventions - JackType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Common enumeration values for repeater and interface MAU jack types." SYNTAX INTEGER { other(1), rj45(2), rj45S(3), -- rj45 shielded db9(4), bnc(5), @@ -372,21 +337,23 @@ other(1), rj45(2), rj45S(3), -- rj45 shielded db9(4), bnc(5), fAUI(6), -- female aui mAUI(7), -- male aui fiberSC(8), fiberMIC(9), fiberST(10), - telco(11) + telco(11), + mtrj(12), -- fiber MT-RJ + hssdc(13) -- fiber channel style-2 } dot3RpMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 } dot3IfMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 } dot3BroadMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 } dot3IfMauAutoNegGroup @@ -642,55 +609,55 @@ ::= { rpMauEntry 2 } rpMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same port (rpMauPortIndex)." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.1, aMAUID." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID." ::= { rpMauEntry 3 } rpMauType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the MAU type. An initial set of MAU types are defined above. The assignment of OBJECT IDENTIFIERs to new types of MAUs is managed by the IANA. If the MAU type is unknown, the object identifier unknownMauType OBJECT IDENTIFIER ::= { 0 0 } is returned. Note that unknownMauType is a syntactically valid object identifier, and any conformant implementation of ASN.1 and the BER must be able to generate and recognize this value." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.2, aMAUType." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.2, aMAUType." ::= { rpMauEntry 4 } rpMauStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), shutdown(5), reset(6) } MAX-ACCESS read-write STATUS current - DESCRIPTION "The current state of the MAU. This object may + DESCRIPTION "The current state of the MAU. This object MAY be implemented as a read-only object by those agents and MAUs that do not implement software control of the MAU state. Some agents may not support setting the value of this object to some of the enumerated values. The value other(1) is returned if the MAU is in a state other than one of the states 2 through 6. @@ -705,40 +672,40 @@ A MAU in standby(4) state forces DI and CI to idle and the media transmitter to idle or fault, if supported. Standby(4) mode only applies to link type MAUs. The state of rpMauMediaAvailable is unaffected. A MAU in shutdown(5) state assumes the same condition on DI, CI, and the media transmitter as though it were powered down or not connected. - The MAU may return other(1) value for the + The MAU MAY return other(1) value for the rpMauJabberState and rpMauMediaAvailable objects when it is in this state. For an AUI, this state will remove power from the AUI. Setting this variable to the value reset(6) resets the MAU in the same manner as a power-off, power-on cycle of at least one-half second would. The agent is not required to return the value reset (6). Setting this variable to the value operational(3), standby(4), or shutdown(5) causes the MAU to assume the respective state except that setting a mixing-type MAU or an AUI to standby(4) will cause the MAU to enter the shutdown state." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.7, aMAUAdminState, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.7, aMAUAdminState, 30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1, - acRESETMAU." + acResetMAU." ::= { rpMauEntry 5 } rpMauMediaAvailable OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), available(3), notAvailable(4), remoteFault(5), invalidSignal(6), @@ -789,21 +756,21 @@ light, or loopback is normal. The value notAvailable(4) indicates link loss, low light, or no loopback. The value remoteFault(5) indicates that a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation. The values remoteJabber(7), remoteLinkLoss(8), - and remoteTest(9) should be used instead of + and remoteTest(9) SHOULD be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. The value invalidSignal(6) indicates that an invalid signal has been received from the other end of the link. InvalidSignal(6) applies only to MAUs of type 10BASE-FB. Where an IEEE Std 802.3u-1995 clause 22 MII is present, a logic one in the remote fault bit @@ -813,72 +780,72 @@ 22.2.4.2.10 of that document) maps to the value notAvailable(4). The value notAvailable(4) takes precedence over the value remoteFault(5). Any MAU that implements management of clause 37 Auto-Negotiation will map the received Remote Fault (RF1 and RF2) bit values for Offline to offline(10), Link Failure to remoteFault(5) and Auto-Negotiation Error to autoNegError(11)." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.4, aMediaAvailable." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.4, aMediaAvailable." ::= { rpMauEntry 6 } rpMauMediaAvailableStateExits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that rpMauMediaAvailable for this MAU instance leaves the state available(3)." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.5, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.5, aLoseMediaCounter." ::= { rpMauEntry 7 } rpMauJabberState OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), noJabber(3), jabbering(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value other(1) is returned if the jabber - state is not 2, 3, or 4. The agent must always + state is not 2, 3, or 4. The agent MUST always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns the jabbering(4) value." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6, aJabber.jabberFlag." ::= { rpMauEntry 8 } rpMauJabberingStateEnters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that mauJabberState for this MAU instance enters the state jabbering(4). For MAUs of type dot3MauTypeAUI, dot3MauType100BaseT4, dot3MauType100BaseTX, dot3MauType100BaseFX and all 1000Mbps types, this counter will always indicate zero." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6, aJabber.jabberCounter." ::= { rpMauEntry 9 } rpMauFalseCarriers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X links. This counter does not increment at the symbol rate. It can @@ -887,22 +854,23 @@ carrier event. This counter increments only for MAUs of type dot3MauType100BaseT4, dot3MauType100BaseTX, and dot3MauType100BaseFX and all 1000Mbps types. For all other MAU types, this counter will always indicate zero. The approximate minimum time for rollover of this counter is 7.4 hours." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.10, aFalseCarriers." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.10, aFalseCarriers." ::= { rpMauEntry 10 } + -- The rpJackTable applies to MAUs attached to repeaters -- which have one or more external jacks (connectors). rpJackTable OBJECT-TYPE SYNTAX SEQUENCE OF RpJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the external jacks attached to MAUs attached to the ports of a repeater." ::= { dot3RpMauBasicGroup 2 } @@ -992,21 +961,21 @@ REFERENCE "RFC 1213, ifIndex" ::= { ifMauEntry 1 } ifMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same interface (ifMauIfIndex)." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.1, aMAUID." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID." ::= { ifMauEntry 2 } ifMauType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the 10 or 100 Mb/s baseband or broadband MAU type. An initial set of MAU types are defined above. The assignment of OBJECT IDENTIFIERs to new types of MAUs is @@ -1022,35 +991,35 @@ value. This object represents the operational type of the MAU, as determined by either (1) the result of the auto-negotiation function or (2) if auto-negotiation is not enabled or is not implemented for this MAU, by the value of the object ifMauDefaultType. In case (2), a set to the object ifMauDefaultType will force the MAU into the new operating mode." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.2, aMAUType." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.2, aMAUType." ::= { ifMauEntry 3 } ifMauStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), shutdown(5), reset(6) } MAX-ACCESS read-write STATUS current - DESCRIPTION "The current state of the MAU. This object may + DESCRIPTION "The current state of the MAU. This object MAY be implemented as a read-only object by those agents and MAUs that do not implement software control of the MAU state. Some agents may not support setting the value of this object to some of the enumerated values. The value other(1) is returned if the MAU is in a state other than one of the states 2 through 6. @@ -1065,40 +1034,40 @@ A MAU in standby(4) state forces DI and CI to idle and the media transmitter to idle or fault, if supported. Standby(4) mode only applies to link type MAUs. The state of ifMauMediaAvailable is unaffected. A MAU in shutdown(5) state assumes the same condition on DI, CI, and the media transmitter as though it were powered down or not connected. - The MAU may return other(1) value for the + The MAU MAY return other(1) value for the ifMauJabberState and ifMauMediaAvailable objects when it is in this state. For an AUI, this state will remove power from the AUI. Setting this variable to the value reset(6) resets the MAU in the same manner as a power-off, power-on cycle of at least one-half second would. The agent is not required to return the value reset (6). Setting this variable to the value operational(3), standby(4), or shutdown(5) causes the MAU to assume the respective state except that setting a mixing-type MAU or an AUI to standby(4) will cause the MAU to enter the shutdown state." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.7, aMAUAdminState, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.7, aMAUAdminState, 30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1, - acRESETMAU." + acResetMAU." ::= { ifMauEntry 4 } ifMauMediaAvailable OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), available(3), notAvailable(4), remoteFault(5), invalidSignal(6), @@ -1149,21 +1118,21 @@ light, or loopback is normal. The value notAvailable(4) indicates link loss, low light, or no loopback. The value remoteFault(5) indicates that a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation. The values remoteJabber(7), remoteLinkLoss(8), - and remoteTest(9) should be used instead of + and remoteTest(9) SHOULD be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. The value invalidSignal(6) indicates that an invalid signal has been received from the other end of the link. InvalidSignal(6) applies only to MAUs of type 10BASE-FB. Where an IEEE Std 802.3u-1995 clause 22 MII is present, a logic one in the remote fault bit @@ -1172,88 +1141,88 @@ zero in the link status bit (reference section 22.2.4.2.10 of that document) maps to the value notAvailable(4). The value notAvailable(4) takes precedence over the value remoteFault(5). Any MAU that implements management of clause 37 Auto-Negotiation will map the received RF1 and RF2 bit values for Offline to offline(10), Link Failure to remoteFault(5) and Auto-Negotiation Error to autoNegError(11)." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.4, aMediaAvailable." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.4, aMediaAvailable." ::= { ifMauEntry 5 } + ifMauMediaAvailableStateExits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that ifMauMediaAvailable for this MAU instance leaves the state available(3)." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.5, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.5, aLoseMediaCounter." ::= { ifMauEntry 6 } ifMauJabberState OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), noJabber(3), jabbering(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value other(1) is returned if the jabber - state is not 2, 3, or 4. The agent must always + state is not 2, 3, or 4. The agent MUST always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns the jabbering(4) value." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6, aJabber.jabberFlag." ::= { ifMauEntry 7 } - ifMauJabberingStateEnters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that mauJabberState for this MAU instance enters the state jabbering(4). This counter will always indicate zero for MAUs of type dot1MauTypeAUI and those of speeds above 10Mbps." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.6, aJabber.jabberCounter." ::= { ifMauEntry 8 } ifMauFalseCarriers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X and 1000BASE-X links. For all other MAU types, this counter will always indicate zero. This counter does not increment at the symbol rate. It can increment after a valid carrier completion at a maximum rate of once per 100 ms for 100BASE-X and once per 10us for 1000BASE-X until the next CarrierEvent." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.10, aFalseCarriers." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.10, aFalseCarriers." ::= { ifMauEntry 9 } ifMauTypeList OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** A value that uniquely identifies the set of possible IEEE 802.3 types that the MAU could be. @@ -1326,28 +1295,28 @@ is determined by auto-negotiation, and the value of this object denotes the type to which the MAU will automatically revert if/when auto-negotiation is later disabled. NOTE TO IMPLEMENTORS: It may be necessary to provide for underlying hardware implementations which do not follow the exact behavior specified above. In particular, when ifMauAutoNegAdminStatus transitions from enabled - to disabled, the agent implementation must + to disabled, the agent implementation MUST ensure that the operational type of the MAU (as reported by ifMauType) correctly transitions to the value specified by this object, rather than continuing to operate at the value earlier determined by the auto-negotiation function." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.1, aMAUID, and - [IEEE 802.3 Std], 22.2.4.1.4." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID, and + 22.2.4.1.4." ::= { ifMauEntry 11 } ifMauAutoNegSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not auto-negotiation is supported on this MAU." ::= { ifMauEntry 12 } @@ -1498,67 +1466,66 @@ If the value of this object is disabled(2) then the interface will act as it would if it had no auto-negotiation signaling. Under these conditions, an IEEE 802.3 MAU will immediately be forced to the state indicated by the value of the object ifMauDefaultType. NOTE TO IMPLEMENTORS: When ifMauAutoNegAdminStatus transitions from enabled - to disabled, the agent implementation must + to disabled, the agent implementation MUST ensure that the operational type of the MAU (as reported by ifMauType) correctly transitions to the value specified by the ifMauDefaultType object, rather than continuing to operate at the value earlier determined by the auto-negotiation function." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.2, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.2, aAutoNegAdminState and 30.6.1.2.2, acAutoNegAdminControl." ::= { ifMauAutoNegEntry 1 } ifMauAutoNegRemoteSignaling OBJECT-TYPE SYNTAX INTEGER { detected(1), notdetected(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating whether the remote end of the link is using auto-negotiation signaling. It takes the value detected(1) if and only if, during the previous link negotiation, FLP Bursts were received." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.3, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.3, aAutoNegRemoteSignaling." ::= { ifMauAutoNegEntry 2 } ifMauAutoNegConfig OBJECT-TYPE SYNTAX INTEGER { other(1), configuring(2), complete(3), disabled(4), parallelDetectFail(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the current status of the auto-negotiation process. The enumeration parallelDetectFail(5) maps to a failure in parallel detection as defined in 28.2.3.1 of [IEEE 802.3 Std]." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.4, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.4, aAutoNegAutoConfig." ::= { ifMauAutoNegEntry 4 } - ifMauAutoNegCapability OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** A value that uniquely identifies the set of capabilities of the local auto-negotiation entity. The value is a sum which initially takes the value zero. Then, for each capability @@ -1588,21 +1555,21 @@ 18 (reserved) 19 100BASE-T2 half duplex mode 20 100BASE-T2 full duplex mode Note that interfaces that support this MIB may have capabilities that extend beyond the scope of this MIB. This object has been deprecated in favour of ifMauAutoNegCapabilityBits" - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.5, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.5, aAutoNegLocalTechnologyAbility." ::= { ifMauAutoNegEntry 5 } ifMauAutoNegCapAdvertised OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** A value that uniquely identifies the set of @@ -1610,21 +1577,21 @@ auto-negotiation entity. Refer to ifMauAutoNegCapability for a description of the possible values of this object. Capabilities in this object that are not available in ifMauAutoNegCapability cannot be enabled. This object has been deprecated in favour of ifMauAutoNegCapAdvertisedBits" - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 6 } ifMauAutoNegCapReceived OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** A value that uniquely identifies the set of @@ -1633,40 +1600,40 @@ ifMauAutoNegCapability for a description of the possible values of this object. Note that interfaces that support this MIB may be attached to remote auto-negotiation entities which have capabilities beyond the scope of this MIB. This object has been deprecated in favour of ifMauAutoNegCapReceivedBits" - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.7, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 7 } ifMauAutoNegRestart OBJECT-TYPE SYNTAX INTEGER { restart(1), norestart(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "If the value of this object is set to restart(1) then this will force auto-negotiation to begin link renegotiation. If auto-negotiation signaling is disabled, a write to this object has no effect. Setting the value of this object to norestart(2) has no effect." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.2.1, + REFERENCE "[IEEE 802.3 Std], 30.6.1.2.1, acAutoNegRestartAutoConfig." ::= { ifMauAutoNegEntry 8 } ifMauAutoNegCapabilityBits OBJECT-TYPE SYNTAX BITS { bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode @@ -1687,21 +1654,21 @@ b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15) -- 1000BASE-T full duplex mode } MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities of the local auto-negotiation entity. Note that interfaces that support this MIB may have capabilities that extend beyond the scope of this MIB." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.5, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.5, aAutoNegLocalTechnologyAbility." ::= { ifMauAutoNegEntry 9 } ifMauAutoNegCapAdvertisedBits OBJECT-TYPE SYNTAX BITS { bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode @@ -1724,21 +1691,21 @@ } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities advertised by the local auto-negotiation entity. Capabilities in this object that are not available in ifMauAutoNegCapability cannot be enabled." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 10 } ifMauAutoNegCapReceivedBits OBJECT-TYPE SYNTAX BITS { bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode @@ -1762,181 +1729,194 @@ MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities received from the remote auto-negotiation entity. Note that interfaces that support this MIB may be attached to remote auto-negotiation entities which have capabilities beyond the scope of this MIB." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.7, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 11 } ifMauAutoNegRemoteFaultAdvertised OBJECT-TYPE SYNTAX INTEGER { noError(1), offline(2), linkFailure(3), autoNegError(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "A value that identifies any local fault indications that this MAU has detected and will advertise at the next auto-negotiation interaction for 1000Mbps MAUs." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.6, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 12 } ifMauAutoNegRemoteFaultReceived OBJECT-TYPE SYNTAX INTEGER { noError(1), offline(2), linkFailure(3), autoNegError(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value that identifies any fault indications received from the far end of a link by the local auto-negotiation entity for 1000Mbps MAUs." - REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.7, + REFERENCE "[IEEE 802.3 Std], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 13 } -- -- The Basic Broadband MAU Table -- broadMauBasicTable OBJECT-TYPE SYNTAX SEQUENCE OF BroadMauBasicEntry MAX-ACCESS not-accessible - STATUS current - DESCRIPTION "Table of descriptive and status information + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + Table of descriptive and status information about the broadband MAUs connected to interfaces." ::= { dot3BroadMauBasicGroup 1 } broadMauBasicEntry OBJECT-TYPE SYNTAX BroadMauBasicEntry MAX-ACCESS not-accessible - STATUS current - DESCRIPTION "An entry in the table, containing information + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + An entry in the table, containing information about a single broadband MAU." INDEX { broadMauIfIndex, broadMauIndex } ::= { broadMauBasicTable 1 } BroadMauBasicEntry ::= SEQUENCE { broadMauIfIndex Integer32, broadMauIndex Integer32, broadMauXmtRcvSplitType INTEGER, broadMauXmtCarrierFreq Integer32, broadMauTranslationFreq Integer32 } broadMauIfIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only - STATUS current - DESCRIPTION "This variable uniquely identifies the interface + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + This variable uniquely identifies the interface to which the MAU described by this entry is connected." REFERENCE "Reference RFC 1213, ifIndex." ::= { broadMauBasicEntry 1 } broadMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only - STATUS current - DESCRIPTION "This variable uniquely identifies the MAU + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + This variable uniquely identifies the MAU connected to interface broadMauIfIndex that is described by this entry." - REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, - aMAUID." + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID." ::= { broadMauBasicEntry 2 } broadMauXmtRcvSplitType OBJECT-TYPE SYNTAX INTEGER { other(1), single(2), dual(3) } MAX-ACCESS read-only - STATUS current - DESCRIPTION "This object indicates the type of frequency + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + This object indicates the type of frequency multiplexing/cabling system used to separate the transmit and receive paths for the 10BROAD36 MAU. The value other(1) is returned if the split type is not either single or dual. The value single(2) indicates a single cable system. The value dual(3) indicates a dual cable system, offset normally zero." - REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.8, aBbMAUXmitRcvSplitType." ::= { broadMauBasicEntry 3 } broadMauXmtCarrierFreq OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only - STATUS current - DESCRIPTION "This variable indicates the transmit carrier + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + This variable indicates the transmit carrier frequency of the 10BROAD36 MAU in MHz/4; that is, in units of 250 kHz." - REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.9, aBroadbandFrequencies.xmitCarrierFrequency." ::= { broadMauBasicEntry 4 } broadMauTranslationFreq OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only - STATUS current - DESCRIPTION "This variable indicates the translation offset + STATUS deprecated + DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** + + This variable indicates the translation offset frequency of the 10BROAD36 MAU in MHz/4; that is, in units of 250 kHz." - REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, + REFERENCE "[IEEE 802.3 Std], 30.5.1.1.9, aBroadbandFrequencies.translationFrequency." ::= { broadMauBasicEntry 5 } -- Notifications for use by 802.3 MAUs snmpDot3MauTraps OBJECT IDENTIFIER ::= { snmpDot3MauMgt 0 } rpMauJabberTrap NOTIFICATION-TYPE OBJECTS { rpMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed repeater MAU enters the jabber state. - The agent must throttle the generation of + The agent MUST throttle the generation of consecutive rpMauJabberTraps so that there is at least a five-second gap between them." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauTraps 1 } ifMauJabberTrap NOTIFICATION-TYPE OBJECTS { ifMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed interface MAU enters the jabber state. - The agent must throttle the generation of + The agent MUST throttle the generation of consecutive ifMauJabberTraps so that there is at least a five-second gap between them." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauTraps 2 } -- Conformance information mauModConf OBJECT IDENTIFIER ::= { mauMod 1 } @@ -2041,23 +2019,30 @@ of mauIfGrpAutoNeg2." ::= { mauModObjGrps 7 } mauBroadBasic OBJECT-GROUP OBJECTS { broadMauIfIndex, broadMauIndex, broadMauXmtRcvSplitType, broadMauXmtCarrierFreq, broadMauTranslationFreq } - STATUS current - DESCRIPTION "Conformance group for broadband MAUs attached - to interfaces." + STATUS deprecated + DESCRIPTION "********* THIS GROUP IS DEPRECATED ********** + + Conformance group for broadband MAUs attached + to interfaces. + + This object group is deprecated. There have + been no reported implementations of this group, + and it was felt to be unlikely that there will + be any future implementations." ::= { mauModObjGrps 8 } mauIfGrpHighCapacity OBJECT-GROUP OBJECTS { ifMauFalseCarriers, ifMauTypeListBits, ifMauDefaultType, ifMauAutoNegSupported } STATUS current DESCRIPTION "Conformance group for MAUs attached to @@ -2095,25 +2080,31 @@ DESCRIPTION "Notifications for repeater MAUs." ::= { mauModNotGrps 1 } ifMauNotifications NOTIFICATION-GROUP NOTIFICATIONS { ifMauJabberTrap } STATUS current DESCRIPTION "Notifications for interface MAUs." ::= { mauModNotGrps 2 } -- Compliances - mauModRpCompl MODULE-COMPLIANCE - STATUS current - DESCRIPTION "Compliance for MAUs attached to repeater - ports." + STATUS deprecated + DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** + + Compliance for MAUs attached to repeater + ports. + + This compliance is deprecated and replaced by + mauModRpCompl2, which corrects an oversight by + allowing rpMauStatus to be implemented + read-only." MODULE -- this module MANDATORY-GROUPS { mauRpGrpBasic } GROUP mauRpGrp100Mbs DESCRIPTION "Implementation of this optional group is recommended for MAUs which have 100Mb/s or greater capability." GROUP mauRpGrpJack @@ -2122,30 +2113,33 @@ external jacks." GROUP rpMauNotifications DESCRIPTION "Implementation of this group is recommended for MAUs attached to repeater ports." ::= { mauModCompls 1 } mauModIfCompl MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ******** - Compliance for MAUs attached to interfaces." + + Compliance for MAUs attached to interfaces. + + This compliance is deprecated and replaced by + mauModIfCompl2." MODULE -- this module MANDATORY-GROUPS { mauIfGrpBasic } GROUP mauIfGrp100Mbs DESCRIPTION "Implementation of this optional group is recommended for MAUs which have 100Mb/s capability." - GROUP mauIfGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs which have one or more external jacks." GROUP mauIfGrpAutoNeg DESCRIPTION "Implementation of this group is mandatory for MAUs which support managed auto-negotiation." @@ -2179,32 +2173,59 @@ DESCRIPTION "Implementation of this group is mandatory for MAUs which support managed auto-negotiation." GROUP mauIfGrpAutoNeg1000Mbps DESCRIPTION "Implementation of this group is mandatory for MAUs which have 1000Mb/s or greater capability and support managed auto-negotiation." - GROUP mauBroadBasic - DESCRIPTION "Implementation of this group is mandatory - for broadband MAUs." - GROUP ifMauNotifications DESCRIPTION "Implementation of this group is recommended for MAUs attached to interfaces." + + OBJECT ifMauStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." ::= { mauModCompls 3 } + mauModRpCompl2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION "Compliance for MAUs attached to repeater + ports." + + MODULE -- this module + MANDATORY-GROUPS { mauRpGrpBasic } + + GROUP mauRpGrp100Mbs + DESCRIPTION "Implementation of this optional group is + recommended for MAUs which have 100Mb/s or + greater capability." + + GROUP mauRpGrpJack + DESCRIPTION "Implementation of this optional group is + recommended for MAUs which have one or more + external jacks." + + GROUP rpMauNotifications + DESCRIPTION "Implementation of this group is recommended + for MAUs attached to repeater ports." + + OBJECT rpMauStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + ::= { mauModCompls 4 } + END -6. Intellectual Property +5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of @@ -2212,143 +2233,196 @@ obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. -7. Acknowledgements +6. Acknowledgements - This document was produced by the IETF IEEE 802.3 Interfaces and Hub + This document was produced by the IETF Ethernet Interfaces and Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people: - Chuck Black John Flick Jeff Johnson Leon Leong Mike Lui Dave Perkins - Geoff Thompson Maurice Turcotte Paul Woodruff + Chuck Black + John Flick + Jeff Johnson + Leon Leong + Mike Lui + Dave Perkins + Geoff Thompson + Maurice Turcotte + Paul Woodruff Special thanks as well to Dave Perkins for his excellent work on the SMICng compiler, which made it easy to take advantage of the latest SNMPv2 constructs in this MIB. -8. References - - [1] IEEE 802.3/ISO 8802-3 Information processing systems - Local - area networks - Part 3: Carrier sense multiple access with - collision detection (CSMA/CD) access method and physical layer - specifications, 1993. +7. References - [2] IEEE Draft P802.3z/D4.2, "MAC Parameters, Physical Layer, - Repeater and Management Parameters for 1000 Mb/s Operation" - Supplement to IEEE Std 802.3, March 1998. + [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for + Describing SNMP Management Frameworks", RFC 2271, Cabletron + Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, + January 1998 - [3] de Graaf, K., D. Romascanu, D. McMaster, and K. McCloghrie, - "Definitions of Managed Objects for IEEE 802.3 Repeater Devices - using SMIv2", RFC 2108, February 1997. + [2] Rose, M., and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based Internets", STD 16, + RFC 1155, Performance Systems International, Hughes LAN Systems, + May 1990 - [4] Information processing systems - Open Systems Interconnection - - Specification of Abstract Syntax Notation One (ASN.1), - International Organization for Standardization, International - Standard 8824, December 1987. + [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, + RFC 1212, Performance Systems International, Hughes LAN Systems, + March 1991 - [5] McCloghrie, K., and M. Rose, Editors, "Management Information - Base for Network Management of TCP/IP-based internets: MIB-II", - STD 17, RFC 1213, Hughes LAN Systems, Performance Systems - International, March 1991. + [4] M. Rose, "A Convention for Defining Traps for use with the + SNMP", RFC 1215, Performance Systems International, March 1991 - [6] McCloghrie, K., and Kastenholtz, F., "The Interfaces Group MIB - using SMIv2", RFC 2233, Cisco Systems, FTP Software, November - 1997. + [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Structure of Management Information for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research, + Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., + International Network Services, January 1996. - [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Structure of Management Information for version - 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, - January 1996. + [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual + Conventions for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco + Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. - [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Textual Conventions for version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Conformance Statements for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., + Cisco Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. - [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Conformance Statements for version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1904, January - 1996. + [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple + Network Management Protocol", STD 15, RFC 1157, SNMP Research, + Performance Systems International, Performance Systems + International, MIT Laboratory for Computer Science, May 1990. - [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Protocol Operations for version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Introduction to Community-based SNMPv2", RFC 1901, SNMP + Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, + Inc., International Network Services, January 1996. - [11] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network - Management Protocol", RFC 1157, SNMP Research, Performance - Systems International, MIT Laboratory for Computer Science, May - 1990. + [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., + Cisco Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. - [12] Harrington D., Presuhn, R., Wijnen, B., "An Architecture for - Describing SNMP Management Frameworks", RFC 2271, Cabletron - Systems, BMC Software, Inc., IBM T.J. Watson Research, January - 1998. + [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron + Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, + January 1998. - [13] Harrington D., Presuhn, R., Wijnen, B., "Message Processing and - Dispatching for the Simple Network Management Protocol (SNMP)", - RFC 2272, Cabletron Systems, BMC Software, Inc., IBM T.J. - Watson Research, January 1998. + [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) + for version 3 of the Simple Network Management Protocol + (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. - [14] Levi D., Meyer P., Stewart, B., "SNMPv3 Applications", RFC 2273, - SNMP Research, Inc., Secure Computing Corporation, Cisco - Systems, January 1998. + [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol + Operations for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco + Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. - [15] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) for - version 3 of the Simple Network Management Protocol (SNMPv3)", - RFC 2274, IBM T. J. Watson Research, January 1998. + [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC + 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco + Systems, January 1998 - [16] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access + [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol - (SNMP)", RFC 2275, IBM T.J. Watson Research, BMC Software, Inc., - Cisco Systems, Inc., January 1998. + (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, + Inc., Cisco Systems, Inc., January 1998 - [17] Bradner, S., "Key words for use in RFCs to Indicate + [16] IEEE, IEEE Std 802.3, 1998 Edition: "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" + (incorporating ANSI/IEEE Std. 802.3, 1996 Edition, IEEE Std. + 802.3r-1996, 802.3u-1995, 802.3x&y-1997, 802.3z-1998, and + 802.3aa-1998), September 1998. + + [17] de Graaf, K., D. Romascanu, D. McMaster, and K. McCloghrie, + "Definitions of Managed Objects for IEEE 802.3 Repeater Devices + using SMIv2", RFC 2108, 3Com Corporation, Madge Networks + (Israel) Ltd., Coloma Communications, Cisco Systems, Inc., + February 1997. + + [18] McCloghrie, K., and M. Rose, Editors, "Management Information + Base for Network Management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, Hughes LAN Systems, Performance Systems + International, March 1991. + + [19] McCloghrie, K., and Kastenholtz, F., "The Interfaces Group MIB + using SMIv2", RFC 2233, Cisco Systems, FTP Software, November + 1997. + + [20] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. - [18] de Graaf, K., Romascanu, D., McMaster, D., K. McCloghrie, + [21] de Graaf, K., Romascanu, D., McMaster, D., K. McCloghrie, S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2", - RFC 2239, November 1997. + RFC 2239, 3Com Corporation, Madge Networks Ltd., Cisco Systems + Inc., Cisco Systems Inc., Farallon Computing, Inc., + November 1997. - [19] McMaster, D., K. McCloghrie and S. Roberts, "Definitions of + [22] McMaster, D., K. McCloghrie and S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units - (MAUs)", RFC 1515, September 1993. + (MAUs)", RFC 1515, SynOptics Communications, Inc., Hughes LAN + Systems, Inc., Farallon Computing, Inc., September 1993. - [20] Flick, J., and J. Johnson, "Definitions of Managed Objects for + [23] Flick, J., and J. Johnson, "Definitions of Managed Objects for the Ethernet-like Interface Types", work in progress, - draft-ietf-hubmib-etherif-mib-04.txt, March, 1998. + draft-ietf-hubmib-etherif-mib-v2-00.txt, Hewlett-Packard + Company, RedBack Networks, August, 1998. -9. Security Considerations +8. Security Considerations - Certain management information defined in this MIB may be considered - sensitive in some network environments. Therefore, authentication of - received SNMP requests and controlled access to management - information should be employed in such environments. The method for - this authentication is a function of the SNMP Administrative - Framework, and has not been expanded by this MIB. + There are a number of management objects defined in this MIB that + have a MAX-ACCESS clause of read-write. Setting these objects can + have a serious effect on the operation of the network, including: - Several objects in this MIB allow write access. Setting these - objects can have a serious effect on the operation of the network, - including enabling or disabling a MAU, changing a MAU's default type, - enabling, disabling or restarting autonegotiation, or modifying the - capabilities that a MAU advertizes during autonegotiation. It is - recommended that implementers seriously consider whether set - operations should be allowed without providing, at a minimum, - authentication of request origin. + enabling or disabling a MAU + changing a MAU's default type + enabling, disabling or restarting autonegotiation + modifying the capabilities that a MAU advertizes during + autonegotiation. -10 Authors' Addresses + Such objects may be considered sensitive or vulnerable in some + network environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. + + SNMPv1 by itself is such an insecure environment. Even if the + network itself is secure (for example by using IPSec), even then, + there is no control as to who on the secure network is allowed to + access and GET/SET (read/change/create/delete) the objects in this + MIB. + + It is recommended that the implementers consider the security + features as provided by the SNMPv3 framework. Specifically, the use + of the User-based Security Model RFC 2274 [12] and the View-based + Access Control Model RFC 2275 [15] is recommended. + + It is then a customer/user responsibility to ensure that the SNMP + entity giving access to an instance of this MIB, is properly + configured to give access to those objects only to those principals + (users) that have legitimate rights to access them. + +9. Authors' Addresses Andrew Smith Extreme Networks, Inc. 10460 Bandley Drive Cupertino, CA 95014, USA Tel: +1 408 342 0999 E-Mail: andrew@extremenetworks.com John Flick Hewlett-Packard Company @@ -2387,21 +2462,71 @@ Tel: +1 408 526 5260 E-Mail: kzm@cisco.com Sam Roberts Farallon Computing, Inc. 2470 Mariner Square Loop Alameda, CA 94501-1010 Tel: +1 510 814 5215 E-Mail: sroberts@farallon.com -11. Full Copyright Statement +A. Change Log + + This section enumerates the changes made to RFC 2239 to produce this + document. + + (1) The MODULE-IDENTITY has been updated to reflect the changes + in the MIB. + + (2) OBJECT-IDENTITY definitions have been added for gigabit MAU + types. + + (3) The ifMauTypeList, ifMauAutoNegCapability, + ifMauAutoNegCapAdvertised and ifMauAutoNegCapReceived + objects have been deprecated and replaced by + ifMauTypeListBits, ifMauAutoNegCapabilityBits, + ifMauAutoNegCapAdvertisedBits and + ifMauAutoNegCapReceivedBits. + + (4) Two new objects, ifMauAutoNegRemoteFaultAdvertised and + ifMauAutoNegRemoteFaultReceived have been added. + + (5) Enumerations for 'offline' and 'autoNegError' have been + added for the rpMauMediaAvailable and ifMauMediaAvailable + objects. + + (6) The broadMauBasicTable and mauBroadBasic object group have + been deprecated. + + (7) The mauIfGrp100Mbs and mauIfGrpAutoNeg object groups have + been deprecated and replaced by mauIfGrpHighCapacity and + mauIfGrpAutoNeg2. + + (8) A new object group, mauIfGrpAutoNeg1000Mbps, has been added. + + (9) The mauModIfCompl and mauModRpCompl compliances have been + deprecated and replaced by mauModIfCompl2 and + mauModRpCompl2. + + (10) Added section on relationship to RFC 2239. + + (11) Updated the SNMP Network Management Framework boilerplate. + + (12) Refer to the Interfaces MIB, rather than the interfaces + group of MIB-II. + + (13) Updated references to refer to latest edition of IEEE 802.3. + + (14) An intellectual property notice was added, as required by + RFC 2026. + +B. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of