draft-ietf-hubmib-etherif-mib-v3-03.txt		rfc3635.txt
	Ethernet Interfaces and Hub MIB Working Group J. Flick		Network Working Group J. Flick
	INTERNET DRAFT Hewlett-Packard Company		Request for Comments: 3635 Hewlett-Packard Company
	March 2003		Obsoletes: 2665 September 2003
			Category: Standards Track
	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-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document specifies an Internet standards track protocol for the
	all provisions of Section 10 of RFC2026.		Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
	Internet-Drafts are working documents of the Internet Engineering		Official Protocol Standards" (STD 1) for the standardization state
	Task Force (IETF), its areas, and its working groups. Note that		and status of this protocol. Distribution of this memo is unlimited.
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). 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.
	In particular, it defines objects for managing Ethernet-like		In particular, it defines objects for managing Ethernet-like
	interfaces.		interfaces. This memo obsoletes RFC 2665. It updates that
			specification by including management information useful for the
	This memo obsoletes RFC 2665. It updates that specification by		management of 10 Gigabit per second (Gb/s) Ethernet interfaces.
	including management information useful for the management of 10
	Gigabit per second (Gb/s) Ethernet interfaces.
	Distribution of this memo is unlimited. Please forward comments to
	hubmib@ietf.org.
	Table of Contents		Table of Contents
	1. Introduction ................................................ 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. The Internet-Standard Management Framework ................. 3		2. The Internet-Standard Management Framework . . . . . . . . . . 3
	3. Overview ................................................... 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Relation to MIB-2 ........................................ 4		3.1. Relation to MIB-2. . . . . . . . . . . . . . . . . . . . 4
	3.2. Relation to the Interfaces MIB ........................... 4		3.2. Relation to the Interfaces MIB . . . . . . . . . . . . . 4
	3.2.1. Layering Model ......................................... 5		3.2.1. Layering Model . . . . . . . . . . . . . . . . . 4
	3.2.2. Virtual Circuits ....................................... 5		3.2.2. Virtual Circuits . . . . . . . . . . . . . . . . 4
	3.2.3. ifRcvAddressTable ...................................... 5		3.2.3. ifRcvAddressTable. . . . . . . . . . . . . . . . 5
	3.2.4. ifType ................................................. 5		3.2.4. ifType . . . . . . . . . . . . . . . . . . . . . 5
	3.2.5. ifXxxOctets ............................................ 6		3.2.5. ifXxxOctets. . . . . . . . . . . . . . . . . . . 5
	3.2.6. ifXxxXcastPkts ......................................... 7		3.2.6. ifXxxXcastPkts . . . . . . . . . . . . . . . . . 6
	3.2.7. ifMtu .................................................. 8		3.2.7. ifMtu. . . . . . . . . . . . . . . . . . . . . . 8
	3.2.8. ifSpeed and ifHighSpeed ................................ 9		3.2.8. ifSpeed and ifHighSpeed. . . . . . . . . . . . . 8
	3.2.9. ifPhysAddress .......................................... 9		3.2.9. ifPhysAddress. . . . . . . . . . . . . . . . . . 9
	3.2.10. Specific Interface MIB Objects ........................ 10		3.2.10. Specific Interface MIB Objects. . . . . . . . . 10
	3.3. Relation to the 802.3 MAU MIB ............................ 13		3.3. Relation to the 802.3 MAU MIB. . . . . . . . . . . . . . 13
	3.4. dot3StatsEtherChipSet .................................... 13		3.4. dot3StatsEtherChipSet. . . . . . . . . . . . . . . . . . 13
	3.5. Mapping of IEEE 802.3 Managed Objects .................... 14		3.5. Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 14
	4. Definitions ................................................ 17		4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5. Intellectual Property ...................................... 55		5. Intellectual Property Statement. . . . . . . . . . . . . . . . 55
	6. Acknowledgements ........................................... 56		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
	7. Normative References ....................................... 57		7. Normative References . . . . . . . . . . . . . . . . . . . . . 57
	8. Informative References ..................................... 58		8. Informative References . . . . . . . . . . . . . . . . . . . . 58
	9. Security Considerations .................................... 59		9. Security Considerations. . . . . . . . . . . . . . . . . . . . 59
	10. IANA Considerations ....................................... 60		10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 60
	11. Author's Address .......................................... 60		A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 61
	A. Change Log ................................................. 61		A.1. Changes since RFC 2665 . . . . . . . . . . . . . . . . . 61
	A.1. Changes since RFC 2665 ................................... 61		A.2. Changes between RFC 2358 and RFC 2665 . . . . . . . . . 62
	A.2. Changes between RFC 2358 and RFC 2665 .................... 62		A.3. Changes between RFC 1650 and RFC 2358. . . . . . . . . . 62
	A.3. Changes between RFC 1650 and RFC 2358 .................... 63		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 63
	B. Full Copyright Statement ................................... 63		Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .64
	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,
	skipping to change at page 4, line 5		skipping to change at page 3, line 37
	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,
	2002 Edition [IEEE802.3], amended by IEEE Std. 802.3ae-2002		2002 Edition [IEEE802.3], amended by IEEE Std. 802.3ae-2002
	[IEEE802.3ae], as originally interpreted by Frank Kastenholz, then of		[IEEE802.3ae], as originally interpreted by Frank Kastenholz, then of
	Interlan in [KASTEN]. Implementors of these MIB objects should note		Interlan in [KASTEN]. Implementors of these MIB objects should note
	that IEEE Std. 802.3 [IEEE802.3] explicitly describes (in the form of		that IEEE Std. 802.3 [IEEE802.3] explicitly describes (in the form of
	Pascal pseudocode) when, where, and how various MAC attributes are		Pascal pseudocode) when, where, and how various MAC attributes are
	measured. The IEEE document also describes the effects of MAC actions		measured. The IEEE document also describes the effects of MAC
	that may be invoked by manipulating instances of the MIB objects		actions that may be invoked by manipulating instances of the MIB
	defined here.		objects defined here.
	To the extent that some of the attributes defined in [IEEE802.3] are		To the extent that some of the attributes defined in [IEEE802.3] are
	represented by previously defined objects in MIB-2 [RFC1213] or in		represented by previously defined objects in MIB-2 [RFC1213] or in
	the Interfaces MIB [RFC2863], such attributes are not redundantly		the Interfaces MIB [RFC2863], such attributes are not redundantly
	represented by objects defined in this memo. Among the attributes		represented by objects defined in this memo. Among the attributes
	represented by objects defined in other memos are the number of		represented by objects defined in other memos are the number of
	octets transmitted or received on a particular interface, the number		octets transmitted or received on a particular interface, the number
	of frames transmitted or received on a particular interface, the		of frames transmitted or received on a particular interface, the
	promiscuous status of an interface, the MAC address of an interface,		promiscuous status of an interface, the MAC address of an interface,
	and multicast information associated with an interface.		and multicast information associated with an interface.
	skipping to change at page 4, line 33		skipping to change at page 4, line 19
	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 IDENTIFIER ::= { transmission 7 }
	3.2. Relation to the Interfaces MIB		3.2. Relation to the Interfaces MIB
	The Interface MIB [RFC2863] requires that any MIB which is an adjunct		The Interface MIB [RFC2863] requires that any MIB which is an adjunct
	of 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 [RFC2863] enumerates several areas which a media-		Section 4 of [RFC2863] enumerates several areas which a
	specific MIB must clarify. Each of these areas is addressed in a		media-specific MIB must clarify. Each of these areas is addressed in
	following subsection. The implementor is referred to [RFC2863] in		a following subsection. The implementor is referred to [RFC2863] in
	order to 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 [IEEE802.3] describes the		aggregation. In this case, Annex 30C of [IEEE802.3] describes the
	layering model and the use of the ifStackTable for representing		layering model and the use of the ifStackTable for representing
	aggregated links. Another example is the use of the 802.3 WAN		aggregated links. Another example is the use of the 802.3 WAN
	Interface Sublayer. In this case, The 802.3 WIS MIB [ETHERWIS]		Interface Sublayer. In this case, The 802.3 WIS MIB [RFC3637]
	describes the layering model and the use of the ifStackTable for		describes the layering model and the use of the ifStackTable for
	representing the WAN sublayer.		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
	skipping to change at page 6, line 13		skipping to change at page 5, line 42
	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 [MAU-MIB]. Note that implementation		ifMauType in the 802.3 MAU MIB [RFC3636]. Note that implementation
	of the 802.3 MAU MIB [MAU-MIB] is REQUIRED for all ethernet-like		of the 802.3 MAU MIB [RFC3636] is REQUIRED for all ethernet-like
	interfaces.		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 [IEEE802.3] (frameSize is defined in bits rather than		4.2.7.1 of [IEEE802.3] (frameSize is defined in bits rather than
	octets, and is defined as 2 x addressSize + lengthOrTypeSize +		octets, and is defined as 2 x addressSize + lengthOrTypeSize +
	dataSize + crcSize). They do not include the number of octets in		dataSize + crcSize). They do not include the number of octets in
	collided or failed transmit attempts, since the MAC layer driver		collided or failed transmit attempts, since the MAC layer driver
	typically does not have visibility to count these octets. They also		typically does not have visibility to count these octets. They also
	do not include octets in received invalid frames, since this		do not include octets in received invalid frames, since this
	information is normally not passed to the MAC layer, and since non-		information is normally not passed to the MAC layer, and since
	promiscuous MAC implementations cannot reliably determine whether an		non-promiscuous MAC implementations cannot reliably determine whether
	invalid frame was actually addressed to this station.		an 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 7, line 27		skipping to change at page 7, line 6
	ifOutOctets.		ifOutOctets.
	3.2.6. ifXxxXcastPkts		3.2.6. ifXxxXcastPkts
	The packet counters in the IF-MIB do not exactly match the definition		The packet counters in the IF-MIB do not exactly match the definition
	of the frame counters in IEEE 802.3. aFramesTransmittedOK counts the		of the frame counters in IEEE 802.3. aFramesTransmittedOK counts the
	number of frames successfully transmitted on the interface, whereas		number of frames successfully transmitted on the interface, whereas
	ifOutUcastPkts, ifOutMulticastPkts and ifOutBroadcastPkts count the		ifOutUcastPkts, ifOutMulticastPkts and ifOutBroadcastPkts count the
	number of transmit requests made from a higher layer, whether or not		number of transmit requests made from a higher layer, whether or not
	the transmit attempt was successful. This means that packets counted		the transmit attempt was successful. This means that packets counted
	by ifOutErrors or ifOutDiscards are also be counted by		by ifOutErrors or ifOutDiscards are also counted by ifOutXcastPkts,
	ifOutXcastPkts, but are not be counted by aFramesTransmittedOK. This		but are not counted by aFramesTransmittedOK. This also means that,
	also means that, since MAC Control frames are generated by a sublayer		since MAC Control frames are generated by a sublayer internal to the
	internal to the interface layer rather than by a higher layer, they		interface layer rather than by a higher layer, they are not counted
	are not counted by ifOutXcastPkts, but are counted by		by ifOutXcastPkts, but are counted by aFramesTransmittedOK. Roughly:
	aFramesTransmittedOK. Roughly:
	aFramesTransmittedOK = ifOutUcastPkts + ifOutMulticastPkts +		aFramesTransmittedOK = ifOutUcastPkts + ifOutMulticastPkts +
	ifOutBroadcastPkts + dot3OutPauseFrames -		ifOutBroadcastPkts + dot3OutPauseFrames -
	(ifOutErrors + ifOutDiscards)		(ifOutErrors + ifOutDiscards)
	Similarly, aFramesReceivedOK counts the number of frames received		Similarly, aFramesReceivedOK counts the number of frames received
	successfully by the interface, whether or not they are passed to a		successfully by the interface, whether or not they are passed to a
	higher layer, whereas ifInUcastPkts, ifInMulticastPkts and		higher layer, whereas ifInUcastPkts, ifInMulticastPkts and
	ifInBroadcastPkts count only the number of packets passed to a higher		ifInBroadcastPkts count only the number of packets passed to a higher
	layer. This means that packets counted by ifInDiscards or		layer. This means that packets counted by ifInDiscards or
	skipping to change at page 8, line 16		skipping to change at page 7, line 41
	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		To better understand the issues surrounding the mapping of the IF-MIB
	IF-MIB packet and octet counters to an Ethernet interface, it is		packet and octet counters to an Ethernet interface, it is useful to
	useful to refer to a Case Diagram [CASE] for the IF-MIB counters,		refer to a Case Diagram [CASE] for the IF-MIB counters, with
	with modifications to show the proper interpretation for the Ethernet		modifications to show the proper interpretation for the Ethernet
	interface layer.		interface layer.
	layer above		layer above
	--------------------------------------------------------------------		--------------------------------------------------------------------
	ifInUcastPkts+ ^ | ifOutUcastPkts+		ifInUcastPkts+ ^ | ifOutUcastPkts+
	ifInBroadcastPkts+ ----|---- ----|---- ifOutBroadcastPkts+		ifInBroadcastPkts+ ----|---- ----|---- ifOutBroadcastPkts+
	ifInMulticastPkts | | ifOutMulticastPkts		ifInMulticastPkts | | ifOutMulticastPkts
	| |		| |
	dot3InPauseFrames <---| |<--- dot3OutPauseFrames		dot3InPauseFrames <---| |<--- dot3OutPauseFrames
	| |		| |
	skipping to change at page 9, line 23		skipping to change at page 9, line 5
	3.2.8. ifSpeed and ifHighSpeed		3.2.8. ifSpeed and ifHighSpeed
	For ethernet-like interfaces operating at 1000 Megabits per second		For ethernet-like interfaces operating at 1000 Megabits per second
	(Mb/s) or less, ifSpeed will represent the current operational speed		(Mb/s) or less, ifSpeed will represent the current operational speed
	of the interface in bits per second. For current interface types,		of the interface in bits per second. For current interface types,
	this will be equal to 1,000,000 (1 million), 10,000,000 (10 million),		this will be equal to 1,000,000 (1 million), 10,000,000 (10 million),
	100,000,000 (100 million), or 1,000,000,000 (1 billion). ifHighSpeed		100,000,000 (100 million), or 1,000,000,000 (1 billion). ifHighSpeed
	will represent the current operational speed in millions of bits per		will represent the current operational speed in millions of bits per
	second. For current ethernet-like interfaces, this will be equal to		second. For current ethernet-like interfaces, this will be equal to
	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,294 for WAN		to 10,000 for LAN implementations 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 [RFC2863].		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 [MAU-MIB].		object in the 802.3 MAU MIB [RFC3636].
	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
	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).
	If the designer truly can not chose, use of the factory- provided ROM		If the designer truly can not chose, use of the factory-provided ROM
	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.
	skipping to change at page 12, line 23		skipping to change at page 12, line 7
	ifInMulticastPkts Refer to [RFC2863]. Note that this does		ifInMulticastPkts Refer to [RFC2863]. Note that this does
	not include MAC Control frames, since		not include MAC Control frames, since
	MAC 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 [RFC2863]. Note that this does		ifInBroadcastPkts Refer to [RFC2863]. Note that this does
	not include MAC Control frames, since		not include MAC Control frames, since
	MAC Control frames are generated by the		MAC Control frames are consumed by the
	interface layer, and are not passed from		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.
	ifOutMulticastPkts Refer to [RFC2863]. Note that this does		ifOutMulticastPkts Refer to [RFC2863]. Note that this does
	not include MAC Control frames, since		not include MAC Control frames, since
	MAC Control frames are consumed by the		MAC Control frames are generated by the
	interface layer and are not passed to		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.
	ifOutBroadcastPkts Refer to [RFC2863]. Note that this does		ifOutBroadcastPkts Refer to [RFC2863]. Note that this does
	not include MAC Control frames, since		not include MAC Control frames, since
	MAC 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.
	skipping to change at page 13, line 17		skipping to change at page 12, line 50
	ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is		ifLinkUpDownTrapEnable Refer to [RFC2863]. Default is
	'enabled'		'enabled'
	ifHighSpeed Refer to section 3.2.8.		ifHighSpeed Refer to section 3.2.8.
	ifPromiscuousMode Refer to [RFC2863].		ifPromiscuousMode Refer to [RFC2863].
	ifConnectorPresent This will normally be 'true'. It will		ifConnectorPresent This will normally be 'true'. It will
	be 'false' in the case where this		be 'false' in the case where this
	interface uses the WAN Interface		interface uses the WAN Interface
	Sublayer. See [ETHERWIS] for details.		Sublayer. See [RFC3637] for details.
	ifAlias Refer to [RFC2863].		ifAlias Refer to [RFC2863].
	ifCounterDiscontinuityTime Refer to [RFC2863]. 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.
	skipping to change at page 13, line 39		skipping to change at page 13, line 23
	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 mauModIfCompl3 compliance statement of the MAU-MIB		Support for the mauModIfCompl3 compliance statement of the MAU-MIB
	[MAU-MIB] is REQUIRED for Ethernet-like interfaces. This MIB is		[RFC3636] is REQUIRED for Ethernet-like interfaces. This MIB is
	needed in order to allow applications to determine the current MAU		needed in order to allow applications to determine the current MAU
	type in use by the interface, and to control autonegotiation and		type in use by the interface, and to control autonegotiation and
	duplex mode for the interface. Implementing this MIB module without		duplex mode for the interface. 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 media type in use, and no standard way to		way to determine the media type in use, and no standard way to
	control the duplex mode 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 previous versions of this document
	have now been moved to a separate document [RFC2666].		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
	of backwards compatability may continue to use the values defined in		of backwards compatibility may continue to use the values defined in
	[RFC2666]. For chipsets not listed in [RFC2666], implementors that		[RFC2666]. For chipsets not listed in [RFC2666], implementors that
	wish to support this object and return a valid OBJECT IDENTIFIER		wish to support this object and return a valid OBJECT IDENTIFIER
	value may assign OBJECT IDENTIFIERS within that part of the		value may assign OBJECT IDENTIFIERS within that part of the
	registration tree 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 +
	ifOutBroadcastPkts*		ifOutBroadcastPkts*
	.aSingleCollisionFrames dot3StatsSingleCollisionFrames		.aSingleCollisionFrames dot3StatsSingleCollisionFrames
	.aMultipleCollisionFrames dot3StatsMultipleCollisionFrames		.aMultipleCollisionFrames dot3StatsMultipleCollisionFrames
	.aFramesReceivedOK IF-MIB - ifInUcastPkts +		.aFramesReceivedOK IF-MIB - ifInUcastPkts +
	ifInMulticastPkts +		ifInMulticastPkts +
	ifInBroadcastPkts*		ifInBroadcastPkts*
	.aFrameCheckSequenceErrors dot3StatsFCSErrors		.aFrameCheckSequenceErrors dot3StatsFCSErrors
	.aAlignmentErrors dot3StatsAlignmentErrors		.aAlignmentErrors dot3StatsAlignmentErrors
	.aOctetsTransmittedOK IF-MIB - ifOutOctets*		.aOctetsTransmittedOK IF-MIB - ifOutOctets*
	.aFramesWithDeferredXmissions dot3StatsDeferredTransmissions		.aFramesWithDeferredXmissions dot3StatsDeferredTransmissions
	.aLateCollisions dot3StatsLateCollisions		.aLateCollisions dot3StatsLateCollisions
	.aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions		.aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions
	.aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors		.aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors
	.aCarrierSenseErrors dot3StatsCarrierSenseErrors		.aCarrierSenseErrors dot3StatsCarrierSenseErrors
	.aOctetsReceivedOK IF-MIB - ifInOctets*		.aOctetsReceivedOK IF-MIB - ifInOctets*
	.aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors		.aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors
	.aPromiscuousStatus IF-MIB - ifPromiscuousMode		.aPromiscuousStatus IF-MIB - ifPromiscuousMode
	.aReadMulticastAddressList IF-MIB - ifRcvAddressTable		.aReadMulticastAddressList IF-MIB - ifRcvAddressTable
	.aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts*		.aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts*
	.aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts*		.aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts*
	.aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts*		.aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts*
	.aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts*		.aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts*
	.aFrameTooLongErrors dot3StatsFrameTooLongs		.aFrameTooLongErrors dot3StatsFrameTooLongs
	.aReadWriteMACAddress IF-MIB - ifPhysAddress		.aReadWriteMACAddress IF-MIB - ifPhysAddress
	.aCollisionFrames dot3CollFrequencies		.aCollisionFrames dot3CollFrequencies
	.aDuplexStatus dot3StatsDuplexStatus		.aDuplexStatus dot3StatsDuplexStatus
	.aRateControlAbility dot3StatsRateControlAbility		.aRateControlAbility dot3StatsRateControlAbility
	.aRateControlStatus dot3StatsRateControlStatus		.aRateControlStatus dot3StatsRateControlStatus
	.acAddGroupAddress IF-MIB - ifRcvAddressTable		.acAddGroupAddress IF-MIB - ifRcvAddressTable
	.acDeleteGroupAddress IF-MIB - ifRcvAddressTable		.acDeleteGroupAddress IF-MIB - ifRcvAddressTable
	.acExecuteSelfTest dot3TestLoopBack		.acExecuteSelfTest dot3TestLoopBack
	oPHYEntity		oPHYEntity
	.aPHYID dot3StatsIndex or		.aPHYID dot3StatsIndex or
	IF-MIB - ifIndex		IF-MIB - ifIndex
	.aSQETestErrors dot3StatsSQETestErrors		.aSQETestErrors dot3StatsSQETestErrors
	.aSymbolErrorDuringCarrier dot3StatsSymbolErrors		.aSymbolErrorDuringCarrier dot3StatsSymbolErrors
	oMACControlEntity		oMACControlEntity
	.aMACControlID dot3StatsIndex or		.aMACControlID dot3StatsIndex or
	IF-MIB - ifIndex		IF-MIB - ifIndex
	.aMACControlFunctionsSupported dot3ControlFunctionsSupported and		.aMACControlFunctionsSupported dot3ControlFunctionsSupported and
	dot3ControlFunctionsEnabled		dot3ControlFunctionsEnabled
	.aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes		.aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes
	oPAUSEEntity		oPAUSEEntity
	.aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames		.aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames
	.aPAUSEMACCtrlFramesReceived dot3InPauseFrames		.aPAUSEMACCtrlFramesReceived dot3InPauseFrames
	* 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. See section 3.2.5		definition of the octet counters in IEEE 802.3. See section 3.2.5
	for details.		for details.
	Also note that the packet counters in the IF-MIB do not exactly match		Also note that the packet counters in the IF-MIB do not exactly match
	the definition of the frame counters in IEEE 802.3. See section		the definition of the frame counters in IEEE 802.3. See section
	3.2.6 for details.		3.2.6 for details.
	The following IEEE 802.3 managed objects have been removed from this		The following IEEE 802.3 managed objects have been removed from this
	skipping to change at page 17, line 29		skipping to change at page 17, line 21
	Integer32, Counter32, Counter64, mib-2, transmission		Integer32, 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 "200302280000Z" -- February 28, 2003		LAST-UPDATED "200309190000Z" -- September 19, 2003
	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 32		skipping to change at page 18, line 21
	amended by IEEE Std 802.3ae-2002:		amended by IEEE Std 802.3ae-2002:
	'Amendment: Media Access Control (MAC)		'Amendment: Media Access Control (MAC)
	Parameters, Physical Layer, and Management		Parameters, Physical Layer, and Management
	Parameters for 10 Gb/s Operation', August,		Parameters for 10 Gb/s Operation', August,
	2002.		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'.
	Copyright (C) The Internet Society (2003). This		Copyright (C) The Internet Society (2003). This
	version of this MIB module is part of RFC XXXX;		version of this MIB module is part of RFC 3635;
	see the RFC itself for full legal notices."		see the RFC itself for full legal notices."
	-- RFC Ed.: Replace XXXX with the actual RFC number & remove
	-- this note
	REVISION "200302280000Z" -- February 28, 2003		REVISION "200309190000Z" -- September 19, 2003
	DESCRIPTION "Updated to include support for 10 Gb/sec		DESCRIPTION "Updated to include support for 10 Gb/sec
	interfaces. This resulted in the following		interfaces. This resulted in the following
	revisions:		revisions:
	- Updated dot3StatsAlignmentErrors and		- Updated dot3StatsAlignmentErrors and
	dot3StatsSymbolErrors DESCRIPTIONs to		dot3StatsSymbolErrors DESCRIPTIONs to
	reflect behaviour at 10 Gb/s		reflect behaviour at 10 Gb/s
	- Added dot3StatsRateControlAbility and		- Added dot3StatsRateControlAbility and
	dot3RateControlStatus for management		dot3RateControlStatus for management
	of the Rate Control function in 10 Gb/s		of the Rate Control function in 10 Gb/s
	skipping to change at page 19, line 21		skipping to change at page 19, line 10
	- Deprecated dot3Compliance and replaced		- Deprecated dot3Compliance and replaced
	it with dot3Compliance2, which includes		it with dot3Compliance2, which includes
	the compliance information for the new		the compliance information for the new
	object groups		object groups
	In addition, the dot3Tests and dot3Errors		In addition, the dot3Tests and dot3Errors
	object identities have been deprecated,		object identities have been deprecated,
	since there is no longer a standard method		since there is no longer a standard method
	for using them.		for using them.
	This version published as RFC XXXX."		This version published as RFC 3635."
	-- RFC Ed.: Replace XXXX with the actual RFC number & remove
	-- this note
	REVISION "199908240400Z" -- August 24, 1999		REVISION "199908240400Z" -- 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 "199806032150Z" -- June 3, 1998		REVISION "199806032150Z" -- June 3, 1998
	DESCRIPTION "Updated to include support for 100 Mb/sec		DESCRIPTION "Updated to include support for 100 Mb/sec
	interfaces.		interfaces.
	This version published as RFC 2358."		This version published as RFC 2358."
	skipping to change at page 49, line 24		skipping to change at page 49, line 7
	GROUP etherCollisionTableGroup		GROUP etherCollisionTableGroup
	DESCRIPTION "This group is optional. It is appropriate		DESCRIPTION "This group is optional. It is appropriate
	for all ethernet-like network interfaces		for all ethernet-like network interfaces
	which are capable of operating in		which are capable of operating in
	half-duplex mode and have the necessary		half-duplex mode and have the necessary
	metering. Implementation in systems with		metering. Implementation in systems with
	such interfaces is highly recommended."		such interfaces is highly recommended."
	::= { etherCompliances 3 }		::= { etherCompliances 3 }
	dot3Compliance2 MODULE-COMPLIANCE		dot3Compliance2 MODULE-COMPLIANCE
	STATUS current		STATUS current
	DESCRIPTION "The compliance statement for managed network		DESCRIPTION "The compliance statement for managed network
	entities which have ethernet-like network		entities which have ethernet-like network
	interfaces.		interfaces.
	Note that compliance with this MIB module		Note that compliance with this MIB module
	requires compliance with the ifCompliance3		requires compliance with the ifCompliance3
	MODULE-COMPLIANCE statement of the IF-MIB		MODULE-COMPLIANCE statement of the IF-MIB
	[RFC2863]. In addition, compliance with this		(RFC2863). In addition, compliance with this
	MIB module requires compliance with the		MIB module requires compliance with the
	mauModIfCompl3 MODULE-COMPLIANCE statement of		mauModIfCompl3 MODULE-COMPLIANCE statement of
	the MAU-MIB [MAU-MIB]."		the MAU-MIB (RFC3636)."
	MODULE -- this module		MODULE -- this module
	MANDATORY-GROUPS { etherStatsBaseGroup2 }		MANDATORY-GROUPS { etherStatsBaseGroup2 }
	GROUP etherDuplexGroup		GROUP etherDuplexGroup
	DESCRIPTION "This group is mandatory for all		DESCRIPTION "This group is mandatory for all
	ethernet-like network interfaces which are		ethernet-like network interfaces which are
	capable of operating in full-duplex mode.		capable of operating in full-duplex mode.
	It is highly recommended for all		It is highly recommended for all
	ethernet-like network interfaces."		ethernet-like network interfaces."
	skipping to change at page 55, line 37		skipping to change at page 55, line 24
	dot3StatsRateControlStatus		dot3StatsRateControlStatus
	}		}
	STATUS current		STATUS current
	DESCRIPTION "A collection of objects providing information		DESCRIPTION "A collection of objects providing information
	about the Rate Control function on ethernet-like		about the Rate Control function on ethernet-like
	interfaces."		interfaces."
	::= { etherGroups 15 }		::= { etherGroups 15 }
	END		END
	5. Intellectual Property		5. Intellectual Property Statement
	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 57, line 49		skipping to change at page 57, line 44
	2578, April 1999.		2578, April 1999.
	[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,		[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
	J., Rose, M. and S. Waldbusser, "Textual Conventions		J., Rose, M. and S. Waldbusser, "Textual Conventions
	for SMIv2", STD 58, RFC 2579, April 1999.		for SMIv2", STD 58, RFC 2579, April 1999.
	[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,		[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
	J., Rose, M. and S. Waldbusser, "Conformance Statements		J., Rose, M. and S. Waldbusser, "Conformance Statements
	for SMIv2", STD 58, RFC 2580, April 1999.		for SMIv2", STD 58, RFC 2580, April 1999.
			[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
			MIB using SMIv2", RFC 2863, June 2000.
	[IEEE802.3] IEEE, IEEE Std 802.3, 2002 Edition: "Carrier Sense		[IEEE802.3] IEEE, IEEE Std 802.3, 2002 Edition: "Carrier Sense
	Multiple Access with Collision Detection (CSMA/CD)		Multiple Access with Collision Detection (CSMA/CD)
	Access Method and Physical Layer Specifications",		Access Method and Physical Layer Specifications", March
	March 2002.		2002.
	[IEEE802.3ae] IEEE, IEEE Std 802.3ae-2002, "Amendment: Media
	Access Control (MAC) Parameters, Physical Layers,
	and Management Parameters for 10 Gb/s Operation",
	August, 2002.
	[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces		[IEEE802.3ae] IEEE, IEEE Std 802.3ae-2002, "Amendment: Media Access
	Group MIB using SMIv2", RFC 2863, June 2000.		Control (MAC) Parameters, Physical Layers, and
			Management Parameters for 10 Gb/s Operation", August,
			2002.
	[MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE		[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE
	802.3 Medium Attachment Units (MAUs) using SMIv2", work		802.3 Medium Attachment Units (MAUs) using SMIv2", RFC
	in progress, draft-ietf-hubmib-mau-mib-v3-03.txt,		3636, September 2003.
	March 2003.
	8. Informative References		8. Informative References
	[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,		[RFC1212] Rose, M. and K. McCloghrie, Editors, "Concise MIB
	"Introduction and Applicability Statements for		Definitions", STD 16, RFC 1212, March 1991.
	Internet-Standard Network Management Framework",
	RFC 3410, December 2002.
	[KASTEN] Kastenholz, F., "IEEE 802.3 Layer Management Draft		[RFC1213] McCloghrie, K. and M. Rose, Editors, "Management
	compatible MIB for TCP/IP Networks", electronic mail		Information Base for Network Management of TCP/IP-based
	message to mib-wg@nnsc.nsf.net, 9 June 1989.		internets: MIB-II", STD 17, RFC 1213, March 1991.
	[RFC1284] Cook, J., "Definitions of Managed Objects for		[RFC1284] Cook, J., "Definitions of Managed Objects for
	Ethernet-Like Interface Types", RFC 1284, December 1991.		Ethernet-Like Interface Types", RFC 1284, December
			1991.
	[RFC1369] Kastenholz, F., "Implementation Notes and Experience for		[RFC1369] Kastenholz, F., "Implementation Notes and Experience
	The Internet Ethernet MIB", RFC 1369, October 1992.		for The Internet Ethernet MIB", RFC 1369, October 1992.
	[RFC1398] Kastenholz, F., "Definitions of Managed Objects for the		[RFC1398] Kastenholz, F., "Definitions of Managed Objects for the
	Ethernet-like Interface Types", RFC 1398, January 1993.		Ethernet-like Interface Types", RFC 1398, January 1993.
	[RFC1643] Kastenholz, F., "Definitions of Managed Objects for the		[RFC1643] Kastenholz, F., "Definitions of Managed Objects for the
	Ethernet-like Interface Types", STD 50, RFC 1643, July		Ethernet-like Interface Types", STD 50, RFC 1643, July
	1994.		1994.
	[RFC1650] Kastenholz, F., "Definitions of Managed Objects for the		[RFC1650] Kastenholz, F., "Definitions of Managed Objects for the
	Ethernet-like Interface Types using SMIv2", RFC 1650,		Ethernet-like Interface Types using SMIv2", RFC 1650,
	August 1994.		August 1994.
	[RFC2358] Flick, J. and J. Johnson, "Definitions of Managed		[RFC2358] Flick, J. and J. Johnson, "Definitions of Managed
	Objects for the Ethernet-like Interface Types", RFC		Objects for the Ethernet-like Interface Types", RFC
	2358, June 1998.		2358, June 1998.
	[RFC2665] Flick, J., and J. Johnson, "Definitions of Managed		[RFC2665] Flick, J. and J. Johnson, "Definitions of Managed
	Objects for the Ethernet-like Interface Types", RFC		Objects for the Ethernet-like Interface Types", RFC
	2665, August 1999.		2665, August 1999.
	[RFC1213] McCloghrie, K. and M. Rose, Editors, "Management		[RFC2666] Flick, J., "Definitions of Object Identifiers for
	Information Base for Network Management of TCP/IP-based		Identifying Ethernet Chip Sets", RFC 2666, August 1999.
	internets: MIB-II", STD 17, RFC 1213, March 1991.
	[RFC2666] Flick, J., "Definitions of Object Identifiers for		[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
	Identifying Ethernet Chip Sets", RFC 2666, August 1999.		"Introduction and Applicability Statements for
			Internet-Standard Network Management Framework", RFC
			3410, December 2002.
	[ETHERWIS] Heard, C. M., "Definitions of Managed Objects for the		[CASE] Case, J., and C. Partridge, "Case Diagrams: A First
	Ethernet WAN Interface Sublayer", work in progress,		Step to Diagrammed Management Information Bases",
	draft-ietf-hubmib-wis-mib-06.txt, January 2003.		Computer Communications Review, 19(1):13-16, January
			1989.
	[CASE] Case, J., and C. Partridge, "Case Diagrams: A First Step		[RFC3637] Heard, C., "Definitions of Managed Objects for the
	to Diagrammed Management Information Bases", Computer		Ethernet WAN Interface Sublayer", RFC 3637, September
	Communications Review, 19(1):13-16, January 1989.		2003.
			[KASTEN] Kastenholz, F., "IEEE 802.3 Layer Management Draft
			compatible MIB for TCP/IP Networks", electronic mail
			message to mib-wg@nnsc.nsf.net, 9 June 1989.
	9. Security Considerations		9. Security Considerations
	There is one management object defined in this MIB that has a MAX-		There is one management object defined in this MIB that has a MAX-
	ACCESS clause of read-write. That object, dot3PauseAdminMode, may be		ACCESS clause of read-write. That object, dot3PauseAdminMode, may be
	used to change the flow control configuration on a network interface,		used to change the flow control configuration on a network interface,
	which may result in dropped packets, or sending flow control packets		which may result in dropped packets, or sending flow control packets
	on links where the link partner will not understand them. Either		on links where the link partner will not understand them. Either
	action could be detrimental to network performance.		action could be detrimental to network performance.
	skipping to change at page 60, line 33		skipping to change at page 60, line 35
	the objects only to those principals (users) that have legitimate		the objects only to those principals (users) that have legitimate
	rights to indeed GET or SET (change/create/delete) them.		rights to indeed GET or SET (change/create/delete) them.
	10. IANA Considerations		10. IANA Considerations
	This document does not define any new name space to be administered		This document does not define any new name space to be administered
	by IANA. However, section 3.2.4 does specify that some of the		by IANA. However, section 3.2.4 does specify that some of the
	defined values in a current IANA-maintained name space are to be		defined values in a current IANA-maintained name space are to be
	marked as deprecated or obsolete. In particular, the following		marked as deprecated or obsolete. In particular, the following
	enumerated values in the IANAifType TEXTUAL-CONVENTION in the		enumerated values in the IANAifType TEXTUAL-CONVENTION in the
	IANAifType-MIB module need to have an ASN.1 comment added stating		IANAifType-MIB module have had an ASN.1 comment added by IANA stating
	that they have been deprecated:		that they have been deprecated:
	- iso88032Csmacd(7)		- iso88032Csmacd(7)
	- starLan(11)		- starLan(11)
	In addition, the following enumerated values need to have an ASN.1		In addition, the following enumerated values have had an ASN.1
	comment added stating that they are obsolete:		comment added by IANA stating that they are obsolete:
	- fastEther(62)		- fastEther(62)
	- fastEtherFX(69)		- fastEtherFX(69)
	- gigabitEthernet(117)		- gigabitEthernet(117)
	In all of the above cases, the ASN.1 comment should indicate that		In all of the above cases, the ASN.1 comment indicates that
	ethernetCsmacd(6) should be used instead of these values.		ethernetCsmacd(6) should be used instead of these values.
	11. Author's Address
	John Flick
	Hewlett-Packard Company
	8000 Foothills Blvd. M/S 5557
	Roseville, CA 95747-5557
	Phone: +1 916 785 4018
	Email: johnf@rose.hp.com
	A. Change Log		A. Change Log
	A.1. Changes since RFC 2665		A.1. Changes since RFC 2665
	This section enumerates changes made to RFC 2665 to produce this		This section enumerates changes made to RFC 2665 to produce this
	document.		document.
	(1) Updated references to the IEEE 802.3 standard to		(1) Updated references to the IEEE 802.3 standard to
	refer to the 2002 edition.		refer to the 2002 edition.
	skipping to change at page 63, line 49		skipping to change at page 63, line 38
	to this MIB and the Interfaces MIB has been added.		to this MIB and the Interfaces MIB has been added.
	(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		Author's Address
	Copyright (C) The Internet Society (2002). All Rights Reserved.
			John Flick
			Hewlett-Packard Company
			8000 Foothills Blvd. M/S 5557
			Roseville, CA 95747-5557
			Phone: +1 916 785 4018
			EMail: johnf@rose.hp.com
			Full Copyright Statement
			Copyright (C) The Internet Society (2003). 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		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
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 59 change blocks.
	233 lines changed or deleted		215 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/