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

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 2 Nov 2003 05:58:38 -0500

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.

Replace

   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 }

With

   ituAlarmEntry OBJECT-TYPE
      SYNTAX      ItuAlarmEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Entries appear in this table for each possible alarm
           severity. For each entry created/deleted in the 
           alarmModeTable an entry in this table is created/deleted 
           with a mapping from alarmModelState to 
           ituAlarmPerceivedSeverity as follows:
	
           alarmModelState -> ituAlarmPerceivedSeverity 
                  1        ->         clear (1) 
                  2        ->         indeterminate (2) 
                  3        ->         warning (6) 
                  4        ->         minor (5) 
                  5        ->         major (4) 
                  6        ->         critical (3)

           All other values of alarmModelState MUST NOT appear
           in this table.

           This table MUST be persistent across system reboots."
      INDEX       { alarmListName, alarmModelIndex,
                   ituAlarmPerceivedSeverity }
      ::= { ituAlarmTable 1 }

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Wednesday, October 22, 2003 8:55 AM
To: Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

Hi

The behaviour of the any additional extended MIBs will be defined in the
extended MIBs. It doesn't make sense to define it here.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 2:56 AM
To: Disman (E-mail)
Subject: Re: [Disman] alarm comment 69-1

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Monday, October 20, 2003 6:17 AM
> Subject: RE: [Disman] alarm comment 69-1
...
> 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.
...

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: Fri, 7 Nov 2003 19:29:50 -0800

Hi -

> Sent: Sunday, November 02, 2003 2:58 AM

...

Let's see if I understand this correctly.  If a system supports the ituAlarmTable,
then whenever an entry is created (whether by user or by system) in the
alarmModelTabel with an alarmModelState value of 1, 2, 3, 4, 5, or 6, then
a corresponding entry will appear in the ituAlarmTable.  Likewise, whenever
an entry is deleted from the ituAlarmTable, and that entry has an alarmModelState
value of 1..6, any corresponding entry will disappear from the ituAlarmTable.
So far, so good?

Here's my problem: if the system also supports some other extension model which
does not necessarily map to the ITU model, then even if that model is able to
avoid alarmModelState values of 2, 3, 4, 5, and 6, I don't see how it could avoid
using alarmModelState value 1, and consequently ending up with entries in both
the ituAlarmTable as well as this other extension table for alarmModelState 1.
Do you consider this to be a feature rather than a bug?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 7 Nov 2003 19:29:50 -0800

Hi -

...

Randy