Subject: RE: [Disman] alarm comment 69-1

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 20 Oct 2003 09:17:13 -0400

Hi

The intention was certainly to have the rows created by the system when the
alarmModelTable rows are created. We did have a small hole in this strategy
which I've just over-engineered by suggesting we add a rowStatus object.
But, you are right, a simpler approach would be better.

If we define a default mapping from alarmModelState to
ituAlarmPerceivedSeverity, then rows can automatically be created on systems
capable of supporting the ITU-T extensions.

alarmModelState = 0; ituAlarmPerceivedSeverity = 1
alarmModelState = 1; ituAlarmPerceivedSeverity = 2
alarmModelState = 2; ituAlarmPerceivedSeverity = 6
alarmModelState = 3; ituAlarmPerceivedSeverity = 5
alarmModelState = 4; ituAlarmPerceivedSeverity = 4
alarmModelState = 5; ituAlarmPerceivedSeverity = 3

All other alarmModelState values will not cause the creation of rows in the
ituAlarmTable.

Sharon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, October 20, 2003 8:39 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

I do not think that this change reflects our intentions with the
ituAlarmTable. 

For a specific device / system entries in this table are specific to the
device / system capabilities. A manager cannot create new entries, if there
are no capabilities to support the EventType and Probable Cause. This is why
we decided from the beginning that entries are created in this table
'automagically', when the model is supported, by the agent, function of the
system / device capabilities. What a manager can change is the perceived
severity he/she wants the alarm to be stamped with, and the additional text.

I think that the fix is to make ituAlarmEventType and ituAlarmProbableCause
read-only, but not to add a RowStatus object.

Regards,

Dan

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: 19 October, 2003 9:08 PM
> To: Disman (E-mail)
> Subject: RE: [Disman] alarm comment 69-1
> 
> 
> Hi
> 
> The following is the proposed resolution to Randy-69-1  Assuming no 
> objection, this item will be considered closed conditional on the 
> proposed edit being done.
> 
> The following object will be added to the ituAlarmTable
> 
>    ituAlarmRowStatus OBJECT-TYPE
>       SYNTAX     RowStatus
>       MAX-ACCESS read-create
>       STATUS     current
>       DESCRIPTION
>        "Control for creating and deleting entries.
>        
>        ituAlarmPerceivedSeverity and ituAlarmGenericModel must 
>        be set before this row can go active. Entries may be
>        modified while active. Alarms whose ituAlarmRowStatus is
>        not active will not appear in the ituAlarmActiveTable.
>        Setting this object to notInService
>        cannot be used as an alarm suppression mechanism. Entries
>        that are notInService will disappear as described in RFC2579.
> 
>        This row can not be modified or deleted while there is an 
>        instance of this alarm in the ituAlarmActiveTable. In these
>        cases, an error of `inconsistentValue' will be returned to
>        the manager."
>       ::= { ituAlarmEntry 6 }
> 
> And default values of 'other' will be added to ituAlarmEventType and 
> ituAlarmProbableCause and of "" to ituAlarmAdditionalText.
> 
> Sharon
> 
> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Tuesday, October 07, 2003 3:19 PM
> To: Disman (E-mail)
> Subject: [Disman] alarm comment 69-1
> 
> 
> Hi -
> 
> > From: "Sharon Chisholm" <[email-masked]>
> > To: "Disman (E-mail)" <[email-masked]>
> > Cc: <[email-masked]>; "Randy Presuhn"
> > <[email-masked]>; "Romascanu, Dan (Dan)"
> <[email-masked]>
> > Sent: Monday, September 29, 2003 7:34 AM
> > Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
> ...
> > 69-1) ituAlarmEntry: the DESCRIPTION needs to say something
> about how
> >     rows in this table come into existence.  Currently, it
> looks like
> >     immaculate conception.  If these things are created
> under management
> >     control, then I'd strongly suggest DEFVALs for
> > ituAlarmPerceivedSeverity,
> >     ituAlarmEventType, ituAlarmProbableCause, and 
> > ituAlarmAdditionalText.
> ...
> 
> Let me step through my reasoning for wanting a clearer
> description of the
> lifecycle of these things.  Perhaps someone can point out 
> where I've gone
> wrong, or, if my reasoning is correct, how we might fix things.
> 
> Currently, the table definition reads:
>    ituAlarmTable OBJECT-TYPE
>       SYNTAX      SEQUENCE OF ItuAlarmEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "A table of ITU Alarm information for possible alarms
>           on the system."
>       ::= { ituAlarmModel 1 }
> 
>    ituAlarmEntry OBJECT-TYPE
>       SYNTAX      ItuAlarmEntry
>       MAX-ACCESS  not-accessible
>       STATUS      current
>       DESCRIPTION
>           "Entries appear in this table for each possible alarm
>            severity.
>            This table MUST be persistent across system reboots."
>       INDEX       { alarmListName, alarmModelIndex,
>                    ituAlarmPerceivedSeverity }
>       ::= { ituAlarmTable 1 }
> 
> The DESCRIPTIONs (and lack of RowStatus) would lead one to
> believe that
> these are static tables that describe the possible severity 
> levels that can
> occur on a system.  However, the INDEX structure ties these to the
> alarmModelTable. Entries in the alarmModelTable may be 
> created (and deleted)
> using AlarmModelRowStatus, so the values of alarmListName and
> alarmModelIndex may be coming from a manager somewhere.  This 
> begs several
> questions:
>     1) when a new alarm model is created using RowStatus, do 
> corresponding
>         entries automagically appear in the ituAlarmTable?  
> Do they appear
> as
>         a side-effect of setting alarmModelSpecificPointer?  
> If so, are the
>         indexing constraints on possible legal values for this pointer
> enforced
>         by the agent?
>     2) If corresponding entries automatically appear in the 
> ituAlarmTable
> when
>         new alarmModelTable entries are created, how are the 
> values for the
>         various columns supplied?
>     3) if an alarmModelEntry is deleted, what happens to the 
> corresponding
>         ituAlarmModelEntries (since it's a one-to-many 
> relationship due to
>         ituAlarmPerceivedSeverity, I assume they will always 
> appear and
> disappear
>         six at a time.)
> 
> Does this help to explain why I'd like the DESCRIPTIONs to
> better explain
> what's going on with this table?
> 
> Randy
> 
> 
> 
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 23:56:02 -0700

Hi -

> Sent: Monday, October 20, 2003 6:17 AM
...
...

I'm trying to understand the implications of this proposal if a system supports
other extension models in addition to the ITU-T one.

    1) what values of alarmModelState will cause auto-creation of rows in
        other extension model MIBs?
    2) presumably all models will have an alarmModelState value of zero.
       How does a given extension model know whether it is the one (from
       potentially many MIBs) that needs to create a row mapping to
       alarmModelState zero?
    3) what causes deletion of rows in these tables?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 21 Oct 2003 23:56:02 -0700

Hi -

...
...

Randy