Subject: [Hubmib] Comments on <draft-ietf-hubmib-wis-mib-00.txt>

From: "C. M. Heard" <[email-masked]>
Date: Mon, 30 Jul 2001 18:41:39 -0700 (PDT)

On Tue, 3 Jul 2001, Dan Romascanu wrote:

> Please see the following Internet-Draft issued by the Ethernet Interfaces
> and Hub MIB WG. The WIS MIB will be discussed in the common meeting of the
> atommib and hubmib wgs in London. Until then comments and questions are
> welcome at [email-masked]

I would like to thank the authors of <draft-ietf-hubmib-wis-mib-00.txt>
for their efforts in providing a valuable starting point for discussion.
However, I do not agree with some of the technical content, and I would
like to present a detailed critique of the document.  The main point I
shall make is that one can avoid much duplication if the WIS MIB is
re-cast an augmentation of the SONET-MIB and the MAU-MIB.  Doing so
makes the resulting MIB module a good deal simpler than it otherwise
would be and capitalizes on existing management technology.

I am presenting these comments on the mailing lists because I will not
be at the common atommib and hubmib WG meeting at the London IETF and
so cannot do it there.  Because these comments are quite lengthy, I've
broken them up into numbered sections.  Here is the outline:

   1. Summary of Technical Issues with <draft-ietf-hubmib-wis-mib-00.txt>
   1.1. Current Interval Counts Aren't Enough -- Previous Interval Needed Too
   1.2. The SONET-MIB is not Re-Used Where it Could Be
   1.3. Historical Data is Defined in a Non-Standard Way
   1.4. There is Overlap in Functionality with the MAU-MIB Draft
   1.5. Some Objects in the Draft are not in P802.3ae D3.1 and Vice-Versa
   2. Comparison of <draft-ietf-hubmib-wis-mib-00.txt> with SONET-MIB,
      MAU-MIB, and P802.3ae D3.1 oWIS -- Analysis and Recommendations
   2.1. Overview
   2.2. Interface Layering Issues
   2.3. sonetSESthresholdSet
   2.4. etherWisDeviceTable, sonetMediumTable, and ifMauTable
   2.5. etherWisSectionCurrentTable and sonetSectionCurrentTable
   2.6. etherWisSectionIntervalTable and sonetSectionIntervalTable
   2.7. etherWisLineCurrentTable and sonetLineCurrentTable
   2.8. etherWisLineIntervalTable and sonetLineIntervalTable
   2.9. sonetFarEndLineStuff2
   2.10. etherWisPathCurrentTable and sonetPathCurrentTable
   2.11. etherWisPathIntervalTable and sonetPathIntervalTable
   2.12. sonetFarEndPathStuff2
   3. Proposal for a Revised ETHER-WIS MIB Module
   3.1. Prerequisite MIB Modules
   3.2. Use of the ifTable and ifStackTable
   3.3. Mapping of IEEE 802.3 Managed Objects
   3.4. Revised Object Definitions

I realize that it will require considerable investment of time to read
this message in its entirety.  If possible, please at least read Section 1.

Thanks,

Mike Heard

1.  Summary of Technical Issues with <draft-ietf-hubmib-wis-mib-00.txt>

1.1.  Current Interval Counts Aren't Enough -- Previous Interval Needed Too

   The ETHER-WIS draft provides two compliance statements, one for
   implementations that support historical data, and one for
   implementations that do not.  The compliance statement for the latter
   includes only the counts for the current 15-minute interval.  It
   excludes counts for the previous and recent 15-minute intervals.
   While it may seem that this is a useful and desirable simplification,
   unfortunately it will not work.  Because the current interval
   counters reset back to zero every 15 minutes, a manager would have to
   poll the counters immediately before they were reset in order to be
   able to accurately record data for historical intervals, and that is
   true regardless of the desired interval duration.  Such tight
   synchronization between manager and agent is impossible to achieve
   in practice.  To avoid this problem the agent must provide at least
   one historical interval, and there is not much difference in
   implementation effort between providing one historical interval and
   providing n (where 4 <= n <= 96).  If one wishes to simplify the
   agent and push the burden of collecting historical data onto the
   manager, then one should simply do away with the 15-minute interval
   counters altogether and use traditional SNMP rollover counters (aka
   generalized nonresetable counters) instead.  That, however, would
   introduce a departure from the SONET MIB style management used by
   existing NMS applications.

1.2.  The SONET-MIB is not Re-Used Where it Could Be

   The ETHER-WIS design team in its initial draft duplicates the
   definitions of objects that are already present in the SONET-MIB
   instead of incorporating those objects by reference.  It is my
   position that existing MIB technology should be re-used where it
   applies, and that seems to be the case here.  Judging from the
   information in the DESCRIPTION clauses, it appears that the SONET-MIB
   provides direct replacements for 28 of the 41 leaf objects in the
   ETHER-WIS draft.  The remaining objects (at least the ones that are
   valid and that do not duplicate MAU-MIB functionality) could reside
   in tables that sparsely augment the relevant tables in the SONET-MIB.
   Furthermore, the mandatory SONET-MIB objects in the relevant groups
   that lack counterparts in the ETHER-WIS draft appear to be applicable
   to WIS interfaces, and in some cases (e.g., sonetSESthresholdSet)
   provide functionality whose absence has drawn comments from the IEEE.
   Finally, the interface layering model required by the SONET-MIB
   appears to be perfectly serviceable for the WIS application.

   The big advantage of using the SONET-MIB, as opposed to defining new
   MIB objects, is that it would allow management technology developed
   for similar applications such as ATM over SONET and Packet over SONET
   to be applied to the SONET-like parts of WIS.  Most of that advantage
   is lost if instead one defines a completely new MIB for WIS, and so
   far I have not seen a good reason to do that.  In addition, the
   definition of duplicate objects has the well-known risks of the
   objects not being exact duplicates and/or becoming out of sync over
   time when definitions evolve.

1.3.  Historical Data is Defined in a Non-Standard Way

   Even if there really is a good reason to define an all-new set of
   15-minute interval counter objects for the WIS application, I still
   object to the fact that the draft does not make use of the TCs from
   the PerfHist-TC-MIB (RFC 2493) or provide the associated objects and
   to the fact that it does not provide validity indicators for the
   stored 15-minute histories.  Both of these things were added (for
   good reason) to the SONET-MIB in its transition from RFC 1595 to RFC
   2558, and I think that ETHER-WIS MIB should incorporate them.  In
   addition, the draft has no equivalents for the sonetSESthresholdSet
   object or the sonetFarEndLineStuff2 and sonetFarEndPathStuff2 object
   groups, and omits the descriptive information that is present in RFC
   2558 defining failures, defects, and unavailable time.  Those last
   omissions have already drawn comments from the IEEE.

1.4.  There is Overlap in Functionality with the MAU-MIB Draft

   Four of the objects in the etherWisDeviceTable -- specifically, those
   related to device reset, power down, and mode selection -- do not
   seem to be WIS-specific and appear to duplicate functionality that is
   present in <draft-ietf-hubmib-mau-mib-v3-00.txt>.  Those objects
   should be removed and the MAU-MIB objects should be used instead.

1.5.  Some Objects in the Draft are not in P802.3ae D3.1 and Vice-Versa

   Three objects in the ETHER-WIS draft -- etherWisDevicePresent and
   etherWisDeviceSpeedSelection in the etherWisDeviceTable and
   etherWisSectionCurrentJ0Expected in the etherWisSectionCurrentTable
   -- do not appear to have any counterparts among the WIS-specific
   managed objects defined in P802.3ae D3.1.  As will be argued below,
   these objects do not appear to be useful.  On the other hand, there
   are three WIS-specific managed objects defined in P802.3ae D3.1 that
   appear to have no counterparts in either the ETHER-WIS draft, the
   SONET-MIB, or the MAU-MIB.  They are aJ1ValueTX, aJ1ValueRX, and
   aFarEndPathStatus.  In addition, the latching semantics of the
   P802.3ae D3.1 status objects and the corresponding reset actions
   acClearSectionStatus, acClearLineStatus, acClearPathStatus, and
   acClearFarEndPathStatus are not captured.  These discrepancies would
   not be difficult to fix.

2.  Comparison of <draft-ietf-hubmib-wis-mib-00.txt> with SONET-MIB,
    MAU-MIB, and P802.3ae D3.1 oWIS -- Analysis and Recommendations

2.1.  Overview

   The table below provides a side-by-side comparison of all the objects
   in the ETHER-WIS draft with their closest counterparts in the
   SONET-MIB.  It also includes relevant SONET-MIB objects and object
   groups that have no counterparts in the ETHER-WIS draft.  In the
   "Notes" column the notation "if layering" means that there is a
   possible discrepancy between the ETHER-WIS and SONET-MIB in the
   intended use of ifTable and ifIndex;  "MAU-MIB" means that the object
   duplicates functionality of the MAU-MIB;  "WIS ext" means that the
   object in question is a WIS extention;  "subset", "superset", and
   "overlap" mean respectively that the ETHER-WIS object has a subset
   of, has a superset of, or overlaps the functionality of the
   corresponding SONET-MIB object;  "applies" indicates a SONET-MIB
   object (or group) that is not in the ETHER-WIS draft but that is
   valid for the WIS application;  "req'd for PM" indicates a SONET-MIB
   object that is not in the ETHER-WIS draft but is required in order to
   properly implement performance monitoring with 15-minute histories;
   and finally, the notation "equivalent" indicates that the behaviour
   (although not necessarily the syntax) specified in the DESCRIPTION
   clause of the ETHER-WIS object is identical with that specified for
   the corresponding SONET-MIB object.  Note that the majority of the
   leaf objects in the ETHER-WIS draft fall into this last category.

ETHER-WIS Object                    SONET-MIB Object/Group        Notes

                                    sonetSESthresholdSet          applies

etherWisDeviceTable                 sonetMediumTable
etherWisDeviceEntry                 sonetMediumEntry              if layering
etherWisDeviceReset                                               MAU-MIB
                                    sonetMediumType               applies
                                    sonetMediumTimeElapsed        req'd for PM
                                    sonetMediumValidIntervals     req'd for PM
                                    sonetMediumLineCoding         applies
                                    sonetMediumLineType           applies
                                    sonetMediumCircuitIdentifier  applies
                                    sonetMediumInvalidIntervals   req'd for PM
etherWisDeviceLoopback              sonetMediumLoopbackConfig     subset
etherWisDeviceSpeedSelection                                      WIS ext
etherWisDevicePowerDown                                           MAU-MIB
etherWisDevicePresent                                             WIS ext
etherWisDeviceModesAllowed                                        MAU-MIB
etherWisDeviceModeSelect                                          MAU-MIB
etherWisDeviceJitterTestMode                                      WIS ext

etherWisSectionCurrentTable         sonetSectionCurrentTable
etherWisSectionCurrentEntry         sonetSectionCurrentEntry      if layering
etherWisSectionCurrentJ0Transmitted                               WIS ext
etherWisSectionCurrentJ0Expected                                  WIS ext
etherWisSectionCurrentJ0Received                                  WIS ext
etherWisSectionCurrentStatus        sonetSectionCurrentStatus     superset
etherWisSectionCurrentESs           sonetSectionCurrentESs        equivalent
etherWisSectionCurrentSESs          sonetSectionCurrentSESs       equivalent
etherWisSectionCurrentSEFSs         sonetSectionCurrentSEFSs      equivalent
etherWisSectionCurrentCVs           sonetSectionCurrentCVs        equivalent

etherWisSectionIntervalTable        sonetSectionIntervalTable
etherWisSectionIntervalEntry        sonetSectionIntervalEntry     if layering
etherWisSectionIntervalNumber       sonetSectionIntervalNumber    equivalent
etherWisSectionIntervalESs          sonetSectionIntervalESs       equivalent
etherWisSectionIntervalSESs         sonetSectionIntervalSESs      equivalent
etherWisSectionIntervalSEFSs        sonetSectionIntervalSEFSs     equivalent
etherWisSectionIntervalCVs          sonetSectionIntervalCVs       equivalent
                                    sonetSectionIntervalValidData req'd for PM

etherWisLineCurrentTable            sonetLineCurrentTable
etherWisLineCurrentEntry            sonetLineCurrentEntry         if layering
etherWisLineCurrentStatus           sonetLineCurrentStatus        equivalent
etherWisLineCurrentESs              sonetLineCurrentESs           equivalent
etherWisLineCurrentSESs             sonetLineCurrentSESs          equivalent
etherWisLineCurrentCVs              sonetLineCurrentCVs           equivalent
etherWisLineCurrentUASs             sonetLineCurrentUASs          equivalent

etherWisLineIntervalTable           sonetLineIntervalTable
etherWisLineIntervalEntry           sonetLineIntervalEntry        if layering
etherWisLineIntervalNumber          sonetLineIntervalNumber       equivalent
etherWisLineIntervalESs             sonetLineIntervalESs          equivalent
etherWisLineIntervalSESs            sonetLineIntervalSESs         equivalent
etherWisLineIntervalCVs             sonetLineIntervalCVs          equivalent
etherWisLineIntervalUASs            sonetLineIntervalUASs         equivalent
                                    sonetLineIntervalValidData    req'd for PM

                                    sonetFarEndLineStuff2         applies

etherWisPathCurrentTable            sonetPathCurrentTable
etherWisPathCurrentEntry            sonetPathCurrentEntry         if layering
                                    sonetPathCurrentWidth         applies
etherWisPathCurrentStatus           sonetPathCurrentStatus        overlap
etherWisPathCurrentESs              sonetPathCurrentESs           equivalent
etherWisPathCurrentSESs             sonetPathCurrentSESs          equivalent
etherWisPathCurrentCVs              sonetPathCurrentCVs           equivalent
etherWisPathCurrentUASs             sonetPathCurrentUASs          equivalent

etherWisPathIntervalTable           sonetPathIntervalTable
etherWisPathIntervalEntry           sonetPathIntervalEntry        if layering
etherWisPathIntervalNumber          sonetPathIntervalNumber       equivalent
etherWisPathIntervalESs             sonetPathIntervalESs          equivalent
etherWisPathIntervalSESs            sonetPathIntervalSESs         equivalent
etherWisPathIntervalCVs             sonetPathIntervalCVs          equivalent
etherWisPathIntervalUASs            sonetPathIntervalUASs         equivalent
                                    sonetPathIntervalValidData    req'd for PM

                                    sonetFarEndPathStuff2         applies

2.2.  Interface Layering Issues

   The ETHER-WIS draft does not provide any guidance on the use of the
   ifTable or the ifStackTable, so it is unclear what ifIndex value is
   supposed to be used to index a given ETHER-WIS table entry.  Since a
   WIS entity is uniquely associated with a single MAC layer entity, I
   assume that the intent was that the ifIndex value associated with
   these table entries should be the same one that is associated with
   the required dot3StatsEntry, dot3HCStatsEntry, dot3ControlEntry,
   dot3PauseEntry, and ifMauEntry instances.

   The SONET-MIB, on the other hand, requires interface layering because
   it is, in general, possible to have multiple path layer entities
   (each requiring separate management) whose data are transported by
   one line layer entity.  The sublayering becomes degenerate when, as
   in the WIS application, there is a single concatenated payload
   occupying the entire path layer bandwidth.  The specific instructions
   in RFC 2558 are as follows.  The ifIndex value corresponding to
   instances of sonetMediumEntry, sonetSectionCurrentEntry,
   sonetSectionIntervalEntry, sonetLineCurrentEntry,
   sonetLineIntervalEntry, sonetFarEndLineCurrentEntry, and
   sonetFarEndLineIntervalEntry associated with a given physical
   interface must point to an instance of ifEntry for which ifType has
   the value sonet(39).  Similarly, the ifIndex value corresponding to
   instances of sonetPathCurrentEntry, sonetPathIntervalEntry,
   sonetFarEndPathCurrentEntry, and sonetFarEndPathIntervalEntry
   associated with a given path layer entity must point to an instance
   of ifEntry for which ifType has the value sonetPath(50).  The
   relationship between the sonet(39) and sonetPath(50) ifTable entries
   associated with a given physical interface is modelled using the
   ifStackTable and ifInvStackTable.  If the SONET-MIB were used for the
   WIS application there would also need to be an ifEntry with ifType
   equal to ethernetCsmacd(6) stacked on top of the sonetPath(50)
   ifEntry.  This is illustrated below.

         _____________________________   _
        |    LLC Layer                |  |
        +_____________________________+  |
        |    MAC Layer                |  |
        +-----------------------------+  > 1 ifEntry  ethernetCsmacd(6)
        |    Reconciliation Sublayer  |  |
        +-----------------------------+  |
        |    Physical Coding Sublayer |  |
         -----------------------------   +
        |    Path Layer               |  > 1 ifEntry  sonetPath(50)
        +-----------------------------+  +
        |    Line Layer               |  |
        +-----------------------------+  |
        |    Section Layer            |  > 1 ifEntry  sonet(39)
        +-----------------------------+  |
        |    Physical Medium Layer    |  |
         -----------------------------   -

   The question arises whether this layering model has some flaw that
   would render it unworkable for its intended application.  It does
   have the peculiarity that the required instance of ifMauEntry will be
   associated with the top layer, although the primary function of the
   relevant ifMauEntry columns (notably ifMauType, ifMauStatus,
   ifMauMediaAvailable, ifMauDefaultType , ifMauAutoNegSupported, and
   ifMauTypeListBits) is to control and report status of the layers
   below.  However, that actually works well for managing devices that
   support both 10GBASE-R and 10GBASE-W on the same optics, because it
   allows the lower layer ifTable entries to be present or absent based
   on MAU type.

   Consider, for example, a 10 Gb/s Ethernet device with 1310 nm optics
   that supports both the LAN (10GBASE-LR) and WAN (10GBASE-LW) signal
   formats.  The b10GbaseLR and b10GbaseLW bits in ifMauTypeListBits
   would be set to indicate this.  To select the 10GBASE-LW format a
   manager would set ifMauDefaultType to dot3MauType10GigBaseLW.  If the
   selected format was previously 10GBASE-LR, this would result in a
   downward adjustment of ifHighSpeed and setting ifConnectorPresent to
   false(2) in the ethernetCsmacd(6) ifEntry.  It would also result the
   creation of appropriate ifTable entries for the SONET sublayers and
   of appropriate ifStackTable and ifInvStackTable entries (note that
   the sonet(39) ifEntry would have ifConnectorPresent set to true(1)).
   To return to the 10GBASE-LR format a manager would set
   ifMauDefaultType to dot3MauType10GigBaseLR, which would cause the
   SONET sublayer-related ifTable, ifStackTable, and ifInvStackTable
   entries to be deleted and would result in setting ifHighSpeed back to
   10000 and ifConnectorPresent back to true(1).

   Based on this discussion it seems to me that the SONET-MIB interface
   layering model would work fine for WIS.  Although layering is not
   needed for the WIS application, it seems like a small price to pay
   in order to use a common MIB technology to manage all types of
   SONET-like interfaces.

