draft-ietf-hubmib-etherif-mib-v3-00.txt | draft-ietf-hubmib-etherif-mib-v3-01.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 14 | skipping to change at page 1, line 14 | |||
INTERNET DRAFT J. Flick | INTERNET DRAFT J. Flick | |||
Hewlett-Packard Company | Hewlett-Packard Company | |||
Editors of previous versions: | Editors of previous versions: | |||
J. Flick | J. Flick | |||
Hewlett-Packard Company | Hewlett-Packard Company | |||
J. Johnson | J. Johnson | |||
RedBack Networks | RedBack Networks | |||
F. Kastenholz | F. Kastenholz | |||
Unisphere Networks | Unisphere Networks | |||
June 2001 | February 2002 | |||
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-v3-00.txt> | <draft-ietf-hubmib-etherif-mib-v3-01.txt> | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 44 | skipping to change at page 1, line 44 | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2002). 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. | |||
This memo obsoletes RFC 2665 ''Definitions of Managed Objects for the | This memo obsoletes RFC 2665 ''Definitions of Managed Objects for the | |||
Ethernet-like Interface Types''. This memo updates that | Ethernet-like Interface Types''. This memo updates that | |||
specification by including management information useful for the | specification by including management information useful for the | |||
management of 10 Gigabit per second (Gb/s) Ethernet interfaces. | management of 10 Gigabit per second (Gb/s) Ethernet interfaces. | |||
skipping to change at page 2, line 37 | skipping to change at page 2, line 37 | |||
2. The SNMP Management Framework .............................. 3 | 2. The SNMP Management Framework .............................. 3 | |||
3. Overview ................................................... 4 | 3. Overview ................................................... 4 | |||
3.1. Relation to MIB-2 ........................................ 5 | 3.1. Relation to MIB-2 ........................................ 5 | |||
3.2. Relation to the Interfaces MIB ........................... 5 | 3.2. Relation to the Interfaces MIB ........................... 5 | |||
3.2.1. Layering Model ......................................... 5 | 3.2.1. Layering Model ......................................... 5 | |||
3.2.2. Virtual Circuits ....................................... 6 | 3.2.2. Virtual Circuits ....................................... 6 | |||
3.2.3. ifRcvAddressTable ...................................... 6 | 3.2.3. ifRcvAddressTable ...................................... 6 | |||
3.2.4. ifType ................................................. 6 | 3.2.4. ifType ................................................. 6 | |||
3.2.5. ifXxxOctets ............................................ 7 | 3.2.5. ifXxxOctets ............................................ 7 | |||
3.2.6. ifXxxXcastPkts ......................................... 8 | 3.2.6. ifXxxXcastPkts ......................................... 8 | |||
3.2.7. ifMtu .................................................. 8 | 3.2.7. ifMtu .................................................. 9 | |||
3.2.8. ifSpeed and ifHighSpeed ................................ 9 | 3.2.8. ifSpeed and ifHighSpeed ................................ 10 | |||
3.2.9. ifPhysAddress .......................................... 10 | 3.2.9. ifPhysAddress .......................................... 10 | |||
3.2.10. Specific Interface MIB Objects ........................ 10 | 3.2.10. Specific Interface MIB Objects ........................ 11 | |||
3.3. Relation to the 802.3 MAU MIB ............................ 13 | 3.3. Relation to the 802.3 MAU MIB ............................ 14 | |||
3.4. dot3StatsEtherChipSet .................................... 14 | 3.4. dot3StatsEtherChipSet .................................... 14 | |||
3.5. Mapping of IEEE 802.3 Managed Objects .................... 14 | 3.5. Mapping of IEEE 802.3 Managed Objects .................... 15 | |||
4. Definitions ................................................ 17 | 4. Definitions ................................................ 18 | |||
5. Intellectual Property ...................................... 53 | 5. Intellectual Property ...................................... 54 | |||
6. Acknowledgements ........................................... 54 | 6. Acknowledgements ........................................... 55 | |||
7. References ................................................. 55 | 7. References ................................................. 56 | |||
8. Security Considerations .................................... 58 | 8. Security Considerations .................................... 59 | |||
9. Author's Address ........................................... 58 | 9. Author's Address ........................................... 60 | |||
A. Change Log ................................................. 59 | A. Change Log ................................................. 60 | |||
A.1. Changes since RFC 2665 ................................... 59 | A.1. Changes since RFC 2665 ................................... 60 | |||
A.2. Changes between RFC 2358 and RFC 2665 .................... 60 | A.2. Changes between RFC 2358 and RFC 2665 .................... 61 | |||
A.3. Changes between RFC 1650 and RFC 2358 .................... 60 | A.3. Changes between RFC 1650 and RFC 2358 .................... 62 | |||
B. Full Copyright Statement ................................... 61 | B. Full Copyright Statement ................................... 63 | |||
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 updates the | This memo also includes a MIB module. This MIB module updates 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, | |||
RFC 2665 [26]. | RFC 2665 [RFC2665]. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [29]. | document are to be interpreted as described in [RFC2119]. | |||
2. The SNMP Management Framework | 2. The SNMP Management Framework | |||
The SNMP Management Framework presently consists of five major | The SNMP Management Framework presently consists of five major | |||
components: | components: | |||
o An overall architecture, described in RFC 2571 [1]. | o An overall architecture, described in RFC 2571 [RFC2571]. | |||
o Mechanisms for describing and naming objects and events for the | o Mechanisms for describing and naming objects and events for the | |||
purpose of management. The first version of this Structure of | purpose of management. The first version of this Structure of | |||
Management Information (SMI) is called SMIv1 and described in | Management Information (SMI) is called SMIv1 and described in | |||
STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. | STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC | |||
The second version, called SMIv2, is described in STD 58, RFC | 1215 [RFC1215]. The second version, called SMIv2, is described | |||
2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. | in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and | |||
STD 58, RFC 2580 [RFC2580]. | ||||
o Message protocols for transferring management information. The | o Message protocols for transferring management information. The | |||
first version of the SNMP message protocol is called SNMPv1 and | first version of the SNMP message protocol is called SNMPv1 and | |||
described in STD 15, RFC 1157 [8]. A second version of the SNMP | described in STD 15, RFC 1157 [RFC1157]. A second version of | |||
message protocol, which is not an Internet standards track | the SNMP message protocol, which is not an Internet standards | |||
protocol, is called SNMPv2c and described in RFC 1901 [9] and | track protocol, is called SNMPv2c and described in RFC 1901 | |||
RFC 1906 [10]. The third version of the message protocol is | [RFC1901] and RFC 1906 [RFC1906]. The third version of the | |||
called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and | message protocol is called SNMPv3 and described in RFC 1906 | |||
RFC 2574 [12]. | [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. | |||
o Protocol operations for accessing management information. The | o Protocol operations for accessing management information. The | |||
first set of protocol operations and associated PDU formats is | first set of protocol operations and associated PDU formats is | |||
described in STD 15, RFC 1157 [8]. A second set of protocol | described in STD 15, RFC 1157 [RFC1157]. A second set of | |||
operations and associated PDU formats is described in RFC 1905 | protocol operations and associated PDU formats is described in | |||
[13]. | RFC 1905 [RFC1905]. | |||
o A set of fundamental applications described in RFC 2573 [14] and | o A set of fundamental applications described in RFC 2573 | |||
the view-based access control mechanism described in RFC 2575 | [RFC2573] and the view-based access control mechanism described | |||
[15]. | in RFC 2575 [RFC2575]. | |||
A more detailed introduction to the current SNMP Management Framework | A more detailed introduction to the current SNMP Management Framework | |||
can be found in RFC 2570 [16]. | can be found in RFC 2570 [RFC2570]. | |||
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 mechanisms defined in the SMI. | defined using the mechanisms defined in the SMI. | |||
This memo specifies a MIB module that is compliant to the SMIv2. A | This memo specifies a MIB module that is compliant to the SMIv2. A | |||
MIB conforming to the SMIv1 can be produced through the appropriate | MIB conforming to the SMIv1 can be produced through the appropriate | |||
translations. The resulting translated MIB must be semantically | translations. The resulting translated MIB must be semantically | |||
equivalent, except where objects or events are omitted because no | equivalent, except where objects or events are omitted because no | |||
translation is possible (use of Counter64). Some machine readable | translation is possible (use of Counter64). Some machine readable | |||
information in SMIv2 will be converted into textual descriptions in | information in SMIv2 will be converted into textual descriptions in | |||
SMIv1 during the translation process. However, this loss of machine | SMIv1 during the translation process. However, this loss of machine | |||
readable information is not considered to change the semantics of the | readable information is not considered to change the semantics of the | |||
MIB. | MIB. | |||
3. Overview | 3. 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 value ethernetCsmacd(6) of the ifType | media are identified by the value ethernetCsmacd(6) of the ifType | |||
object in the Interfaces MIB [28]. Some older implementations may | object in the Interfaces MIB [RFC2863]. Some older implementations | |||
return the values iso88023Csmacd(7) or starLan(11) for ifType for | may return the values iso88023Csmacd(7) or starLan(11) for ifType for | |||
ethernet-like media. | ethernet-like media. | |||
The definitions presented here are based on Section 30, "10 Mb/s, 100 | The definitions presented here are based on Section 30, "10 Mb/s, 100 | |||
Mb/s 1000 Mb/s and 10 Gb/s Management", and Annex 30A, "GDMO | Mb/s 1000 Mb/s and 10 Gb/s Management", and Annex 30A, "GDMO | |||
Specification for 802.3 managed object classes" of IEEE Std. 802.3, | Specification for 802.3 managed object classes" of IEEE Std. 802.3, | |||
2000 Edition [17], ammended by IEEE Draft P802.3ae/D3.0 [18], as | 2000 Edition [IEEE802.3], ammended by IEEE Draft P802.3ae/D4.01 | |||
originally interpreted by Frank Kastenholz, then of Interlan in [19]. | [P802.3a3], as originally interpreted by Frank Kastenholz, then of | |||
Implementors of these MIB objects should note that IEEE Std. 802.3 | Interlan in [KASTEN]. Implementors of these MIB objects should note | |||
[17] explicitly describes (in the form of Pascal pseudocode) when, | that IEEE Std. 802.3 [IEEE802.3] explicitly describes (in the form of | |||
where, and how various MAC attributes are measured. The IEEE document | Pascal pseudocode) when, where, and how various MAC attributes are | |||
also describes the effects of MAC actions that may be invoked by | measured. The IEEE document also describes the effects of MAC actions | |||
manipulating instances of the MIB objects defined here. | that may be invoked by manipulating instances of the MIB objects | |||
defined here. | ||||
To the extent that some of the attributes defined in [17] are | To the extent that some of the attributes defined in [IEEE802.3] are | |||
represented by previously defined objects in MIB-2 [27] or in the | represented by previously defined objects in MIB-2 [RFC1213] or in | |||
Interfaces MIB [28], such attributes are not redundantly represented | the Interfaces MIB [RFC2863], such attributes are not redundantly | |||
by objects defined in this memo. Among the attributes represented by | represented by objects defined in this memo. Among the attributes | |||
objects defined in other memos are the number of octets transmitted | represented by objects defined in other memos are the number of | |||
or received on a particular interface, the number of frames | octets transmitted or received on a particular interface, the number | |||
transmitted or received on a particular interface, the promiscuous | of frames transmitted or received on a particular interface, the | |||
status of an interface, the MAC address of an interface, and | promiscuous status of an interface, the MAC address of an interface, | |||
multicast information associated with an interface. | and multicast information associated with an interface. | |||
3.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) [27] interface group. | the "old" [RFC1213] 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 MIB-2 is one-to-one. As such, the value of an | in the context of MIB-2 is one-to-one. As such, the value of an | |||
ifIndex object instance can be directly used to identify | ifIndex object instance can be directly used to identify | |||
corresponding instances of the objects defined herein. | 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 } | |||
3.2. Relation to the Interfaces MIB | 3.2. Relation to the Interfaces MIB | |||
The Interface MIB [28] requires that any MIB which is an adjunct of | The Interface MIB [RFC2863] requires that any MIB which is an adjunct | |||
the Interface MIB clarify specific areas within the Interface MIB. | of 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 4 of [28] enumerates several areas which a media-specific MIB | Section 4 of [RFC2863] enumerates several areas which a media- | |||
must clarify. Each of these areas is addressed in a following | specific MIB must clarify. Each of these areas is addressed in a | |||
subsection. The implementor is referred to [28] in order to | following subsection. The implementor is referred to [RFC2863] in | |||
understand the general intent of these areas. | order to understand the general intent of these areas. | |||
3.2.1. Layering Model | 3.2.1. Layering Model | |||
Ordinarily, there are no sublayers for an ethernet-like interface. | Ordinarily, there are no sublayers for an ethernet-like interface. | |||
However there may be implementation-specific requirements which | However there may be implementation-specific requirements which | |||
require the use of sublayers. One example is the use of 802.3 link | require the use of sublayers. One example is the use of 802.3 link | |||
aggregation. In this case, Annex 30C of [17] describes the layering | aggregation. In this case, Annex 30C of [IEEE802.3] describes the | |||
model and the use of the ifStackTable for representing aggregated | layering model and the use of the ifStackTable for representing | |||
links. | aggregated links. Another example is the use of the 802.3 WAN | |||
Interface Sublayer. In this case, The 802.3 WIS MIB [ETHERWIS] | ||||
describes the layering model and the use of the ifStackTable for | ||||
representing the WAN sublayer. | ||||
3.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. | |||
3.2.3. ifRcvAddressTable | 3.2.3. 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 | |||
skipping to change at page 6, line 47 | skipping to change at page 7, line 7 | |||
individual vendors, not by any IETF working group. A requirement for | individual vendors, not by any IETF working group. A requirement for | |||
compliance with this document is that all ethernet-like interfaces | compliance with this document is that all ethernet-like interfaces | |||
MUST return ethernetCsmacd(6) for ifType, and MUST NOT return | MUST return ethernetCsmacd(6) for ifType, and MUST NOT return | |||
fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as | fastEther(62), fastEtherFX(69), or gigabitEthernet(117). However, as | |||
there are fielded implementations that do return these obsolete | there are fielded implementations that do return these obsolete | |||
ifType values, management applications SHOULD be prepared to receive | ifType values, management applications SHOULD be prepared to receive | |||
them from older implementations. | them from older implementations. | |||
Information on the particular flavor of Ethernet that an interface is | Information on the particular flavor of Ethernet that an interface is | |||
running is available from ifSpeed in the Interfaces MIB, and | running is available from ifSpeed in the Interfaces MIB, and | |||
ifMauType in the 802.3 MAU MIB [30]. Note that implementation of the | ifMauType in the 802.3 MAU MIB [MAU-MIB]. Note that implementation | |||
802.3 MAU MIB [30] is REQUIRED for all ethernet-like interfaces. | of the 802.3 MAU MIB [MAU-MIB] is REQUIRED for all ethernet-like | |||
interfaces. | ||||
3.2.5. ifXxxOctets | 3.2.5. ifXxxOctets | |||
The Interface MIB octet counters, ifInOctets, ifOutOctets, | The Interface MIB octet counters, ifInOctets, ifOutOctets, | |||
ifHCInOctets and ifHCOutOctets, MUST include all octets in valid | ifHCInOctets and ifHCOutOctets, MUST include all octets in valid | |||
frames sent or received on the interface, including the MAC header | frames sent or received on the interface, including the MAC header | |||
and FCS, but not the preamble, start of frame delimiter, or extension | and FCS, but not the preamble, start of frame delimiter, or extension | |||
octets. This corresponds to the definition of frameSize/8 in section | octets. This corresponds to the definition of frameSize/8 in section | |||
4.2.7.1 of [17] (frameSize is defined in bits rather than octets, and | 4.2.7.1 of [IEEE802.3] (frameSize is defined in bits rather than | |||
is defined as 2 x addressSize + lengthOrTypeSize + dataSize + | octets, and is defined as 2 x addressSize + lengthOrTypeSize + | |||
crcSize). They do not include the number of octets in collided or | dataSize + crcSize). They do not include the number of octets in | |||
failed transmit attempts, since the MAC layer driver typically does | collided or failed transmit attempts, since the MAC layer driver | |||
not have visibility to count these octets. They also do not include | typically does not have visibility to count these octets. They also | |||
octets in received invalid frames, since this information is normally | do not include octets in received invalid frames, since this | |||
not passed to the MAC layer, and since non-promiscuous MAC | information is normally not passed to the MAC layer, and since non- | |||
implementations cannot reliably determine whether an invalid frame | promiscuous MAC implementations cannot reliably determine whether an | |||
was actually addressed to this station. | invalid frame was actually addressed to this station. | |||
Note that these counters do include octets in valid MAC control | Note that these counters do include octets in valid MAC control | |||
frames sent or received on the interface, as well as octets in | frames sent or received on the interface, as well as octets in | |||
otherwise valid received MAC frames that are discarded by the MAC | otherwise valid received MAC frames that are discarded by the MAC | |||
layer for some reason (insufficient buffer space, unknown protocol, | layer for some reason (insufficient buffer space, unknown protocol, | |||
etc.). | etc.). | |||
Note that the octet counters in IF-MIB do not exactly match the | Note that the octet counters in IF-MIB do not exactly match the | |||
definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK | definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK | |||
and aOctetsReceivedOK count only the octets in the clientData and Pad | and aOctetsReceivedOK count only the octets in the clientData and Pad | |||
skipping to change at page 8, line 49 | skipping to change at page 9, line 9 | |||
This specification chooses to treat MAC control frames as being | This specification chooses to treat MAC control frames as being | |||
originated and consumed within the interface and not counted by the | originated and consumed within the interface and not counted by the | |||
IF-MIB packet counters. MAC control frames are normally sent as | IF-MIB packet counters. MAC control frames are normally sent as | |||
multicast packets. In many network environments, MAC control frames | multicast packets. In many network environments, MAC control frames | |||
can greatly outnumber multicast frames carrying actual data. If MAC | can greatly outnumber multicast frames carrying actual data. If MAC | |||
control frames were included in the ifInMulticastPkts and | control frames were included in the ifInMulticastPkts and | |||
ifOutMulticastPkts, the count of data-carrying multicast packets | ifOutMulticastPkts, the count of data-carrying multicast packets | |||
would tend to be drowned out by the count of MAC control frames, | would tend to be drowned out by the count of MAC control frames, | |||
rendering those counters considerably less useful. | rendering those counters considerably less useful. | |||
To better understand the issues surrounding the mapping of of the | ||||
IF-MIB packet and octet counters to an Ethernet interface, it is | ||||
useful to refer to a Case Diagram [CASE] for the IF-MIB counters, | ||||
with modifications to show the proper interpretation for the Ethernet | ||||
interface layer. | ||||
layer above | ||||
-------------------------------------------------------------------- | ||||
ifInUcastPkts+ ^ | ifOutUcastPkts+ | ||||
ifInBroadcastPkts+ ----|---- ----|---- ifOutBroadcastPkts+ | ||||
ifInMulticastPkts | | ifOutMulticastPkts | ||||
| | | ||||
dot3InPauseFrames <---| |<--- dot3OutPauseFrames | ||||
| | | ||||
ifInDiscards <---| | | ||||
| | | ||||
ifInUnknownProtos <---| |---> ifOutDiscards | ||||
| | | ||||
ifInOctets ----|---- ----|---- ifOutOctets | ||||
| | | ||||
ifInErrors <---| |---> ifOutErrors | ||||
| V | ||||
-------------------------------------------------------------------- | ||||
layer below | ||||
3.2.7. ifMtu | 3.2.7. ifMtu | |||
The defined standard MTU for ethernet-like interfaces is 1500 octets. | The defined standard MTU for ethernet-like interfaces is 1500 octets. | |||
However, many implementations today support larger packet sizes than | However, many implementations today support larger packet sizes than | |||
the IEEE 802.3 standard. The value of this object MUST reflect the | the IEEE 802.3 standard. The value of this object MUST reflect the | |||
actual MTU in use on the interface, whether it matches the standard | actual MTU in use on the interface, whether it matches the standard | |||
MTU or not. | MTU or not. | |||
This value should reflect the value seen by the MAC client interface. | This value should reflect the value seen by the MAC client interface. | |||
When a higher layer protocol, like IP, is running over Ethernet | When a higher layer protocol, like IP, is running over Ethernet | |||
framing, this is the MTU that will be seen by that higher layer | framing, this is the MTU that will be seen by that higher layer | |||
protocol. However, most ethernet-like interfaces today run multiple | protocol. However, most ethernet-like interfaces today run multiple | |||
protocols that use a mix of different framing types. For example, an | protocols that use a mix of different framing types. For example, an | |||
skipping to change at page 9, line 42 | skipping to change at page 10, line 26 | |||
1, 10, 100, or 1,000. If the interface implements auto-negotiation, | 1, 10, 100, or 1,000. If the interface implements auto-negotiation, | |||
auto-negotiation is enabled for this interface, and the interface has | auto-negotiation is enabled for this interface, and the interface has | |||
not yet negotiated to an operational speed, these objects SHOULD | not yet negotiated to an operational speed, these objects SHOULD | |||
reflect the maximum speed supported by the interface. | reflect the maximum speed supported by the interface. | |||
For ethernet-like interfaces operating at greater than 1000 Mb/s, | For ethernet-like interfaces operating at greater than 1000 Mb/s, | |||
ifHighSpeed will represent the current operational speed of the | ifHighSpeed will represent the current operational speed of the | |||
interface in millions of bits per second. Note that for WAN | interface in millions of bits per second. Note that for WAN | |||
implementations, this will be the payload data rate over the WAN | implementations, this will be the payload data rate over the WAN | |||
interface sublayer. For current implementations, this will be equal | interface sublayer. For current implementations, this will be equal | |||
to 10,000 for LAN implentations of 10 Gb/s, and 9,585 for WAN | to 10,000 for LAN implentations of 10 Gb/s, and 9,294 for WAN | |||
implementations of the 10 Gb/s MAC over an OC-192 PHY. For these | implementations of the 10 Gb/s MAC over an OC-192 PHY. For these | |||
speeds, ifSpeed should report a maximum unsigned 32-bit value of | speeds, ifSpeed should report a maximum unsigned 32-bit value of | |||
4,294,967,295 as specified in [28]. | 4,294,967,295 as specified in [RFC2863]. | |||
Note that these object MUST NOT indicate a doubled value when | Note that these object MUST NOT indicate a doubled value when | |||
operating in full-duplex mode. It MUST indicate the correct line | operating in full-duplex mode. It MUST indicate the correct line | |||
speed regardless of the current duplex mode. The duplex mode of the | speed regardless of the current duplex mode. The duplex mode of the | |||
interface may be determined by examining either the | interface may be determined by examining either the | |||
dot3StatsDuplexStatus object in this MIB module, or the ifMauType | dot3StatsDuplexStatus object in this MIB module, or the ifMauType | |||
object in the 802.3 MAU MIB [30]. | object in the 802.3 MAU MIB [MAU-MIB]. | |||
3.2.9. ifPhysAddress | 3.2.9. 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 | |||
skipping to change at page 10, line 45 | skipping to change at page 11, line 31 | |||
Object Guidelines | Object Guidelines | |||
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 [28]. | ifDescr Refer to [RFC2863]. | |||
ifType Refer to section 3.2.4. | ifType Refer to section 3.2.4. | |||
ifMtu Refer to section 3.2.7. | ifMtu Refer to section 3.2.7. | |||
ifSpeed Refer to section 3.2.8. | ifSpeed Refer to section 3.2.8. | |||
ifPhysAddress Refer to section 3.2.9. | ifPhysAddress Refer to section 3.2.9. | |||
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 [28]. | ifLastChange Refer to [RFC2863]. | |||
ifInOctets The number of octets in valid MAC frames | ifInOctets The number of octets in valid MAC frames | |||
received on this interface, including | received on this interface, including | |||
the MAC header and FCS. This does | the MAC header and FCS. This does | |||
include the number of octets in valid | include the number of octets in valid | |||
MAC Control frames received on this | MAC Control frames received on this | |||
interface. See section 3.2.5. | interface. See section 3.2.5. | |||
ifInUcastPkts Refer to [28]. Note that this does not | ifInUcastPkts Refer to [RFC2863]. Note that this does | |||
include MAC Control frames, since MAC | not include MAC Control frames, since | |||
Control frames are consumed by the | MAC Control frames are consumed by the | |||
interface layer and are not passed to | interface layer and are not passed to | |||
any higher layer protocol. See | any higher layer protocol. See | |||
section 3.2.6. | section 3.2.6. | |||
ifInDiscards Refer to [28]. | ifInDiscards Refer to [RFC2863]. | |||
ifInErrors The sum for this interface of | ifInErrors The sum for this interface of | |||
dot3StatsAlignmentErrors, | dot3StatsAlignmentErrors, | |||
dot3StatsFCSErrors, | dot3StatsFCSErrors, | |||
dot3StatsFrameTooLongs, | dot3StatsFrameTooLongs, | |||
and dot3StatsInternalMacReceiveErrors. | and dot3StatsInternalMacReceiveErrors. | |||
ifInUnknownProtos Refer to [28]. | ifInUnknownProtos Refer to [RFC2863]. | |||
ifOutOctets The number of octets transmitted in | ifOutOctets The number of octets transmitted in | |||
valid MAC frames on this interface, | valid MAC frames on this interface, | |||
including the MAC header and FCS. This | including the MAC header and FCS. This | |||
does include the number of octets in | does include the number of octets in | |||
valid MAC Control frames transmitted on | valid MAC Control frames transmitted on | |||
this interface. See section 3.2.5. | this interface. See section 3.2.5. | |||
ifOutUcastPkts Refer to [28]. Note that this does not | ifOutUcastPkts Refer to [RFC2863]. Note that this does | |||
include MAC Control frames, since MAC | not include MAC Control frames, since | |||
Control frames are generated by the | MAC Control frames are generated by the | |||
interface layer, and are not passed from | interface layer, and are not passed from | |||
any higher layer protocol. See section | any higher layer protocol. See section | |||
3.2.6. | 3.2.6. | |||
ifOutDiscards Refer to [28]. | ifOutDiscards Refer to [RFC2863]. | |||
ifOutErrors The sum for this interface of: | ifOutErrors The sum for this interface of: | |||
dot3StatsSQETestErrors, | dot3StatsSQETestErrors, | |||
dot3StatsLateCollisions, | dot3StatsLateCollisions, | |||
dot3StatsExcessiveCollisions, | dot3StatsExcessiveCollisions, | |||
dot3StatsInternalMacTransmitErrors and | dot3StatsInternalMacTransmitErrors and | |||
dot3StatsCarrierSenseErrors. | dot3StatsCarrierSenseErrors. | |||
ifName Locally-significant textual name for the | ifName Locally-significant textual name for the | |||
interface (e.g. lan0). | interface (e.g. lan0). | |||
ifInMulticastPkts Refer to [28]. Note that this does not | ifInMulticastPkts Refer to [RFC2863]. Note that this does | |||
include MAC Control frames, since MAC | not include MAC Control frames, since | |||
Control frames are consumed by the | MAC Control frames are consumed by the | |||
interface layer and are not passed to | interface layer and are not passed to | |||
any higher layer protocol. See section | any higher layer protocol. See section | |||
3.2.6. | 3.2.6. | |||
ifInBroadcastPkts Refer to [28]. Note that this does not | ifInBroadcastPkts Refer to [RFC2863]. Note that this does | |||
include MAC Control frames, since MAC | not include MAC Control frames, since | |||
Control frames are generated by the | MAC Control frames are generated by the | |||
interface layer, and are not passed from | interface layer, and are not passed from | |||
any higher layer protocol. See section | any higher layer protocol. See section | |||
3.2.6. | 3.2.6. | |||
ifOutMulticastPkts Refer to [28]. Note that this does not | ifOutMulticastPkts Refer to [RFC2863]. Note that this does | |||
include MAC Control frames, since MAC | not include MAC Control frames, since | |||
Control frames are consumed by the | MAC Control frames are consumed by the | |||
interface layer and are not passed to | interface layer and are not passed to | |||
any higher layer protocol. See section | any higher layer protocol. See section | |||
3.2.6. | 3.2.6. | |||
ifOutBroadcastPkts Refer to [28]. Note that this does not | ifOutBroadcastPkts Refer to [RFC2863]. Note that this does | |||
include MAC Control frames, since MAC | not include MAC Control frames, since | |||
Control frames are generated by the | MAC Control frames are generated by the | |||
interface layer, and are not passed from | interface layer, and are not passed from | |||
any higher layer protocol. See section | any higher layer protocol. See section | |||
3.2.6. | 3.2.6. | |||
ifHCInOctets 64-bit versions of counters. Required | ifHCInOctets 64-bit versions of counters. Required | |||
ifHCOutOctets for ethernet-like interfaces that are | ifHCOutOctets for ethernet-like interfaces that are | |||
capable of operating at 20 Mb/s or | capable of operating at 20 Mb/s or | |||
faster, even if the interface is | faster, even if the interface is | |||
currently operating at less than | currently operating at less than | |||
20 Mb/s. | 20 Mb/s. | |||
ifHCInUcastPkts 64-bit versions of packet counters. | ifHCInUcastPkts 64-bit versions of packet counters. | |||
ifHCInMulticastPkts Required for ethernet-like interfaces | ifHCInMulticastPkts Required for ethernet-like interfaces | |||
ifHCInBroadcastPkts that are capable of operating at | ifHCInBroadcastPkts that are capable of operating at | |||
ifHCOutUcastPkts 640 Mb/s or faster, even if the | ifHCOutUcastPkts 640 Mb/s or faster, even if the | |||
ifHCOutMulticastPkts interface is currently operating at | ifHCOutMulticastPkts interface is currently operating at | |||
ifHCOutBroadcastPkts less than 640 Mb/s. | ifHCOutBroadcastPkts less than 640 Mb/s. | |||
ifLinkUpDownTrapEnable Refer to [28]. Default is 'enabled' | ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is | |||
'enabled' | ||||
ifHighSpeed Refer to section 3.2.8. | ifHighSpeed Refer to section 3.2.8. | |||
ifPromiscuousMode Refer to [28]. | ifPromiscuousMode Refer to [RFC2863]. | |||
ifConnectorPresent This will normally be 'true'. | ifConnectorPresent This will normally be 'true'. It will | |||
be 'false' in the case where this | ||||
interface uses the WAN Interface | ||||
Sublayer. See [ETHERWIS] for details. | ||||
ifAlias Refer to [28]. | ifAlias Refer to [RFC2863]. | |||
ifCounterDiscontinuityTime Refer to [28]. Note that a | ifCounterDiscontinuityTime Refer to [RFC2863]. Note that a | |||
discontinuity in the Interface MIB | discontinuity in the Interface MIB | |||
counters may also indicate a | counters may also indicate a | |||
discontinuity in some or all of the | discontinuity in some or all of the | |||
counters in this MIB that are associated | counters in this MIB that are associated | |||
with that interface. | with that interface. | |||
ifStackHigherLayer Refer to section 3.2.1. | ifStackHigherLayer Refer to section 3.2.1. | |||
ifStackLowerLayer | ifStackLowerLayer | |||
ifStackStatus | ifStackStatus | |||
ifRcvAddressAddress Refer to section 3.2.3. | ifRcvAddressAddress Refer to section 3.2.3. | |||
ifRcvAddressStatus | ifRcvAddressStatus | |||
ifRcvAddressType | ifRcvAddressType | |||
3.3. Relation to the 802.3 MAU MIB | 3.3. Relation to the 802.3 MAU MIB | |||
Support for the mauModIfCompl2 compliance statement of the MAU-MIB | Support for the mauModIfCompl3 compliance statement of the MAU-MIB | |||
[30] is REQUIRED for Ethernet-like interfaces. This MIB is needed in | [MAU-MIB] is REQUIRED for Ethernet-like interfaces. This MIB is | |||
order to allow applications to determine the current MAU type in use | needed in order to allow applications to determine the current MAU | |||
by the interface, and to control autonegotiation and duplex mode for | type in use by the interface, and to control autonegotiation and | |||
the interface. Implementing this MIB module without implementing the | duplex mode for the interface. Implementing this MIB module without | |||
MAU-MIB would leave applications with no standard way to determine | implementing the MAU-MIB would leave applications with no standard | |||
the media type in use, and no standard way to control the duplex mode | way to determine the media type in use, and no standard way to | |||
of the interface. | control the duplex mode of the interface. | |||
3.4. dot3StatsEtherChipSet | 3.4. dot3StatsEtherChipSet | |||
This document defines an object called dot3StatsEtherChipSet, which | This document defines an object called dot3StatsEtherChipSet, which | |||
is used to identify the MAC hardware used to communicate on an | is used to identify the MAC hardware used to communicate on an | |||
interface. Previous versions of this document contained a number of | interface. Previous versions of this document contained a number of | |||
OID assignments for some existing Ethernet chipsets. Maintaining | OID assignments for some existing Ethernet chipsets. Maintaining | |||
that list as part of this document has proven to be problematic, so | that list as part of this document has proven to be problematic, so | |||
the OID assignments contained in prevous versions of this document | the OID assignments contained in prevous versions of this document | |||
have now been moved to a separate document [31]. | have now been moved to a separate document [RFC2666]. | |||
The dot3StatsEtherChipSet object has now been deprecated. | The dot3StatsEtherChipSet object has now been deprecated. | |||
Implementation feedback indicates that this object is much more | Implementation feedback indicates that this object is much more | |||
useful in theory than in practice. The object's utility in debugging | useful in theory than in practice. The object's utility in debugging | |||
network problems in the field appears to be limited. In those cases | network problems in the field appears to be limited. In those cases | |||
where it may be useful, it is not sufficient, since it identifies | where it may be useful, it is not sufficient, since it identifies | |||
only the MAC chip, and not the PHY, PMD, or driver. The | only the MAC chip, and not the PHY, PMD, or driver. The | |||
administrative overhead involved in maintaining a central registry of | administrative overhead involved in maintaining a central registry of | |||
chipset OIDs cannot be justified for an object whose usefulness is | chipset OIDs cannot be justified for an object whose usefulness is | |||
questionable at best. | questionable at best. | |||
Implementations which continue to support this object for the purpose | Implementations which continue to support this object for the purpose | |||
skipping to change at page 14, line 27 | skipping to change at page 15, line 16 | |||
useful in theory than in practice. The object's utility in debugging | useful in theory than in practice. The object's utility in debugging | |||
network problems in the field appears to be limited. In those cases | network problems in the field appears to be limited. In those cases | |||
where it may be useful, it is not sufficient, since it identifies | where it may be useful, it is not sufficient, since it identifies | |||
only the MAC chip, and not the PHY, PMD, or driver. The | only the MAC chip, and not the PHY, PMD, or driver. The | |||
administrative overhead involved in maintaining a central registry of | administrative overhead involved in maintaining a central registry of | |||
chipset OIDs cannot be justified for an object whose usefulness is | chipset OIDs cannot be justified for an object whose usefulness is | |||
questionable at best. | questionable at best. | |||
Implementations which continue to support this object for the purpose | Implementations which continue to support this object for the purpose | |||
of backwards compatability may continue to use the values defined in | of backwards compatability may continue to use the values defined in | |||
[31]. For chipsets not listed in [31], implementors that wish to | [RFC2666]. For chipsets not listed in [RFC2666], implementors that | |||
support this object and return a valid OBJECT IDENTIFIER value may | wish to support this object and return a valid OBJECT IDENTIFIER | |||
assign OBJECT IDENTIFIERS within that part of the registration tree | value may assign OBJECT IDENTIFIERS within that part of the | |||
delegated to individual enterprises. | registration tree delegated to individual enterprises. | |||
3.5. Mapping of IEEE 802.3 Managed Objects | 3.5. 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 + | |||
skipping to change at page 16, line 14 | skipping to change at page 17, line 4 | |||
MIB module as a result of implementation feedback: | MIB module as a result of implementation feedback: | |||
oMacEntity | oMacEntity | |||
.aFramesWithExcessiveDeferral | .aFramesWithExcessiveDeferral | |||
.aInRangeLengthErrors | .aInRangeLengthErrors | |||
.aOutOfRangeLengthField | .aOutOfRangeLengthField | |||
.aMACEnableStatus | .aMACEnableStatus | |||
.aTransmitEnableStatus | .aTransmitEnableStatus | |||
.aMulticastReceiveStatus | .aMulticastReceiveStatus | |||
.acInitializeMAC | .acInitializeMAC | |||
Please see [RFC1369] for the detailed reasoning on why these objects | ||||
Please see [21] for the detailed reasoning on why these objects were | were removed. | |||
removed. | ||||
In addition, the following IEEE 802.3 managed objects have not been | In addition, the following IEEE 802.3 managed objects have not been | |||
included in this MIB for the following reasons. | included in this MIB for the following reasons. | |||
IEEE 802.3 Managed Object Disposition | IEEE 802.3 Managed Object Disposition | |||
oMACEntity | oMACEntity | |||
.aMACCapabilities Can be derived from | .aMACCapabilities Can be derived from | |||
MAU-MIB - ifMauTypeListBits | MAU-MIB - ifMauTypeListBits | |||
skipping to change at page 17, line 33 | skipping to change at page 18, line 21 | |||
Counter32, Counter64, mib-2, transmission | Counter32, Counter64, mib-2, transmission | |||
FROM SNMPv2-SMI | FROM SNMPv2-SMI | |||
MODULE-COMPLIANCE, OBJECT-GROUP | MODULE-COMPLIANCE, OBJECT-GROUP | |||
FROM SNMPv2-CONF | FROM SNMPv2-CONF | |||
TruthValue | TruthValue | |||
FROM SNMPv2-TC | FROM SNMPv2-TC | |||
ifIndex, InterfaceIndex | ifIndex, InterfaceIndex | |||
FROM IF-MIB; | FROM IF-MIB; | |||
etherMIB MODULE-IDENTITY | etherMIB MODULE-IDENTITY | |||
LAST-UPDATED "200106260024Z" -- June 26, 2001 | LAST-UPDATED "200202280000Z" -- February 28, 2002 | |||
ORGANIZATION "IETF Ethernet Interfaces and Hub MIB | ORGANIZATION "IETF Ethernet Interfaces and Hub MIB | |||
Working Group" | Working Group" | |||
CONTACT-INFO | CONTACT-INFO | |||
"WG E-mail: hubmib@ietf.org | "WG E-mail: hubmib@ietf.org | |||
To subscribe: hubmib-request@ietf.org | To subscribe: hubmib-request@ietf.org | |||
Chair: Dan Romascanu | Chair: Dan Romascanu | |||
Postal: Avaya Inc. | Postal: Avaya Inc. | |||
Atidum Technology Park, Bldg. 3 | Atidum Technology Park, Bldg. 3 | |||
Tel Aviv 61131 | Tel Aviv 61131 | |||
skipping to change at page 18, line 24 | skipping to change at page 19, line 11 | |||
[IEEE 802.3 Std] refers to: | [IEEE 802.3 Std] refers to: | |||
IEEE Std 802.3, 2000 Edition: 'IEEE Standard | IEEE Std 802.3, 2000 Edition: 'IEEE Standard | |||
for Information technology - | for Information technology - | |||
Telecommunications and information exchange | Telecommunications and information exchange | |||
between systems - Local and metropolitan | between systems - Local and metropolitan | |||
area networks - Specific requirements - | area networks - Specific requirements - | |||
Part 3: Carrier sense multiple access with | Part 3: Carrier sense multiple access with | |||
collision detection (CSMA/CD) access method | collision detection (CSMA/CD) access method | |||
and physical layer specifications', as | and physical layer specifications', as | |||
ammended by IEEE Draft P802.3ae/D3.0: | ammended by IEEE Draft P802.3ae/D4.01: | |||
'Supplement to Carrier Sense Multiple Access | 'Supplement to Carrier Sense Multiple Access | |||
with Collision Detection (CSMA/CD) Access | with Collision Detection (CSMA/CD) Access | |||
Method & Physical Layer Specifications - | Method & Physical Layer Specifications - | |||
Media Access Control (MAC) Parameters, | Media Access Control (MAC) Parameters, | |||
Physical Layer, and Management Parameters | Physical Layer, and Management Parameters | |||
for 10 Gb/s Operation', March, 2001. | for 10 Gb/s Operation', February, 2002. | |||
Of particular interest is Clause 30, '10 Mb/s, | Of particular interest is Clause 30, '10 Mb/s, | |||
100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'." | 100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'." | |||
REVISION "200106260024Z" -- June 26, 2001 | REVISION "200202280000Z" -- February 28, 2002 | |||
DESCRIPTION "Updated to include support for 10 Gb/sec | DESCRIPTION "Updated to include support for 10 Gb/sec | |||
interfaces. | interfaces. | |||
This version published as RFC XXXX." | This version published as RFC XXXX." | |||
REVISION "9908240400Z" -- August 24, 1999 | REVISION "9908240400Z" -- August 24, 1999 | |||
DESCRIPTION "Updated to include support for 1000 Mb/sec | DESCRIPTION "Updated to include support for 1000 Mb/sec | |||
interfaces and full-duplex interfaces. | interfaces and full-duplex interfaces. | |||
This version published as RFC 2665." | This version published as RFC 2665." | |||
REVISION "9806032150Z" -- June 3, 1998 | REVISION "9806032150Z" -- June 3, 1998 | |||
skipping to change at page 26, line 38 | skipping to change at page 27, line 26 | |||
The count represented by an instance of this | The count represented by an instance of this | |||
object is incremented when the frameTooLong | object is incremented when the frameTooLong | |||
status is returned by the MAC service to the | status is returned by the MAC service to the | |||
LLC (or other MAC user). Received frames for | LLC (or other MAC user). Received frames for | |||
which multiple error conditions pertain are, | which multiple error conditions pertain are, | |||
according to the conventions of IEEE 802.3 | according to the conventions of IEEE 802.3 | |||
Layer Management, counted exclusively according | Layer Management, counted exclusively according | |||
to the error status presented to the LLC. | to the error status presented to the LLC. | |||
For interfaces operating at 10 Gb/s, this | For interfaces operating at 10 Gb/s, this | |||
counter can roll over in less than 5 minutes if | counter can roll over in less than 80 minutes if | |||
it is incrementing at its maximum rate. Since | it is incrementing at its maximum rate. Since | |||
that amount of time could be less than a | that amount of time could be less than a | |||
management station's poll cycle time, in order | management station's poll cycle time, in order | |||
to avoid a loss of information, a management | to avoid a loss of information, a management | |||
station is advised to poll the | station is advised to poll the | |||
dot3HCStatsFrameTooLongs object for 10 Gb/s | dot3HCStatsFrameTooLongs object for 10 Gb/s | |||
or faster interfaces. | or faster interfaces. | |||
Discontinuities in the value of this counter can | Discontinuities in the value of this counter can | |||
occur at re-initialization of the management | occur at re-initialization of the management | |||
skipping to change at page 44, line 29 | skipping to change at page 45, line 22 | |||
-- 802.3 Tests | -- 802.3 Tests | |||
dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } | dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } | |||
dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } | dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } | |||
-- TDR Test | -- TDR Test | |||
dot3TestTdr OBJECT-IDENTITY | dot3TestTdr OBJECT-IDENTITY | |||
STATUS current | STATUS deprecated | |||
DESCRIPTION "The Time-Domain Reflectometry (TDR) test is | DESCRIPTION "The Time-Domain Reflectometry (TDR) test is | |||
specific to ethernet-like interfaces of type | specific to ethernet-like interfaces of type | |||
10Base5 and 10Base2. The TDR value may be | 10Base5 and 10Base2. The TDR value may be | |||
useful in determining the approximate distance | useful in determining the approximate distance | |||
to a cable fault. It is advisable to repeat | to a cable fault. It is advisable to repeat | |||
this test to check for a consistent resulting | this test to check for a consistent resulting | |||
TDR value, to verify that there is a fault. | TDR value, to verify that there is a fault. | |||
A TDR test returns as its result the time | A TDR test returns as its result the time | |||
interval, measured in 10 MHz ticks or 100 nsec | interval, measured in 10 MHz ticks or 100 nsec | |||
skipping to change at page 45, line 10 | skipping to change at page 45, line 49 | |||
object, and the OBJECT IDENTIFIER of that | object, and the OBJECT IDENTIFIER of that | |||
instance is stored in the appropriate instance | instance is stored in the appropriate instance | |||
of the appropriate test result code object | of the appropriate test result code object | |||
(thereby indicating where the result has been | (thereby indicating where the result has been | |||
stored)." | stored)." | |||
::= { dot3Tests 1 } | ::= { dot3Tests 1 } | |||
-- Loopback Test | -- Loopback Test | |||
dot3TestLoopBack OBJECT-IDENTITY | dot3TestLoopBack OBJECT-IDENTITY | |||
STATUS current | STATUS deprecated | |||
DESCRIPTION "This test configures the MAC chip and executes | DESCRIPTION "This test configures the MAC chip and executes | |||
an internal loopback test of memory, data paths, | an internal loopback test of memory, data paths, | |||
and the MAC chip logic. This loopback test can | and the MAC chip logic. This loopback test can | |||
only be executed if the interface is offline. | only be executed if the interface is offline. | |||
Once the test has completed, the MAC chip should | Once the test has completed, the MAC chip should | |||
be reinitialized for network operation, but it | be reinitialized for network operation, but it | |||
should remain offline. | should remain offline. | |||
If an error occurs during a test, the | If an error occurs during a test, the | |||
appropriate test result object will be set | appropriate test result object will be set | |||
to indicate a failure. The two OBJECT | to indicate a failure. The two OBJECT | |||
IDENTIFIER values dot3ErrorInitError and | IDENTIFIER values dot3ErrorInitError and | |||
dot3ErrorLoopbackError may be used to provided | dot3ErrorLoopbackError may be used to provided | |||
more information as values for an appropriate | more information as values for an appropriate | |||
test result code object." | test result code object." | |||
::= { dot3Tests 2 } | ::= { dot3Tests 2 } | |||
dot3ErrorInitError OBJECT-IDENTITY | dot3ErrorInitError OBJECT-IDENTITY | |||
STATUS current | STATUS deprecated | |||
DESCRIPTION "Couldn't initialize MAC chip for test." | DESCRIPTION "Couldn't initialize MAC chip for test." | |||
::= { dot3Errors 1 } | ::= { dot3Errors 1 } | |||
dot3ErrorLoopbackError OBJECT-IDENTITY | dot3ErrorLoopbackError OBJECT-IDENTITY | |||
STATUS current | STATUS deprecated | |||
DESCRIPTION "Expected data not received (or not received | DESCRIPTION "Expected data not received (or not received | |||
correctly) in loopback test." | correctly) in loopback test." | |||
::= { dot3Errors 2 } | ::= { dot3Errors 2 } | |||
-- { dot3 8 }, the dot3ChipSets tree, is defined in [31] | -- { dot3 8 }, the dot3ChipSets tree, is defined in [31] | |||
-- conformance information | -- conformance information | |||
etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } | etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 } | |||
skipping to change at page 54, line 26 | skipping to change at page 55, line 17 | |||
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. | |||
6. Acknowledgements | 6. Acknowledgements | |||
This document was produced by the IETF Ethernet Interfaces and Hub | This document was produced by the IETF Ethernet Interfaces and Hub | |||
MIB Working Group, whose efforts were greatly advanced by the | MIB Working Group, whose efforts were greatly advanced by the | |||
contributions of the following people: | contributions of the following people: | |||
Ran Atkinson | ||||
Mike Ayers | ||||
Mike Heard | ||||
Lynn Kubinec | Lynn Kubinec | |||
Kam Lam | ||||
Kerry McDonald | ||||
Steve McRobert | Steve McRobert | |||
K.C. Norseth | ||||
Dan Romascanu | Dan Romascanu | |||
Randy Presuhn | ||||
Andrew Smith | Andrew Smith | |||
Kaj Tesink | ||||
Geoff Thompson | Geoff Thompson | |||
This document is based on the Proposed Standard Ethernet MIB, RFC | This document is based on the Proposed Standard Ethernet MIB, RFC | |||
2665 [26], edited by John Flick of Hewlett-Packard and Jeffrey | 2665 [RFC2665], edited by John Flick of Hewlett-Packard and Jeffrey | |||
Johnson of RedBack Networks and produced by the Ethernet Interfaces | Johnson of RedBack Networks and produced by the Ethernet Interfaces | |||
and Hub MIB Working Group. It extends that document by providing | and Hub MIB Working Group. It extends that document by providing | |||
support for 10 Gb/s Ethernet interfaces as defined in [18]. | support for 10 Gb/s Ethernet interfaces as defined in [P802.3ae]. | |||
RFC 2665, in turn, is based on the Proposed Standard Ethernet MIB, | RFC 2665, in turn, is based on the Proposed Standard Ethernet MIB, | |||
RFC 2358 [25], edited by John Flick of Hewlett-Packard and Jeffrey | RFC 2358 [RFC2358], edited by John Flick of Hewlett-Packard and | |||
Johnson of RedBack Networks and produced by the 802.3 Hub MIB Working | Jeffrey Johnson of RedBack Networks and produced by the 802.3 Hub MIB | |||
Group. It extends that document by providing support for full-duplex | Working Group. It extends that document by providing support for | |||
Ethernet interfaces and 1000 Mb/sec Ethernet interfaces as outlined | full-duplex Ethernet interfaces and 1000 Mb/sec Ethernet interfaces | |||
in [17]. | as outlined in [IEEE802.3]. | |||
RFC 2358, in turn, is almost completely based on both the Standard | RFC 2358, in turn, is almost completely based on both the Standard | |||
Ethernet MIB, RFC 1643 [23], and the Proposed Standard Ethernet MIB | Ethernet MIB, RFC 1643 [RFC1643], and the Proposed Standard Ethernet | |||
using the SNMPv2 SMI, RFC 1650 [24], both of which were edited by | MIB using the SNMPv2 SMI, RFC 1650 [RFC1650], both of which were | |||
Frank Kastenholz of FTP Software and produced by the Interfaces MIB | edited by Frank Kastenholz of FTP Software and produced by the | |||
Working Group. RFC 2358 extends those documents by providing support | Interfaces MIB Working Group. RFC 2358 extends those documents by | |||
for 100 Mb/sec ethernet interfaces. | providing support for 100 Mb/sec ethernet interfaces. | |||
RFC 1643 and RFC 1650, in turn, are based on the Draft Standard | RFC 1643 and RFC 1650, in turn, are based on the Draft Standard | |||
Ethernet MIB, RFC 1398 [22], also edited by Frank Kastenholz and | Ethernet MIB, RFC 1398 [RFC1398], also edited by Frank Kastenholz and | |||
produced by the Ethernet MIB Working Group. | produced by the Ethernet MIB Working Group. | |||
RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, | RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, | |||
RFC 1284 [20], which was edited by John Cook of Chipcom and produced | RFC 1284 [RFC1284], which was edited by John Cook of Chipcom and | |||
by the Transmission MIB Working Group. The Ethernet MIB Working | produced by the Transmission MIB Working Group. The Ethernet MIB | |||
Group gathered implementation experience of the variables specified | Working Group gathered implementation experience of the variables | |||
in RFC 1284, documented that experience in RFC 1369 [21], and used | specified in RFC 1284, documented that experience in RFC 1369 | |||
that information to develop this revised MIB. | [RFC1369], and used that information to develop this revised MIB. | |||
RFC 1284, in turn, is based on a document written by Frank | RFC 1284, in turn, is based on a document written by Frank | |||
Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management | Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management | |||
Draft M compatible MIB for TCP/IP Networks [19]. This document was | Draft M compatible MIB for TCP/IP Networks [KASTEN]. This document | |||
modestly reworked, initially by the SNMP Working Group, and then by | was modestly reworked, initially by the SNMP Working Group, and then | |||
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 | |||
RFC 1212 [3] concise format. Anil Rijsinghani of DEC contributed | RFC 1212 [RFC1212] concise format. Anil Rijsinghani of DEC | |||
text that more adequately describes the TDR test. Thanks to Frank | contributed text that more adequately describes the TDR test. Thanks | |||
Kastenholz of Interlan and Louis Steinberg of IBM for their | to Frank Kastenholz of Interlan and Louis Steinberg of IBM for their | |||
experimentation. | experimentation. | |||
7. References | 7. References | |||
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for | Normative References | |||
Describing SNMP Management Frameworks", RFC 2571, May 1999. | ||||
[2] Rose, M. and K. McCloghrie, "Structure and Identification of | [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, | |||
Management Information for TCP/IP-based Internets", STD 16, | J., Rose, M. and S. Waldbusser, "Structure of Management | |||
RFC 1155, May 1990. | Information Version 2 (SMIv2)", STD 58, RFC 2578, April | |||
1999. | ||||
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, | [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, | |||
RFC 1212, March 1991. | J., Rose, M. and S. Waldbusser, "Textual Conventions for | |||
SMIv2", STD 58, RFC 2579, April 1999. | ||||
[4] Rose, M., "A Convention for Defining Traps for use with the | [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, | |||
SNMP", RFC 1215, March 1991. | J., Rose, M. and S. Waldbusser, "Conformance Statements | |||
for SMIv2", STD 58, RFC 2580, April 1999. | ||||
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, | [IEEE802.3] IEEE, IEEE Std 802.3, 2000 Edition: "Information | |||
M. and S. Waldbusser, "Structure of Management Information | technology - Telecommunications and information exchange | |||
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. | between systems - Local and metropolitan area networks - | |||
Specific requirements - Part 3: Carrier sense multiple | ||||
access with collision detection (CSMA/CD) access method | ||||
and physical layer specifications", (Adopted by ISO/IEC | ||||
and redesignated as ISO/IEC 8802-3:2000(E), 2000. | ||||
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, | [P802.3ae] Law, D., Editor, Draft Supplement to IEEE Std. 802.3, | |||
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, | IEEE Draft P802.3ae/D4.01, February 2002, work in | |||
RFC 2579, April 1999. | progress. | |||
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, | [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | |||
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD | MIB using SMIv2", RFC 2863, June 2000. | |||
58, RFC 2580, April 1999. | ||||
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple | [MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE | |||
Network Management Protocol", STD 15, RFC 1157, May 1990. | 802.3 Medium Attachment Units (MAUs) using SMIv2", work | |||
in progress, draft-ietf-hubmib-mau-mib-v3-01.txt, | ||||
February 2002. | ||||
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, | Non-Normative References | |||
"Introduction to Community-based SNMPv2", RFC 1901, January | ||||
1996. | ||||
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport | [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An | |||
Mappings for Version 2 of the Simple Network Management Protocol | Architecture for Describing SNMP Management Frameworks", | |||
(SNMPv2)", RFC 1906, January 1996. | RFC 2571, April 1999. | |||
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message | [RFC1155] Rose, M. and K. McCloghrie, "Structure and | |||
Processing and Dispatching for the Simple Network Management | Identification of Management Information for | |||
Protocol (SNMP)", RFC 2572, May 1999. | TCP/IP-based Internets", STD 16, RFC 1155, May 1990. | |||
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) | [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", | |||
for version 3 of the Simple Network Management Protocol | STD 16, RFC 1212, March 1991. | |||
(SNMPv3)", RFC 2574, May 1999. | ||||
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol | [RFC1215] Rose, M., "A Convention for Defining Traps for use with | |||
Operations for Version 2 of the Simple Network Management | the SNMP", RFC 1215, March 1991. | |||
Protocol (SNMPv2)", RFC 1905, January 1996. | ||||
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC | [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, | |||
2573, May 1999. | "Simple Network Management Protocol", STD 15, RFC 1157, | |||
May 1990. | ||||
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access | [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, | |||
Control Model (VACM) for the Simple Network Management Protocol | "Introduction to Community-based SNMPv2", RFC 1901, | |||
(SNMP)", RFC 2575, May 1999. | January 1996. | |||
[16] Case, J., Mundy, R., Partain, D. and B. Stewart, | [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, | |||
"Introduction to Version 3 of the Internet-Standard Network | "Transport Mappings for Version 2 of the Simple Network | |||
Management Framework", RFC 2570, April 1999. | Management Protocol (SNMPv2)", RFC 1906, January 1996. | |||
[17] IEEE, IEEE Std 802.3, 2000 Edition: "Information technology - | [RFC2572] Case, J., Harrington, D., Presuhn R. and B. Wijnen, | |||
Telecommunications and information exchange between systems - | "Message Processing and Dispatching for the Simple | |||
Local and metropolitan area networks - Specific requirements - | Network Management Protocol (SNMP)", RFC 2572, May 1999. | |||
Part 3: Carrier sense multiple access with collision detection | ||||
(CSMA/CD) access method and physical layer specifications", | ||||
(Adopted by ISO/IEC and redesignated as ISO/IEC 8802-3:2000(E), | ||||
2000. | ||||
[18] IEEE, IEEE Draft P802.3ae/D3.0: "Supplement to Carrier Sense | [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model | |||
Multiple Access with Collision Detection (CSMA/CD) Access | (USM) for version 3 of the Simple Network Management | |||
Method & Physical Layer Specifications - Media Access Control | Protocol (SNMPv3)", RFC 2574, May 1999. | |||
(MAC) Parameters, Physical Layer, and Management Parameters | ||||
for 10 Gb/s Operation", March 2001. | ||||
[19] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible | [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, | |||
MIB for TCP/IP Networks", electronic mail message to mib- | "Protocol Operations for Version 2 of the Simple Network | |||
wg@nnsc.nsf.net, 9 June 1989. | Management Protocol (SNMPv2)", RFC 1905, January 1996. | |||
[20] Cook, J., "Definitions of Managed Objects for Ethernet-Like | [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 | |||
Interface Types", RFC 1284, December 1991. | Applications", RFC 2573, May 1999. | |||
[21] Kastenholz, F., "Implementation Notes and Experience for The | [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based | |||
Internet Ethernet MIB", RFC 1369, October 1992. | Access Control Model (VACM) for the Simple Network | |||
Management Protocol (SNMP)", RFC 2575, May 1999. | ||||
[22] Kastenholz, F., "Definitions of Managed Objects for the | [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, | |||
Ethernet-like Interface Types", RFC 1398, January 1993. | "Introduction to Version 3 of the Internet-Standard | |||
Network Management Framework", RFC 2570, April 1999. | ||||
[23] Kastenholz, F., "Definitions of Managed Objects for the | [KASTEN] Kastenholz, F., "IEEE 802.3 Layer Management Draft | |||
Ethernet-like Interface Types", STD 50, RFC 1643, July 1994. | compatible MIB for TCP/IP Networks", electronic mail | |||
message to mib-wg@nnsc.nsf.net, 9 June 1989. | ||||
[24] Kastenholz, F., "Definitions of Managed Objects for the | [RFC1284] Cook, J., "Definitions of Managed Objects for | |||
Ethernet-like Interface Types using SMIv2", RFC 1650, August | Ethernet-Like Interface Types", RFC 1284, December 1991. | |||
[RFC1369] Kastenholz, F., "Implementation Notes and Experience for | ||||
The Internet Ethernet MIB", RFC 1369, October 1992. | ||||
[RFC1398] Kastenholz, F., "Definitions of Managed Objects for the | ||||
Ethernet-like Interface Types", RFC 1398, January 1993. | ||||
[RFC1643] Kastenholz, F., "Definitions of Managed Objects for the | ||||
Ethernet-like Interface Types", STD 50, RFC 1643, July | ||||
1994. | 1994. | |||
[25] Flick, J. and J. Johnson, "Definitions of Managed Objects | [RFC1650] Kastenholz, F., "Definitions of Managed Objects for the | |||
for the Ethernet-like Interface Types", RFC 2358, June 1998. | Ethernet-like Interface Types using SMIv2", RFC 1650, | |||
August 1994. | ||||
[26] Flick, J., and J. Johnson, "Definitions of Managed Objects | [RFC2358] Flick, J. and J. Johnson, "Definitions of Managed | |||
for the Ethernet-like Interface Types", RFC 2665, August 1999. | Objects for the Ethernet-like Interface Types", RFC | |||
2358, June 1998. | ||||
[27] McCloghrie, K. and M. Rose, Editors, "Management Information | [RFC2665] Flick, J., and J. Johnson, "Definitions of Managed | |||
Base for Network Management of TCP/IP-based internets: MIB-II", | Objects for the Ethernet-like Interface Types", RFC | |||
STD 17, RFC 1213, March 1991. | 2665, August 1999. | |||
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB | [RFC1213] McCloghrie, K. and M. Rose, Editors, "Management | |||
using SMIv2", RFC 2863, June 2000. | Information Base for Network Management of TCP/IP-based | |||
internets: MIB-II", STD 17, RFC 1213, March 1991. | ||||
[29] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirements Levels", BCP 14, RFC 2119, March 1997. | Requirements Levels", BCP 14, RFC 2119, March 1997. | |||
[30] Flick, J., Smith, A., deGraaf, K., Romascanu, D., McMaster, | [RFC2666] Flick, J., "Definitions of Object Identifiers for | |||
D., McCloghrie, K. and S. Roberts, "Definitions of Managed | Identifying Ethernet Chip Sets", RFC 2666, August 1999. | |||
Objects for IEEE 802.3 Medium Attachment Units (MAUs) using | ||||
SMIv2", work in progress, draft-ietf-hubmib-mau-mib-v3-00.txt, | ||||
June 2001. | ||||
[31] Flick, J., "Definitions of Object Identifiers for Identifying | [ETHERWIS] Ayers, M., Flick, J., Heard, C. M., Lam, K., McDonald, | |||
Ethernet Chip Sets", RFC 2666, August 1999. | K., Norseth, K. C., and K. Tesink, "Definitions of | |||
Managed Objects for the Ethernet WAN Interface | ||||
Sublayer", work in progress, | ||||
draft-ietf-hubmib-wis-mib-02.txt, February 2002. | ||||
[CASE] Case, J., and C. Partridge, "Case Diagrams: A First Step | ||||
to Diagrammed Management Information Bases", Computer | ||||
Communications Review, 19(1):13-16, January 1989. | ||||
8. Security Considerations | 8. Security Considerations | |||
There are two management objects defined in this MIB that have a | There are two management objects defined in this MIB that have a | |||
MAX-ACCESS clause of read-write. Such objects may be considered | MAX-ACCESS clause of read-write. Such objects may be considered | |||
sensitive or vulnerable in some network environments. The support | sensitive or vulnerable in some network environments. The support | |||
for SET operations in a non-secure environment without proper | for SET operations in a non-secure environment without proper | |||
protection can have a negative effect on network operations. | protection can have a negative effect on network 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 | |||
skipping to change at page 58, line 33 | skipping to change at page 59, line 50 | |||
these objects when sending them over the network via SNMP. Not all | these objects 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. | |||
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 2574 [12] and the View-based | of the User-based Security Model RFC 2574 [RFC2574] and the View- | |||
Access Control Model RFC 2575 [15] is recommended. | based Access Control Model RFC 2575 [RFC2575] 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. | |||
9. Author's Address | 9. Author's Address | |||
John Flick | John Flick | |||
Hewlett-Packard Company | Hewlett-Packard Company | |||
skipping to change at page 61, line 40 | skipping to change at page 63, line 13 | |||
(11) Converted the dot3Tests, dot3Errors, and dot3ChipSets | (11) Converted the dot3Tests, dot3Errors, and dot3ChipSets | |||
OIDs to use the OBJECT-IDENTITY macro. | OIDs to use the OBJECT-IDENTITY macro. | |||
(12) Added to the list of registered dot3ChipSets. | (12) Added to the list of registered dot3ChipSets. | |||
(13) An intellectual property notice and copyright notice | (13) An intellectual property notice and copyright notice | |||
were added, as required by RFC 2026. | were added, as required by RFC 2026. | |||
B. Full Copyright Statement | B. Full Copyright Statement | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
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 and | or assist in its implementation may be prepared, copied, published and | |||
distributed, in whole or in part, without restriction of any kind, | distributed, in whole or in part, without restriction of any kind, | |||
provided that the above copyright notice and this paragraph are | 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. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |