Subject: RE: Last Call: Definitions of Managed Objects for SONET Linear APS Architectures to Proposed Standard

From: "Orly Nicklass" <[email-masked]>
Date: Tue, 8 Oct 2002 09:32:12 +0200

Erik, Faye,

Since I did not see any significant problem raised by the list for the addition of the new value, and today is the last day of the CALL, can we close this with the improved description as suggested by Mike (see below)?,

As for the root of the MIB, I don't see much consensus either way.

apsConfigMode OBJECT-TYPE
>     SYNTAX      INTEGER {
>                         onePlusOne(1),
>                         oneToN(2),
>                         onePlusOneCompatible(3),
>                         onePlusOneOptimized(4),
>                         other(5)
>                         }
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>        "The architecture of the APS group.
[ ... ]
>         other
>
>         The APS group is configured with an architecture other
>         that those explicitly described in this MIB.
          Any implementation that supports this value must         +
          document any restrictions that it implies with respect   +
          to the other objects in this MIB.                        +

>         This object may not be modified if the associated
>         apsConfigRowStatus object is equal to active(1)."
>     DEFVAL {onePlusOne}
>     ::= { apsConfigEntry 3 }

-----Original Message-----
From: Michael Thatcher [mailto:[email-masked]]
Sent: Friday, October 04, 2002 1:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Last Call: Definitions of Managed Objects for SONET Linear
APS Architectures to Proposed Standard

Orly raised 2 issues with the Sonet APS mib during IETF last call.

     (1)
     I noticed that the MIB is defined to be under transmission,
     however, since it is
     SONET related, doesn't it make more sense to put it under
     SONET like:
     :: ={sonetMIB XX }
     where XX can be 4
     instead of
     :: = { transmission XX } ?

Placing APS-MIB under SonetMIB causes two problems.  It makes the mib
dependant on the SonetMIB when currently there is no such dependancy.
The value  of  XX in {SonetMIB XX} is not defined and would require
definition in SONET-MIB or some agency to monitor/control assignment
such that any changes to SONET-MIB does not use the value of XX.  It's
not worth the effort.

     (2)
     unusual request:
     the following object
     apsConfigMode OBJECT-TYPE
            SYNTAX      INTEGER {
                                onePlusOne(1),
                                oneToN(2),
                                onePlusOneCompatible(3),
                                onePlusOneOptimized(4)
                                }
     had several changes over the cycles of the draft. Currently it
     seems like we are
     dealing with ports that are connected independent of each
     other. There are cases
     where ports are connected via Y cable, and the active port
     changed based on
     failure. It is not the APS protocol as defined by the ITU
     document but the MIB can
     serve that purpose as well. Such installation is very common
     and popular  in the
     field. Is it possible to have more options for the mode of
     switching, to support
     such? something like  others(6) could serve well  for options
     that are currently not
     defined by the STD but might be used by companies.

Jim Kuhfeld identified this as an issue raised over 2 years ago with no
response to suggested resolution.  Trying to add 'other' to
apsConfigMode has potential implications on other objects, e.g.
apsConfigRevert.   I think trying to address this during IETF last call
is not appropriate because there has been adequate time for the issue to
have been addressed in the past 2 years.

Mike Thatcher

---

From: Mike Thatcher <[email-masked]>
Date: Tue, 08 Oct 2002 08:43:55 -0700

Orly Nicklass wrote:
> Erik, Faye,
> 
> Since I did not see any significant problem raised by the list for the 
> addition of the new value, and today is the last day of the CALL, can we 
> close this with the improved description as suggested by Mike (see below)?,
> 

I don't understand this statement.  Mike Heard had significant issues with 
adding the new value.  I had and still have issues because it is not clear what 
impact this change has with other objects and the fact that it's being addressed 
during ietf last call when the issue was raised 2 years ago and dropped.

> As for the root of the MIB, I don't see much consensus either way.

It seems to me that consenus is to leave it as it is.