2.3.  sonetSESthresholdSet

   sonetSESthresholdSet has no counterpart in the ETHER-WIS draft.  This
   enumerated integer is a scalar object, outside any table, that
   specifies which of several sets of Severely Errored Second threshold
   values is currently in use.  As noted in a recent e-mail from Dan
   Romascanu, the IEEE has commented on the absence of any objects
   corresponding to aSectionSesThreshold, aLineSesThreshold, and
   aPathSesThreshold.  If only a few discrete sets of thresholds are
   needed (as was concluded by the AToMMIB wg when the SONET-MIB was
   being revised in the 1996-1998 time frame), then sonetSESthresholdSet
   will fill that gap, as its value specifies the values of all of those
   threshold objects (for example, the value ansi1997(5) specifies the
   P802.3ae D3.1 default values of 8554, 9835, and 2400 for section,
   line, and path SES thresholds respectively).  If more flexibility is
   desired, then supplemental MIB objects could be defined, in which
   case sonetSESthresholdSet would assume the value other(1) if a
   "non-standard" threshold set was dialed-in.  The AToMMIB wg chose to
   leave such extensions out of the standard MIB and allow the vendors
   who wished to do so to define supplemental threshold objects in their
   enterprise MIBs.

   - Recommendation:  require that sonetSESthresholdSet be implemented
   by all systems that have 10 Gb/s Ethernet WAN interfaces, and specify
   in the text of the appropriate document how this object maps to
   aSectionSesThreshold, aLineSesThreshold, and aPathSesThreshold.  In
   accordance with the conformance statements in RFC 2558, the
   MIN-ACCESS for this object would be read-only.

2.4.  etherWisDeviceTable, sonetMediumTable, and ifMauTable

   The etherWisDeviceTable has some parts in common with the SONET-MIB
   sonetMediumTable and the MAU-MIB ifMauTable, while other parts that
   are unique.  It is assumed that the required conformance groups from
   the MAU-MIB would be implemented in WIS applications, so the analysis
   below will only discuss MAU-MIB objects to the extent that there is
   duplication.  On the other had, the conformance statements in the
   SONET-MIB require implementation of all accessible columns in the
   sonetMediumTable.  For that reason, applicability of all items in
   that table is discussed.

   The etherWisDeviceTable objects labelled in the comparison table with
   the notation "MAU-MIB" appear from their names or DESCRIPTION clauses
   to duplicate functionality that is already present in the MAU-MIB.
   Specifically:  based on its DESCRIPTION clause, the function
   performed by etherWisDeviceReset appears to be available by setting
   ifMauStatus to the value reset(6);  based on its name and how the
   term "power down" is used in P802.3ae D3.1, the function performed by
   etherWisDevicePowerDown appears to be available by setting
   ifMauStatus to shutdown(5);  based on its DESCRIPTION clause, the
   functionality of etherWisDeviceModesAllowed appears to be provided
   ifMauTypeListBits;  and based on its DESCRIPTION clause, the
   functionality of etherWisDeviceModeSelect appears to be provided by
   ifMauType and ifMauDefaultType.  Note that the last two items are
   present to allow the mode to be changed between 10GBASE-R and
   10GBASE-W.  They clearly do not belong in the ETHER-WIS MIB, because
   the ETHER-WIS MIB applies only when the selected mode is 10GBASE-W.

   The only overlap between the etherWisDeviceTable and sonetMediumTable
   is the loopback object contained in each.  sonetMediumLoopbackConfig
   supports a facility loopback, a terminal loopback, and an unspecified
   "other" loopback;  based on its description, etherWisDeviceLoopback
   supports only a facility loopback.  Clearly, sonetMediumLoopbackConfig
   could be used in place of etherWisDeviceLoopback, subject to the
   proviso that a system that does not support loopbacks other than
   facility loopback must return an error if a manager attempts to
   activate one of those loopbacks.  Since P802.3ae D3.1 does not
   specify any hardare registers to activate a facility loopback, the
   MIN-ACCESS for this object should be read-only;  this is in
   accordance with the conformance statements in RFC 2558.  [ NOTE:  the
   hardware registers specified in P802.3ae D3.1 all activate "internal"
   loopbacks that return data provided from a higher layer back to the
   service interface for performing self-tests.  The EtherLike-MIB
   provides the object dot3TestLoopBack to activate such self-tests. ]

   The objects sonetMediumTimeElapsed, sonetMediumValidIntervals, and
   sonetMediumInvalidIntervals are present to tell how much time has
   elapsed in the current 15-minute interval, what is the largest valid
   index in the interval tables, and how many intervals within that
   index range are missing.  These objects clearly apply to any MIB
   module that contains performance history based on 15 minute
   intervals, and they are required when the PerfCurrentCount and
   PerfIntervalCount TCs (RFC 2493) are used.

   Based on their DESCRIPTION clauses, the remaining objects in the
   sonetMediumTable clearly apply to WIS devices, although possibly with
   fixed values.  Note that the main purpose for sonetMediumType (which
   admits values sonet(1) and sdh(2)) is to specify whether the SS bits
   (bits 5 and 6) of the H1 overhead byte are set to the SONET default
   value of '00'b or to the SDH-compatible value of '10'b.  The
   appropriate value for WIS devices is sonet(1).  Vendors that provide
   SDH-compatibility features may find it useful to support sdh(2) also.

   The remaining etherWisDeviceTable objects -- etherWisDevicePresent,
   etherWisDeviceSpeedSelection, and etherWisDeviceJitterTestMode --
   have no counterparts among the WIS-specific managed objects defined
   in P802.3ae D3.1 Clause 30.  They do, however, map to the
   WIS-specific MDIO registers in Clause 45.  etherWisDevicePresent maps
   to the device present bits in the WIS Status 2 register (2.8.15:14).
   These bits exist to reveal whether there is a device present and
   responding at the specified address.  However, no managed object is
   needed for this purpose;  one would do better simply not to
   instantiate ifTable and etherWisDeviceTable entries for devices that
   do not exist.  etherWisDeviceSpeedSelection maps to the speed
   selection bits in the WIS Control 1 register (2.0.13, 2.0.6, and
   2.0.5:2).  However, there is only one valid setting for these bits,
   so it is not necessary to provide a managed object to control them.
   etherWisDeviceJitterTestMode maps to the WIS Control 2 register
   jitter control bits (2.7.3:1) and to the WIS Jitter Test Seed WIS
   Jitter Test Error count registers.  As noted in a recent e-mail from
   Dan Romascanu, the IEEE has stated that this object does not map well
   and has suggested that the object be replaced by
   etherWisJitterTestPattern (with values for square-wave and
   pseudo random patterns), etherWisRxJitterTestMode, and
   etherWisTxJitterTestMode.  Those objects need to be supplemented
   by etherWisJitterTestSeed (to control the transition rate in the
   square-wave test mode and to control the data pattern in the
   pseudo-random test mode) and etherWisJitterTestErrorCount (to count
   receive errors in the the pseudo-random test mode).  Support for the
   jitter test capabilities is required by P802.3ae D3.1 Clause 50.

   Here are my recommendations concerning the etherWisDeviceTable and
   the sonetMediumTable:

   - for each WIS interface, require that there be corresponding
   instances of sonetMediumEntry and etherWisDeviceEntry;

   - use the same ifIndex value to index the etherWisDeviceEntry and the
   corresponding sonetMediumEntry (i.e., treat etherWisDeviceEntry as
   sparsely augmenting sonetMediumEntry with WIS-specific extensions);

   - remove the object etherWisDeviceLoopback from etherWisDeviceEntry
   and use sonetMediumLoopbackConfig instead;

   - remove the objects etherWisDeviceReset, etherWisDevicePowerDown,
   etherWisDeviceModesAllowed, and etherWisDeviceModeSelect from
   etherWisDeviceEntry and use ifMauStatus, ifMauTypeListBits,
   ifMauDefaultType, and ifMauType instead;

   - remove the objects etherWisDevicePresent and
   etherWisDeviceSpeedSelection from etherWisDeviceEntry, as these
   objects are not useful;

   - replace etherWisDeviceJitterTestMode with etherWisJitterTestPattern,
   etherWisRxJitterTestMode, etherWisTxJitterTestMode,
   etherWisJitterTestSeed, and etherWisJitterTestErrorCount.

