Subject: draft-ietf-atommib-sonetaps-mib-06.txt

From: Jim Kuhfeld <[email-masked]>
Date: Mon, 18 Mar 2002 19:00:43 -0800

Attached is the latest draft of the APS-MIB and a diff of the nroff source 
between this version and the 05 draft. A list of changes follows. Normal
submission of drafts was still blocked as of this morning, so I am posting
this directly to the working group at Faye's request. The official submission
will follow.

-------

SUMMARY OF CHANGES BETWEEN draft-ietf-atommib-sonetaps-mib-05.txt AND  
draft-ietf-atommib-sonetaps-mib-06.txt

The reference to peer SNMPv1 definitions in the Abstract was deleted.

The term MIB was used instead of mib.

Section 3, Object Definitions, was seen as redundant and was eliminated. 

The DESCRIPTION for apsConfigGroups was clarified.

A StorageType field was added to ApsConfigEntry and ApsChanConfigEntry.

apsStatusEntry now AUGMENTS { apsConfigEntry }.

Counter discontinuity TimeStamp objects were added to ApsStatusEntry and 
ApsChanStatusEntry.

The object apsMapIfIndex was deleted from ApsMapEntry and apsMapEntry
now uses INDEX { ifIndex }.

apsChanStatusEntry now AUGMENTS { apsChanConfigEntry }.

A Wait-to-Restore bit, wtr, was added to apsChanStatusCurrent.

apsChanStatusSwitchovers and apsChanStatusLastSwitchover now
note switchovers from the protection line back to a working line.

A potential instance of counter discontinuity has been noted in the 
DESCRIPTION of apsChanStatusSwitchoverSeconds.

apsNotificationEnable has been added as a means to enable and disable
notifications defined in the MIB.

There are now two compliance statements, one for read-write compliance 
and one for read-only compliance.

The name of NOTIFICATION-GROUP apsEventOptional was changed to 
apsEventGroup.

The Security Considerations section provides a list of objects which
could potentially disrupt APS operations.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 19 Mar 2002 09:27:18 -0800 (PST)

On Mon, 18 Mar 2002, Jim Kuhfeld wrote:
> this directly to the working group at Faye's request. The official
> submission will follow.

While scanning through the nroff diffs I noticed this:

   apsChanStatusSignalFailures OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "A count of Signal Failure conditions that have been
            detected on the incoming signal. This condition occurs
            when a loss of signal, loss of frame, AIS-L or a Line
            bit error rate exceeding 10^-3 is detected on an
            incoming line.           ^^^^^

Instead of "10^-3" this should be "the currently configured SF BER
threshold" or possibly "the value of the relevant instance of
apsConfigSfBerThreshold".

In the degrade counter definition there is a related problem, although
it is very minor:

   apsChanStatusSignalDegrades OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "A count of Signal Degrade conditions. This
            condition occurs when the line Bit Error Rate
            exceeds the currently configured threshold.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should probably say "currently configured SD BER threshold"
or "the value of the relevant instance of apsConfigSdBerThreshold".

Hopefully these can be fixed prior to official I-D submission.  If
not I will mention them in IETF last call.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 20 Mar 2002 20:33:36 -0800 (PST)

> this directly to the working group at Faye's request. The official

While reading through the text of Section 3 I noticed the following
discrepancy:

   The apsChanConfigTable supports addition, modification and deletion
   of entries representing linear APS channels.  Entries are indexed by
   a text group name and integer channel number. Each entry contains an
   InterfaceIndex value identifying the SONET LTE used for the channel
   and the priority of the channel. A side effect of row creation or
   deletion is the setting of map entry fields. Creation of 2-14 entries
                                                              ^^
                                                              15
   in this table with a common group name index and consecutive channel
   numbers beginning with zero is the first step in the creation and
   configuration of an APS group. It is not necessary to create channel
   numbers in order, however the resulting set of channels must begin
   with channel number 0 and must be consecutive. However, if the
   onePlusOneOptimized architecture is selected, the set of channel
   numbers begins with 1 instead of 0. Note that the term null channel,
   which is used throughout this document refers to the protection line.

Rationale:  except in the onePlusOneOptimized architecture the channel
numbers range from 0 to 14, hence there may be up to 15 channels total.

Also, the above text seems a bit awkward to my ear.  Since one is
usually asked to propose a remedy when one complains about something, let
me suggest the following replacement text for the 5th sentence onward:

   Creation of two or more entries in this table with a common group
   name index and consecutive channel numbers is the first step in the
   creation and configuration of an APS group.  It is not necessary to
   create channel numbers in order;  however, before an APS group is
   made active, the set of channels must begin with channel number 0
   (for architectures other than onePlusOneOptimized) or channel
   number 1 (for the onePlusOneOptimized architecture) and must have
   consecutive channel numbers not exceeding 14.  Note that the term
   null channel, which is used throughout this document, refers to
   the protection line.

I'm not sure if it's necessary to mention that for architectures
other than oneToN there must be exactly two channels.  Probably
the authors can do a better wordsmithing job than this.

Thanks,

Mike