draft-ietf-hubmib-wis-mib-07.txt		rfc3637.txt
	Ethernet Interfaces and Hub MIB Working Group C. M. Heard, Editor		Network Working Group C.M. Heard, Ed.
	INTERNET DRAFT Consultant		Request for Comments: 3637 Consultant
	March 17, 2003		Category: Standards Track September 2003
	Definitions of Managed Objects		Definitions of Managed Objects
	for the Ethernet WAN Interface Sublayer		for the Ethernet WAN Interface Sublayer
	<draft-ietf-hubmib-wis-mib-07.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-Drafts are working		Internet community, and requests discussion and suggestions for
	documents of the Internet Engineering Task Force (IETF), its areas,		improvements. Please refer to the current edition of the "Internet
	and its working groups. Note that other groups may also distribute		Official Protocol Standards" (STD 1) for the standardization state
	working documents as Internet-Drafts.		and status of this protocol. Distribution of this memo is unlimited.
	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 document defines a portion of the Management Information Base		This document defines a portion of the Management Information Base
	(MIB) for use with network management protocols in TCP/IP based		(MIB) for use with network management protocols in TCP/IP based
	internets. In particular, it defines objects for managing the		internets. In particular, it defines objects for managing the
	Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).		Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).
	The MIB module defined in this memo is an extension of the SONET/SDH		The MIB module defined in this memo is an extension of the
			Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
	Interface MIB and is implemented in conjunction with it and with the		Interface MIB and is implemented in conjunction with it and with the
	Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB,		Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB,
	the Interfaces Group MIB, and the Inverted Stack Table MIB.		the Interfaces Group MIB, and the Inverted Stack Table MIB.
	Table of Contents		Table of Contents
	1 Conventions ............................................... 3		1. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2 The Internet-Standard Management Framework ................ 3		2. The Internet-Standard Management Framework . . . . . . . . . . 2
	3 Overview .................................................. 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1 Relationship to the SONET/SDH Interface MIB ............. 4		3.1. Relationship to the SONET/SDH Interface MIB. . . . . . . 3
	3.2 Relationship to the Ethernet-like Interface MIB ......... 4		3.2. Relationship to the Ethernet-like Interface MIB. . . . . 4
	3.3 Relationship to the 802.3 MAU MIB ....................... 5		3.3. Relationship to the 802.3 MAU MIB. . . . . . . . . . . . 4
	3.4 Use of the ifTable ...................................... 5		3.4. Use of the ifTable . . . . . . . . . . . . . . . . . . . 4
	3.4.1 Layering Model ........................................ 5		3.4.1. Layering Model . . . . . . . . . . . . . . . . . 5
	3.4.2 Use of ifTable for LLC Layer/MAC		3.4.2. Use of ifTable for LLC Layer/MAC Layer
	Layer/Reconciliation Sublayer/Physical Coding		Reconciliation Sublayer/Physical Coding Sublayer 5
	Sublayer ............................................... 6		3.4.3. Use of ifTable for SONET/SDH Path Layer. . . . . 5
	3.4.3 Use of ifTable for SONET/SDH Path Layer ............... 6		3.4.4. Use of ifTable for SONET/SDH Medium/Section/
	3.4.4 Use of ifTable for SONET/SDH Medium/Section/Line		Line Layer . . . . . . . . . . . . . . . . . . . 5
	Layer .................................................. 6
	3.5 SONET/SDH Terminology ................................... 6		3.5. SONET/SDH Terminology. . . . . . . . . . . . . . . . . . 6
	3.6 Mapping of IEEE 802.3 Managed Objects ................... 7		3.6. Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 7
	3.7 Mapping of SNMP Objects to WIS Station Management		3.7. Mapping of SNMP Objects to WIS Station Management
	Registers .............................................. 12		Registers. . . . . . . . . . . . . . . . . . . . . . . . 12
	3.8 Structure of the MIB Module ............................. 14		3.8. Structure of the MIB Module . . . . . . . . . . . . . . 14
	3.8.1 etherWisDeviceTable ................................... 14		3.8.1. etherWisDeviceTable. . . . . . . . . . . . . . . 14
	3.8.2 etherWisSectionCurrentTable ........................... 15		3.8.2. etherWisSectionCurrentTable. . . . . . . . . . . 15
	3.8.3 etherWisPathCurrentTable .............................. 15		3.8.3. etherWisPathCurrentTable . . . . . . . . . . . . 15
	3.8.4 etherWisFarEndPathCurrentTable ........................ 15		3.8.4. etherWisFarEndPathCurrentTable . . . . . . . . . 15
	4 Object Definitions ........................................ 16		4. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 16
	5 Intellectual Property ..................................... 30		5. Intellectual Property Statement. . . . . . . . . . . . . . . . 30
	6 Acknowledgments ........................................... 30		6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 30
	7 Security Considerations ................................... 31		7. Security Considerations. . . . . . . . . . . . . . . . . . . . 31
	8 References ................................................ 32		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	8.1 Normative References .................................... 32		8.1. Normative References . . . . . . . . . . . . . . . . . . 32
	8.2 Informative References .................................. 33		8.2. Informative References . . . . . . . . . . . . . . . . . 33
	9 Contributors .............................................. 33		Appendix A: Collection of Performance Data Using WIS
	10 Editor's Address ......................................... 34		MDIO Registers . . . . . . . . . . . . . . . . . . . . . . . . 34
	Appendix A: Collection of Performance Data Using WIS		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	MDIO Registers ......................................... 35		Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Full Copyright Statement ................................... 36		Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 37
	1. Conventions		1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL", when they appear in this document, are to be interpreted		"OPTIONAL", when they appear in this document, are to be interpreted
	as described in RFC 2119 [RFC2119].		as described in BCP 14, RFC 2119 [RFC2119].
	2. The Internet-Standard Management Framework		2. The Internet-Standard Management Framework
	For a detailed overview of the documents that describe the current		For a detailed overview of the documents that describe the current
	Internet-Standard Management Framework, please refer to section 7 of		Internet-Standard Management Framework, please refer to section 7 of
	RFC 3410 [RFC3410].		RFC 3410 [RFC3410].
	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. MIB objects are generally		the Management Information Base or MIB. MIB objects are generally
	accessed through the Simple Network Management Protocol (SNMP).		accessed through the Simple Network Management Protocol (SNMP).
	Objects in the MIB are defined using the mechanisms defined in the		Objects in the MIB are defined using the mechanisms defined in the
	Structure of Management Information (SMI). This memo specifies a MIB		Structure of Management Information (SMI). This memo specifies a MIB
	module that is compliant to the SMIv2, which is described in STD 58,		module that is compliant to the SMIv2, which is described in STD 58,
	RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580		RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
	[RFC2580].		[RFC2580].
	3. Overview		3. Overview
	The objects defined in this memo are used in conjunction with objects		The objects defined in this memo are used in conjunction with objects
	defined in the Interfaces Group MIB [RFC2863], the SONET/SDH		defined in the Interfaces Group MIB [RFC2863], the SONET/SDH
	Interface MIB [SONETng], and the 802.3 MAU MIB [MAU-MIB] to manage		Interface MIB [RFC3592], and the 802.3 MAU MIB [RFC3636] to manage
	the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS) defined		the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS) defined
	in [802.3ae]. The WIS contains functions to perform OC-192c/VC-4-64c		in [802.3ae]. The WIS contains functions to perform OC-192c/VC-4-64c
	framing and scrambling. It resides between the Physical Coding		framing and scrambling. It resides between the Physical Coding
	Sublayer (PCS) and the Physical Medium Attachment (PMA) sublayer		Sublayer (PCS) and the Physical Medium Attachment (PMA) sublayer
	within a 10GBASE-W 10 Gb/s WAN-compatible physical layer device (PHY)		within a 10GBASE-W 10 Gb/s WAN-compatible physical layer device (PHY)
	and may be used in conjunction with any of the PCS, PMA, and Physical		and may be used in conjunction with any of the PCS, PMA, and Physical
	Medium Dependent (PMD) sublayers defined in [802.3ae] for 10GBASE-W		Medium Dependent (PMD) sublayers defined in [802.3ae] for 10GBASE-W
	PHYs. Three types of 10GBASE-W PHYs are defined, distinguished by		PHYs. Three types of 10GBASE-W PHYs are defined, distinguished by
	the type of optics employed: 10GBASE-SW, 10GBASE-LW, and 10GBASE-EW.		the type of optics employed: 10GBASE-SW, 10GBASE-LW, and 10GBASE-EW.
	The objects defined in this memo may be used to manage an Ethernet		The objects defined in this memo may be used to manage an Ethernet
	skipping to change at page 4, line 15		skipping to change at page 3, line 42
	provide approximate representations of the optional attributes (i.e.,		provide approximate representations of the optional attributes (i.e.,
	the members of the pWISOptional package). Some objects with no		the members of the pWISOptional package). Some objects with no
	analogues in oWIS are defined to support WIS testing features		analogues in oWIS are defined to support WIS testing features
	required by Clause 50 of [802.3ae].		required by Clause 50 of [802.3ae].
	3.1. Relationship to the SONET/SDH Interface MIB		3.1. Relationship to the SONET/SDH Interface MIB
	Since the Ethernet WAN Interface Sublayer was designed to be SONET-		Since the Ethernet WAN Interface Sublayer was designed to be SONET-
	compatible, information similar to that provided by most of the		compatible, information similar to that provided by most of the
	members of the oWIS managed object class is available from objects		members of the oWIS managed object class is available from objects
	defined in the SONET-MIB [SONETng]. Thus, the MIB module defined in		defined in the SONET-MIB [RFC3592]. Thus, the MIB module defined in
	this memo is a sparse augmentation of the SONET-MIB -- in other		this memo is a sparse augmentation of the SONET-MIB -- in other
	words, every table defined here is an extension of some table in the		words, every table defined here is an extension of some table in the
	SONET-MIB -- and its compliance statement REQUIRES that an agent		SONET-MIB -- and its compliance statement REQUIRES that an agent
	implementing the objects defined in this memo also implement the		implementing the objects defined in this memo also implement the
	relevant SONET-MIB objects. That includes all objects required by		relevant SONET-MIB objects. That includes all objects required by
	sonetCompliance2 as well as some that it leaves optional.		sonetCompliance2 as well as some that it leaves optional.
	It should be noted that some of the objects incorporated by reference		It should be noted that some of the objects incorporated by reference
	from the SONET-MIB -- specifically, the threshold objects and		from the SONET-MIB -- specifically, the threshold objects and
	interval counter objects -- provide only approximate representations		interval counter objects -- provide only approximate representations
	skipping to change at page 5, line 8		skipping to change at page 4, line 24
	3.2. Relationship to the Ethernet-like Interface MIB		3.2. Relationship to the Ethernet-like Interface MIB
	An interface which includes the Ethernet WIS is, by definition, an		An interface which includes the Ethernet WIS is, by definition, an
	Ethernet-like interface, and an agent implementing the objects		Ethernet-like interface, and an agent implementing the objects
	defined in this memo MUST implement the objects required by the		defined in this memo MUST implement the objects required by the
	dot3Compliance2 compliance statement in the EtherLike-MIB.		dot3Compliance2 compliance statement in the EtherLike-MIB.
	3.3. Relationship to the 802.3 MAU MIB		3.3. Relationship 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 all Ethernet-like interfaces. The MAU-MIB		[RFC3636] is REQUIRED for all Ethernet-like interfaces. The MAU-MIB
	is needed in order to allow applications to control and/or determine		is needed in order to allow applications to control and/or determine
	the media type in use. That is important for devices than can		the media type in use. That is important for devices than can
	support both the 10GBASE-R 10 Gb/s LAN format (which does not include		support both the 10GBASE-R 10 Gb/s LAN format (which does not include
	the WIS) and the 10GBASE-W 10 Gb/s WAN format (which does include the		the WIS) and the 10GBASE-W 10 Gb/s WAN format (which does include the
	WIS). The MAU-MIB also provides the means to put a device in standby		WIS). The MAU-MIB also provides the means to put a device in standby
	mode or to reset it; the latter may be used to re-initialize the		mode or to reset it; the latter may be used to re-initialize the
	WIS.		WIS.
	3.4. Use of the ifTable		3.4. Use of the ifTable
	This section specifies how the ifTable, as defined in [RFC2863], is		This section specifies how the ifTable, as defined in [RFC2863], is
	used for the Ethernet WIS application.		used for the Ethernet WIS application.
	3.4.1. Layering Model		3.4.1. Layering Model
	Ethernet interfaces that employ the WIS are layered as defined in		Ethernet interfaces that employ the WIS are layered as defined in
	[802.3ae]. The corresponding use of the ifTable [RFC2863] is shown		[802.3ae]. The corresponding use of the ifTable [RFC2863] is shown
	in the figure below.		in the figure below.
	_____________________________ _		_____________________________ _
	| LLC Layer | |		| LLC Layer | |
	+-----------------------------+ |		+-----------------------------+ |
	| MAC Layer | |		| MAC Layer | |
	+-----------------------------+ > 1 ifEntry		+-----------------------------+ > 1 ifEntry
	| Reconciliation Sublayer | | ifType: ethernetCsmacd(6)		| Reconciliation Sublayer | | ifType: ethernetCsmacd(6)
	+-----------------------------+ |		+-----------------------------+ |
	| Physical Coding Sublayer | |		| Physical Coding Sublayer | |
	+-----------------------------+ +		+-----------------------------+ +
	| Path Layer | > 1 ifEntry		| Path Layer | > 1 ifEntry
	+-----------------------------+ + ifType: sonetPath(50)		+-----------------------------+ + ifType: sonetPath(50)
	| Line Layer | |		| Line Layer | |
	+-----------------------------+ |		+-----------------------------+ |
	| Section Layer | > 1 ifEntry		| Section Layer | > 1 ifEntry
	+-----------------------------+ | ifType: sonet(39)		+-----------------------------+ | ifType: sonet(39)
	| Physical Medium Layer | |		| Physical Medium Layer | |
	----------------------------- -		----------------------------- -
	Figure 1 - Use of ifTable for an Ethernet WIS port		Figure 1 - Use of ifTable for an Ethernet WIS port
	The exact configuration and multiplexing of the layers is maintained		The exact configuration and multiplexing of the layers is maintained
	in the ifStackTable [RFC2863] and in the ifInvStackTable [RFC2864].		in the ifStackTable [RFC2863] and in the ifInvStackTable [RFC2864].
	3.4.2. Use of ifTable for LLC Layer/MAC Layer/Reconciliation		3.4.2. Use of ifTable for LLC Layer/MAC Layer/Reconciliation
	Sublayer/Physical Coding Sublayer		Sublayer/Physical Coding Sublayer
	The ifTable MUST be used as specified in [ETHERIF] and [MAU-MIB] for		The ifTable MUST be used as specified in [RFC3635] and [RFC3636] for
	the LLC Layer/MAC Layer/Reconciliation Sublayer/Physical Coding		the LLC Layer/MAC Layer/Reconciliation Sublayer/Physical Coding
	Sublayer.		Sublayer.
	3.4.3. Use of ifTable for SONET/SDH Path Layer		3.4.3. Use of ifTable for SONET/SDH Path Layer
	The ifTable MUST be used as specified in [SONETng] for the SONET/SDH		The ifTable MUST be used as specified in [RFC3592] for the SONET/SDH
	Path Layer. The value of ifHighSpeed is set to 9585. ifSpeed		Path Layer. The value of ifHighSpeed is set to 9585. ifSpeed
	reports a value of 4294967295.		reports a value of 4294967295.
	3.4.4. Use of ifTable for SONET/SDH Medium/Section/Line Layer		3.4.4. Use of ifTable for SONET/SDH Medium/Section/Line Layer
	The ifTable MUST be used as specified in [SONETng] for the SONET/SDH		The ifTable MUST be used as specified in [RFC3592] for the SONET/SDH
	Medium/Section/Line Layer. The value of ifHighSpeed is set to 9953.		Medium/Section/Line Layer. The value of ifHighSpeed is set to 9953.
	ifSpeed reports a value of 4294967295.		ifSpeed reports a value of 4294967295.
	3.5. SONET/SDH Terminology		3.5. SONET/SDH Terminology
	The SONET/SDH terminology used in [802.3ae] is mostly the same as in		The SONET/SDH terminology used in [802.3ae] is mostly the same as in
	[SONETng], but there are a few differences. In those cases the		[RFC3592], but there are a few differences. In those cases the
	definitions in [802.3ae] take precedence. The specific differences		definitions in [802.3ae] take precedence. The specific differences
	are as follows.		are as follows.
	Unequipped		Unequipped
	This defect is not defined by [802.3ae]. An implementation that		This defect is not defined by [802.3ae]. An implementation that
	supports it SHOULD report it by setting the sonetPathUnequipped		supports it SHOULD report it by setting the sonetPathUnequipped
	bit in the appropriate instance of sonetPathCurrentStatus.		bit in the appropriate instance of sonetPathCurrentStatus.
	Signal Label Mismatch		Signal Label Mismatch
	This defect is called Payload Label Mismatch (PLM) in [802.3ae].		This defect is called Payload Label Mismatch (PLM) in [802.3ae].
	It is reported by setting both the sonetPathSignalLabelMismatch		It is reported by setting both the sonetPathSignalLabelMismatch
	bit in the appropriate instance of sonetPathCurrentStatus		bit in the appropriate instance of sonetPathCurrentStatus
	(defined in [SONETng]) and the etherWisPathPLM bit in the		(defined in [RFC3592]) and the etherWisPathPLM bit in the
	corresponding instance of etherWisPathCurrentStatus (defined		corresponding instance of etherWisPathCurrentStatus (defined
	below).		below).
	Loss of Codegroup Delineation		Loss of Codegroup Delineation
	[802.3ae] defines Loss of Codegroup Delineation (LCD) as		[802.3ae] defines Loss of Codegroup Delineation (LCD) as
	occurring when the Physical Coding Sublayer is unable to locate		occurring when the Physical Coding Sublayer is unable to locate
	64B/66B code group boundaries. There is no analogous defect		64B/66B code group boundaries. There is no analogous defect
	defined in [SONETng]. It is reported by setting the		defined in [RFC3592]. It is reported by setting the
	etherWisPathLCD bit in the appropriate instance of the object		etherWisPathLCD bit in the appropriate instance of the object
	etherWisPathCurrentStatus defined below.		etherWisPathCurrentStatus defined below.
	STS-Path Remote Defect Indication		STS-Path Remote Defect Indication
	[802.3ae] mandates the use of ERDI-P (Enhanced Remote Defect		[802.3ae] mandates the use of ERDI-P (Enhanced Remote Defect
	Indication - Path) defined in [T1.231] to signal remote server		Indication - Path) defined in [T1.231] to signal remote server
	defects (triggered by path AIS or path LOP) and remote payload		defects (triggered by path AIS or path LOP) and remote payload
	defects (triggered by Payload Label Mismatch or Loss of Codegroup		defects (triggered by Payload Label Mismatch or Loss of Codegroup
	Delineation). [SONETng] defines the one-bit RDI-P (Remote Defect		Delineation). [RFC3592] defines the one-bit RDI-P (Remote Defect
	Indication - Path), which signals remote server detects (i.e.,		Indication - Path), which signals remote server detects (i.e.,
	path AIS and path LOP) only. An implementation of the MIB module		path AIS and path LOP) only. An implementation of the MIB module
	defined in this memo MUST set the sonetPathSTSRDI bit in the		defined in this memo MUST set the sonetPathSTSRDI bit in the
	appropriate instance of sonetPathCurrentStatus when it receives		appropriate instance of sonetPathCurrentStatus when it receives
	an ERDI-P server defect indication from the remote end. Both		an ERDI-P server defect indication from the remote end. Both
	ERDI-P payload defects and ERDI-P server defects are reported in		ERDI-P payload defects and ERDI-P server defects are reported in
	the object etherWisFarEndPathCurrentStatus defined below.		the object etherWisFarEndPathCurrentStatus defined below.
	Path Coding Violations		Path Coding Violations
	In [802.3ae] the path layer CV count is based on block errors and		In [802.3ae] the path layer CV count is based on block errors and
	skipping to change at page 7, line 32		skipping to change at page 7, line 18
	byte that indicates incorrect parity, regardless of the number of		byte that indicates incorrect parity, regardless of the number of
	bits in error. Note that Section 8.4.5.1 of [T1.231] allows		bits in error. Note that Section 8.4.5.1 of [T1.231] allows
	either path BIP-8 errors or path block errors to be used for the		either path BIP-8 errors or path block errors to be used for the
	path layer error count.		path layer error count.
	3.6. Mapping of IEEE 802.3 Managed Objects		3.6. Mapping of IEEE 802.3 Managed Objects
	This section contains the mapping between oWIS managed objects		This section contains the mapping between oWIS managed objects
	defined in [802.3ae] and managed objects defined in this document and		defined in [802.3ae] and managed objects defined in this document and
	in associated MIB modules, i.e., the IF-MIB [RFC2863], the SONET-MIB		in associated MIB modules, i.e., the IF-MIB [RFC2863], the SONET-MIB
	[SONETng], and the MAU-MIB [MAU-MIB].		[RFC3592], and the MAU-MIB [RFC3636].
	IEEE 802.3 Managed Object Corresponding SNMP Object		IEEE 802.3 Managed Object Corresponding SNMP Object
	oWIS - pWISBasic package		oWIS - pWISBasic package
	aWISID IF-MIB - ifIndex		aWISID IF-MIB - ifIndex
	aSectionStatus SONET-MIB - sonetSectionCurrentStatus		aSectionStatus SONET-MIB - sonetSectionCurrentStatus
	aLineStatus SONET-MIB - sonetLineCurrentStatus		aLineStatus SONET-MIB - sonetLineCurrentStatus
	aPathStatus etherWisPathCurrentStatus		aPathStatus etherWisPathCurrentStatus
	aFarEndPathStatus etherWisFarEndPathCurrentStatus		aFarEndPathStatus etherWisFarEndPathCurrentStatus
	oWIS - pWISOptional package		oWIS - pWISOptional package
	aSectionSESThreshold SONET-MIB - sonetSESthresholdSet		aSectionSESThreshold SONET-MIB - sonetSESthresholdSet
	aSectionSESs SONET-MIB - sonetSectionCurrentSESs +		aSectionSESs SONET-MIB - sonetSectionCurrentSESs +
	sonetSectionIntervalSESs		sonetSectionIntervalSESs
	aSectionESs SONET-MIB - sonetSectionCurrentESs +		aSectionESs SONET-MIB - sonetSectionCurrentESs +
	sonetSectionIntervalESs		sonetSectionIntervalESs
	aSectionSEFSs SONET-MIB - sonetSectionCurrentSEFSs +		aSectionSEFSs SONET-MIB - sonetSectionCurrentSEFSs +
	sonetSectionIntervalSEFSs		sonetSectionIntervalSEFSs
	aSectionCVs SONET-MIB - sonetSectionCurrentCVs +		aSectionCVs SONET-MIB - sonetSectionCurrentCVs +
	sonetSectionIntervalCVs		sonetSectionIntervalCVs
	aJ0ValueTX etherWisSectionCurrentJ0Transmitted		aJ0ValueTX etherWisSectionCurrentJ0Transmitted
	aJ0ValueRX etherWisSectionCurrentJ0Received		aJ0ValueRX etherWisSectionCurrentJ0Received
	aLineSESThreshold SONET-MIB - sonetSESthresholdSet		aLineSESThreshold SONET-MIB - sonetSESthresholdSet
	aLineSESs SONET-MIB - sonetLineCurrentSESs +		aLineSESs SONET-MIB - sonetLineCurrentSESs +
	sonetLineIntervalSESs		sonetLineIntervalSESs
	aLineESs SONET-MIB - sonetLineCurrentESs +		aLineESs SONET-MIB - sonetLineCurrentESs +
	sonetLineIntervalESs		sonetLineIntervalESs
	aLineCVs SONET-MIB - sonetLineCurrentCVs +		aLineCVs SONET-MIB - sonetLineCurrentCVs +
	sonetLineIntervalCVs		sonetLineIntervalCVs
	aFarEndLineSESs SONET-MIB - sonetFarEndLineCurrentSESs +		aFarEndLineSESs SONET-MIB - sonetFarEndLineCurrentSESs +
	skipping to change at page 8, line 42		skipping to change at page 8, line 27
	sonetFarEndPathIntervalESs		sonetFarEndPathIntervalESs
	aFarEndPathCVs SONET-MIB - sonetFarEndPathCurrentCVs +		aFarEndPathCVs SONET-MIB - sonetFarEndPathCurrentCVs +
	sonetFarEndPathIntervalCVs		sonetFarEndPathIntervalCVs
	It should be noted that the threshold and counter objects imported		It should be noted that the threshold and counter objects imported
	from the SONET-MIB are not completely equivalent to the corresponding		from the SONET-MIB are not completely equivalent to the corresponding
	IEEE 802.3 objects. The specific differences are as follows:		IEEE 802.3 objects. The specific differences are as follows:
	IEEE 802.3 Managed Object How Corresponding SNMP Object Differs		IEEE 802.3 Managed Object How Corresponding SNMP Object Differs
	aSectionSESThreshold This object is defined in [802.3ae]		aSectionSESThreshold This object is defined in [802.3ae] as an
	as an integer with one instance per		integer with one instance per interface.
	interface. sonetSESthresholdSet		sonetSESthresholdSet is an enumerated value
	is an enumerated value that has one		that has one instance per network element;
	instance per network element; it		it controls the thresholds for all layers
	controls the thresholds for all layers		simultaneously and allows only certain
	simultaneously and allows only certain		discrete values to be selected.
	discrete values to be selected.
	aSectionSESs This object is defined in [802.3ae] as		aSectionSESs This object is defined in [802.3ae] as a
	a generalized nonresetable counter.		generalized nonresetable counter. The
	The objects sonetSectionCurrentSESs and		objects sonetSectionCurrentSESs and
	sonetSectionIntervalSESs are 15-minute		sonetSectionIntervalSESs are 15-minute
	interval counters.		interval counters.
	aSectionESs This object is defined as a generalized
	nonresetable counter in [802.3ae].		aSectionESs This object is defined as a generalized
	The objects sonetSectionCurrentESs and		nonresetable counter in [802.3ae]. The
	sonetSectionIntervalESs are 15-minute		objects sonetSectionCurrentESs and
	interval counters.		sonetSectionIntervalESs are 15-minute
	aSectionSEFSs This object is defined as a generalized		interval counters.
	nonresetable counter in [802.3ae].
	The objects sonetSectionCurrentSEFSs and		aSectionSEFSs This object is defined as a generalized
	sonetSectionIntervalSEFSs are 15-minute		nonresetable counter in [802.3ae]. The
	interval counters.		objects sonetSectionCurrentSEFSs and
	aSectionCVs This object is defined as a generalized		sonetSectionIntervalSEFSs are 15-minute
	nonresetable counter in [802.3ae], and		interval counters.
	it is not subject to inhibiting. The
	objects sonetSectionCurrentCVs and		aSectionCVs This object is defined as a generalized
	sonetSectionIntervalCVs are 15-minute		nonresetable counter in [802.3ae], and it
	interval counters, and they are		is not subject to inhibiting. The objects
	inhibited (not incremented) during		sonetSectionCurrentCVs and
	one-second intervals that qualify as		sonetSectionIntervalCVs are 15-minute
	severely errored seconds.		interval counters, and they are inhibited
	aLineSESThreshold This object is defined in [802.3ae]		(not incremented) during one-second
	as an integer with one instance per		intervals that qualify as severely errored
	interface. sonetSESthresholdSet		seconds.
	is an enumerated value that has one
	instance per network element; it		aLineSESThreshold This object is defined in [802.3ae] as an
	controls the thresholds for all layers		integer with one instance per interface.
	simultaneously and allows only certain		sonetSESthresholdSet is an enumerated value
	discrete values to be selected.		that has one instance per network element;
	aLineSESs This object is defined as a generalized		it controls the thresholds for all layers
	nonresetable counter in [802.3ae], and		simultaneously and allows only certain
	it is not subject to inhibiting. The		discrete values to be selected.
	objects sonetLineCurrentSESs and
	sonetLineIntervalSESs are 15-minute		aLineSESs This object is defined as a generalized
	interval counters, and they are		nonresetable counter in [802.3ae], and it
	inhibited (not incremented) during		is not subject to inhibiting. The objects
	one-second intervals that qualify as		sonetLineCurrentSESs and
	unavailable seconds.		sonetLineIntervalSESs are 15-minute
	aLineESs This object is defined as a generalized		interval counters, and they are inhibited
	nonresetable counter in [802.3ae], and		(not incremented) during one-second
	it is not subject to inhibiting. The		intervals that qualify as unavailable
	objects sonetLineCurrentESs and		seconds.
	sonetLineIntervalESs are 15-minute
	interval counters, and they are		aLineESs This object is defined as a generalized
	inhibited (not incremented) during		nonresetable counter in [802.3ae], and it
	one-second intervals that qualify as		is not subject to inhibiting. The objects
	unavailable seconds.		sonetLineCurrentESs and
	aLineCVs This object is defined as a generalized		sonetLineIntervalESs are 15-minute interval
	nonresetable counter in [802.3ae], and		counters, and they are inhibited (not
	it is not subject to inhibiting. The		incremented) during one-second intervals
	objects sonetLineCurrentCVs and		that qualify as unavailable seconds.
	sonetLineIntervalCVs are 15-minute
	interval counters, and they are		aLineCVs This object is defined as a generalized
	inhibited (not incremented) during		nonresetable counter in [802.3ae], and it
	one-second intervals that qualify		is not subject to inhibiting. The objects
	either as severely errored seconds		sonetLineCurrentCVs and
	or as unavailable seconds.		sonetLineIntervalCVs are 15-minute interval
	aFarEndLineSESs This object is defined as a generalized		counters, and they are inhibited (not
	nonresetable counter in [802.3ae], and		incremented) during one-second intervals
	it is not subject to inhibiting. The		that qualify either as severely errored
	objects sonetFarEndLineCurrentSESs and		seconds or as unavailable seconds.
	sonetFarEndLineIntervalSESs are
	15-minute interval counters, and they		aFarEndLineSESs This object is defined as a generalized
	are inhibited (not incremented) during		nonresetable counter in [802.3ae], and it
	one-second intervals that qualify as		is not subject to inhibiting. The objects
	unavailable seconds.		sonetFarEndLineCurrentSESs and
	aFarEndLineESs This object is defined as a generalized		sonetFarEndLineIntervalSESs are 15-minute
	nonresetable counter in [802.3ae], and		interval counters, and they are inhibited
	it is not subject to inhibiting. The		(not incremented) during one-second
	objects sonetFarEndLineCurrentESs and		intervals that qualify as unavailable
	sonetFarEndLineIntervalESs are 15-minute		seconds.
	interval counters, and they are
	inhibited (not incremented) during		aFarEndLineESs This object is defined as a generalized
	one-second intervals that qualify as		nonresetable counter in [802.3ae], and it
	unavailable seconds.		is not subject to inhibiting. The objects
	aFarEndLineCVs This object is defined as a generalized		sonetFarEndLineCurrentESs and
	nonresetable counter in [802.3ae], and		sonetFarEndLineIntervalESs are 15-minute
	it is not subject to inhibiting. The		interval counters, and they are inhibited
	objects sonetFarEndLineCurrentCVs and		(not incremented) during one-second
	sonetFarEndLineIntervalCVs are 15-minute		intervals that qualify as unavailable
	interval counters, and they are		seconds.
	inhibited (not incremented) during
	one-second intervals that qualify		aFarEndLineCVs This object is defined as a generalized
	either as severely errored seconds		nonresetable counter in [802.3ae], and it
	or as unavailable seconds.		is not subject to inhibiting. The objects
	aPathSESThreshold This object is defined in [802.3ae]		sonetFarEndLineCurrentCVs and
	as an integer with one instance per		sonetFarEndLineIntervalCVs are 15-minute
	interface. sonetSESthresholdSet		interval counters, and they are inhibited
	is an enumerated value that has one		(not incremented) during one-second
	instance per network element; it		intervals that qualify either as severely
	controls the thresholds for all layers		errored seconds or as unavailable seconds.
	simultaneously and allows only certain
	discrete values to be selected.		aPathSESThreshold This object is defined in [802.3ae] as an
	aPathSESs This object is defined as a generalized		integer with one instance per interface.
	nonresetable counter in [802.3ae], and		sonetSESthresholdSet is an enumerated value
	it is not subject to inhibiting. The		that has one instance per network element;
	objects sonetPathCurrentSESs and		it controls the thresholds for all layers
	sonetPathIntervalSESs are 15-minute		simultaneously and allows only certain
	interval counters, and they are		discrete values to be selected.
	inhibited (not incremented) during
	one-second intervals that qualify as		aPathSESs This object is defined as a generalized
	unavailable seconds. In addition,		nonresetable counter in [802.3ae], and it
	[802.3ae] includes PLM-P and LCD-P		is not subject to inhibiting. The objects
	defects in the criteria for declaring		sonetPathCurrentSESs and
	path layer severely errored seconds,		sonetPathIntervalSESs are 15-minute
	while [SONETng] does not.		interval counters, and they are inhibited
	aPathESs This object is defined as a generalized		(not incremented) during one-second
	nonresetable counter in [802.3ae], and		intervals that qualify as unavailable
	it is not subject to inhibiting. The		seconds. In addition, [802.3ae] includes
	objects sonetPathCurrentESs and		PLM-P and LCD-P defects in the criteria for
	sonetPathIntervalESs are 15-minute		declaring path layer severely errored
	interval counters, and they are		seconds, while [RFC3592] does not.
	inhibited (not incremented) during
	one-second intervals that qualify as		aPathESs This object is defined as a generalized
	unavailable seconds. In addition,		nonresetable counter in [802.3ae], and it
	[802.3ae] includes PLM-P and LCD-P		is not subject to inhibiting. The objects
	defects in the criteria for declaring		sonetPathCurrentESs and
	path layer errored seconds, while		sonetPathIntervalESs are 15-minute interval
	[SONETng] does not.		counters, and they are inhibited (not
	aPathCVs This object is defined as a generalized		incremented) during one-second intervals
	nonresetable counter in [802.3ae], and		that qualify as unavailable seconds. In
	it is not subject to inhibiting. The		addition, [802.3ae] includes PLM-P and
	objects sonetPathCurrentCVs and		LCD-P defects in the criteria for declaring
	sonetPathIntervalCVs are 15-minute		path layer errored seconds, while [RFC3592]
	interval counters, and they are		does not.
	inhibited (not incremented) during
	one-second intervals that qualify		aPathCVs This object is defined as a generalized
	either as severely errored seconds		nonresetable counter in [802.3ae], and it
	or as unavailable seconds.		is not subject to inhibiting. The objects
	aFarEndPathSESs This object is defined as a generalized		sonetPathCurrentCVs and
	nonresetable counter in [802.3ae], and		sonetPathIntervalCVs are 15-minute interval
	it is not subject to inhibiting. The		counters, and they are inhibited (not
	objects sonetFarEndPathCurrentSESs and		incremented) during one-second intervals
	sonetFarEndPathIntervalSESs are		that qualify either as severely errored
	15-minute interval counters, and they		seconds or as unavailable seconds.
	are inhibited (not incremented) during
	one-second intervals that qualify as		aFarEndPathSESs This object is defined as a generalized
	unavailable seconds. In addition,		nonresetable counter in [802.3ae], and it
	[802.3ae] includes far-end PLM-P and		is not subject to inhibiting. The objects
	LCD-P defects in the criteria for		sonetFarEndPathCurrentSESs and
	declaring far-end path layer severely		sonetFarEndPathIntervalSESs are 15-minute
	errored seconds, while [SONETng] does		interval counters, and they are inhibited
	not.		(not incremented) during one-second
	aFarEndPathESs This object is defined as a generalized		intervals that qualify as unavailable
	nonresetable counter in [802.3ae], and		seconds. In addition, [802.3ae] includes
	it is not subject to inhibiting. The		far-end PLM-P and LCD-P defects in the
	objects sonetFarEndPathCurrentESs and		criteria for declaring far-end path layer
	sonetFarEndPathIntervalESs are 15-minute		severely errored seconds, while [RFC3592]
	interval counters, and they are		does not.
	inhibited (not incremented) during
	one-second intervals that qualify as		aFarEndPathESs This object is defined as a generalized
	unavailable seconds. In addition,		nonresetable counter in [802.3ae], and it
	[802.3ae] includes far-end PLM-P and		is not subject to inhibiting. The objects
	LCD-P defects in the criteria for		sonetFarEndPathCurrentESs and
	declaring far-end path layer errored		sonetFarEndPathIntervalESs are 15-minute
	seconds, while [SONETng] does not.		interval counters, and they are inhibited
	aFarEndPathCVs This object is defined as a generalized		(not incremented) during one-second
	nonresetable counter in [802.3ae], and		intervals that qualify as unavailable
	it is not subject to inhibiting. The		seconds. In addition, [802.3ae] includes
	objects sonetFarEndPathCurrentCVs and		far-end PLM-P and LCD-P defects in the
	sonetFarEndPathIntervalCVs are 15-minute		criteria for declaring far-end path layer
	interval counters, and they are		errored seconds, while [RFC3592] does not.
	inhibited (not incremented) during
	one-second intervals that qualify		aFarEndPathCVs This object is defined as a generalized
	either as severely errored seconds		nonresetable counter in [802.3ae], and it
	or as unavailable seconds.		is not subject to inhibiting. The objects
			sonetFarEndPathCurrentCVs and
			sonetFarEndPathIntervalCVs are 15-minute
			interval counters, and they are inhibited
			(not incremented) during one-second
			intervals that qualify either as severely
			errored seconds or as unavailable seconds.
	Note: despite the semantic differences between the threshold objects		Note: despite the semantic differences between the threshold objects
	and counter objects imported from the SONET-MIB and the corresponding		and counter objects imported from the SONET-MIB and the corresponding
	IEEE 802.3 objects, the hardware support mandated by [802.3ae]		IEEE 802.3 objects, the hardware support mandated by [802.3ae]
	subclause 50.3.11 suffices for both. See Appendix A for details.		subclause 50.3.11 suffices for both. See Appendix A for details.
	3.7. Mapping of SNMP Objects to WIS Station Management Registers		3.7. Mapping of SNMP Objects to WIS Station Management Registers
	Some of the objects defined in this memo or incorporated by reference		Some of the objects defined in this memo or incorporated by reference
	from the SONET-MIB [SONETng] or the MAU-MIB [MAU-MIB] require WIS-		from the SONET-MIB [RFC3592] or the MAU-MIB [RFC3636] require
	specific hardware support. [802.3ae] subclause 50.3.11 specifies WIS		WIS-specific hardware support. [802.3ae] subclause 50.3.11 specifies
	management interface requirements, including a required subset of the		WIS management interface requirements, including a required subset of
	WIS Management Data Input/Output (MDIO) registers defined in		the WIS Management Data Input/Output (MDIO) registers defined in
	[802.3ae] subclause 45.2.2. The table below provides a cross-		[802.3ae] subclause 45.2.2. The table below provides a cross-
	reference between those managed objects and the WIS MDIO registers		reference between those managed objects and the WIS MDIO registers
	from the subset in [802.3ae] subclause 50.3.11 required to support		from the subset in [802.3ae] subclause 50.3.11 required to support
	them. Note that the MDIO interface is optional; however, if it is		them. Note that the MDIO interface is optional; however, if it is
	not implemented, then the capabilities of the required register		not implemented, then the capabilities of the required register
	subset must be provided by other means.		subset must be provided by other means.
	SNMP Object WIS MDIO Register(s)		SNMP Object WIS MDIO Register(s)
	ETHER-WIS - etherWisDeviceTxTestPatternMode 10G WIS control 2		ETHER-WIS - etherWisDeviceTxTestPatternMode 10G WIS control 2
	ETHER-WIS - etherWisDeviceRxTestPatternMode 10G WIS control 2		ETHER-WIS - etherWisDeviceRxTestPatternMode 10G WIS control 2
	ETHER-WIS - etherWisDeviceRxTestPatternErrors 10G WIS test pattern		ETHER-WIS - etherWisDeviceRxTestPatternErrors 10G WIS test pattern
	error counter		error counter
	SONET-MIB - sonetMediumType none required		SONET-MIB - sonetMediumType none required
	SONET-MIB - sonetMediumTimeElapsed none required		SONET-MIB - sonetMediumTimeElapsed none required
	SONET-MIB - sonetMediumValidIntervals none required		SONET-MIB - sonetMediumValidIntervals none required
	SONET-MIB - sonetMediumLineCoding none required		SONET-MIB - sonetMediumLineCoding none required
	SONET-MIB - sonetMediumLineType none required		SONET-MIB - sonetMediumLineType none required
	SONET-MIB - sonetMediumCircuitIdentifier none required		SONET-MIB - sonetMediumCircuitIdentifier none required
	SONET-MIB - sonetMediumInvalidIntervals none required		SONET-MIB - sonetMediumInvalidIntervals none required
	SONET-MIB - sonetMediumLoopbackConfig none required		SONET-MIB - sonetMediumLoopbackConfig none required
	SONET-MIB - sonetSESthresholdSet none required		SONET-MIB - sonetSESthresholdSet none required
	skipping to change at page 16, line 27		skipping to change at page 16, line 27
	sonetMediumStuff2, sonetSectionStuff2,		sonetMediumStuff2, sonetSectionStuff2,
	sonetLineStuff2, sonetFarEndLineStuff2,		sonetLineStuff2, sonetFarEndLineStuff2,
	sonetPathStuff2, sonetFarEndPathStuff2,		sonetPathStuff2, sonetFarEndPathStuff2,
	sonetMediumType, sonetMediumLineCoding,		sonetMediumType, sonetMediumLineCoding,
	sonetMediumLineType, sonetMediumCircuitIdentifier,		sonetMediumLineType, sonetMediumCircuitIdentifier,
	sonetMediumLoopbackConfig, sonetSESthresholdSet,		sonetMediumLoopbackConfig, sonetSESthresholdSet,
	sonetPathCurrentWidth		sonetPathCurrentWidth
	FROM SONET-MIB;		FROM SONET-MIB;
	etherWisMIB MODULE-IDENTITY		etherWisMIB MODULE-IDENTITY
	LAST-UPDATED "200303171832Z" -- March 17, 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 charter:		"WG charter:
	http://www.ietf.org/html.charters/hubmib-charter.html		http://www.ietf.org/html.charters/hubmib-charter.html
	Mailing Lists:		Mailing Lists:
	General Discussion: hubmib@ietf.org		General Discussion: hubmib@ietf.org
	To Subscribe: hubmib-request@ietf.org		To Subscribe: hubmib-request@ietf.org
	In Body: subscribe your_email_address		In Body: subscribe your_email_address
	skipping to change at page 17, line 33		skipping to change at page 17, line 33
	(MAC) Parameters, Physical Layer and Management		(MAC) Parameters, Physical Layer and Management
	Parameters for 10 Gb/s Operation', 30 August 2002.		Parameters for 10 Gb/s Operation', 30 August 2002.
	Of particular interest are Clause 50, 'WAN Interface		Of particular interest are Clause 50, 'WAN Interface
	Sublayer (WIS), type 10GBASE-W', Clause 30, '10Mb/s,		Sublayer (WIS), type 10GBASE-W', Clause 30, '10Mb/s,
	100Mb/s, 1000Mb/s, and 10Gb/s MAC Control, and Link		100Mb/s, 1000Mb/s, and 10Gb/s MAC Control, and Link
	Aggregation Management', and Clause 45, 'Management		Aggregation Management', and Clause 45, 'Management
	Data Input/Output (MDIO) Interface'.		Data Input/Output (MDIO) Interface'.
	Copyright (C) The Internet Society (2003). This version		Copyright (C) The Internet Society (2003). This version
	of this MIB module is part of RFC yyyy; see the RFC		of this MIB module is part of RFC 3637; see the RFC
	itself for full legal notices."		itself for full legal notices."
	REVISION "200303171832Z" -- March 17, 2003		REVISION "200309190000Z" -- September 19, 2003
	DESCRIPTION "Initial version, published as RFC yyyy."		DESCRIPTION "Initial version, published as RFC 3637."
			::= { transmission 134 }
	::= { transmission XXX }
	-- The main sections of the module		-- The main sections of the module
	etherWisObjects OBJECT IDENTIFIER ::= { etherWisMIB 1 }		etherWisObjects OBJECT IDENTIFIER ::= { etherWisMIB 1 }
	etherWisObjectsPath OBJECT IDENTIFIER ::= { etherWisMIB 2 }		etherWisObjectsPath OBJECT IDENTIFIER ::= { etherWisMIB 2 }
	etherWisConformance OBJECT IDENTIFIER ::= { etherWisMIB 3 }		etherWisConformance OBJECT IDENTIFIER ::= { etherWisMIB 3 }
	-- groups in the Ethernet WIS MIB module		-- groups in the Ethernet WIS MIB module
	etherWisDevice OBJECT IDENTIFIER ::= { etherWisObjects 1 }		etherWisDevice OBJECT IDENTIFIER ::= { etherWisObjects 1 }
	etherWisSection OBJECT IDENTIFIER ::= { etherWisObjects 2 }		etherWisSection OBJECT IDENTIFIER ::= { etherWisObjects 2 }
	etherWisPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 1 }		etherWisPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 1 }
	etherWisFarEndPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 2 }		etherWisFarEndPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 2 }
	skipping to change at page 25, line 50		skipping to change at page 25, line 50
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"This variable indicates the current status at the		"This variable indicates the current status at the
	far end of the path using a bit map that can indicate		far end of the path using a bit map that can indicate
	multiple defects at once. The bit positions are		multiple defects at once. The bit positions are
	assigned as follows:		assigned as follows:
	etherWisFarEndPayloadDefect(0)		etherWisFarEndPayloadDefect(0)
	A far end payload defect (i.e., far end		A far end payload defect (i.e., far end
	PLM-P or LCD-P) is currently being signalled		PLM-P or LCD-P) is currently being signaled
	in G1 bits 5-7.		in G1 bits 5-7.
	etherWisFarEndServerDefect(1)		etherWisFarEndServerDefect(1)
	A far end server defect (i.e., far end		A far end server defect (i.e., far end
	LOP-P or AIS-P) is currently being signalled		LOP-P or AIS-P) is currently being signaled
	in G1 bits 5-7. Note: when this bit is set,		in G1 bits 5-7. Note: when this bit is set,
	sonetPathSTSRDI MUST be set in the corresponding		sonetPathSTSRDI MUST be set in the corresponding
	instance of sonetPathCurrentStatus."		instance of sonetPathCurrentStatus."
	REFERENCE		REFERENCE
	"[IEEE 802.3 Std.], 30.8.1.1.25, aFarEndPathStatus."		"[IEEE 802.3 Std.], 30.8.1.1.25, aFarEndPathStatus."
	::= { etherWisFarEndPathCurrentEntry 1 }		::= { etherWisFarEndPathCurrentEntry 1 }
	--		--
	-- Conformance Statements		-- Conformance Statements
	--		--
	skipping to change at page 30, line 24		skipping to change at page 30, line 24
	}		}
	MIN-ACCESS read-only		MIN-ACCESS read-only
	DESCRIPTION		DESCRIPTION
	"Write access is not required, nor is support		"Write access is not required, nor is support
	for any value other than sts192cSTM64(6)."		for any value other than sts192cSTM64(6)."
	::= { etherWisCompliances 1 }		::= { etherWisCompliances 1 }
	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 31, line 14		skipping to change at page 31, line 14
	7. Security Considerations		7. Security Considerations
	There are five managed objects defined in this MIB module that have a		There are five managed objects defined in this MIB module that have a
	MAX-ACCESS clause of read-write: etherWisDeviceTxTestPatternMode,		MAX-ACCESS clause of read-write: etherWisDeviceTxTestPatternMode,
	etherWisDeviceRxTestPatternMode, etherWisDeviceRxTestPatternErrors,		etherWisDeviceRxTestPatternMode, etherWisDeviceRxTestPatternErrors,
	etherWisSectionCurrentJ0Transmitted, and		etherWisSectionCurrentJ0Transmitted, and
	etherWisPathCurrentJ1Transmitted. Writing to these objects can have		etherWisPathCurrentJ1Transmitted. Writing to these objects can have
	the following potentially disruptive effects on network operation:		the following potentially disruptive effects on network operation:
	o changing the transmit or receive test pattern mode or modifying		o changing the transmit or receive test pattern mode or modifying
	the accumulated error count from a PRBS31 pattern test on an		the accumulated error count from a PRBS31 pattern test on an
	administratively disabled 10GBASE-W interface, which can		administratively disabled 10GBASE-W interface, which can
	interfere with an in-progress pattern test;		interfere with an in-progress pattern test;
	o modifying the transmitted section trace and/or path trace		o modifying the transmitted section trace and/or path trace
	message on an operational 10GBASE-W interface, which can cause		message on an operational 10GBASE-W interface, which can cause
	connectivity alarms to be raised at the remote of the link.		connectivity alarms to be raised at the remote of the link.
	The user of this MIB module must therefore be aware that support for		The user of this MIB module must therefore be aware that support for
	SET operations in a non-secure environment without proper protection		SET operations in a non-secure environment without proper protection
	can have a negative effect on network operations.		can have a negative effect on network operations.
	The readable objects in this MIB module (i.e., those with MAX-ACCESS		The readable objects in this MIB module (i.e., those with MAX-ACCESS
	other than not-accessible) may be considered sensitive in some		other than not-accessible) may be considered sensitive in some
	environments since, collectively, they provide information about the		environments since, collectively, they provide information about the
	performance of network interfaces and can reveal some aspects of		performance of network interfaces and can reveal some aspects of
	their configuration. In such environments it is important to control		their configuration. In such environments it is important to control
	skipping to change at page 32, line 9		skipping to change at page 32, line 9
	enable cryptographic security. It is then a customer/operator		enable cryptographic security. It is then a customer/operator
	responsibility to ensure that the SNMP entity giving access to an		responsibility to ensure that the SNMP entity giving access to an
	instance of this MIB module is properly configured to give access to		instance of this MIB module is properly configured to give access to
	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.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] 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.
	[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,		[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
	Rose, M. and S. Waldbusser, "Structure of Management		Rose, M. and S. Waldbusser, "Structure of Management
	Information Version 2 (SMIv2)", STD 58, RFC 2578, April		Information Version 2 (SMIv2)", STD 58, RFC 2578, April
	1999.		1999.
	[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,		[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
	Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2",		Rose, M. and S. Waldbusser, "Textual Conventions for
	STD 58, RFC 2579, April 1999.		SMIv2", STD 58, RFC 2579, April 1999.
	[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,		[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
	Rose, M. and S. Waldbusser, "Conformance Statements for		Rose, M. and S. Waldbusser, "Conformance Statements for
	SMIv2", STD 58, RFC 2580, April 1999.		SMIv2", STD 58, RFC 2580, April 1999.
	[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group		[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
	MIB", RFC 2863, June 2000.		MIB", RFC 2863, June 2000.
	[RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table		[RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table
	Extension to the Interfaces Group MIB", RFC 2864, June 2000.		Extension to the Interfaces Group MIB", RFC 2864, June
			2000.
	[SONETng] Tesink, K., "Definitions of Managed Objects for the		[RFC3592] Tesink, K., "Definitions of Managed Objects for the
	SONET/SDH Interface Type", <draft-ietf-atommib-rfc2558bis-		Synchronous Optical Network/Synchronous Digital Hierarchy
	01.txt>, work in progress.		(SONET/SDH) Interface Type", RFC 3592, September 2003.
	[T1.231] American National Standard for Telecommunications - Digital		[T1.231] American National Standard for Telecommunications -
	Hierarchy - Layer 1 In-Service Digital Transmission		Digital Hierarchy - Layer 1 In-Service Digital
	Performance Monitoring, ANSI T1.231-1997, September 1997.		Transmission Performance Monitoring, ANSI T1.231-1997,
			September 1997.
	[ETHERIF] Flick, J., "Definitions of Managed Objects for the		[RFC3635] Flick, J., "Definitions of Managed Objects for the
	Ethernet-like Interface Types", <draft-ietf-hubmib-etherif-		Ethernet-like Interface Types", RFC 3635, September 2003.
	mib-v3-03.txt>, work in progress.
	[MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE 802.3		[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3
	Medium Attachment Units (MAUs)", <draft-ietf-hubmib-mau-		Medium Attachment Units (MAUs)", RFC 3636, September
	mib-v3-03.txt>, work in progress.		2003.
	[802.3ae] Institute of Electrical and Electronic Engineers, IEEE Std		[802.3ae] Institute of Electrical and Electronic Engineers, IEEE
	802.3ae-2002, "IEEE Standard for Carrier Sense Multiple		Std 802.3ae-2002, "IEEE Standard for Carrier Sense
	Access with Collision Detection (CSMA/CD) Access Method and		Multiple Access with Collision Detection (CSMA/CD) Access
	Physical Layer Specifications - Media Access Control (MAC)		Method and Physical Layer Specifications - Media Access
	Parameters, Physical Layer and Management Parameters for 10		Control (MAC) Parameters, Physical Layer and Management
	Gb/s Operation", August 2002.		Parameters for 10 Gb/s Operation", August 2002.
	8.2. Informative References		8.2. Informative References
	[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,		[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
	"Introduction and Applicability Statements for Internet-		"Introduction and Applicability Statements for Internet-
	Standard Management Framework", RFC 3410, December 2002.		Standard Management Framework", RFC 3410, December 2002.
	9. Contributors		Appendix A: Collection of Performance Data Using WIS MDIO Registers
			The purpose of this appendix is to illustrate how the WIS MDIO
			registers specified in [802.3ae] subclause 45.2.2 (and more
			specifically the subset required by [802.3ae] subclause 50.3.11) can
			be used to collect performance data either according to the
			conventions adopted by this document or according to the conventions
			specified in [802.3ae] Clause 30.
			For an agent implementing the SNMP managed objects required by this
			document the first step in collecting WIS performance data would be
			to poll the 10G WIS status 3 register and the various error count
			registers (10G WIS section BIP error count, 10G WIS line BIP errors,
			10G WIS far end line BIP errors, 10G WIS path block error count, and
			10G WIS far end path block error count) once per second. The 10G WIS
			status 3 register bits are all latched until read and so would
			indicate whether a given defect occurred any time during the previous
			second. The error count registers roll over modulo 2^16 or 2^32, and
			so to find the number of errors within the previous second the agent
			would need to subtract (modulo 2^16 or 2^32) the current reading from
			the reading taken one second ago. Armed with that information, the
			agent could determine for any layer whether the one second interval
			was an errored second, a severely errored second (that requires
			comparison with a threshold unless a defect is present), or a
			severely errored frame second. Determining whether a given second is
			or is not part of unavailable time requires additional logic; the
			most straightforward and accurate method is the delay-line approach
			outlined in Appendix A of [RFC3592]. With that information available
			the agent would be able to determine by how much each current count
			should be incremented (including effects of inhibiting).
			Implementations that conform to [T1.231] would end each 15-minute
			interval on time-of-day clock 1/4 hour boundaries; if the delay-line
			approach is used then a time-of-day timestamp would accompany the
			one-second statistics. At the end of each interval the current
			registers would be pushed onto the history stack and then would be
			cleared. The xyxIntervalValidData flags would be set to False(2) if
			the number of samples was not between 890 and 910 or, in the case of
			far-end counts, if a near-end defect occurred during the
			just-completed interval (see [T1.231] Section 9.1.2.2 for details).
			An agent implementing the [802.3ae] Clause 30 oWIS objects could also
			start by polling the 10G WIS status 3 register and the various error
			count registers to find the defects and error counts for the previous
			second, and it could determine the number of errors and whether the
			second was an errored second, a severely errored second, or a
			severely errored frame second in the same manner as above. The rest
			of the process would simply be to increment the generalized non-
			resetable counters without consideration of any inhibiting rules.
			Contributors
	Mike Ayers		Mike Ayers
	1204 Knox Ave.		1204 Knox Ave.
	San Jose, CA 95122		San Jose, CA 95122
	USA		USA
	Phone: +1 408 857 6810		Phone: +1 408 857 6810
	EMail: mike.ayers@earthling.net		EMail: mike.ayers@earthling.net
	John Flick		John Flick
	skipping to change at page 34, line 25		skipping to change at page 36, line 25
	Kaj Tesink		Kaj Tesink
	Telcordia Technologies		Telcordia Technologies
	331 Newman Springs Road		331 Newman Springs Road
	P.O. Box 7020		P.O. Box 7020
	Red Bank, NJ 07701-7020		Red Bank, NJ 07701-7020
	USA		USA
	Phone: +1 732 758 5254		Phone: +1 732 758 5254
	EMail: kaj@research.telcordia.com		EMail: kaj@research.telcordia.com
	10. Editor's Address		Editor's Address
	C. M. Heard		C. M. Heard
	600 Rainbow Dr. #141		600 Rainbow Dr. #141
	Mountain View, CA 94041-2542		Mountain View, CA 94041-2542
	USA		USA
	Phone: +1 650 964 8391		Phone: +1 650 964 8391
	EMail: heard@pobox.com		EMail: heard@pobox.com
	Appendix A: Collection of Performance Data Using WIS MDIO Registers
	The purpose of this appendix is to illustrate how the WIS MDIO
	registers specified in [802.3ae] subclause 45.2.2 (and more
	specifically the subset required by [802.3ae] subclause 50.3.11) can
	be used to collect performance data either according to the
	conventions adopted by this document or according to the conventions
	specified in [802.3ae] Clause 30.
	For an agent implementing the SNMP managed objects required by this
	document the first step in collecting WIS performance data would be
	to poll the 10G WIS status 3 register and the various error count
	registers (10G WIS section BIP error count, 10G WIS line BIP errors,
	10G WIS far end line BIP errors, 10G WIS path block error count, and
	10G WIS far end path block error count) once per second. The 10G WIS
	status 3 register bits are all latched until read and so would
	indicate whether a given defect occurred any time during the previous
	second. The error count registers roll over modulo 2^16 or 2^32, and
	so to find the number of errors within the previous second the agent
	would need to subtract (modulo 2^16 or 2^32) the current reading from
	the reading taken one second ago. Armed with that information, the
	agent could determine for any layer whether the one second interval
	was an errored second, a severely errored second (that requires
	comparison with a threshold unless a defect is present), or a
	severely errored frame second. Determining whether a given second is
	or is not part of unavailable time requires additional logic; the
	most straightforward and accurate method is the delay-line approach
	outlined in Appendix A of [SONETng]. With that information available
	the agent would be able to determine by how much each current count
	should be incremented (including effects of inhibiting).
	Implementations that conform to [T1.231] would end each 15-minute
	interval on time-of-day clock 1/4 hour boundaries; if the delay-line
	approach is used then a time-of-day timestamp would accompany the
	one-second statistics. At the end of each interval the current
	registers would be pushed onto the history stack and then would be
	cleared. The xyxIntervalValidData flags would be set to False(2) if
	the number of samples was not between 890 and 910 or, in the case of
	far-end counts, if a near-end defect occurred during the just-
	completed interval (see [T1.231] Section 9.1.2.2 for details).
	An agent implementing the [802.3ae] Clause 30 oWIS objects could also
	start by polling the 10G WIS status 3 register and the various error
	count registers to find the defects and error counts for the previous
	second, and it could determine the number of errors and whether the
	second was an errored second, a severely errored second, or a
	severely errored frame second in the same manner as above. The rest
	of the process would simply be to increment the generalized non-
	resetable counters without consideration of any inhibiting rules.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		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.
	Revision History		Acknowledgement
	NOTE TO RFC Editor: this section is to be removed prior to
	publication as an RFC.
	The following changes were made to <draft-ietf-hubmib-wis-mib-01.txt>
	to produce <draft-ietf-hubmib-wis-mib-02.txt>:
	1.) Section 3.1 was updated as agreed in "WIS MIB compliance
	statement issue" e-mail thread, specifically to explain that the
	ETHER-WIS compliance statement requires all objects that required
	by sonetCompliance2 as well as some that it leaves optional.
	2.) In Section 3.5 the paragraph dealing with STS-Path Remote
	Defect Indication was updated to indicate that an implementation
	of the WIS MIB (not necessarily an arbitrary implementation of the
	WIS) has to set the SONET-MIB's RDI status bit when a remote
	server defect is detected.
	3.) In Section 3.6 the text introducing the table of semantic
	differences between IEEE GDMO and SNMP objects was wordsmithed.
	4.) In Section 3.7 the mapping between objects in the
	etherWisDeviceTable and the station management registers was
	updated to reflect the updated MDIO register definitions in
	P802.3ae/D4.01 and the corresponding updates to the MIB objects.
	5.) In Section 3.8.1 the text was updated to state that the
	purpose of the etherWisDeviceTable is to support mandatory and
	optional WIS test features.
	6.) In Sections 3.8.1, 3.8.2, 3.8.3, and 3.8.4 certain instances
	of "SHALL" were changed to "MUST" to improve readability.
	7.) The LAST-UPDATED, ORGANIZATION, REVISION, and DESCRIPTION
	clauses of the MODULE-IDENTITY invocation were updated.
	8.) The lower-case "shall" in the DESCRIPTION clause of each table
	entry was changed to an uppercase "MUST", per RFC 2119, because it
	describes a requirement of the specification in the draft.
	9.) The etherWisDeviceTestPatternType objects was removed, and the
	objects etherWisDeviceTxTestPatternMode and
	etherWisDeviceRxTestPatternMode were changed from simple
	"enable/disable" flags to enumerations that reflect the specific
	text pattern mode in which the transmitter or receiver is
	operating. A new optional object called
	etherWisDeviceRxTestPatternErrors was added to make visible the
	error count MDIO register contents when the receiver is operating
	in the (optional) PRBS31 test pattern mode added in D4.01.
	10.) The SYNTAX of etherWisSectionCurrentJ0Transmitted and
	etherWisSectionCurrentJ0Received was changed from INTEGER (0..255)
	to OCTET STRING (SIZE (16)) to reflect the change from 1-byte to
	16-byte section trace messages in D4.01, and the DESCRIPTION
	clauses were rewritten along the lines for those of the
	corresponding path trace objects.
	11.) In the DESCRIPTION of etherWisPathCurrentJ0Transmitted "path
	message" was changes to "path trace message".
	12.) etherWisDeviceGroup was split into a mandatory group
	etherWisDeviceGroupBasic and an optional group
	etherWisDeviceGroupExtra.
	13.) The compliance name was changed from
	etherWisCurrentCompliance to etherWisCompliance.
	14.) OBJECT clauses were added to specify required values for
	etherWisDeviceTxTestPatternMode and
	etherWisDeviceRxTestPatternMode.
	15.) A GROUP clause was added to state that
	etherWisDeviceGroupExtra needs to be implemented in order to
	support the PRBS31 test pattern mode. The DESCRIPTION clause
	points out that the prbs31 enumeration is needed for
	etherWisDeviceTxTestPatternMode/etherWisDeviceRxTestPatternMode.
	16.) References [SONETng] and [P802.3ae] were updated to draft-
	ietf-atommib-rfc2558bis-00.txt and P802.3ae/D4.01, respectively.
	The following changes were made to <draft-ietf-hubmib-wis-mib-02.txt>
	to produce <draft-ietf-hubmib-wis-mib-03.txt>:
	1.) The page formatting was changed to match that used in recent
	RFCs.
	2.) Heading numbering and bracketed references were removed from
	the abstract, and "SONET MIB" was expanded to "SONET/SDH Interface
	MIB".
	3.) RFC 2119 terminology conventions were moved from the abstract
	into a separate numbered "Conventions" section and were
	wordsmithed to match the style of recent RFCs.
	4.) Each occurrence of "SONET MIB" in Section 3, "Overview", was
	expanded to "SONET/SDH Interface MIB".
	5.) Each occurrence of "MAU-MIB" in Section 3, "Overview", was
	expanded to "802.3 MAU MIB".
	6.) Each occurrence of "SONET MIB" in Sections 3.1, 3.8.1, 3.8.2,
	3.8.3, and 3.8.4 was changed to "SONET-MIB" (this matches the
	usage elsewhere, specifically Sections 3.2 and 3.3).
	7.) All occurrences of "[P802.3ae] subclause 50.3.10" were updated
	to "[P802.3ae] subclause 50.3.11" in order to match the subclause
	numbering in P802.3ae/D4.2 (affected sections are 3.1, 3.6, 3.7,
	and Appendix A).
	8.) "Ethernet-like Interfaces MIB" was changed to "Ethernet-like
	Interface MIB" in Section 3.2 in order to match the usage in the
	abstract.
	9.) "mauModIfCompl2" was updated to "mauModIfCompl3" in Section
	3.3 in order to match <draft-ietf-hubmib-mau-mib-v3-01.txt>.
	10.) An unnecessary heading was removed the table in Section 3.6
	that compares the semantics of IEEE threshold and counter objects
	with those of the corresponding objects imported from the SONET-
	MIB.
	11.) The text at the end of Section 3.6 was wordsmithed to remove
	unnecessary verbiage.
	12.) The MDIO register name spellings in Section 3.7, Section 4,
	and Appendix A were updated to match those in P802.3ae/D4.2
	subclause 45.2.2.
	13.) A missing comma was added to the
	etherWisDeviceRxTestPatternErrors REFERENCE clause.
	14.) DESCRIPTION clauses of etherWisSectionCurrentJ0Transmitted
	and etherWisPathCurrentJ1Transmitted were updated to state that
	the default value should be '89'h followed by 16 octets of '00'h,
	rather than 16 octets of '00'h followed by '89'h (this matches the
	resolution in P802.3ae/D4.2 of a byte ordering inconsistency).
	15.) The MAX-ACCESS clauses of etherWisPathCurrentStatus and
	etherWisPathCurrentStatus were changed from 'read-write' to
	16.) In Section 6, "Security Considerations", all read-write
	objects have been explicitly listed and mention of read-create
	objects has been removed.
	17.) References [ETHERIF], [MAU-MIB], and [P802.3ae] were updated
	to <draft-ietf-hubmib-etherif-mib-v3-01.txt>, <draft-ietf-hubmib-
	mau-mib-v3-01.txt>, and P802.3ae/D4.2, respectively.
	18.) Normative and informative references were moved into separate
	sub-sections.
	19.) A "To-Do List" section was added.
	The following changes were made to <draft-ietf-hubmib-wis-mib-03.txt>
	to produce <draft-ietf-hubmib-wis-mib-04.txt>:
	1.) "tx" and "rx" were spelled out in the MDIO register names in
	Section 3.7 in order to match the usage in P802.3ae/D4.3 and
	P802.3ae/D5.0.
	2.) References [IEEE 802.3 Std] in the MIB module and [P802.3ae]
	in the text were updated to point to P802.3ae/D5.0.
	3.) Author contact information was updated.
	The following changes were made to <draft-ietf-hubmib-wis-mib-04.txt>
	to produce <draft-ietf-hubmib-wis-mib-05.txt>:
	1.) Gauge32 was added to the IMPORTS list. It was not being
	imported from SNMPv2-SMI as required by RFC 2578.
	2.) Enum values for etherWisDeviceTxTestPatternMode and
	etherWisDeviceTxTestPatternMode now start at 1 instead of 0, as
	recommended by RFC 2578.
	3.) The OBJECT clauses for etherWisDeviceTxTestPatternMode and
	etherWisDeviceRxTestPatternMode now state that an implementation
	does not have to allow value assignments that the Clause 45 MDIO
	registers can't support.
	4.) An OBJECT clause for etherWisDeviceRxTestPatternErrors was
	added to specify that the WRITE-SYNTAX is Gauge32(0).
	5.) A paragraph warning that some environments may consider the
	information in read-only objects to be sensitive was added to the
	Security Considerations section, and the entire section was
	updated to conform to the latest template posted to the
	mibs@ops.ietf.org mailing list.
	6.) The acronyms in Section 3 were expanded on first use.
	7.) All occurrences of "ifAdminState" were changed to
	"ifAdminStatus".
	8.) The DESCRIPTION clauses for etherWisPathCurrentJ1Transmitted
	and etherWisSectionCurrentJ0Transmitted were changed to use
	"transmitted" in place of "to be transmitted".
	9.) All remaining instances of "SHALL" were changed to "MUST" in
	Sections 3.8.1, 3.8.2, 3.8.3, and 3.8.4 in order to improve
	readability.
	10.) The reference tag [P802.3ae] was replaced with [802.3ae], and
	the corresponding normative reference was updated to point to IEEE
	Std 802.3ae-2002, published 30 Aug 2002. The reference [IEEE
	802.3 Std] in the MIB module was similarly updated.
	11.) RFC 2119 was moved from the informative reference list to the
	normative reference list, in accordance with current IESG and RFC
	Editor policy.
	12.) The MIB boilerplate in Section 2 and the SMI/SNMP-related
	references were updated to conform to the latest template posted
	to the mibs@ops.ietf.org mailing list.
	13.) The DESCRIPTION clause of the MODULE-IDENTITY invocation was
	updated to include the required copyright statement.
	14.) The dates in the LAST-UPDATED and REVISION clauses of the
	MODULE-IDENTITY invocation were changed to the current date.
	15.) The document pagination was changed to match that expected
	upon publication as an RFC.
	The following changes were made to <draft-ietf-hubmib-wis-mib-05.txt>
	to produce <draft-ietf-hubmib-wis-mib-06.txt>:
	1.) Names of WIS MIB design team members other than the editor
	were removed from author list on front page. They now appear in
	the Contributors section with (updated) contact information.
	2.) Reference tag [2570bis] was replaced with [RFC3410], and the
	corresponding informative reference was updated to point to RFC
	3410.
	3.) Working group mailing list information was added to the
	CONTACT-INFO clause of the MODULE-IDENTITY invocation.
	4.) The dates in the LAST-UPDATED and REVISION clauses of the
	MODULE-IDENTITY invocation were changed to the current date.
	5.) The Intellectual Property section was relocated.
	6.) The working group names in the Acknowlegments section were
	corrected.
	7.) The part of the Security Considerations section dealing with
	read-only objects was wordsmithed, and some typos in the last part
	were fixed.
	8.) References [SONETng], [ETHERIF], and [MAU-MIB] were updated to
	point to <draft-ietf-atommib-rfc2558bis-01.txt>, <draft-ietf-
	hubmib-etherif-mib-v3-02.txt>, and <draft-ietf-hubmib-mau-mib-v3-
	02.txt>, respectively.
	9.) All references to multi-author RFCs were updated to conform to
	the style used in recently published RFCs.
	10.) The "To-Do List" was replaced with a "NOTES TO RFC Editor"
	section.
	The following changes were made to <draft-ietf-hubmib-wis-mib-06.txt>
	to produce <draft-ietf-hubmib-wis-mib-07.txt>:
	1.) The prerequisite external compliance statements (IF-
	MIB.ifCompliance3, IF-INVERTED-STACK-MIB.ifInvCompliance,
	EtherLike-MIB.dot3Compliance2, and MAU-MIB.mauModIfCompl3) were
	listed explicitly in the etherWisCompliance DESCRIPTION clause.
	2.) The OBJECT clauses for etherWisDeviceTxTestPatternMode and
	etherWisDeviceRxTestPatternMode no longer state that an
	implementation is not required to support certain combinations of
	settings because the Clause 45 MDIO registers do not, in fact,
	impose any inter-dependencies in the settings.
	3.) The dates in the LAST-UPDATED and REVISION clauses of the
	MODULE-IDENTITY invocation were changed to the current date.
	4.) References [ETHERIF] and [MAU-MIB] were updated to point to
	<draft-ietf-hubmib-etherif-mib-v3-03.txt> and <draft-ietf-hubmib-
	mau-mib-v3-03.txt>, respectively.
	************************************************************		Funding for the RFC Editor function is currently provided by the
	* NOTES TO RFC Editor (to be removed prior to publication) *		Internet Society.
	* *
	* 1.) The normative references [SONETng], [ETHERIF], and *
	* [MAU-MIB] must be updated to point to the appropriate *
	* RFCs when the respective Internet Drafts are published, *
	* and all occurrences of the reference tags must be *
	* changed to [RFCnnnn] where nnnn is the assigned RFC *
	* number. *
	* *
	* 2.) Please replace all occurrences of "yyyy" in the *
	* DESCRIPTION clause of the MODULE-IDENTITY invocation *
	* in Section 4 with the RFC number assigned to this *
	* specification and remove the accompanying notes. *
	* *
	* 3.) Please replace "XXX" in the MODULE-IDENTITY value *
	* with an IANA-assigned value under the 'transmission' *
	* subtree and remove the accompanying note. *
	* *
	* 4.) Please remove the "Revision History" section. *
	* *
	************************************************************
End of changes. 52 change blocks.
	658 lines changed or deleted		372 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/