2.5.  etherWisSectionCurrentTable and sonetSectionCurrentTable

   etherWisSectionCurrentJ0Transmitted, etherWisSectionCurrentJ0Expected,
   and etherWisSectionCurrentJ0Received have no equivalents in the
   SONET-MIB.  etherWisSectionCurrentJ0Transmitted supports provisioning
   of a single-byte section trace message in accordance with SONET (but
   not SDH) standards.  The corresponding WIS managed object in P802.3ae
   D3.1 Annex 30 is aJ0ValueTX.  etherWisSectionCurrentJ0Received
   supports monitoring of a received single-byte section trace message.
   The corresponding WIS managed object in P802.3ae D3.1 Annex 30 is
   aJ0ValueRX.  etherWisSectionCurrentJ0Expected has no counterpart in
   P802.3ae D3.1.  As presently defined this object is not very useful
   because no notification is defined to be sent when received J0 value
   does not match the expected value.  The ETHER-WIS MIB should either
   define such a notification and allow a distinguished value (e.g.,
   256) to indicate that section trace mismatch notifications are
   suppressed or else should eliminate this object.

   etherWisSectionCurrentStatus and sonetSectionCurrentStatus differ
   in that the former has bit positions for etherWisSectionNoError,
   etherWisSectionLocalFault, etherWisSectionLinkDown,
   etherWisSectionLOS, and etherWisSectionLOF, whereas the latter has
   only sonetSectionNoDefect, sonetSectionLOS, and sonetSectionLOF.  As
   noted in a recent e-mail from Dan Romascanu, the IEEE has stated that
   there are no LinkDown and LocalFault status bits defined for the
   Section Layer and has requested that the etherWisSectionLocalFault
   and etherWisSectionLinkDown bits be removed.  Thus,
   sonetSectionCurrentStatus as currently defined in the SONET-MIB has
   all of the status bits required for WIS interfaces.  However, it does
   not capture the latching semantics of the corresponding WIS managed
   object aSectionStatus defined in P802.3ae D3.1 Annex 30, as has been
   pointed out previously by John Flick.  One way to do that would be to
   re-define etherWisSectionCurrentStatus as a read-write BITS object
   with bit positions etherWisSectionLOS(0) and etherWisSectionLOF(1)
   such that a write operation with a given bit position set would
   unlatch that bit position while a write operation with a given bit
   position clear would have no effect on that bit position.  This would
   provide functionality similar to that of the P802.3ae D3.1 action
   acClearSectionStatus but without the hazard that a status bit could
   be set in between a get operation and a clear action.  Note that it
   does not require hardware capabilities beyond those specified in
   P802.3ae D3.1 Clause 45 to support both the non-latching
   sonetSectionCurrentStatus object and the proposed WIS object with
   latching semantics.

   etherWisSectionCurrentESs, etherWisSectionCurrentSESs,
   etherWisSectionCurrentSEFSs, and etherWisSectionCurrentCVs are
   functionally identical to their counterparts from the SONET-MIB.  The
   differences in the definitions are that (a) the ETHER-WIS object
   DESCRIPTION clauses have slightly different (albeit equivalent)
   wording and (b) the ETHER-WIS objects have a SYNTAX of Integer32
   instead of PerfCurrentCount.  Clearly, the SONET-MIB objects will
   serve just as well.

   Here are my recommendations concerning the
   etherWisSectionCurrentTable and the sonetSectionCurrentTable:

   - for each WIS interface, require that there be corresponding
   instances of sonetSectionCurrentEntry and
   etherWisSectionCurrentEntry;

   - use the same ifIndex value to index the etherWisSectionCurrentEntry
   and the corresponding sonetSectionCurrentEntry (i.e., treat
   etherWisSectionCurrentEntry as sparsely augmenting
   sonetSectionCurrentEntry with WIS-specific extensions);

   - remove all objects from etherWisSectionCurrentEntry except for
   etherWisSectionCurrentStatus, etherWisSectionCurrentJ0Transmitted,
   and etherWisSectionCurrentJ0Received;

   - re-define etherWisSectionCurrentStatus as a read-write BITS object
   with bit positions etherWisSectionLOS(0) and etherWisSectionLOF(1)
   that capture the sematics of the P802.3ae D3.1 objects aSectionStatus
   and acClearSectionStatus.

2.6.  etherWisSectionIntervalTable and sonetSectionIntervalTable

   etherWisSectionIntervalNumber, etherWisSectionIntervalESs,
   etherWisSectionIntervalSESs, etherWisSectionIntervalSEFSs, and
   etherWisSectionIntervalCVs are functionally identical to their
   counterparts from the SONET-MIB.  The differences in the definitions
   are that (a) the ETHER-WIS object DESCRIPTION clauses have slightly
   different (albeit equivalent) wording and (b) the ETHER-WIS interval
   counter objects have a SYNTAX of Integer32 instead of
   PerfIntervalCount.  Clearly, the SONET-MIB objects will serve
   just as well.

   sonetSectionIntervalValidData has no counterpart in the ETHER-WIS
   draft.  This object is needed to implement 15-minute historical data
   in compliance with ANSI T1.231, the American National Standard for
   Layer 1 In-Service Digital Transmission Performance Monitoring.  As
   is noted in the DESCRIPTION clause for the most recent SONET-MIB
   revision, its purpose is to indicate, for each interval, whether the
   data is valid in the sense intended by ANSI T1.231-1993 and ANSI
   T1.231-1997 clause 9.1.2.2.  For those who are not familiar with that
   document, clause 9.1.2.2 states that an invalid data flag must be
   provided to indicate when the performance data stored in a managed
   object (i) was collected over a time period that is greater or less
   than the nominal interval duration by more than 10 seconds or (ii)
   was not complete (i.e. some data was missing from the accumulation).
   Case (i) can occur when an agent, as required by T1.231 and allowed
   by the SONET-MIB, ends its 15-minute intervals on a 15-minute
   time-of-day boundary.  The first interval after the agent starts
   collecting performance data will typically be short, and an interval
   that ends after a time-of-day adjustment of more than 10 seconds can
   be either long or short depending on the direction of the adjustment.
   Case (ii) can occur when collection of far-end performance data is
   interrupted owing to a near-end defect.  In order to properly
   interpret the performance data, there needs to be a validity
   indicator for each stored interval.

   - Recommendation:  eliminate the etherWisSectionIntervalTable and use
   the sonetSectionIntervalTable instead.

2.7.  etherWisLineCurrentTable and sonetLineCurrentTable

   etherWisLineCurrentStatus and sonetLineCurrentStatus differ only
   in the assignment of bit positions.  There is no difference in
   functionality;  both have bit positions for NoDefect, LineAIS, and
   LineRDI.  Both ojects contain all of the status bits required for
   WIS interfaces.  However, neither captures the latching semantics
   of the corresponding WIS managed object in P802.3ae D3.1 Annex 30
   aLineStatus.  A remedy for that would be to re-define
   etherWisLineCurrentStatus as a read-write BITS object with bit
   positions etherWisLineAIS(0) and etherWisLineRDI(1) such that a write
   operation with a given bit position set would unlatch that bit
   position while a write operation with a given bit position clear
   would have no effect on that bit position.  This would provide
   functionality similar to that of the P802.3ae D3.1 action
   acClearLineStatus but without the hazard that a status bit could be
   set in between a get operation and a clear action.  Note that it
   does not require hardware capabilities beyond those specified in
   P802.3ae D3.1 Clause 45 to support both the non-latching
   sonetLineCurrentStatus object and the proposed WIS object with
   latching semantics.

   etherWisLineCurrentESs, etherWisLineCurrentSESs,
   etherWisLineCurrentCVs, and etherWisLineCurrentUASs are functionlly
   identical to their counterparts from the SONET-MIB.  The differences
   in the definitions are that (a) the ETHER-WIS object DESCRIPTION
   clauses have slightly different (albeit equivalent) wording and (b)
   the ETHER-WIS objects have a SYNTAX of Integer32 instead of
   PerfCurrentCount.  Clearly, the SONET-MIB objects will serve
   just as well.

   Here are my recommendations concerning the etherWisLineCurrentTable
   and the sonetLineCurrentTable:

   - for each WIS interface, require that there be corresponding
   instances of sonetLineCurrentEntry and etherWisLineCurrentEntry;

   - use the same ifIndex value to index the etherWisLineCurrentEntry
   and the corresponding sonetLineCurrentEntry (i.e., treat
   etherWisLineCurrentEntry as sparsely augmenting sonetLineCurrentEntry
   with WIS-specific extensions);

   - remove all objects from etherWisLineCurrentEntry except for
   etherWisLineCurrentStatus;

   - re-define etherWisLineCurrentStatus as a read-write BITS object
   with bit positions etherWisLineAIS(0) and etherWisLineRDI(1) that
   capture the sematics of the P802.3ae D3.1 objects aLineStatus and
   acClearLineStatus.

2.8.  etherWisLineIntervalTable and sonetLineIntervalTable

   etherWisLineIntervalNumber, etherWisLineIntervalESs,
   etherWisLineIntervalSESs, etherWisLineIntervalCVs, and
   etherWisLineIntervalUASs are functionally identical to their
   counterparts from the SONET-MIB.  The differences in the definitions
   are that (a) the ETHER-WIS object DESCRIPTION clauses have slightly
   different (albeit equivalent) wording and (b) the ETHER-WIS interval
   count objects have a SYNTAX of Integer32 instead of
   PerfIntervalCount.  Clearly, the SONET-MIB objects will serve
   just as well.

   sonetLineIntervalValidData has no counterpart in the ETHER-WIS draft.
   As discussed above, such an object is required when accumulating
   15-minute historical data.

   - Recommendation:  eliminate the etherWisLineIntervalTable and use
   the sonetLineIntervalTable instead.

