Subject: RE: ARC MIB Improvement

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Fri, 23 Mar 2001 22:47:38 -0500

Tammy:

	This makes a big difference!!!
	So, when ARC is activated to an managed entity (resource), all
associated alarms are 
	suppressed/deferred.

	Is there any need to have ARC per alarm types?  Can we eliminate
this?

Anni
> ----------
> From: 	Tammy Ferris[SMTP:[email-masked]]
> Sent: 	Friday, March 23, 2001 10:09 PM
> Cc: 	[email-masked]'
> Subject: 	Re: ARC MIB Improvement
> 
> 
> Kam,
> I would like some way to specify "all" alarm types which is the default
> and
> expected to be the most typical setting for ARC  and also better matches
> the ITU
> 
> model.
> Tammy
> 
> "Lam, Hing-Kam (Kam)" wrote:
> 
> > All,
> >
> > At the end of the ARC MIB presentation on Monday (3/19), I briefly
> mentioned
> > about the possible improvement of the MIB but didn't have time to go
> into
> > details. Here are the details of improving the 00 version (
> > http://www.ietf.org/internet-drafts/draft-lam-disman-arcmib-00.txt ).
> >
> > (1) As Dave suggested before, the ARC table will only have rows with ARC
> > state values other than ALM. That is, once a resource transitions from a
> ARC
> > mode state (i.e., NALM, NALM-QI[-CD], or NALM-TI) to the ALM state, the
> > entry will be deleted automatically from the ARC table.
> >
> > (2) Remove the arcNalmTITimeInterval and the arcNalmCDTimeInterval
> objects
> > to outside of the ARC table. Outside of the table allows these two
> interval
> > to be used as default values for all applicable resoruces. In this way,
> the
> > ARC table will be reduced from 6 columns to 4 columns only. The 4
> columns
> > are arcIndex (identifying the resource), arcAlarmType (i.e., the
> condition
> > to be controlled, e.g., LOS), arcState (NALM, NALM-TI, or NALM-QI), and
> > arcNalmTimeRemainding.
> > At the creation of an ARC entry for a resource, the initial value for
> > arcNalmTimeRemainding will be the value of arcNalmTITimeInterval (if the
> ARC
> > state is NALM-TI) or arcNalmCDTimeInterval (if the ARC state is NALM-QI)
> or
> > zero (if the ARC state is NALM).
> > On the other, at the creation of an ARC entry, the manager may specify a
> > value for arcNalmTimeRemainding to override the default value, if
> needed.
> > This change will make the table smaller and also avoid holes in the
> table if
> > TI and QI are not supported for a resource.
> >
> > (3) Change the arcNalmTimeRemainding object from read-only to
> read-write.
> > This will allow the manager to increase or decrease the value when the
> > resource is in the NALM-TI or the NALM-QI-CD (if supported) state. This
> is
> > particularly useful in the case of performing maintenance on the
> resource
> > when the technician needs to increase or decrease the allowed time.
> >
> > I believe that (1) will make the ARC MIB scale better. (2) will simplify
> the
> > MIB. Both (2) and (3) meet the ARC requirements better.
> > Any comments?
> >
> > Regards,
> > Kam
>

---

From: Tammy Ferris <[email-masked]>
Date: Mon, 26 Mar 2001 09:12:04 -0600

An-Ni,
How about something like the following:
alarmSet OBJECT-TYPE  SYNTAX  INTEGER    {
              allAlarms (0),
              alarmSubset1 (1),
              alarmSubset2 (2),
              alarmSubset3 (3),
              alarmSubset4 (4),
              alarmSubset5 (5),
              alarmSubset6 (6),
              alarmSubset7 (7)
              }
      MAX-ACCESS read-write
      STATUS       current
      DESCRIPTION
               " Identifies the set of alarms to be controlled."
       ::= { TBD TBD }

With the above, there is still the flexibility to configure a subset.  How this
configuration occurs could be left out of the standard or a generic way
specified.

What do you think?
Tammy