summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2358.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2358.txt')
-rw-r--r--doc/rfc/rfc2358.txt2187
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc2358.txt b/doc/rfc/rfc2358.txt
new file mode 100644
index 0000000..78ff776
--- /dev/null
+++ b/doc/rfc/rfc2358.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+Network Working Group J. Flick
+Request for Comments: 2358 Hewlett-Packard Company
+Obsoletes: 1650 J. Johnson
+Category: Standards Track RedBack Networks
+ June 1998
+
+
+ Definitions of Managed Objects for
+ the Ethernet-like Interface Types
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ 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 1650 "Definitions of Managed Objects for the
+ Ethernet-like Interface Types using SMIv2". This memo extends that
+ specification by including management information useful for the
+ management of 100 Mb/s Ethernet interfaces.
+
+ 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, reflect 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.
+
+
+
+
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 1]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 2. The SNMP Network Management Framework ...................... 2
+ 2.1. Object Definitions ....................................... 3
+ 3. Overview ................................................... 3
+ 3.1. Relation to MIB-2 ........................................ 4
+ 3.2. Relation to the Interfaces MIB ........................... 4
+ 3.2.1. Layering Model ......................................... 4
+ 3.2.2. Virtual Circuits ....................................... 4
+ 3.2.3. ifTestTable ............................................ 5
+ 3.2.4. ifRcvAddressTable ...................................... 5
+ 3.2.5. ifPhysAddress .......................................... 5
+ 3.2.6. ifType ................................................. 6
+ 3.2.7. Specific Interface MIB Objects ......................... 7
+ 3.3. Relation to the 802.3 MAU MIB ............................ 10
+ 3.4. Mapping of IEEE 802.3 Managed Objects .................... 10
+ 4. Definitions ................................................ 11
+ 5. Intellectual Property ...................................... 34
+ 6. Acknowledgements ........................................... 34
+ 7. References ................................................. 35
+ 8. Security Considerations .................................... 36
+ 9. Authors' Addresses ......................................... 37
+ A. Change Log ................................................. 38
+ B. Full Copyright Statement ................................... 39
+
+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 ethernet-like
+ interfaces.
+
+ This memo also includes a MIB module. This MIB module extends the
+ list of managed objects specified in the earlier version of this MIB:
+ RFC1650 [11].
+
+ 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 [13].
+
+2. The SNMP Network Management Framework
+
+ The SNMP Network Management Framework consists of several components.
+ For the purpose of this specification, the applicable components of
+ the Framework are the SMI and related documents [2, 3, 4], which
+ define the mechanisms used for describing and naming objects for the
+ purpose of management.
+
+
+
+Flick & Johnson Standards Track [Page 2]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ The Framework permits new objects to be defined for the purpose of
+ experimentation and evaluation.
+
+2.1. Object Definitions
+
+ 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) [1]
+ defined in the SMI [2]. In particular, each object 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. Overview
+
+ Instances of these object types represent attributes of an interface
+ to an ethernet-like communications medium. At present, ethernet-like
+ media are identified by the following values of the ifType object in
+ the Interfaces MIB [12]:
+
+ ethernetCsmacd(6)
+ iso88023Csmacd(7)
+ starLan(11)
+
+ The definitions presented here are based on the IEEE 802.3 Layer
+ Management Specification [5], as originally interpreted by Frank
+ Kastenholz then of Interlan in [7]. Implementors of these MIB
+ objects should note that the IEEE document explicitly describes (in
+ the form of Pascal pseudocode) when, where, and how various MAC
+ attributes are measured. The IEEE document also describes the
+ effects of MAC actions that may be invoked by manipulating instances
+ of the MIB objects defined here.
+
+ To the extent that some of the attributes defined in [5] are
+ represented by previously defined objects in MIB-2 [16] or in the
+ Interfaces MIB [12], such attributes are not redundantly represented
+ by objects defined in this memo. Among the attributes represented by
+ objects defined in other memos are the number of octets transmitted
+ or received on a particular interface, the number of frames
+ transmitted or received on a particular interface, the promiscuous
+ status of an interface, the MAC address of an interface, and
+ multicast information associated with an interface.
+
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 3]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+3.1. Relation to MIB-2
+
+ This section applies only when this MIB is used in conjunction with
+ the "old" (RFC 1213) [16] interface group.
+
+ The relationship between an ethernet-like interface and an interface
+ in the context of the Internet-standard MIB is one-to-one. As such,
+ the value of an ifIndex object instance can be directly used to
+ identify corresponding instances of the objects defined herein.
+
+ For agents which implement the (now deprecated) ifSpecific object, an
+ instance of that object that is associated with an ethernet-like
+ interface has the OBJECT IDENTIFIER value:
+
+ dot3 OBJECT IDENTIFER ::= { transmission 7 }
+
+3.2. Relation to the Interfaces MIB
+
+ The Interface MIB [12] requires that any MIB which is an adjunct of
+ the Interface MIB clarify specific areas within the Interface MIB.
+ These areas were intentionally left vague in the Interface MIB to
+ avoid over constraining the MIB, thereby precluding management of
+ certain media-types.
+
+ Section 3.3 of [12] enumerates several areas which a media-specific
+ MIB must clarify. Each of these areas is addressed in a following
+ subsection. The implementor is referred to [12] in order to
+ understand the general intent of these areas.
+
+3.2.1. Layering Model
+
+ This MIB does not provide for layering. There are no sublayers.
+
+ EDITOR'S NOTE:
+
+ One could foresee the development of an 802.2 and enet-transceiver
+ MIB. They could be higher and lower sublayers, respectively. All
+ that THIS document should do is allude to the possibilities and urge
+ the implementor to be aware of the possibility and that they may have
+ requirements which supersede the requirements in this document.
+
+3.2.2. Virtual Circuits
+
+ This medium does not support virtual circuits and this area is not
+ applicable to this MIB.
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 4]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+3.2.3. ifTestTable
+
+ This MIB defines two tests for media which are instrumented with this
+ MIB; TDR and Loopback. Implementation of these tests is not
+ required. Many common interface chips do not support one or both of
+ these tests.
+
+ These two tests are provided as a convenience, allowing a common
+ method to invoke the test.
+
+ Standard MIBs do not include objects in which to return the results
+ of the TDR test. Any needed objects MUST be provided in the vendor
+ specific MIB.
+
+ Note that the ifTestTable is now deprecated. Work is underway to
+ define a replacement MIB for system and interface testing. It is
+ expected that the tests defined in this document will be usable in
+ this replacement MIB.
+
+3.2.4. ifRcvAddressTable
+
+ This table contains all IEEE 802.3 addresses, unicast, multicast, and
+ broadcast, for which this interface will receive packets and forward
+ them up to a higher layer entity for local consumption. The format
+ of the address, contained in ifRcvAddressAddress, is the same as for
+ ifPhysAddress.
+
+ In the event that the interface is part of a MAC bridge, this table
+ does not include unicast addresses which are accepted for possible
+ forwarding out some other port. This table is explicitly not
+ intended to provide a bridge address filtering mechanism.
+
+3.2.5. ifPhysAddress
+
+ This object contains the IEEE 802.3 address which is placed in the
+ source-address field of any Ethernet, Starlan, or IEEE 802.3 frames
+ that originate at this interface. Usually this will be kept in ROM
+ on the interface hardware. Some systems may set this address via
+ software.
+
+ In a system where there are several such addresses the designer has a
+ tougher choice. The address chosen should be the one most likely to
+ be of use to network management (e.g. the address placed in ARP
+ responses for systems which are primarily IP systems).
+
+ If the designer truly can not chose, use of the factory- provided ROM
+ address is suggested.
+
+
+
+
+Flick & Johnson Standards Track [Page 5]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ If the address can not be determined, an octet string of zero length
+ should be returned.
+
+ The address is stored in binary in this object. The address is
+ stored in "canonical" bit order, that is, the Group Bit is positioned
+ as the low-order bit of the first octet. Thus, the first byte of a
+ multicast address would have the bit 0x01 set.
+
+3.2.6. ifType
+
+ This MIB applies to interfaces which have any of the following ifType
+ values:
+
+ ethernetCsmacd(6)
+ iso88023Csmacd(7)
+ starLan(11)
+
+ It is RECOMMENDED that all Ethernet-like interfaces use an ifType of
+ ethernetCsmacd(6) regardless of the speed that the interface is
+ running or the link-layer encapsulation in use. iso88023Csmacd(7)
+ and starLan(11) are supported for backwards compatability.
+
+ There are two other interface types defined in the IANAifType-MIB for
+ 100 Mbit Ethernet. They are fastEther(62), and fastEtherFX(69).
+ This document takes the position that an Ethernet is an Ethernet, and
+ Ethernet interfaces SHOULD always have the same value of ifType.
+ Information on the particular flavor of Ethernet that an interface is
+ running is available from ifSpeed in the Interfaces MIB, and
+ ifMauType in the 802.3 MAU MIB. An Ethernet-like interface SHOULD
+ NOT use the fastEther(62) or fastEtherFX(69) ifTypes.
+
+ Interfaces with any of the supported ifType values map to the
+ EtherLike-MIB in the same manner. Which compliance statement an
+ interface should implement is dependent on the maximum speed
+ supported on the interface. The EtherLike-MIB etherCompliance
+ compliance statement applies to all Ethernet-like interfaces whose
+ maximum supported speed is 10 Mbit/sec or less. There are no
+ implementation differences. Similarly, the EtherLike-MIB
+ ether100MbsCompliance compliance statement applies to all Ethernet-
+ like interfaces whose maximum supported speed is 100Mbit/sec.
+
+ An interface that is capable of operating at 100Mbit/sec MUST
+ implement the ether100MbsCompliance compliance statement, even if it
+ is currently operating at a lower speed. Counters in the
+ ether100MbsCompliance compliance statement that only apply to 100
+ Mbit interfaces would simply not increment when the interface is
+ operating at a lower speed.
+
+
+
+
+Flick & Johnson Standards Track [Page 6]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+3.2.7. Specific Interface MIB Objects
+
+ The following table provides specific implementation guidelines for
+ applying the interface group objects to ethernet-like media.
+
+ Object
+
+ ifIndex Each ethernet-like interface is
+ represented by an ifEntry. The
+ dot3StatsTable in this MIB module is
+ indexed by dot3StatsIndex. The interface
+ identified by a particular value of
+ dot3StatsIndex is the same interface as
+ identified by the same value of ifIndex.
+
+ ifDescr Refer to [12].
+
+ ifType Refer to section 3.2.6.
+
+ ifMtu 1500 octets.
+
+ ifSpeed The current operational speed of the
+ interface in bits per second. For
+ current ethernet-like interfaces, this
+ will be equal to 1,000,000 (1 million),
+ 10,000,000 (10 million), or 100,000,000
+ (100 million). If the interface
+ implements auto-negotiation,
+ auto-negotiation is enabled for this
+ interface, and the interface has not yet
+ negotiated to an operational speed, this
+ object SHOULD reflect the maximum speed
+ supported by the interface. Note that
+ this object MUST NOT indicate a doubled
+ value when operating in full-duplex
+ mode. It MUST indicate the correct
+ line speed regardless of the current
+ duplex mode. The correct object to use
+ to determine the duplex mode of the
+ interface is the ifMauType object in the
+ 802.3 MAU MIB.
+
+ ifPhysAddress Refer to section 3.2.5.
+
+ ifAdminStatus Write access is not required. Support
+ for 'testing' is not required.
+
+
+
+
+
+Flick & Johnson Standards Track [Page 7]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ ifOperStatus The operational state of the interface.
+ Support for 'testing' is not required.
+ The value 'dormant' has no meaning for
+ an ethernet-like interface.
+
+ ifLastChange Refer to [12].
+
+ ifInOctets The number of octets in valid MAC frames
+ received on this interface, including
+ the MAC header and FCS.
+
+ ifInUcastPkts Refer to [12].
+
+ ifInDiscards Refer to [12].
+
+ ifInErrors The sum for this interface of
+ dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors,
+ dot3StatsFrameTooLongs,
+ dot3StatsInternalMacReceiveErrors and
+ dot3StatsSymbolErrors.
+
+ ifInUnknownProtos Refer to [12].
+
+ ifOutOctets The number of octets transmitted in
+ valid MAC frames on this interface,
+ including the MAC header and FCS.
+
+ ifOutUcastPkts Refer to [12].
+
+ ifOutDiscards Refer to [12].
+
+ ifOutErrors The sum for this interface of:
+ dot3StatsSQETestErrors,
+ dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions,
+ dot3StatsInternalMacTransmitErrors and
+ dot3StatsCarrierSenseErrors.
+
+ ifName Locally-significant textual name for the
+ interface (e.g. lan0).
+
+ ifInMulticastPkts Refer to [12].
+
+ ifInBroadcastPkts Refer to [12].
+
+ ifOutMulticastPkts Refer to [12].
+
+
+
+
+Flick & Johnson Standards Track [Page 8]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ ifOutBroadcastPkts Refer to [12].
+
+ ifHCInOctets 64-bit versions of counters. Required
+ ifHCOutOctets for ethernet-like interfaces that are
+ capable of operating at 20Mbit/sec or
+ faster, even if the interface is
+ currently operating at less than
+ 20Mbit/sec.
+
+ ifHCInUcastPkts 64-bit versions of packet counters.
+ ifHCInMulticastPkts Support for these counters is not
+ ifHCInBroadcastPkts required for the interface types
+ ifHCOutUcastPkts supported by this MIB. They are only
+ ifHCOutMulticastPkts required for interfaces capable of
+ ifHCOutBroadcastPkts operating at 640Mbit/sec or faster.
+ Note that a future revision of this
+ document may support faster interfaces,
+ and therefore may require support for
+ these counters.
+
+ ifLinkUpDownTrapEnable Refer to [12]. Default is 'enabled'
+
+ ifHighSpeed The current operational speed of the
+ interface in millions of bits per
+ second. For current ethernet-like
+ interfaces, this will be equal to 1, 10,
+ or 100. If the interface implements
+ auto-negotiation, auto-negotiation is
+ enabled for this interface, and the
+ interface has not yet negotiated to an
+ operational speed, this object SHOULD
+ reflect the maximum speed supported by
+ the interface. Note that this object
+ MUST NOT indicate a doubled value when
+ operating in full-duplex mode. It MUST
+ indicate the correct line speed
+ regardless of the current duplex mode.
+ The correct object to use to determine
+ the duplex mode of the interface is the
+ ifMauType object in the 802.3 MAU MIB.
+
+ ifPromiscuousMode Refer to [12].
+
+ ifConnectorPresent This will normally be 'true'.
+
+ ifAlias Refer to [12].
+
+ ifCounterDiscontinuityTime Refer to [12].
+
+
+
+Flick & Johnson Standards Track [Page 9]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ ifStackHigherLayer Refer to section 3.2.1.
+ ifStackLowerLayer
+ ifStackStatus
+
+ ifRcvAddressAddress Refer to section 3.2.4.
+ ifRcvAddressStatus
+ ifRcvAddressType
+
+3.3. Relation to the 802.3 MAU MIB
+
+ Support for the mauModIfCompl compliance statement of the MAU-MIB
+ [14] is REQUIRED for Ethernet-like interfaces. This MIB is needed in
+ order to allow applications to determine the current MAU type in use
+ by the interface. The MAU type indicates not only the media type in
+ use, but also indicates whether the interface is operating in half-
+ duplex or full-duplex mode. Implementing this MIB module without
+ implementing the MAU-MIB would leave applications with no standard
+ way to determine the duplex mode of the interface.
+
+3.4. Mapping of IEEE 802.3 Managed Objects
+
+ IEEE 802.3 Managed Object Corresponding SNMP Object
+
+ oMacEntity
+ .aMACID dot3StatsIndex or
+ IF-MIB - ifIndex
+ .aFramesTransmittedOK IF-MIB - ifOutUCastPkts +
+ ifOutMulticastPkts +
+ ifOutBroadcastPkts
+ .aSingleCollisionFrames dot3StatsSingleCollisionFrames
+ .aMultipleCollisionFrames dot3StatsMultipleCollisionFrames
+ .aFramesReceivedOK IF-MIB - ifInUcastPkts +
+ ifInMulticastPkts +
+ ifInBroadcastPkts
+ .aFrameCheckSequenceErrors dot3StatsFCSErrors
+ .aAlignmentErrors dot3StatsAlignmentErrors
+ .aOctetsTransmittedOK IF-MIB - ifOutOctets
+ .aFramesWithDeferredXmissions dot3StatsDeferredTransmissions
+ .aLateCollisions dot3StatsLateCollisions
+ .aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions
+ .aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors
+ .aCarrierSenseErrors dot3StatsCarrierSenseErrors
+ .aOctetsReceivedOK IF-MIB - ifInOctets
+ .aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors
+ .aPromiscuousStatus IF-MIB - ifPromiscuousMode
+ .aReadMulticastAddressList IF-MIB - ifRcvAddressTable
+ .aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts
+ .aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts
+
+
+
+Flick & Johnson Standards Track [Page 10]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts
+ .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts
+ .aFrameTooLongErrors dot3StatsFrameTooLongs
+ .aReadWriteMACAddress IF-MIB - ifPhysAddress
+ .aCollisionFrames dot3CollFrequencies
+ .acAddGroupAddress IF-MIB - ifRcvAddressTable
+ .acDeleteGroupAddress IF-MIB - ifRcvAddressTable
+ .acExecuteSelfTest dot3TestLoopBack
+
+ oPHYEntity
+ .aSQETestErrors dot3StatsSQETestErrors
+ .aSymbolErrorDuringCarrier dot3StatsSymbolErrors
+
+
+ The following IEEE 802.3 managed objects have been removed from this
+ MIB module as a result of implementation feedback:
+
+ oMacEntity
+ .aFramesWithExcessiveDeferral
+ .aInRangeLengthErrors
+ .aOutOfRangeLengthField
+ .aMACEnableStatus
+ .aTransmitEnableStatus
+ .aMulticastReceiveStatus
+ .acInitializeMAC
+
+ Please see [15] for the detailed reasoning on why these objects were
+ removed.
+
+4. Definitions
+
+ EtherLike-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
+ Counter32, mib-2, transmission
+ FROM SNMPv2-SMI
+ MODULE-COMPLIANCE, OBJECT-GROUP
+ FROM SNMPv2-CONF
+ ifIndex, InterfaceIndex
+ FROM IF-MIB;
+
+ etherMIB MODULE-IDENTITY
+ LAST-UPDATED "9806032150Z" -- June 3, 1998
+ ORGANIZATION "IETF 802.3 Hub MIB Working Group"
+ CONTACT-INFO
+ "WG E-mail: hubmib@hprnd.rose.hp.com
+ To subscribe: hubmib-request@hprnd.rose.hp.com
+
+
+
+Flick & Johnson Standards Track [Page 11]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ Chair: Dan Romascanu
+ Postal: LANNET Ltd.
+ Atidum Technology Park, Bldg. 3
+ Tel Aviv 61131
+ Israel
+ Tel: +972 3 645 8414
+ E-mail: dromasca@lannet.com
+
+ Editor: John Flick
+ Postal: Hewlett-Packard Company
+ 8000 Foothills Blvd. M/S 5556
+ Roseville, CA 95747-5556
+ USA
+ Tel: +1 916 785 4018
+ Fax: +1 916 785 3583
+ E-mail: johnf@hprnd.rose.hp.com
+
+ Editor: Jeffrey Johnson
+ Postal: RedBack Networks
+ 2570 North First Street, Suite 410
+ San Jose, CA, 95131
+ USA
+ Tel: +1 408 571 2699
+ Fax: +1 408 571 2698
+ E-Mail: jeff@redbacknetworks.com"
+
+ DESCRIPTION "The MIB module to describe generic objects for
+ Ethernet-like network interfaces. This MIB is an
+ updated version of the Ethernet-like MIB in RFC
+ 1650."
+
+ REVISION "9806032150Z"
+ DESCRIPTION "Updated to include support for 100 Mb/sec
+ interfaces."
+
+ REVISION "9402030400Z"
+ DESCRIPTION "Version published as RFC 1650."
+ ::= { mib-2 35 }
+
+ etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 }
+
+ dot3 OBJECT IDENTIFIER ::= { transmission 7 }
+
+ -- the Ethernet-like Statistics group
+
+ dot3StatsTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3StatsEntry
+ MAX-ACCESS not-accessible
+
+
+
+Flick & Johnson Standards Track [Page 12]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ STATUS current
+ DESCRIPTION "Statistics for a collection of ethernet-like
+ interfaces attached to a particular system."
+ ::= { dot3 2 }
+
+ dot3StatsEntry OBJECT-TYPE
+ SYNTAX Dot3StatsEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "Statistics for a particular interface to an
+ ethernet-like medium."
+ INDEX { dot3StatsIndex }
+ ::= { dot3StatsTable 1 }
+
+ Dot3StatsEntry ::=
+ SEQUENCE {
+ dot3StatsIndex InterfaceIndex,
+ dot3StatsAlignmentErrors Counter32,
+ dot3StatsFCSErrors Counter32,
+ dot3StatsSingleCollisionFrames Counter32,
+ dot3StatsMultipleCollisionFrames Counter32,
+ dot3StatsSQETestErrors Counter32,
+ dot3StatsDeferredTransmissions Counter32,
+ dot3StatsLateCollisions Counter32,
+ dot3StatsExcessiveCollisions Counter32,
+ dot3StatsInternalMacTransmitErrors Counter32,
+ dot3StatsCarrierSenseErrors Counter32,
+ dot3StatsFrameTooLongs Counter32,
+ dot3StatsInternalMacReceiveErrors Counter32,
+ dot3StatsEtherChipSet OBJECT IDENTIFIER,
+ dot3StatsSymbolErrors Counter32
+ }
+
+ dot3StatsIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "An index value that uniquely identifies an
+ interface to an ethernet-like medium. The
+ interface identified by a particular value of
+ this index is the same interface as identified
+ by the same value of ifIndex."
+ ::= { dot3StatsEntry 1 }
+
+ dot3StatsAlignmentErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+
+
+
+Flick & Johnson Standards Track [Page 13]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ DESCRIPTION "A count of frames received on a particular
+ interface that are not an integral number of
+ octets in length and do not pass the FCS check.
+
+ The count represented by an instance of this
+ object is incremented when the alignmentError
+ status is returned by the MAC service to the
+ LLC (or other MAC user). Received frames for
+ which multiple error conditions obtain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 2 }
+
+ dot3StatsFCSErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames received on a particular
+ interface that are an integral number of octets
+ in length but do not pass the FCS check.
+
+ The count represented by an instance of this
+ object is incremented when the frameCheckError
+ status is returned by the MAC service to the
+ LLC (or other MAC user). Received frames for
+ which multiple error conditions obtain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 3 }
+
+ dot3StatsSingleCollisionFrames OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of successfully transmitted frames on
+ a particular interface for which transmission
+ is inhibited by exactly one collision.
+
+ A frame that is counted by an instance of this
+ object is also counted by the corresponding
+ instance of either the ifOutUcastPkts,
+ ifOutMulticastPkts, or ifOutBroadcastPkts,
+ and is not counted by the corresponding
+ instance of the dot3StatsMultipleCollisionFrames
+
+
+
+Flick & Johnson Standards Track [Page 14]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ object."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 4 }
+
+
+ dot3StatsMultipleCollisionFrames OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of successfully transmitted frames on
+ a particular interface for which transmission
+ is inhibited by more than one collision.
+
+ A frame that is counted by an instance of this
+ object is also counted by the corresponding
+ instance of either the ifOutUcastPkts,
+ ifOutMulticastPkts, or ifOutBroadcastPkts,
+ and is not counted by the corresponding
+ instance of the dot3StatsSingleCollisionFrames
+ object."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 5 }
+
+
+ dot3StatsSQETestErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of times that the SQE TEST ERROR
+ message is generated by the PLS sublayer for a
+ particular interface. The SQE TEST ERROR
+ message is defined in section 7.2.2.2.4 of
+ ANSI/IEEE 802.3-1985 and its generation is
+ described in section 7.2.4.6 of the same
+ document."
+ REFERENCE "ANSI/IEEE Std 802.3-1985 Carrier Sense
+ Multiple Access with Collision Detection Access
+ Method and Physical Layer Specifications"
+ ::= { dot3StatsEntry 6 }
+
+ dot3StatsDeferredTransmissions OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames for which the first
+ transmission attempt on a particular interface
+ is delayed because the medium is busy.
+
+
+
+
+Flick & Johnson Standards Track [Page 15]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ The count represented by an instance of this
+ object does not include frames involved in
+ collisions."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 7 }
+
+ dot3StatsLateCollisions OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "The number of times that a collision is
+ detected on a particular interface later than
+ 512 bit-times into the transmission of a
+ packet.
+
+ Five hundred and twelve bit-times corresponds
+ to 51.2 microseconds on a 10 Mbit/s system. A
+ (late) collision included in a count
+ represented by an instance of this object is
+ also considered as a (generic) collision for
+ purposes of other collision-related
+ statistics."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 8 }
+
+ dot3StatsExcessiveCollisions OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames for which transmission on a
+ particular interface fails due to excessive
+ collisions."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 9 }
+
+ dot3StatsInternalMacTransmitErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames for which transmission on a
+ particular interface fails due to an internal
+ MAC sublayer transmit error. A frame is only
+ counted by an instance of this object if it is
+ not counted by the corresponding instance of
+ either the dot3StatsLateCollisions object, the
+ dot3StatsExcessiveCollisions object, or the
+ dot3StatsCarrierSenseErrors object.
+
+
+
+
+Flick & Johnson Standards Track [Page 16]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ The precise meaning of the count represented by
+ an instance of this object is implementation-
+ specific. In particular, an instance of this
+ object may represent a count of transmission
+ errors on a particular interface that are not
+ otherwise counted."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 10 }
+
+ dot3StatsCarrierSenseErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "The number of times that the carrier sense
+ condition was lost or never asserted when
+ attempting to transmit a frame on a particular
+ interface.
+
+ The count represented by an instance of this
+ object is incremented at most once per
+ transmission attempt, even if the carrier sense
+ condition fluctuates during a transmission
+ attempt."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 11 }
+
+ -- { dot3StatsEntry 12 } is not assigned
+
+ dot3StatsFrameTooLongs OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames received on a particular
+ interface that exceed the maximum permitted
+ frame size.
+
+ The count represented by an instance of this
+ object is incremented when the frameTooLong
+ status is returned by the MAC service to the
+ LLC (or other MAC user). Received frames for
+ which multiple error conditions obtain are,
+ according to the conventions of IEEE 802.3
+ Layer Management, counted exclusively according
+ to the error status presented to the LLC."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 13 }
+
+ -- { dot3StatsEntry 14 } is not assigned
+
+
+
+Flick & Johnson Standards Track [Page 17]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ -- { dot3StatsEntry 15 } is not assigned
+
+ dot3StatsInternalMacReceiveErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of frames for which reception on a
+ particular interface fails due to an internal
+ MAC sublayer receive error. A frame is only
+ counted by an instance of this object if it is
+ not counted by the corresponding instance of
+ either the dot3StatsFrameTooLongs object, the
+ dot3StatsAlignmentErrors object, or the
+ dot3StatsFCSErrors object.
+ The precise meaning of the count represented by
+ an instance of this object is implementation-
+ specific. In particular, an instance of this
+ object may represent a count of receive errors
+ on a particular interface that are not
+ otherwise counted."
+ REFERENCE "IEEE 802.3 Layer Management"
+ ::= { dot3StatsEntry 16 }
+
+ dot3StatsEtherChipSet OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "This object contains an OBJECT IDENTIFIER
+ which identifies the chipset used to
+ realize the interface. Ethernet-like
+ interfaces are typically built out of
+ several different chips. The MIB implementor
+ is presented with a decision of which chip
+ to identify via this object. The implementor
+ should identify the chip which is usually
+ called the Medium Access Control chip.
+ If no such chip is easily identifiable,
+ the implementor should identify the chip
+ which actually gathers the transmit
+ and receive statistics and error
+ indications. This would allow a
+ manager station to correlate the
+ statistics and the chip generating
+ them, giving it the ability to take
+ into account any known anomalies
+ in the chip."
+ ::= { dot3StatsEntry 17 }
+
+
+
+
+Flick & Johnson Standards Track [Page 18]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3StatsSymbolErrors OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "The number of times there was an invalid data
+ symbol when a valid carrier was present on a
+ particular interface.
+
+ The count represented by an instance of this
+ object is incremented at most once per carrier
+ event, even if multiple symbol errors occur
+ during the carrier event."
+ REFERENCE "IEEE 802.3u-1995 10 & 100 Mb/s Management"
+ ::= { dot3StatsEntry 18 }
+
+ -- the Ethernet-like Collision Statistics group
+
+ -- Implementation of this group is optional; it is appropriate
+ -- for all systems which have the necessary metering
+
+ dot3CollTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot3CollEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "A collection of collision histograms for a
+ particular set of interfaces."
+ ::= { dot3 5 }
+
+ dot3CollEntry OBJECT-TYPE
+ SYNTAX Dot3CollEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "A cell in the histogram of per-frame
+ collisions for a particular interface. An
+ instance of this object represents the
+ frequency of individual MAC frames for which
+ the transmission (successful or otherwise) on a
+ particular interface is accompanied by a
+ particular number of media collisions."
+ INDEX { ifIndex, dot3CollCount }
+ ::= { dot3CollTable 1 }
+
+ Dot3CollEntry ::=
+ SEQUENCE {
+ dot3CollCount INTEGER,
+ dot3CollFrequencies Counter32
+ }
+
+
+
+
+Flick & Johnson Standards Track [Page 19]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ -- { dot3CollEntry 1 } is no longer in use
+
+ dot3CollCount OBJECT-TYPE
+ SYNTAX INTEGER (1..16)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION "The number of per-frame media collisions for
+ which a particular collision histogram cell
+ represents the frequency on a particular
+ interface."
+ ::= { dot3CollEntry 2 }
+
+
+ dot3CollFrequencies OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION "A count of individual MAC frames for which the
+ transmission (successful or otherwise) on a
+ particular interface occurs after the
+ frame has experienced exactly the number
+ of collisions in the associated
+ dot3CollCount object.
+
+ For example, a frame which is transmitted
+ on interface 77 after experiencing
+ exactly 4 collisions would be indicated
+ by incrementing only dot3CollFrequencies.77.4.
+ No other instance of dot3CollFrequencies would
+ be incremented in this example."
+ ::= { dot3CollEntry 3 }
+
+ -- 802.3 Tests
+
+ dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
+
+ dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }
+
+
+ -- TDR Test
+
+ dot3TestTdr OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The Time-Domain Reflectometry (TDR) test is
+ specific to ethernet-like interfaces of type
+ 10Base5 and 10Base2. The TDR value may be
+ useful in determining the approximate distance
+ to a cable fault. It is advisable to repeat
+
+
+
+Flick & Johnson Standards Track [Page 20]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ this test to check for a consistent resulting
+ TDR value, to verify that there is a fault.
+
+ A TDR test returns as its result the time
+ interval, measured in 10 MHz ticks or 100 nsec
+ units, between the start of TDR test
+ transmission and the subsequent detection of a
+ collision or deassertion of carrier. On
+ successful completion of a TDR test, the result
+ is stored as the value of an appropriate
+ instance of an appropriate vendor specific MIB
+ object, and the OBJECT IDENTIFIER of that
+ instance is stored in the appropriate instance
+ of the appropriate test result code object
+ (thereby indicating where the result has been
+ stored)."
+ ::= { dot3Tests 1 }
+
+ -- Loopback Test
+
+ dot3TestLoopBack OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "This test configures the MAC chip and executes
+ an internal loopback test of memory, data paths,
+ and the MAC chip logic. This loopback test can
+ only be executed if the interface is offline.
+ Once the test has completed, the MAC chip should
+ be reinitialized for network operation, but it
+ should remain offline.
+
+ If an error occurs during a test, the
+ appropriate test result object will be set
+ to indicate a failure. The two OBJECT
+ IDENTIFIER values dot3ErrorInitError and
+ dot3ErrorLoopbackError may be used to provided
+ more information as values for an appropriate
+ test result code object."
+ ::= { dot3Tests 2 }
+
+ dot3ErrorInitError OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "Couldn't initialize MAC chip for test."
+ ::= { dot3Errors 1 }
+
+ dot3ErrorLoopbackError OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "Expected data not received (or not received
+ correctly) in loopback test."
+
+
+
+Flick & Johnson Standards Track [Page 21]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ ::= { dot3Errors 2 }
+
+
+ -- 802.3 Hardware Chipsets
+
+ -- The object dot3StatsEtherChipSet is provided to
+ -- identify the MAC hardware used to communicate on an
+ -- interface. The following hardware chipsets are
+ -- registered:
+
+ dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 }
+
+ dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 }
+
+ dot3ChipSetAMD7990 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am7990 Local Area Network
+ Controller for Ethernet (LANCE)."
+ ::= { dot3ChipSetAMD 1 }
+
+ dot3ChipSetAMD79900 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79900 chip."
+ ::= { dot3ChipSetAMD 2 }
+
+ dot3ChipSetAMD79C940 OBJECT-IDENTITY
+
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C940 Media Access Controller
+ for Ethernet (MACE)."
+ ::= { dot3ChipSetAMD 3 }
+
+ dot3ChipSetAMD79C90 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C90 CMOS Local Area Network
+ Controller for Ethernet (C-LANCE)."
+ ::= { dot3ChipSetAMD 4 }
+
+ dot3ChipSetAMD79C960 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C960 PCnet-ISA Single Chip
+ Ethernet Controller for ISA."
+ ::= { dot3ChipSetAMD 5 }
+
+
+
+Flick & Johnson Standards Track [Page 22]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3ChipSetAMD79C961 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C961 PCnet-ISA+ Single Chip
+ Plug & Play Full-Duplex Ethernet Controller
+ for ISA."
+ ::= { dot3ChipSetAMD 6 }
+
+ dot3ChipSetAMD79C961A OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C961A PCnet-ISA II Single Chip
+ Plug & Play Full-Duplex Ethernet Controller
+ for ISA."
+ ::= { dot3ChipSetAMD 7 }
+
+ dot3ChipSetAMD79C965 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C965 PCnet-32 Single Chip
+ Ethernet Controller for PCI."
+ ::= { dot3ChipSetAMD 8 }
+
+ dot3ChipSetAMD79C970 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C970 PCnet PCI Single Chip
+ Ethernet Controller for PCI Local Bus."
+
+ ::= { dot3ChipSetAMD 9 }
+
+ dot3ChipSetAMD79C970A OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices AM79C970A PCnet PCI II Single Chip
+ Full-Duplex Ethernet Controller for PCI Local
+ Bus."
+ ::= { dot3ChipSetAMD 10 }
+
+ dot3ChipSetAMD79C971 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C971 PCnet-FAST Single Chip
+ Full-Duplex 10/100 Mbps Ethernet Controller for
+ PCI Local Bus."
+ ::= { dot3ChipSetAMD 11 }
+
+ dot3ChipSetAMD79C972 OBJECT-IDENTITY
+
+
+
+Flick & Johnson Standards Track [Page 23]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Advanced
+ Micro Devices Am79C972 PCnet-FAST+ Enhanced
+ 10/100 Mbps PCI Ethernet Controller with OnNow
+ Support."
+ ::= { dot3ChipSetAMD 12 }
+
+ dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 }
+
+ dot3ChipSetIntel82586 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Intel
+ 82586 IEEE 802.3 Ethernet LAN Coprocessor."
+ ::= { dot3ChipSetIntel 1 }
+
+ dot3ChipSetIntel82596 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Intel
+ 82596 High-Performance 32-Bit Local Area Network
+ Coprocessor."
+ ::= { dot3ChipSetIntel 2 }
+
+ dot3ChipSetIntel82595 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Intel
+ 82595 High Integration Ethernet Controller."
+ ::= { dot3ChipSetIntel 3 }
+
+ dot3ChipSetIntel82557 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Intel
+ 82557 Fast Ethernet PCI Bus Lan Controller."
+ ::= { dot3ChipSetIntel 4 }
+
+ dot3ChipSetIntel82558 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Intel
+ 82558 Fast Ethernet PCI Bus LAN Controller with
+ Integrated PHY."
+ ::= { dot3ChipSetIntel 5 }
+
+ dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 }
+
+ dot3ChipSetSeeq8003 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 8003 chip set."
+ ::= { dot3ChipSetSeeq 1 }
+
+
+
+Flick & Johnson Standards Track [Page 24]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3ChipSetSeeq80C03 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 80C03 Full-Duplex CMOS Ethernet Data Link
+ Controller (MAC)."
+ ::= { dot3ChipSetSeeq 2 }
+
+ dot3ChipSetSeeq84C30 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 4-Port 84C30 Full-Duplex CMOS Ethernet 10
+ MBit/Sec Data Link Controller (MAC)."
+ ::= { dot3ChipSetSeeq 3 }
+
+ dot3ChipSetSeeq8431 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 4-Port 8431 Full-Duplex CMOS Ethernet 10
+ MBit/Sec Data Link Controller (MAC)."
+ ::= { dot3ChipSetSeeq 4 }
+
+ dot3ChipSetSeeq80C300 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 80C300 Full-Duplex CMOS Ethernet 10/100
+ Mbit/Sec Data Link Controller (MAC)."
+ ::= { dot3ChipSetSeeq 5 }
+
+ dot3ChipSetSeeq84C300 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 4-Port 84C300 Fast Ethernet Controller (MAC)."
+ ::= { dot3ChipSetSeeq 6 }
+
+ dot3ChipSetSeeq84301 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 4-Port 84301 Fast Ethernet Controller (MAC)."
+ ::= { dot3ChipSetSeeq 7 }
+
+ dot3ChipSetSeeq84302 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 4-Port 84302 Fast Ethernet Controller (MAC)."
+ ::= { dot3ChipSetSeeq 8 }
+
+ dot3ChipSetSeeq8100 OBJECT-IDENTITY
+ STATUS current
+
+
+
+Flick & Johnson Standards Track [Page 25]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ DESCRIPTION "The authoritative identifier for the SEEQ
+ 8100 Gigabit Ethernet Controller (MAC & PCS)."
+ ::= { dot3ChipSetSeeq 9 }
+
+ dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 }
+
+ dot3ChipSetNational8390 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP8390 Network Interface
+ Controller."
+ ::= { dot3ChipSetNational 1 }
+
+ dot3ChipSetNationalSonic OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83932 Systems-Oriented Network
+ Interface Controller (SONIC)."
+ ::= { dot3ChipSetNational 2 }
+
+ dot3ChipSetNational83901 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83901 Serial Network Interface
+ Controller (SNIC)."
+ ::= { dot3ChipSetNational 3 }
+
+ dot3ChipSetNational83902 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83902 Serial Network Interface
+ Controller for Twisted Pair (ST-NIC)."
+ ::= { dot3ChipSetNational 4 }
+
+ dot3ChipSetNational83905 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83905 AT Local Area Network
+ Twisted-Pair Interface (AT/LANTIC)."
+ ::= { dot3ChipSetNational 5 }
+
+ dot3ChipSetNational83907 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83907 AT Twisted-Pair Enhanced
+ Coaxial Network Interface Controller
+ (AT/LANTIC II)."
+ ::= { dot3ChipSetNational 6 }
+
+
+
+Flick & Johnson Standards Track [Page 26]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3ChipSetNational83916 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83916 Systems-Oriented Network
+ Interface Controller (SONIC-16)."
+ ::= { dot3ChipSetNational 7 }
+
+ dot3ChipSetNational83934 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83934 Systems-Oriented Network
+ Interface Controller with Twisted Pair Interface
+ (SONIC-T)."
+ ::= { dot3ChipSetNational 8 }
+
+ dot3ChipSetNational83936 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the National
+ Semiconductor DP83936AVUL Full-Duplex Systems-
+ Oriented Network Interface Controller with
+ Twisted Pair Interface (SONIC-T)."
+ ::= { dot3ChipSetNational 9 }
+
+ dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 }
+
+ dot3ChipSetFujitsu86950 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Fujitsu
+ 86950 chip."
+ ::= { dot3ChipSetFujitsu 1 }
+
+ dot3ChipSetFujitsu86960 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Fujitsu
+ MB86960 Network Interface Controller with
+ Encoder/Decoder (NICE)."
+ ::= { dot3ChipSetFujitsu 2 }
+
+ dot3ChipSetFujitsu86964 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Fujitsu
+ MB86964 Ethernet Controller with 10BASE-T
+ Tranceiver."
+ ::= { dot3ChipSetFujitsu 3 }
+
+ dot3ChipSetFujitsu86965A OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Fujitsu
+
+
+
+Flick & Johnson Standards Track [Page 27]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ MB86965A EtherCoupler Single-Chip Ethernet
+ Controller."
+ ::= { dot3ChipSetFujitsu 4 }
+
+ dot3ChipSetFujitsu86965B OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Fujitsu
+ MB86965B EtherCoupler Single-Chip Ethernet
+ Controller (supports full-duplex)."
+ ::= { dot3ChipSetFujitsu 5 }
+
+ dot3ChipSetDigital OBJECT IDENTIFIER ::= { dot3ChipSets 6 }
+
+ dot3ChipSetDigitalDC21040 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor DC21040 chip."
+ ::= { dot3ChipSetDigital 1 }
+
+ dot3ChipSetDigital21041 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor 21041 PCI Ethernet LAN
+ Controller."
+ ::= { dot3ChipSetDigital 2 }
+
+ dot3ChipSetDigital21140 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor 21140 PCI Fast Ethernet LAN
+ Controller."
+ ::= { dot3ChipSetDigital 3 }
+
+ dot3ChipSetDigital21143 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor 21143 PCI/CardBus 10/100-Mb/s
+ Ethernet LAN Controller."
+ ::= { dot3ChipSetDigital 4 }
+
+ dot3ChipSetDigital21340 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor 21340 10/100-MB/s managed buffered
+ port switch."
+ ::= { dot3ChipSetDigital 5 }
+
+ dot3ChipSetDigital21440 OBJECT-IDENTITY
+
+
+
+Flick & Johnson Standards Track [Page 28]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor 21440 Multiport 10/100Mbps
+ Ethernet Controller."
+ ::= { dot3ChipSetDigital 6 }
+
+ dot3ChipSetDigital21540 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Digital
+ Semiconductor 21540 PCI/CardBus Ethernet LAN
+ Controller with Modem Interface."
+ ::= { dot3ChipSetDigital 7 }
+
+ dot3ChipSetTI OBJECT IDENTIFIER ::= { dot3ChipSets 7 }
+
+ dot3ChipSetTIE100 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Texas
+ Instruments TNETE100 ThunderLAN PCI Fast
+ Ethernet Controller."
+ ::= { dot3ChipSetTI 1 }
+
+ dot3ChipSetTIE110 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Texas
+ Instruments TNETE110 ThunderLAN PCI 10BASE-T
+ Ethernet Adapter."
+ ::= { dot3ChipSetTI 2 }
+
+ dot3ChipSetTIX3100 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Texas
+ Instruments TNETX3100 Desktop ThunderSWITCH
+ 8/2."
+ ::= { dot3ChipSetTI 3 }
+
+ dot3ChipSetTIX3150 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Texas
+ Instruments TNETX3150 ThunderSWITCH 12/3."
+ ::= { dot3ChipSetTI 4 }
+
+ dot3ChipSetTIX3270 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Texas
+ Instruments TNETX3270 ThunderSWITCH 24/3."
+ ::= { dot3ChipSetTI 5 }
+
+
+
+
+Flick & Johnson Standards Track [Page 29]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3ChipSetToshiba OBJECT IDENTIFIER ::= { dot3ChipSets 8 }
+
+ dot3ChipSetToshibaTC35815F OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Toshiba
+ TC35815F PCI-Based 100/10Mbps Ethernet
+ Controller."
+ ::= { dot3ChipSetToshiba 1 }
+
+ dot3ChipSetLucent OBJECT IDENTIFIER ::= { dot3ChipSets 9 }
+
+ dot3ChipSetLucentATT1MX10 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Lucent
+ Technologies ATT1MX10 (Spinnaker) Quad MAC and
+ Tranceiver for Ethernet Frame Switching."
+ ::= { dot3ChipSetLucent 1 }
+
+ dot3ChipSetLucentLUC3M08 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Lucent
+ Technologies LUC3M08 Eight Ethernet MACs for
+ 10/100 Mbits/s Frame Switching."
+ ::= { dot3ChipSetLucent 2 }
+
+ dot3ChipSetGalileo OBJECT IDENTIFIER ::= { dot3ChipSets 10 }
+
+ dot3ChipSetGalileoGT48001 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Galileo
+ Technology GT-48001A Switched Ethernet
+ Controller."
+ ::= { dot3ChipSetGalileo 1 }
+
+ dot3ChipSetGalileoGT48002 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Galileo
+ Technology GT-48002A Switched Fast Ethernet
+ Controller."
+ ::= { dot3ChipSetGalileo 2 }
+
+ dot3ChipSetGalileoGT48004 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Galileo
+ Technology GT-48004A Four Port Fast Ethernet
+ Switch for Multiport 10/100BASE-X Systems."
+ ::= { dot3ChipSetGalileo 3 }
+
+
+
+
+Flick & Johnson Standards Track [Page 30]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3ChipSetGalileoGT48207 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Galileo
+ Technology GT-48207 Low-Cost 10 Port Switched
+ Ethernet Controller for 10+10/100BASE-X."
+ ::= { dot3ChipSetGalileo 4 }
+
+ dot3ChipSetGalileoGT48208 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Galileo
+ Technology GT-48208 Advanced 10 Port Switched
+ Ethernet Controller for 10+10/100BASE-X."
+ ::= { dot3ChipSetGalileo 5 }
+
+ dot3ChipSetGalileoGT48212 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Galileo
+ Technology GT-48212 Advanced 14 Port Switched
+ Ethernet Controller for 10+10/100BASE-X."
+ ::= { dot3ChipSetGalileo 6 }
+
+ dot3ChipSetJato OBJECT IDENTIFIER ::= { dot3ChipSets 11 }
+
+ dot3ChipSetJatoJT1001 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the Jato
+ Technologies JT1001 GigEMAC Server
+ 10/100/1000Mbps Ethernet Controller with PCI
+ interface."
+ ::= { dot3ChipSetJato 1 }
+
+ dot3ChipSetXaQti OBJECT IDENTIFIER ::= { dot3ChipSets 12 }
+
+ dot3ChipSetXaQtiXQ11800FP OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the XaQTI
+ XQ11800FP XMAC II Gigabit Ethernet Media Access
+ Controller."
+ ::= { dot3ChipSetXaQti 1 }
+
+ dot3ChipSetXaQtiXQ18110FP OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION "The authoritative identifier for the XaQTI
+ XQ18110FP GigaPower Protocol Accelerator."
+ ::= { dot3ChipSetXaQti 2 }
+
+ -- For those chipsets not represented above, OBJECT IDENTIFIER
+ -- assignment is required in other documentation, e.g.,
+
+
+
+Flick & Johnson Standards Track [Page 31]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ -- assignment within that part of the registration tree
+ -- delegated to individual enterprises (see RFC 1155 and
+ -- RFC 1902).
+ --
+ -- In the future, management of chipset registrations may be
+ -- delegated to the Internet Assigned Numbers Authority (IANA).
+
+ -- conformance information
+
+ etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 }
+
+ etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 }
+ etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 }
+
+
+ -- compliance statements
+
+ etherCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION "The compliance statement for managed network
+ entities which have ethernet-like network
+ interfaces."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { etherStatsGroup }
+
+ GROUP etherCollisionTableGroup
+ DESCRIPTION "This group is optional. It is appropriate
+ for all systems which have the necessary
+ metering. Implementation in such systems is
+ highly recommended."
+ ::= { etherCompliances 1 }
+
+ ether100MbsCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION "The compliance statement for managed network
+ entities which have 100 Mb/sec ethernet-like
+ network interfaces."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { etherStats100MbsGroup }
+
+ GROUP etherCollisionTableGroup
+ DESCRIPTION "This group is optional. It is appropriate
+ for all systems which have the necessary
+ metering. Implementation in such systems is
+ highly recommended."
+ ::= { etherCompliances 2 }
+
+
+
+Flick & Johnson Standards Track [Page 32]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ -- units of conformance
+
+ etherStatsGroup OBJECT-GROUP
+ OBJECTS { dot3StatsIndex,
+ dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors,
+ dot3StatsSingleCollisionFrames,
+ dot3StatsMultipleCollisionFrames,
+ dot3StatsSQETestErrors,
+ dot3StatsDeferredTransmissions,
+ dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions,
+ dot3StatsInternalMacTransmitErrors,
+ dot3StatsCarrierSenseErrors,
+ dot3StatsFrameTooLongs,
+ dot3StatsInternalMacReceiveErrors,
+ dot3StatsEtherChipSet
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ applicable to all ethernet-like network
+ interfaces."
+ ::= { etherGroups 1 }
+
+
+ etherCollisionTableGroup OBJECT-GROUP
+ OBJECTS { dot3CollFrequencies
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing a histogram
+ of packets successfully transmitted after
+ experiencing exactly N collisions."
+ ::= { etherGroups 2 }
+
+
+ etherStats100MbsGroup OBJECT-GROUP
+ OBJECTS { dot3StatsIndex,
+ dot3StatsAlignmentErrors,
+ dot3StatsFCSErrors,
+ dot3StatsSingleCollisionFrames,
+ dot3StatsMultipleCollisionFrames,
+ dot3StatsDeferredTransmissions,
+ dot3StatsLateCollisions,
+ dot3StatsExcessiveCollisions,
+ dot3StatsInternalMacTransmitErrors,
+ dot3StatsCarrierSenseErrors,
+ dot3StatsFrameTooLongs,
+ dot3StatsInternalMacReceiveErrors,
+
+
+
+Flick & Johnson Standards Track [Page 33]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ dot3StatsEtherChipSet,
+ dot3StatsSymbolErrors
+ }
+ STATUS current
+ DESCRIPTION "A collection of objects providing information
+ applicable to 100 Mb/sec ethernet-like network
+ interfaces."
+ ::= { etherGroups 3 }
+
+
+ END
+
+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
+ licenses to be made available, or the result of an attempt made to
+ 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.
+
+6. Acknowledgements
+
+ This document was produced by the 802.3 Hub MIB Working Group.
+
+ This document is almost completely based on both the Standard
+ Ethernet MIB, RFC 1643 [10], and the Proposed Standard Ethernet MIB
+ using the SNMPv2 SMI, RFC 1650 [11], both of which were edited by
+ Frank Kastenholz of FTP Software and produced by the Ethernet MIB
+ Working Group. This document extends those documents by providing
+ support for 100 Mb/sec ethernet interfaces as outlined in [6].
+
+ RFC 1643 and RFC 1650, in turn, are based on the Draft Standard
+ Ethernet MIB, RFC 1398 [9], also edited by Frank Kastenholz and
+ produced by the Ethernet MIB Working Group.
+
+
+
+Flick & Johnson Standards Track [Page 34]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB,
+ RFC 1284 [8], which was edited by John Cook of Chipcom and produced
+ by the Transmission MIB Working Group. The Ethernet MIB Working
+ Group gathered implementation experience of the variables specified
+ in RFC 1284 and used that information to develop this revised MIB.
+
+ RFC 1284, in turn, is based on a document written by Frank
+ Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management
+ Draft M compatible MIB for TCP/IP Networks [7]. This document has
+ been modestly reworked, initially by the SNMP Working Group, and then
+ by the Transmission Working Group, to reflect the current conventions
+ for defining objects for MIB interfaces. James Davin, of the MIT
+ Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
+ Systems, contributed to later drafts of this memo. Marshall Rose of
+ Performance Systems International, Inc. converted the document into
+ its current concise format. Anil Rijsinghani of DEC contributed text
+ that more adequately describes the TDR test. Thanks to Frank
+ Kastenholz of Interlan and Louis Steinberg of IBM for their
+ experimentation.
+
+7. References
+
+ [1] Information processing systems - Open Systems Interconnection -
+ Specification of Abstract Syntax Notation One (ASN.1),
+ International Organization for Standardization, International
+ Standard 8824, December 1987.
+
+ [2] 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.
+
+ [3] 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.
+
+ [4] 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.
+
+ [5] IEEE, IEEE 802.3 Layer Management, November 1988.
+
+ [6] IEEE, IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30,
+ Supplement to IEEE Std 802.3, October 26, 1995.
+
+ [7] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB
+ for TCP/IP Networks", electronic mail message to mib-
+ wg@nnsc.nsf.net, 9 June 1989.
+
+
+
+Flick & Johnson Standards Track [Page 35]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ [8] Cook, J., "Definitions of Managed Objects for Ethernet-Like
+ Interface Types", RFC 1284, December 1991.
+
+ [9] Kastenholz, F., "Definitions of Managed Objects for the
+ Ethernet-like Interface Types", RFC 1398, January 1993.
+
+ [10] Kastenholz, F., "Definitions of Managed Objects for the
+ Ethernet-like Interface Types", RFC 1643, July 1994.
+
+ [11] Kastenholz, F., "Definitions of Managed Objects for the
+ Ethernet-like Interface Types using SMIv2", RFC 1650, August
+ 1994.
+
+ [12] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB
+ using SMIv2", RFC 2233, Cisco Systems, November 1997.
+
+ [13] Bradner, S., "Key words for use in RFCs to Indicate Requirements
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [14] deGraaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S.
+ Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium
+ Attachment Units (MAUs) using SMIv2", RFC 2239, November 1997.
+
+ [15] Kastenholz, F., "Implementation Notes and Experience for The
+ Internet Ethernet MIB", RFC 1369, October 1992.
+
+ [16] McCloghrie, K., and M. Rose, Editors, "Management Information
+ Base for Network Management of TCP/IP-based internets: MIB-II",
+ STD 17, RFC 1213, March 1991.
+
+ [17] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
+ for version 3 of the Simple Network Management Protocol
+ (SNMPv3)", RFC 2274, January 1998.
+
+ [18] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
+ Control Model for the Simple Network Management Protocol (SNMP)",
+ RFC 2275, January 1998.
+
+8. Security Considerations
+
+ There are no management objects defined in this MIB that have a MAX-
+ ACCESS clause of read-write and/or read-create. So, if this MIB is
+ implemented correctly, then there is no risk that an intruder can
+ alter or create any management objects of this MIB via direct SNMP
+ SET operations.
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 36]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+ There are a number of managed objects in this MIB that may be
+ considered to contain sensitive information. In particular, the
+ dot3StatsEtherChipSet object may be considered sensitive in many
+ environments, since it would allow an intruder to obtain information
+ about which vendor's equipment is in use on the network.
+
+ Therefore, it may be important in some environments to control read
+ access to these objects and possibly to even encrypt the values of
+ these object when sending them over the network via SNMP. Not all
+ versions of SNMP provide features for such a secure environment.
+
+ 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 (read) the objects in this MIB.
+
+ It is recommended that the implementors consider the security
+ features as provided by the SNMPv3 framework. Specifically, the use
+ of the User-based Security Model RFC 2274 [17] and the View-based
+ Access Control Model RFC 2275 [18] 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
+
+ John Flick
+ Hewlett-Packard Company
+ 8000 Foothills Blvd. M/S 5556
+ Roseville, CA 95747-5556
+
+ Phone: +1 916 785 4018
+ EMail: johnf@hprnd.rose.hp.com
+
+
+ Jeffrey Johnson
+ RedBack Networks
+ 2570 North First Street, Suite 410
+ San Jose, CA, 95131, USA
+
+ Phone: +1 408 571 2699
+ EMail: jeff@redbacknetworks.com
+
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 37]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+A. Change Log
+
+ This section enumerates changes made to RFC 1650 to produce this
+ document.
+
+ (1) The MODULE-IDENTITY has been updated to reflect the changes
+ in the MIB.
+
+ (2) A new object, dot3StatsSymbolErrors, has been added.
+
+ (3) The definition of the object dot3StatsIndex has been
+ converted to use the SMIv2 OBJECT-TYPE macro.
+
+ (4) A new conformance group, etherStats100MbsGroup, has been
+ added.
+
+ (5) A new compliance statement, ether100MbsCompliance, has
+ been added.
+
+ (6) The Acknowledgements were extended to provide a more
+ complete history of the origin of this document.
+
+ (7) The discussion of ifType has been expanded.
+
+ (8) A section on mapping of Interfaces MIB objects has
+ been added.
+
+ (9) A section defining the relationship of this MIB to
+ the MAU MIB has been added.
+
+ (10) A section on the mapping of IEEE 802.3 managed objects
+ to this MIB and the Interfaces MIB has been added.
+
+ (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets
+ OIDs to use the OBJECT-IDENTITY macro.
+
+ (12) Added to the list of registered dot3ChipSets.
+
+ (13) An intellectual property notice and copyright notice
+ were added, as required by RFC 2026.
+
+
+
+
+
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 38]
+
+RFC 2358 MIB for Ethernet-like Interface Types June 1998
+
+
+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
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Flick & Johnson Standards Track [Page 39]
+