2.9.  sonetFarEndLineStuff2

   As was pointed out in a recent e-mail from Dan Romascanu, the
   IEEE has noted the absence of FarEndLine objects analogous to
   aFarEndLineESs, aFarEndLineSESs, and aFarEndLineCVs and has requested
   that this omission be rectified.  Implementation of the objects in
   the sonetFarEndLineStuff2 group -- i.e., sonetFarEndLineCurrentESs,
   sonetFarEndLineCurrentSESs, sonetFarEndLineCurrentCVs,
   sonetFarEndLineCurrentUASs, sonetFarEndLineIntervalESs,
   sonetFarEndLineIntervalSESs, sonetFarEndLineIntervalCVs,
   sonetFarEndLineIntervalUASs, and sonetFarEndLineIntervalValidData --
   would satisfy this request.

   - Recommendation:  include sonetFarEndLineStuff2 in the list of
   mandatory object groups.  The status registers defined in P802.3ae
   D3.1 provide the necessary hardware support to implement the entire
   object group.

2.10.  etherWisPathCurrentTable and sonetPathCurrentTable

   sonetPathCurrentWidth has no counterpart in the ETHER-WIS draft.
   When used in conjunction with the WIS application the it would assume
   the fixed value sts192cSTM64(6).  [ NOTE:  the values sts192cSTM64(6)
   and sts768cSTM256(7) for sonetPathCurrentWidth are not present in RFC
   2558, but they will be added when the SONET-MIB advances to DRAFT
   STANDARD. ]

   etherWisPathCurrentStatus and sonetPathCurrentStatus differ
   in that the former has bit positions for etherWisPathNoDefect,
   etherWisPathLCD, etherWisPathPLM, etherWisPathAIS, and
   etherWisPathLOP, whereas the latter has sonetPathNoDefect,
   sonetPathSTSLOP, sonetPathSTSAIS, sonetPathSTSRDI,
   sonetPathUnequipped, and sonetPathSignalLabelMismatch.  The
   correspondence is as follows:

   ETHER-WIS bit        SONET-MIB bit                Description

   etherWisPathNoDefect sonetPathNoDefect            No Defect
   etherWisPathLOP      sonetPathSTSLOP              Loss of Pointer
   etherWisPathAIS      sonetPathSTSAIS              Alarm Indication Signal
                        sonetPathSTSRDI              Remote Defect Indication
                        sonetPathUnequipped          Unequipped (C2 Byte = 0)
   etherWisPathPLM      sonetPathSignalLabelMismatch Payload Label Mismatch
   etherWisPathLCD                                   Loss of Codegroup
                                                                  Delineation

   The bits in etherWisPathCurrentStatus other than etherWisPathNoDefect
   do map properly to those the corresponding WIS managed object
   aPathStatus defined in P802.3ae D3.1 Annex 30;  however,
   etherWisPathCurrentStatus does not capture the latching semantics of
   aPathStatus.  A remedy for that would be to re-define
   etherWisPathCurrentStatus as a read-write BITS object with bit
   positions etherWisPathLOP(0), etherWisPathAIS(1), etherWisPathPLM(2),
   and etherWisPathLCD(3) such that a write operation with a given bit
   position set would unlatch that bit position while a write operation
   with a given bit position clear would have no effect on that bit
   position.  This would provide functionality similar to that of the
   P802.3ae D3.1 action acClearPathStatus but without the hazard that a
   status bit could be set in between a get operation and a clear
   action.  Note that sonetPathCurrentStatus is still useful for
   providing non-latching versions of etherWisPathLOP, etherWisPathAIS,
   and etherWisPathPLM mapped per the table above.  sonetPathSTSRDI
   provides a non-latching version of the far-end server defect (see
   2.12 below).  Implementations that are able to support the Unequipped
   defect (which is not required by P802.3ae D3.1) may report that
   defect via the non-latching sonetPathUnequipped bit.  A non-latching
   equivalent of etherWisPathLCD is available from the MAU-MIB object
   ifMauMediaAvailable via the enumeration value pcsLinkFault(15).
   Note that it does not require hardware capabilities beyond those
   specified in P802.3ae D3.1 Clause 45 to support both the non-latching
   sonetPathCurrentStatus and ifMediaAvailable objects and the proposed
   WIS object with latching semantics.

   etherWisPathCurrentESs, etherWisPathCurrentSESs,
   etherWisPathCurrentCVs, and etherWisPathCurrentUASs are functionlly
   identical to their counterparts from the SONET-MIB.  The differences
   in the definitions are that (a) the ETHER-WIS object DESCRIPTION
   clauses have slightly different (albeit equivalent) wording and (b)
   the ETHER-WIS objects have a SYNTAX of Integer32 instead of
   PerfCurrentCount.  Clearly, the SONET-MIB objects will serve
   just as well.

   P802.3ae D3.1 defines to additional path layer objects -- aJ1ValueTX
   and aJ1ValueRX -- that have no counterparts in either the ETHER-WIS
   draft or the SONET-MIB.  Their functions are to set the transmitted
   path trace message and to report the received path trace message.
   In order to provide that functionality by two additional objects --
   etherWisPathCurrentJ1Transmitted and etherWisPathCurrentJ1Received --
   would need to be defined.

   Here are my recommendations concerning the etherWisPathCurrentTable
   and the sonetPathCurrentTable:

   - for each WIS interface, require that there be corresponding
   instances of sonetPathCurrentEntry and etherWisPathCurrentEntry;

   - use the same ifIndex value to index the etherWisPathCurrentEntry
   and the corresponding sonetPathCurrentEntry (i.e., treat
   etherWisPathCurrentEntry as sparsely augmenting sonetPathCurrentEntry
   with WIS-specific extensions);

   - remove all objects from etherWisPathCurrentEntry except for
   etherWisPathCurrentStatus;

   - re-define etherWisPathCurrentStatus as a read-write BITS object
   with bit positions etherWisPathLOP(0), etherWisPathAIS(1),
   etherWisPathPLM(2), and etherWisPathLCD(3) that capture the sematics
   of the P802.3ae D3.1 objects aPathStatus and acClearPathStatus;

   - define two path trace objects etherWisPathCurrentJ1Transmitted and
   etherWisPathCurrentJ1Received with SYNTAX OCTET STRING (SIZE(16)).

2.11.  etherWisPathIntervalTable and sonetPathIntervalTable

   etherWisPathIntervalNumber, etherWisPathIntervalESs,
   etherWisPathIntervalSESs, etherWisPathIntervalCVs, and
   etherWisPathIntervalUASs are functionally identical to their
   counterparts from the SONET-MIB.  The differences in the definitions
   are that (a) the ETHER-WIS object DESCRIPTION clauses have slightly
   different (albeit equivalent) wording and (b) the ETHER-WIS interval
   count objects have a SYNTAX of Integer32 instead of
   PerfIntervalCount.  Clearly, the SONET-MIB objects will serve
   just as well.

   sonetPathIntervalValidData has no counterpart in the ETHER-WIS draft.
   As discussed above, such an object is required when accumulating 15-
   minute historical data.

   - Recommendation:  eliminate the etherWisPathIntervalTable and use
   the sonetPathIntervalTable instead.

2.12.  sonetFarEndPathStuff2

   As was pointed out in a recent e-mail from Dan Romascanu, the
   IEEE has noted the absence of FarEndPath objects analogous to
   aFarEndPathStatus, acClearFarEndPathStatus, aFarEndPathSESs,
   aFarEndPathESs, and aFarEndPathCVs and has requested that this
   omission be rectified.  Implementation of the objects in
   the sonetFarEndPathStuff2 group -- i.e., sonetFarEndPathCurrentESs,
   sonetFarEndPathCurrentSESs, sonetFarEndPathCurrentCVs,
   sonetFarEndPathCurrentUASs, sonetFarEndPathIntervalESs,
   sonetFarEndPathIntervalSESs, sonetFarEndPathIntervalCVs,
   sonetFarEndPathIntervalUASs, and sonetFarEndPathIntervalValidData --
   would satisfy part of that request.  The remaining part could be
   satisfied by defining a read-write BITS object
   etherWisFarEndPathCurrentStatus with bit positions
   etherWisFarEndServerDefect(0) and etherWisFarEndPayloadDefect(1)
   such that a write operation with a given bit position set would
   unlatch that bit position while a write operation with a given bit
   position clear would have no effect on that bit position.  This would
   provide functionality similar to that of the P802.3ae D3.1 action
   acClearFarEndPathStatus but without the hazard that a status bit
   could be set in between a get operation and a clear action.

   Here are my recommendations concerning the etherWisPathCurrentTable
   and the sonetPathCurrentTable:

   - define a new table etherWisFarEndPathCurrentTable;

   - for each WIS interface, require that there be corresponding
   instances of sonetFarEndPathCurrentEntry and
   etherWisFarEndPathCurrentEntry;

   - use the same ifIndex value to index the
   etherWisFarEndPathCurrentEntry and the corresponding
   sonetFarEndPathCurrentEntry (i.e., treat
   etherWisFarEndPathCurrentEntry as sparsely augmenting
   sonetFarEndPathCurrentEntry with WIS-specific extensions);

   - define etherWisFarEndPathCurrentStatus as a read-write BITS
   object with bit positions etherWisFarEndServerDefect(0) and
   etherWisFarEndPayloadDefect(1) to capture the sematics of the
   P802.3ae D3.1 objects aFarEndPathStatus and acClearFarEndPathStatus;

   - include sonetFarEndPathStuff2 in the list of mandatory object
   groups.  The status registers defined in P802.3ae D3.1 provide the
   necessary hardware support to implement the entire object group.

   NOTE:  P802.3ae D3.1 defines three bit positions for
   aFarEndPathStatus corresponding to remote AIS-P, remote LOP-P, and
   remote payload defects (PLM-P and LCD-P), and defines corresponding
   hardware register status bits.  However, P802.3ae also states that
   remote defects are reported via the G1 byte using the ERDI-P codings
   in ANSI T1.416-1999, which in turn references T1.231-1997.  The
   encodings for bits 5, 6, and 7 of the G1 byte are 101/111/100 for
   ERDI-P server defects (triggered by AIS-P or LOP-P), 010 for ERDI-P
   payload defects (triggered by PLM-P or LCD-P), and 110 for ERDI-P
   connectivity defects (which are not used for the WIS application).
   The recommendations above were written to be consistent with the
   definition of ERDI-P in T1.231-1997.  It is recommended that this
   issue be brought to the attention of the P802.3ae working group.

