< draft-ietf-hubmib-etherif-mib-06.txt   draft-ietf-hubmib-etherif-mib-07.txt >
Hub MIB Working Group J. Flick Hub MIB Working Group J. Flick
INTERNET DRAFT Hewlett-Packard Company INTERNET DRAFT Hewlett-Packard Company
J. Johnson J. Johnson
RedBack Networks RedBack Networks
May 1998 June 1998
Definitions of Managed Objects for Definitions of Managed Objects for
the Ethernet-like Interface Types the Ethernet-like Interface Types
<draft-ietf-hubmib-etherif-mib-06.txt> <draft-ietf-hubmib-etherif-mib-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
The origin of this memo is from RFC 1650 ''Definitions of Managed This memo obsoletes RFC 1650 ''Definitions of Managed Objects for the
Objects for the Ethernet-like Interface Types using SMIv2.'' This Ethernet-like Interface Types using SMIv2.'' This memo extends that
memo extends that specification by including management information specification by including management information useful for the
useful for the management of 100 Mb/s Ethernet interfaces. 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.
Distribution of this memo is unlimited. Please forward comments to Distribution of this memo is unlimited. Please forward comments to
hubmib@hprnd.rose.hp.com. hubmib@hprnd.rose.hp.com.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
2. The SNMP Network Management Framework ...................... 2 2. The SNMP Network Management Framework ...................... 3
2.1. Object Definitions ....................................... 3 2.1. Object Definitions ....................................... 3
3. Change Log ................................................. 3 3. Overview ................................................... 3
4. Overview ................................................... 4 3.1. Relation to MIB-2 ........................................ 4
4.1. Relation to MIB-2 ........................................ 4 3.2. Relation to the Interfaces MIB ........................... 4
4.2. Relation to the Interfaces MIB ........................... 5 3.2.1. Layering Model ......................................... 4
4.2.1. Layering Model ......................................... 5 3.2.2. Virtual Circuits ....................................... 5
4.2.2. Virtual Circuits ....................................... 5 3.2.3. ifTestTable ............................................ 5
4.2.3. ifTestTable ............................................ 6 3.2.4. ifRcvAddressTable ...................................... 5
4.2.4. ifRcvAddressTable ...................................... 6 3.2.5. ifPhysAddress .......................................... 5
4.2.5. ifPhysAddress .......................................... 6 3.2.6. ifType ................................................. 6
4.2.6. ifType ................................................. 7 3.2.7. Specific Interface MIB Objects ......................... 7
4.2.7. Specific Interface MIB Objects ......................... 8 3.3. Relation to the 802.3 MAU MIB ............................ 10
4.3. Relation to the 802.3 MAU MIB ............................ 11 3.4. Mapping of IEEE 802.3 Managed Objects .................... 10
4.4. Mapping of IEEE 802.3 Managed Objects .................... 11 4. Definitions ................................................ 12
5. Definitions ................................................ 12 5. Intellectual Property ...................................... 34
6. Intellectual Property ...................................... 35 6. Acknowledgements ........................................... 35
7. Acknowledgements ........................................... 35 7. References ................................................. 35
8. References ................................................. 36 8. Security Considerations .................................... 37
9. Security Considerations .................................... 38 9. Author's Addresses ......................................... 38
10. Author's Addresses ........................................ 38 A. Change Log ................................................. 38
11. Full Copyright Statement .................................. 39 B. Full Copyright Statement ................................... 39
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it defines objects for managing ethernet-like In particular, it defines objects for managing ethernet-like
interfaces. interfaces.
This memo also includes a MIB module. This MIB module extends the This memo also includes a MIB module. This MIB module extends the
list of managed objects specified in the earlier version of this MIB: list of managed objects specified in the earlier version of this MIB:
skipping to change at page 3, line 22 skipping to change at page 3, line 30
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [1] defined using the subset of Abstract Syntax Notation One (ASN.1) [1]
defined in the SMI [2]. In particular, each object object type is defined in the SMI [2]. In particular, each object object type is
named by an OBJECT IDENTIFIER, an administratively assigned name. named by an OBJECT IDENTIFIER, an administratively assigned name.
The object type together with an object instance serves to uniquely The object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to convenience, we often use a textual string, termed the descriptor, to
refer to the object type. refer to the object type.
3. Change Log 3. Overview
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.
4. Overview
Instances of these object types represent attributes of an interface Instances of these object types represent attributes of an interface
to an ethernet-like communications medium. At present, ethernet-like to an ethernet-like communications medium. At present, ethernet-like
media are identified by the following values of the ifType object in media are identified by the following values of the ifType object in
the Interfaces MIB [12]: the Interfaces MIB [12]:
ethernetCsmacd(6) ethernetCsmacd(6)
iso88023Csmacd(7) iso88023Csmacd(7)
starLan(11) starLan(11)
skipping to change at page 4, line 47 skipping to change at page 4, line 15
To the extent that some of the attributes defined in [5] are To the extent that some of the attributes defined in [5] are
represented by previously defined objects in MIB-2 [16] or in the represented by previously defined objects in MIB-2 [16] or in the
Interfaces MIB [12], such attributes are not redundantly represented Interfaces MIB [12], such attributes are not redundantly represented
by objects defined in this memo. Among the attributes represented by by objects defined in this memo. Among the attributes represented by
objects defined in other memos are the number of octets transmitted objects defined in other memos are the number of octets transmitted
or received on a particular interface, the number of frames or received on a particular interface, the number of frames
transmitted or received on a particular interface, the promiscuous transmitted or received on a particular interface, the promiscuous
status of an interface, the MAC address of an interface, and status of an interface, the MAC address of an interface, and
multicast information associated with an interface. multicast information associated with an interface.
4.1. Relation to MIB-2 3.1. Relation to MIB-2
This section applies only when this MIB is used in conjunction with This section applies only when this MIB is used in conjunction with
the "old" (RFC 1213) [16] interface group. the "old" (RFC 1213) [16] interface group.
The relationship between an ethernet-like interface and an interface The relationship between an ethernet-like interface and an interface
in the context of the Internet-standard MIB is one-to-one. As such, 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 the value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined herein. identify corresponding instances of the objects defined herein.
For agents which implement the (now deprecated) ifSpecific object, an For agents which implement the (now deprecated) ifSpecific object, an
instance of that object that is associated with an ethernet-like instance of that object that is associated with an ethernet-like
interface has the OBJECT IDENTIFIER value: interface has the OBJECT IDENTIFIER value:
dot3 OBJECT IDENTIFER ::= { transmission 7 } dot3 OBJECT IDENTIFER ::= { transmission 7 }
4.2. Relation to the Interfaces MIB 3.2. Relation to the Interfaces MIB
The Interface MIB [12] requires that any MIB which is an adjunct of The Interface MIB [12] requires that any MIB which is an adjunct of
the Interface MIB clarify specific areas within the Interface MIB. the Interface MIB clarify specific areas within the Interface MIB.
These areas were intentionally left vague in the Interface MIB to These areas were intentionally left vague in the Interface MIB to
avoid over constraining the MIB, thereby precluding management of avoid over constraining the MIB, thereby precluding management of
certain media-types. certain media-types.
Section 3.3 of [12] enumerates several areas which a media-specific Section 3.3 of [12] enumerates several areas which a media-specific
MIB must clarify. Each of these areas is addressed in a following MIB must clarify. Each of these areas is addressed in a following
subsection. The implementor is referred to [12] in order to subsection. The implementor is referred to [12] in order to
understand the general intent of these areas. understand the general intent of these areas.
4.2.1. Layering Model 3.2.1. Layering Model
This MIB does not provide for layering. There are no sublayers. This MIB does not provide for layering. There are no sublayers.
EDITOR'S NOTE: EDITOR'S NOTE:
One could foresee the development of an 802.2 and enet-transceiver One could foresee the development of an 802.2 and enet-transceiver
MIB. They could be higher and lower sublayers, respectively. All MIB. They could be higher and lower sublayers, respectively. All
that THIS document should do is allude to the possibilities and urge 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 the implementor to be aware of the possibility and that they may have
requirements which supersede the requirements in this document. requirements which supersede the requirements in this document.
4.2.2. Virtual Circuits 3.2.2. Virtual Circuits
This medium does not support virtual circuits and this area is not This medium does not support virtual circuits and this area is not
applicable to this MIB. applicable to this MIB.
4.2.3. ifTestTable 3.2.3. ifTestTable
This MIB defines two tests for media which are instrumented with this This MIB defines two tests for media which are instrumented with this
MIB; TDR and Loopback. Implementation of these tests is not MIB; TDR and Loopback. Implementation of these tests is not
required. Many common interface chips do not support one or both of required. Many common interface chips do not support one or both of
these tests. these tests.
These two tests are provided as a convenience, allowing a common These two tests are provided as a convenience, allowing a common
method to invoke the test. method to invoke the test.
Standard MIBs do not include objects in which to return the results 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 of the TDR test. Any needed objects MUST be provided in the vendor
specific MIB. specific MIB.
Note that the ifTestTable is now deprecated. Work is underway to Note that the ifTestTable is now deprecated. Work is underway to
define a replacement MIB for system and interface testing. It is define a replacement MIB for system and interface testing. It is
expected that the tests defined in this document will be usable in expected that the tests defined in this document will be usable in
this replacement MIB. this replacement MIB.
4.2.4. ifRcvAddressTable 3.2.4. ifRcvAddressTable
This table contains all IEEE 802.3 addresses, unicast, multicast, and This table contains all IEEE 802.3 addresses, unicast, multicast, and
broadcast, for which this interface will receive packets and forward broadcast, for which this interface will receive packets and forward
them up to a higher layer entity for local consumption. The format them up to a higher layer entity for local consumption. The format
of the address, contained in ifRcvAddressAddress, is the same as for of the address, contained in ifRcvAddressAddress, is the same as for
ifPhysAddress. ifPhysAddress.
In the event that the interface is part of a MAC bridge, this table In the event that the interface is part of a MAC bridge, this table
does not include unicast addresses which are accepted for possible does not include unicast addresses which are accepted for possible
forwarding out some other port. This table is explicitly not forwarding out some other port. This table is explicitly not
intended to provide a bridge address filtering mechanism. intended to provide a bridge address filtering mechanism.
4.2.5. ifPhysAddress 3.2.5. ifPhysAddress
This object contains the IEEE 802.3 address which is placed in the 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 source-address field of any Ethernet, Starlan, or IEEE 802.3 frames
that originate at this interface. Usually this will be kept in ROM that originate at this interface. Usually this will be kept in ROM
on the interface hardware. Some systems may set this address via on the interface hardware. Some systems may set this address via
software. software.
In a system where there are several such addresses the designer has a 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 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 be of use to network management (e.g. the address placed in ARP
responses for systems which are primarily IP systems). responses for systems which are primarily IP systems).
skipping to change at page 7, line 14 skipping to change at page 6, line 26
address is suggested. address is suggested.
If the address can not be determined, an octet string of zero length If the address can not be determined, an octet string of zero length
should be returned. should be returned.
The address is stored in binary in this object. The address is The address is stored in binary in this object. The address is
stored in "canonical" bit order, that is, the Group Bit is positioned 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 as the low-order bit of the first octet. Thus, the first byte of a
multicast address would have the bit 0x01 set. multicast address would have the bit 0x01 set.
4.2.6. ifType 3.2.6. ifType
This MIB applies to interfaces which have any of the following ifType This MIB applies to interfaces which have any of the following ifType
values: values:
ethernetCsmacd(6) ethernetCsmacd(6)
iso88023Csmacd(7) iso88023Csmacd(7)
starLan(11) starLan(11)
It is RECOMMENDED that all Ethernet-like interfaces use an ifType of It is RECOMMENDED that all Ethernet-like interfaces use an ifType of
ethernetCsmacd(6) regardless of the speed that the interface is ethernetCsmacd(6) regardless of the speed that the interface is
skipping to change at page 8, line 7 skipping to change at page 7, line 19
ether100MbsCompliance compliance statement applies to all Ethernet- ether100MbsCompliance compliance statement applies to all Ethernet-
like interfaces whose maximum supported speed is 100Mbit/sec. like interfaces whose maximum supported speed is 100Mbit/sec.
An interface that is capable of operating at 100Mbit/sec MUST An interface that is capable of operating at 100Mbit/sec MUST
implement the ether100MbsCompliance compliance statement, even if it implement the ether100MbsCompliance compliance statement, even if it
is currently operating at a lower speed. Counters in the is currently operating at a lower speed. Counters in the
ether100MbsCompliance compliance statement that only apply to 100 ether100MbsCompliance compliance statement that only apply to 100
Mbit interfaces would simply not increment when the interface is Mbit interfaces would simply not increment when the interface is
operating at a lower speed. operating at a lower speed.
4.2.7. Specific Interface MIB Objects 3.2.7. Specific Interface MIB Objects
The following table provides specific implementation guidelines for The following table provides specific implementation guidelines for
applying the interface group objects to ethernet-like media. applying the interface group objects to ethernet-like media.
Object Object
ifIndex Each ethernet-like interface is ifIndex Each ethernet-like interface is
represented by an ifEntry. The represented by an ifEntry. The
dot3StatsTable in this MIB module is dot3StatsTable in this MIB module is
indexed by dot3StatsIndex. The interface indexed by dot3StatsIndex. The interface
identified by a particular value of identified by a particular value of
dot3StatsIndex is the same interface as dot3StatsIndex is the same interface as
identified by the same value of ifIndex. identified by the same value of ifIndex.
ifDescr Refer to [12]. ifDescr Refer to [12].
ifType Refer to section 4.2.6. ifType Refer to section 3.2.6.
ifMtu 1500 octets. ifMtu 1500 octets.
ifSpeed The current operational speed of the ifSpeed The current operational speed of the
interface in bits per second. For interface in bits per second. For
current ethernet-like interfaces, this current ethernet-like interfaces, this
will be equal to 1,000,000 (1 million), will be equal to 1,000,000 (1 million),
10,000,000 (10 million), or 100,000,000 10,000,000 (10 million), or 100,000,000
(100 million). If the interface (100 million). If the interface
implements auto-negotiation, implements auto-negotiation,
skipping to change at page 8, line 49 skipping to change at page 8, line 14
supported by the interface. Note that supported by the interface. Note that
this object MUST NOT indicate a doubled this object MUST NOT indicate a doubled
value when operating in full-duplex value when operating in full-duplex
mode. It MUST indicate the correct mode. It MUST indicate the correct
line speed regardless of the current line speed regardless of the current
duplex mode. The correct object to use duplex mode. The correct object to use
to determine the duplex mode of the to determine the duplex mode of the
interface is the ifMauType object in the interface is the ifMauType object in the
802.3 MAU MIB. 802.3 MAU MIB.
ifPhysAddress Refer to section 4.2.5. ifPhysAddress Refer to section 3.2.5.
ifAdminStatus Write access is not required. Support ifAdminStatus Write access is not required. Support
for 'testing' is not required. for 'testing' is not required.
ifOperStatus The operational state of the interface. ifOperStatus The operational state of the interface.
Support for 'testing' is not required. Support for 'testing' is not required.
The value 'dormant' has no meaning for The value 'dormant' has no meaning for
an ethernet-like interface. an ethernet-like interface.
ifLastChange Refer to [12]. ifLastChange Refer to [12].
skipping to change at page 11, line 7 skipping to change at page 10, line 20
ifMauType object in the 802.3 MAU MIB. ifMauType object in the 802.3 MAU MIB.
ifPromiscuousMode Refer to [12]. ifPromiscuousMode Refer to [12].
ifConnectorPresent This will normally be 'true'. ifConnectorPresent This will normally be 'true'.
ifAlias Refer to [12]. ifAlias Refer to [12].
ifCounterDiscontinuityTime Refer to [12]. ifCounterDiscontinuityTime Refer to [12].
ifStackHigherLayer Refer to section 4.2.1. ifStackHigherLayer Refer to section 3.2.1.
ifStackLowerLayer ifStackLowerLayer
ifStackStatus ifStackStatus
ifRcvAddressAddress Refer to section 4.2.4. ifRcvAddressAddress Refer to section 3.2.4.
ifRcvAddressStatus ifRcvAddressStatus
ifRcvAddressType ifRcvAddressType
4.3. Relation to the 802.3 MAU MIB 3.3. Relation to the 802.3 MAU MIB
Support for the mauModIfCompl compliance statement of the MAU-MIB Support for the mauModIfCompl compliance statement of the MAU-MIB
[14] is REQUIRED for Ethernet-like interfaces. This MIB is needed in [14] is REQUIRED for Ethernet-like interfaces. This MIB is needed in
order to allow applications to determine the current MAU type in use 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 by the interface. The MAU type indicates not only the media type in
use, but also indicates whether the interface is operating in half- use, but also indicates whether the interface is operating in half-
duplex or full-duplex mode. Implementing this MIB module without duplex or full-duplex mode. Implementing this MIB module without
implementing the MAU-MIB would leave applications with no standard implementing the MAU-MIB would leave applications with no standard
way to determine the duplex mode of the interface. way to determine the duplex mode of the interface.
4.4. Mapping of IEEE 802.3 Managed Objects 3.4. Mapping of IEEE 802.3 Managed Objects
IEEE 802.3 Managed Object Corresponding SNMP Object IEEE 802.3 Managed Object Corresponding SNMP Object
oMacEntity oMacEntity
.aMACID dot3StatsIndex or .aMACID dot3StatsIndex or
IF-MIB - ifIndex IF-MIB - ifIndex
.aFramesTransmittedOK IF-MIB - ifOutUCastPkts + .aFramesTransmittedOK IF-MIB - ifOutUCastPkts +
ifOutMulticastPkts + ifOutMulticastPkts +
ifOutBroadcastPkts ifOutBroadcastPkts
.aSingleCollisionFrames dot3StatsSingleCollisionFrames .aSingleCollisionFrames dot3StatsSingleCollisionFrames
skipping to change at page 12, line 36 skipping to change at page 12, line 5
.aInRangeLengthErrors .aInRangeLengthErrors
.aOutOfRangeLengthField .aOutOfRangeLengthField
.aMACEnableStatus .aMACEnableStatus
.aTransmitEnableStatus .aTransmitEnableStatus
.aMulticastReceiveStatus .aMulticastReceiveStatus
.acInitializeMAC .acInitializeMAC
Please see [15] for the detailed reasoning on why these objects were Please see [15] for the detailed reasoning on why these objects were
removed. removed.
5. Definitions 4. Definitions
EtherLike-MIB DEFINITIONS ::= BEGIN EtherLike-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
Counter32, mib-2, transmission Counter32, mib-2, transmission
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
ifIndex, InterfaceIndex ifIndex, InterfaceIndex
FROM IF-MIB; FROM IF-MIB;
etherMIB MODULE-IDENTITY etherMIB MODULE-IDENTITY
LAST-UPDATED "9805122107Z" -- May 12, 1998 LAST-UPDATED "9806032150Z" -- June 3, 1998
ORGANIZATION "IETF 802.3 Hub MIB Working Group" ORGANIZATION "IETF 802.3 Hub MIB Working Group"
CONTACT-INFO CONTACT-INFO
"WG E-mail: hubmib@hprnd.rose.hp.com "WG E-mail: hubmib@hprnd.rose.hp.com
To subscribe: hubmib-request@hprnd.rose.hp.com To subscribe: hubmib-request@hprnd.rose.hp.com
Chair: Dan Romascanu Chair: Dan Romascanu
Postal: LANNET Ltd. Postal: LANNET Ltd.
Atidum Technology Park, Bldg. 3 Atidum Technology Park, Bldg. 3
Tel Aviv 61131 Tel Aviv 61131
Israel Israel
skipping to change at page 13, line 41 skipping to change at page 13, line 7
USA USA
Tel: +1 408 571 2699 Tel: +1 408 571 2699
Fax: +1 408 571 2698 Fax: +1 408 571 2698
E-Mail: jeff@redbacknetworks.com" E-Mail: jeff@redbacknetworks.com"
DESCRIPTION "The MIB module to describe generic objects for DESCRIPTION "The MIB module to describe generic objects for
Ethernet-like network interfaces. This MIB is an Ethernet-like network interfaces. This MIB is an
updated version of the Ethernet-like MIB in RFC updated version of the Ethernet-like MIB in RFC
1650." 1650."
REVISION "9802260008Z" REVISION "9806032150Z"
DESCRIPTION "Updated to include support for 100 Mb/sec DESCRIPTION "Updated to include support for 100 Mb/sec
interfaces." interfaces."
REVISION "9402030400Z" REVISION "9402030400Z"
DESCRIPTION "Version published as RFC 1650." DESCRIPTION "Version published as RFC 1650."
::= { mib-2 35 } ::= { mib-2 35 }
etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 } etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 }
dot3 OBJECT IDENTIFIER ::= { transmission 7 } dot3 OBJECT IDENTIFIER ::= { transmission 7 }
skipping to change at page 33, line 13 skipping to change at page 32, line 28
STATUS current STATUS current
DESCRIPTION "The authoritative identifier for the XaQTI DESCRIPTION "The authoritative identifier for the XaQTI
XQ18110FP GigaPower Protocol Accelerator." XQ18110FP GigaPower Protocol Accelerator."
::= { dot3ChipSetXaQti 2 } ::= { dot3ChipSetXaQti 2 }
-- For those chipsets not represented above, OBJECT IDENTIFIER -- For those chipsets not represented above, OBJECT IDENTIFIER
-- assignment is required in other documentation, e.g., -- assignment is required in other documentation, e.g.,
-- assignment within that part of the registration tree -- assignment within that part of the registration tree
-- delegated to individual enterprises (see RFC 1155 and -- delegated to individual enterprises (see RFC 1155 and
-- RFC 1902). -- RFC 1902).
--
-- In the future, management of chipset registrations may be
-- delegated to the Internet Assigned Numbers Authority (IANA).
-- conformance information -- conformance information
etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 }
etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 } etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 }
etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 } etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 }
-- compliance statements -- compliance statements
skipping to change at page 35, line 19 skipping to change at page 34, line 36
dot3StatsSymbolErrors dot3StatsSymbolErrors
} }
STATUS current STATUS current
DESCRIPTION "A collection of objects providing information DESCRIPTION "A collection of objects providing information
applicable to 100 Mb/sec ethernet-like network applicable to 100 Mb/sec ethernet-like network
interfaces." interfaces."
::= { etherGroups 3 } ::= { etherGroups 3 }
END END
6. Intellectual Property 5. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 35, line 41 skipping to change at page 35, line 13
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
7. Acknowledgements 6. Acknowledgements
This document was produced by the 802.3 Hub MIB Working Group. This document was produced by the 802.3 Hub MIB Working Group.
This document is almost completely based on both the Standard This document is almost completely based on both the Standard
Ethernet MIB, RFC 1643 [10], and the Proposed Standard Ethernet MIB Ethernet MIB, RFC 1643 [10], and the Proposed Standard Ethernet MIB
using the SNMPv2 SMI, RFC 1650 [11], both of which were edited by using the SNMPv2 SMI, RFC 1650 [11], both of which were edited by
Frank Kastenholz of FTP Software and produced by the Ethernet MIB Frank Kastenholz of FTP Software and produced by the Ethernet MIB
Working Group. This document extends those documents by providing Working Group. This document extends those documents by providing
support for 100 Mb/sec ethernet interfaces as outlined in [6]. support for 100 Mb/sec ethernet interfaces as outlined in [6].
skipping to change at page 36, line 31 skipping to change at page 35, line 48
by the Transmission Working Group, to reflect the current conventions by the Transmission Working Group, to reflect the current conventions
for defining objects for MIB interfaces. James Davin, of the MIT for defining objects for MIB interfaces. James Davin, of the MIT
Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
Systems, contributed to later drafts of this memo. Marshall Rose of Systems, contributed to later drafts of this memo. Marshall Rose of
Performance Systems International, Inc. converted the document into Performance Systems International, Inc. converted the document into
its current concise format. Anil Rijsinghani of DEC contributed text its current concise format. Anil Rijsinghani of DEC contributed text
that more adequately describes the TDR test. Thanks to Frank that more adequately describes the TDR test. Thanks to Frank
Kastenholz of Interlan and Louis Steinberg of IBM for their Kastenholz of Interlan and Louis Steinberg of IBM for their
experimentation. experimentation.
8. References 7. References
[1] Information processing systems - Open Systems Interconnection - [1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International International Organization for Standardization, International
Standard 8824, December 1987. Standard 8824, December 1987.
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version S. Waldbusser, "Structure of Management Information for Version
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996. January 1996.
skipping to change at page 38, line 10 skipping to change at page 37, line 29
International, March 1991. International, March 1991.
[17] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) [17] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2274, January 1998. (SNMPv3)", RFC 2274, January 1998.
[18] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [18] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model for the Simple Network Management Protocol Control Model for the Simple Network Management Protocol
(SNMP)", RFC 2275, January 1998. (SNMP)", RFC 2275, January 1998.
9. Security Considerations 8. Security Considerations
There are no management objects defined in this MIB that have a MAX- 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 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 implemented correctly, then there is no risk that an intruder can
alter or create any management objects of this MIB via direct SNMP alter or create any management objects of this MIB via direct SNMP
SET operations. SET operations.
There are a number of managed objects in this MIB that may be There are a number of managed objects in this MIB that may be
considered to contain sensitive information. None of them however considered to contain sensitive information. In particular, the
are more sensitive than any other generic MIB objects. 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 Therefore, it may be important in some environments to control read
access to these objects and possibly to even encrypt the values of access to these objects and possibly to even encrypt the values of
these object when sending them over the network via SNMP. Not all these object when sending them over the network via SNMP. Not all
versions of SNMP provide features for such a secure environment. versions of SNMP provide features for such a secure environment.
SNMPv1 by itself is such an insecure environment. Even if the SNMPv1 by itself is such an insecure environment. Even if the
network itself is secure (for example by using IPSec), even then, 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 there is no control as to who on the secure network is allowed to
access and GET (read) the objects in this MIB. access and GET (read) the objects in this MIB.
skipping to change at page 38, line 42 skipping to change at page 38, line 16
It is recommended that the implementors consider the security It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2274 [17] and the View-based of the User-based Security Model RFC 2274 [17] and the View-based
Access Control Model RFC 2275 [18] is recommended. Access Control Model RFC 2275 [18] is recommended.
It is then a customer/user responsibility to ensure that the SNMP It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly entity giving access to an instance of this MIB, is properly
configured to give access to those objects only to those principals configured to give access to those objects only to those principals
(users) that have legitimate rights to access them. (users) that have legitimate rights to access them.
10. Author's Addresses 9. Author's Addresses
John Flick John Flick
Hewlett-Packard Company Hewlett-Packard Company
8000 Foothills Blvd. M/S 5556 8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556 Roseville, CA 95747-5556
Phone: +1 916 785 4018 Phone: +1 916 785 4018
Email: johnf@hprnd.rose.hp.com Email: johnf@hprnd.rose.hp.com
Jeffrey Johnson Jeffrey Johnson
RedBack Networks RedBack Networks
2570 North First Street, Suite 410 2570 North First Street, Suite 410
San Jose, CA, 95131, USA San Jose, CA, 95131, USA
Phone: +1 408 571 2699 Phone: +1 408 571 2699
EMail: jeff@redbacknetworks.com EMail: jeff@redbacknetworks.com
11. Full Copyright Statement 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.
B. Full Copyright Statement
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 32 change blocks. 
96 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/