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/