3.  Proposal for a Revised ETHER-WIS MIB Module

   This section proposes a revised ETHER-WIS MIB module that implements
   the recommendations suggested above.  Its structure exactly
   parallels that of the SONET-MIB minus the VT/VC stuff.

3.1.  Prerequisite MIB Modules

   An agent implementing the objects defined in the following MIB module
   MUST implement the objects required by the dot3Compliance2 compliance
   statement in the EtherLike-MIB and by the mauModIfCompl2 compliance
   statement in the MAU-MIB.  In addition, the agent MUST implement the
   SONET-MIB object groups specified in the compliance statement for
   the following module;  in so doing the agent will also meet the
   requirements of the sonetCompliance2 compliance statement in the
   SONET-MIB.  Finally, the agent MUST implement the applicable groups
   of the IF-MIB and SHOULD implement the applicable groups of the
   IF-INVERTED-STACK-MIB.

3.2.  Use of the ifTable and ifStackTable

   An agent implementing the objects defined in the following MIB module
   MUST use the layered interface model shown in the figure below.

           _____________________________   _
          |    LLC Layer                |  |
          +_____________________________+  |
          |    MAC Layer                |  |
          +-----------------------------+  > 1 ifEntry
          |    Reconciliation Sublayer  |  |   ifType: ethernetCsmacd(6)
          +-----------------------------+  |
          |    Physical Coding Sublayer |  |
           -----------------------------   +
          |    Path Layer               |  > 1 ifEntry
          +-----------------------------+  +   ifType: sonetPath(50)
          |    Line Layer               |  |
          +-----------------------------+  |
          |    Section Layer            |  > 1 ifEntry
          +-----------------------------+  |   ifType: sonet(39)
          |    Physical Medium Layer    |  |
           -----------------------------   -

       Use of the ifTable for an Ethernet WIS port

   The usage of the ifTable for the LLC/MAC/RS/PCS layers SHALL be
   as described in <draft-ietf-hubmib-etherif-mib-v3-00.txt> and
   <draft-ietf-hubmib-mau-mib-v3-00.txt>.  The usage of the ifTable
   for the Path layer and for the Line/Section/Medium layers SHALL
   be as described in RFC 2558.  The configuration of the layers SHALL
   be maintained in the ifStackTable [RFC 2863] and the ifInvStackTable
   [RFC 2864].

3.3.  Mapping of IEEE 802.3 Managed Objects

   IEEE 802.3 Managed Object    Corresponding SNMP Object

   oWIS
    aWISID                      IF-MIB - ifIndex
    aSectionStatus,
    acClearSectionStatus        etherWisSectionCurrentStatus
    aLineStatus,
    acClearLineStatus           etherWisLineCurrentStatus
    aPathStatus,
    acClearPathStatus           etherWisPathCurrentStatus
    aFarEndPathStatus,
    acClearFarEndPathStatus     etherWisFarEndPathCurrentStatus
    aSectionSESThreshold        SONET-MIB - sonetSESthresholdSet
    aSectionSESs                SONET-MIB - sonetSectionCurrentSESs +
                                            sonetSectionIntervalSESs
    aSectionESs                 SONET-MIB - sonetSectionCurrentESs +
                                            sonetSectionIntervalESs
    aSectionSEFSs               SONET-MIB - sonetSectionCurrentSEFSs +
                                            sonetSectionIntervalSEFSs
    aSectionCVs                 SONET-MIB - sonetSectionCurrentCVs +
                                            sonetSectionIntervalCVs
    aJ0ValueTX                  etherWisSectionCurrentJ0Transmitted
    aJ0ValueRX                  etherWisSectionCurrentJ0Received
    aLineSESThreshold           SONET-MIB - sonetSESthresholdSet
    aLineSESs                   SONET-MIB - sonetLineCurrentSESs +
                                            sonetLineIntervalSESs
    aLineESs                    SONET-MIB - sonetLineCurrentESs +
                                            sonetLineIntervalESs
    aLineCVs                    SONET-MIB - sonetLineCurrentCVs +
                                            sonetLineIntervalCVs
    aFarEndLineSESs             SONET-MIB - sonetFarEndLineCurrentSESs +
                                            sonetFarEndLineIntervalSESs
    aFarEndLineESs              SONET-MIB - sonetFarEndLineCurrentESs +
                                            sonetFarEndLineIntervalESs
    aFarEndLineCVs              SONET-MIB - sonetFarEndLineCurrentCVs +
                                            sonetFarEndLineIntervalCVs
    aPathSESThreshold           SONET-MIB - sonetSESthresholdSet
    aPathSESs                   SONET-MIB - sonetPathCurrentSESs +
                                            sonetPathIntervalSESs
    aPathESs                    SONET-MIB - sonetPathCurrentESs +
                                            sonetPathIntervalESs
    aPathCVs                    SONET-MIB - sonetPathCurrentCVs +
                                            sonetPathIntervalCVs
    aJ1ValueTX                  etherWisPathCurrentJ1Transmitted
    aJ1ValueRX                  etherWisPathCurrentJ1Received
    aFarEndPathSESs             SONET-MIB - sonetFarEndPathCurrentSESs +
                                            sonetFarEndPathIntervalSESs
    aFarEndPathESs              SONET-MIB - sonetFarEndPathCurrentESs +
                                            sonetFarEndPathIntervalESs
    aFarEndPathCVs              SONET-MIB - sonetFarEndPathCurrentCVs +
                                            sonetFarEndPathIntervalCVs
    acResetWIS                  MAU-MIB - ifMauStatus

