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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 8 Oct 2002 12:18:02 +0200

W.r.t the root of the MIB, I think that Mike Heard last Friday actually gave a pretty good
argument to just leave it as you have it in your current draft.

Thanks,
Bert 

-----Original Message-----
From: Orly Nicklass [mailto:[email-masked]]
Sent: dinsdag 8 oktober 2002 9:32
To: Michael Thatcher; [email-masked]; [email-masked]
Subject: RE: Last Call: Definitions of Managed Objects for SONET Linear APS Architectures to Proposed Standard

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] <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