3.4.  Revised Object Definitions

   ETHER-WIS DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
       Integer32, transmission       -- instead of mib-2
           FROM SNMPv2-SMI
       ifIndex
           FROM IF-MIB
       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF
       sonetMediumStuff2, sonetSectionStuff2,
       sonetLineStuff2, sonetFarEndLineStuff2,
       sonetPathStuff2, sonetFarEndPathStuff2,
       sonetMediumType, sonetMediumLineCoding,
       sonetMediumLineType, sonetMediumCircuitIdentifier,
       sonetMediumLoopbackConfig, sonetSESthresholdSet
           FROM SONET-MIB;

   etherWisMIB MODULE-IDENTITY
       LAST-UPDATED "200107302358Z"  -- July 30, 2001
       ORGANIZATION "Individual Submission to IETF Ethernet
                    Interfaces and Hub MIB Working Group"
       CONTACT-INFO
           "WG E-mail: [email-masked]
         To subscribe: [email-masked]

                Chair: Dan Romascanu
               Postal: Avaya Inc.
                       Atidum Technology Park, Bldg. 3
                       Tel Aviv 61131
                       Israel
                  Tel: +972 3 645 8414
               E-mail: [email-masked]

            Submitter: C. M. Heard
               Postal: 600 Rainbow Dr. #141
                       Mountain View, CA 94041-2542
                       USA
                  Tel: +1 650-964-8391
               E-mail: [email-masked]"

       DESCRIPTION
         "The objects in this MIB module are used in conjunction
         with objects in the SONET-MIB and the MAU-MIB to manage
         the Ethernet WAN Interface Sublayer (WIS).

         The following reference is used throughout this MIB module:

         [IEEE 802.3 Std] refers to:
            IEEE Std 802.3, 2000 Edition: 'IEEE Standard
            for Information technology -
            Telecommunications and information exchange
            between systems - Local and metropolitan
            area networks - Specific requirements -
            Part 3: Carrier sense multiple access with
            collision detection (CSMA/CD) access method
            and physical layer specifications', as
            ammended by IEEE Draft P802.3ae/D3.1:
            'Supplement to Carrier Sense Multiple Access
            with Collision Detection (CSMA/CD) Access
            Method & Physical Layer Specifications -
            Media Access Control (MAC) Parameters,
            Physical Layer, and Management Parameters
            for 10 Gb/s Operation', June 15, 2001.

         Of particular interest is Clause 30, '10 Mb/s,
         100 Mb/s, 1000 Mb/s, and 10 Gb/s Management'."

       REVISION    "200107302358Z"  -- July 30, 2001
       DESCRIPTION "Initial version."

       ::= { transmission XXX }  -- to be assigned by IANA

   -- The main sections of the module

   etherWisObjects         OBJECT IDENTIFIER ::= { etherWisMIB 1 }

   etherWisObjectsPath     OBJECT IDENTIFIER ::= { etherWisMIB 2 }

   etherWisConformance     OBJECT IDENTIFIER ::= { etherWisMIB 3 }

   -- groups in the Ethernet WIS MIB module

   etherWisDevice          OBJECT IDENTIFIER ::= { etherWisObjects 1 }

   etherWisSection         OBJECT IDENTIFIER ::= { etherWisObjects 2 }

   etherWisLine            OBJECT IDENTIFIER ::= { etherWisObjects 3 }

   etherWisPath            OBJECT IDENTIFIER ::= { etherWisObjectsPath 1 }

   etherWisFarEndPath      OBJECT IDENTIFIER ::= { etherWisObjectsPath 2 }

   -- The Device group

   -- These objects provide WIS extensions to
   -- the SONET-MIB Medium Group.

   etherWisDeviceTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF EtherWisDeviceEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "The table for Ethernet WIS devices"
        ::= { etherWisDevice 1 }

   etherWisDeviceEntry OBJECT-TYPE
       SYNTAX  EtherWisDeviceEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "An entry in the Ethernet WIS device table.  For each
          instance of this object there shall be a corresponding
          instance of sonetMediumEntry."
       INDEX  { ifIndex }
        ::= { etherWisDeviceTable 1}

   EtherWisDeviceEntry ::=
       SEQUENCE {
           etherWisJitterTestPattern           INTEGER,
           etherWisRxJitterTestMode            INTEGER,
           etherWisTxJitterTestMode            INTEGER,
           etherWisJitterTestSeed              INTEGER,
           etherWisJitterErrorCount            Counter64
           }

   etherWisJitterTestPattern OBJECT-TYPE
       SYNTAX  INTEGER {
                   pseudoRandom(0),
                   squareWave(1)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable controls the type of test pattern used for
          jitter testing.  The value pseudoRandom(0) set the test
          pattern to a Pseudo-Random Binary Sequence (PRBS).  The
          value squareWave(1) sets the test pattern to a square wave."
       REFERENCE
          "[IEEE 802.3 Std.], 45.2.2.6 10G WIS Control 2 register
          (2.7), and 45.2.2.6.1 Jitter test pattern (2.7.3)."
        ::= { etherWisDeviceEntry 1 }

   etherWisRxJitterTestMode OBJECT-TYPE
       SYNTAX  INTEGER {
                   disabled(0),
                   enabled(1)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable controls the receive jitter test mode.
          The value disabled(0) set the WIS receive path into
          normal mode.  The value enabled(1) sets the WIS receive
          path into jitter test mode.  It must not be selected
          when the corresponding instance of ifAdminState has
          the value up(1)."
       REFERENCE
          "[IEEE 802.3 Std.], 45.2.2.6, 10G WIS Control 2 register
          (2.7), and 45.2.2.6.2, Receive jitter test mode (2.7.2)."
        ::= { etherWisDeviceEntry 2 }

   etherWisTxJitterTestMode OBJECT-TYPE
       SYNTAX  INTEGER {
                   disabled(0),
                   enabled(1)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable controls the transmit jitter test mode.
          The value disabled(0) set the WIS transmit path into
          normal mode.  The value enabled(1) sets the WIS transmit
          path into jitter test mode.  It must not be selected
          when the corresponding instance of ifAdminState has
          the value up(1)."
       REFERENCE
          "[IEEE 802.3 Std.], 45.2.2.6, 10G WIS Control 2 register
          (2.7), and 45.2.2.6.3, Transmit jitter test mode (2.7.1)."
        ::= { etherWisDeviceEntry 3 }

   etherWisJitterTestSeed OBJECT-TYPE
       SYNTAX  INTEGER (0..65535)
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable controls the transmit jitter test seed.

          When etherWisJitterTestPattern has the value
          pseudoRandom(0) this variable contains a sixteen-bit
          pattern that will be mapped into the scrambled parts
          of the SONET frame (i.e., in all byte positions except
          the A1, A2, J0, and Z0 bytes).  The least significant
          bit will be transmitted first.

          When etherWisJitterTestPattern has the value
          squareWave(0) this variable contains an alternating
          one-zero pattern that controls the square-wave
          transition rate.  The least significant bit will
          be transmitted first.

          The value of this variable must not be altered
          when the value of etherWisRxJitterTestMode or
          etherWisTxJitterTestMode is enabled(1)."
       REFERENCE
          "[IEEE 802.3 Std.], 45.2.2.18, 10G WIS Jitter Test
          Seed register (2.61)."
        ::= { etherWisDeviceEntry 4 }

   etherWisJitterErrorCount OBJECT-TYPE
       SYNTAX  Counter64
       MAX-ACCESS  read-only
       STATUS  current
       DESCRIPTION
          "This variable counts the number of errors obseved
          by the receiver during a jitter test.  At high
          error rates this variable may under-report the
          actual number of errors."
       REFERENCE
          "[IEEE 802.3 Std.], 45.2.2.19, 10G WIS Jitter Test Error
          Counter register (2.62)."
        ::= { etherWisDeviceEntry 5 }

   -- The Section group

   -- These objects provide WIS extensions to
   -- the SONET-MIB Section Group.

   etherWisSectionCurrentTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF EtherWisSectionCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "The table for the current state of Ethernet WIS sections."
        ::= { etherWisSection 1 }

   etherWisSectionCurrentEntry OBJECT-TYPE
       SYNTAX  EtherWisSectionCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "An entry in the etherWisSectionCurrentTable.  For each
          instance of this object there shall be a corresponding
          instance of sonetSectionCurrentEntry."
       INDEX  { ifIndex }
        ::= { etherWisSectionCurrentTable 1 }

   EtherWisSectionCurrentEntry ::=
       SEQUENCE {
           etherWisSectionCurrentStatus        BITS,
           etherWisSectionCurrentJ0Transmitted INTEGER,
           etherWisSectionCurrentJ0Received    INTEGER
           }

   etherWisSectionCurrentStatus OBJECT-TYPE
       SYNTAX  BITS {
                   etherWisSectionLOS(0),
                   etherWisSectionLOF(1)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable indicates the current status of the
          section with a bit map that can indicate multiple
          defects at once.  These bits shall be implemented
          with a latching function, such that the occurrence
          of a particular defect will cause the corresponding
          bit to become set to a one and remain set to one
          until it is unlatched.  A bit is unlatched by a set
          operation specifying a value with that bit set to 1.
          A set operation shall have no effect on (i.e., shall
          not unlatch) bit positions for which it specifies
          a value of 0.

          The bit positions are assigned as follows:

          etherWisSectionLOS(0)
             An LOS (Loss of Signal) defect has been detected
             since the last time this bit position was unlatched.

          etherWisSectionLOF(1)
             An LOF (Loss of Frame) defect has been detected
             since the last time this bit position was unlatched."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.2, aSectionStatus,
          and 30.8.1.2.2, acClearSectionStatus."
        ::= { etherWisSectionCurrentEntry 1 }

   etherWisSectionCurrentJ0Transmitted OBJECT-TYPE
       SYNTAX  INTEGER ( 0..255 )
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This is the section trace J0 byte that is to be
          transmitted.  The value should be set to '01'h
          when the section trace function is not used,
          and the implementation should use that value
          as a default if no other value has been set."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.8, aJ0ValueTX."
        ::= { etherWisSectionCurrentEntry 2 }

   etherWisSectionCurrentJ0Received OBJECT-TYPE
       SYNTAX  INTEGER ( 0..255 )
       MAX-ACCESS  read-only
       STATUS  current
       DESCRIPTION
          "This is the section trace J0 byte that was
          received."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.9, aJ0ValueRX."
        ::= { etherWisSectionCurrentEntry 3 }

   -- The Line group

   -- These objects provide WIS extensions to
   -- the SONET-MIB Line Group.

   etherWisLineCurrentTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF EtherWisLineCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "The table for the current state of Ethernet WIS lines."
        ::= { etherWisLine 1 }

   etherWisLineCurrentEntry OBJECT-TYPE
       SYNTAX  EtherWisLineCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "An entry in the etherWisLineCurrentTable.  For each
          instance of this object there shall be a corresponding
          instance of sonetLineCurrentEntry."
       INDEX  { ifIndex }
        ::= { etherWisLineCurrentTable 1 }

   EtherWisLineCurrentEntry ::=
       SEQUENCE {
           etherWisLineCurrentStatus           BITS
           }

   etherWisLineCurrentStatus OBJECT-TYPE
       SYNTAX  BITS {
                   etherWisLineAIS(0),
                   etherWisLineRDI(1)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable indicates the current status of the
          line with a bit map that can indicate multiple
          defects at once.  These bits shall be implemented
          with a latching function, such that the occurrence
          of a particular defect will cause the corresponding
          bit to become set to a one and remain set to one
          until it is unlatched.  A bit is unlatched by a set
          operation specifying a value with that bit set to 1.
          A set operation shall have no effect on (i.e., shall
          not unlatch) bit positions for which it specifies
          a value of 0.

          The bit positions are assigned as follows:

          etherWisLineAIS(0)
             An AIS-L (Alarm Indication Signal - Line)
             defect has been detected since the last
             time this bit position was unlatched.

          etherWisLineRDI(1)
             An RDI-L (Remote Defect Indication - Line)
             defect has been detected since the last
             time this bit position was unlatched."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.10, aLineStatus,
          and 30.8.1.2.3, acClearLineStatus."
        ::= { etherWisLineCurrentEntry 1 }

   -- The Path group

   -- These objects provide WIS extensions to
   -- the SONET-MIB Path Group.

   etherWisPathCurrentTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF EtherWisPathCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "The table for the current state of Ethernet WIS paths."
        ::= { etherWisPath 1 }

   etherWisPathCurrentEntry OBJECT-TYPE
       SYNTAX  EtherWisPathCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "An entry in the etherWisPathCurrentTable.  For each
          instance of this object there shall be a corresponding
          instance of sonetPathCurrentEntry."
       INDEX  { ifIndex }
        ::= { etherWisPathCurrentTable 1 }

   EtherWisPathCurrentEntry ::=
       SEQUENCE {
           etherWisPathCurrentStatus           BITS,
           etherWisPathCurrentJ1Transmitted    OCTET STRING,
           etherWisPathCurrentJ1Received       OCTET STRING
           }

   etherWisPathCurrentStatus OBJECT-TYPE
       SYNTAX  BITS {
                   etherWisPathLOP(0),
                   etherWisPathAIS(1),
                   etherWisPathPLM(2),
                   etherWisPathLCD(3)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable indicates the current status of the
          path with a bit map that can indicate multiple
          defects at once.  These bits shall be implemented
          with a latching function, such that the occurrence
          of a particular defect will cause the corresponding
          bit to become set to a one and remain set to one
          until it is unlatched.  A bit is unlatched by a set
          operation specifying a value with that bit set to 1.
          A set operation shall have no effect on (i.e., shall
          not unlatch) bit positions for which it specifies
          a value of 0.

          The bit positions are assigned as follows:

          etherWisPathLOP(0)
             An LOP-P (Loss of Pointer - Path)
             defect has been detected since the last
             time this bit position was unlatched.

          etherWisPathAIS(1)
             An AIS-P (Alarm Indication Signal - Path)
             defect has been detected since the last
             time this bit position was unlatched.

          etherWisPathPLM(1)
             A PLM-P (Payload Label Mismatch - Path)
             defect has been detected since the last
             time this bit position was unlatched.

          etherWisPathLCD(3)
             An LCD-P (Loss of Codegroup Delination - Path)
             defect has been detected since the last
             time this bit position was unlatched."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.18, aPathStatus,
          and 30.8.1.2.4, acClearPathStatus."
        ::= { etherWisPathCurrentEntry 1 }

   etherWisPathCurrentJ1Transmitted OBJECT-TYPE
       SYNTAX  OCTET STRING (SIZE (16))
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This is the 16-octet path message that is to
          be transmitted in the J1 byte.  The value should
          be fifteen octets of '00'h followed by '89'h
          (or some cyclic shift thereof) when the path
          trace function is not used, and the implementation
          should use that value (or a cyclic shift thereof)
          as a default if no other value has been set."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.23, aJ1ValueTX."
        ::= { etherWisPathCurrentEntry 2 }

   etherWisPathCurrentJ1Received OBJECT-TYPE
       SYNTAX  OCTET STRING (SIZE (16))
       MAX-ACCESS  read-only
       STATUS  current
       DESCRIPTION
          "This is the 16-octet path trace message that
          was received in the J1 byte."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.24, aJ1ValueRX."
        ::= { etherWisPathCurrentEntry 3 }

   -- The Far End Path group

   -- These objects provide WIS extensions to
   -- the SONET-MIB Far End Path Group.

   etherWisFarEndPathCurrentTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF EtherWisFarEndPathCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "The table for the current far-end state of Ethernet WIS paths."
        ::= { etherWisFarEndPath 1 }

   etherWisFarEndPathCurrentEntry OBJECT-TYPE
       SYNTAX  EtherWisFarEndPathCurrentEntry
       MAX-ACCESS  not-accessible
       STATUS  current
       DESCRIPTION
          "An entry in the etherWisFarEndPathCurrentTable.  For each
          instance of this object there shall be a corresponding
          instance of sonetFarEndPathCurrentEntry."
       INDEX  { ifIndex }
        ::= { etherWisFarEndPathCurrentTable 1 }

   EtherWisFarEndPathCurrentEntry ::=
       SEQUENCE {
           etherWisFarEndPathCurrentStatus     BITS
           }

   etherWisFarEndPathCurrentStatus OBJECT-TYPE
       SYNTAX  BITS {
                   etherWisFarEndServerDefect(0),
                   etherWisFarEndPayloadDefect(1)
               }
       MAX-ACCESS  read-write
       STATUS  current
       DESCRIPTION
          "This variable indicates the current status at the
          far end of the path using a bit map that can indicate
          multiple defects at once.  These bits shall be implemented
          with a latching function, such that the occurrence
          of a particular defect will cause the corresponding
          bit to become set to a one and remain set to one
          until unlatched.  A bit is unlatched by a set
          operation specifying a value with that bit set to 1.
          A set operation shall have no effect on (i.e., shall
          not unlatch) bit positions for which it specifies
          a value of 0.

          The bit positions are assigned as follows:

          etherWisFarEndServerDefect(0)
             A far end server defect (i.e., far end
             LOP-P or AIS-P) has been detected since
             the last time this bit position was unlatched.

          etherWisFarEndPayloadDefect(1)
             A far end server defect (i.e., far end
             PLM-P or LCD-P) has been detected since
             the last time this bit position was unlatched."
       REFERENCE
          "[IEEE 802.3 Std.], 30.8.1.1.25, aFarEndPathStatus,
          and 30.8.1.2.5, acClearFarEndPathStatus."
        ::= { etherWisFarEndPathCurrentEntry 1 }

   --
   --     Conformance Statements
   --

   etherWisGroups      OBJECT IDENTIFIER ::= { etherWisConformance 1 }

   etherWisCompliances OBJECT IDENTIFIER ::= { etherWisConformance 2 }

   --     Object Groups

   etherWisDeviceGroup OBJECT-GROUP
       OBJECTS {
           etherWisJitterTestPattern,
           etherWisRxJitterTestMode,
           etherWisTxJitterTestMode,
           etherWisJitterTestSeed,
           etherWisJitterErrorCount
           }
       STATUS  current
       DESCRIPTION
          "A collection of objects that control test
          features required of all WIS devices."
        ::= { etherWisGroups 1 }

   etherWisSectionGroup OBJECT-GROUP
       OBJECTS {
           etherWisSectionCurrentStatus,
           etherWisSectionCurrentJ0Transmitted,
           etherWisSectionCurrentJ0Received
           }
       STATUS  current
       DESCRIPTION
          "A collection of objects that provide
          required information about a WIS section."
        ::= { etherWisGroups 2 }

   etherWisLineGroup OBJECT-GROUP
       OBJECTS {
           etherWisLineCurrentStatus
           }
       STATUS  current
       DESCRIPTION
          "A collection of objects that provide
          required information about a WIS line."
        ::= { etherWisGroups 3 }

   etherWisPathGroup OBJECT-GROUP
       OBJECTS {
           etherWisPathCurrentStatus,
           etherWisPathCurrentJ1Transmitted,
           etherWisPathCurrentJ1Received
           }
       STATUS  current
       DESCRIPTION
          "A collection of objects that provide
          required information about a WIS path."
        ::= { etherWisGroups 4 }

   etherWisFarEndPathGroup OBJECT-GROUP
       OBJECTS {
           etherWisFarEndPathCurrentStatus
           }
       STATUS  current
       DESCRIPTION
          "A collection of objects that provide required
          information about the far end of a WIS path."
        ::= { etherWisGroups 5 }

   --     Compliance Statements

   etherWisCurrentCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
          "The compliance statement for this module."

       MODULE  -- this module
           MANDATORY-GROUPS {
               etherWisDeviceGroup,
               etherWisSectionGroup,
               etherWisLineGroup,
               etherWisPathGroup,
               etherWisFarEndPathGroup
               }

       MODULE SONET-MIB
           MANDATORY-GROUPS {
               sonetMediumStuff2,
               sonetSectionStuff2,
               sonetLineStuff2,
               sonetFarEndLineStuff2,
               sonetPathStuff2,
               sonetFarEndPathStuff2
               }

           OBJECT      sonetMediumType
           SYNTAX      INTEGER {
               sonet(1)
               }
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required, nor is support
               for any value other than sonet(1)."

           OBJECT      sonetMediumLineCoding
           SYNTAX      INTEGER {
               sonetMediumNRZ(4)
               }
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required, nor is support
               for any value other than sonetMediumNRZ(4)."

           OBJECT      sonetMediumLineType
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required."

           OBJECT      sonetMediumCircuitIdentifier
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required."

           OBJECT      sonetMediumLoopbackConfig
           SYNTAX      BITS {
               sonetNoLoop(0),
               sonetFacilityLoop(1)
               }
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required, nor is support for values
               other than sonetNoLoop(0) and sonetFacilityLoop(1)."

           OBJECT      sonetSESthresholdSet
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required, and only one
               of the enumerated values need be supported."

           OBJECT      sonetPathCurrentWidth
           SYNTAX      INTEGER {
               sts192cSTM64(6)
               }
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required, nor is support
               for any value other than sts192cSTM64(6)."

        ::= { etherWisCompliances 1 }

   END

_______________________________________________
Hubmib mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hubmib

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 31 Jul 2001 17:21:59 -0500

> From: C. M. Heard [mailto:[email-masked]] 
> Sent: Monday, July 30, 2001 06:42 PM
> To: Hubmib Working Group; AToMMIB Working Group
> Subject: [Hubmib] Comments on <draft-ietf-hubmib-wis-mib-00.txt>

	Thanks for putting the time and effort into this extensive
commentary.  I will read it in its entirety, most likely on the flight to
London, and keep it in consideration.

/|/|ike