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

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 19 Oct 2003 15:07:36 -0400

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: "Sharon Chisholm" <[email-masked]>
Date: Sun, 19 Oct 2003 15:07:36 -0400

Hi

       

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 -

<[email-masked]>
...
...

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Oct 2003 14:39:23 +0200

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Oct 2003 14:39:23 +0200

Regards,

Dan

---

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

> objection, this item will be considered closed conditional on the 
> proposed edit being done.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 11:57:48 +0200

Let me try.

> Sent: 22 October, 2003 8:56 AM
> To: Disman (E-mail)
> Subject: Re: [Disman] alarm comment 69-1
> 
> 
> 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?

This is specific to the extension model. A mapping table, as proposed by Sharon defines what is required for the ITU Alarm model. Other models would define different mappings. 

>     2) presumably all models will have an alarmModelState 
> value of zero.

Not clear. Actually the SYNTAX of alarmModelState is Unsigned32 (1..4294967295). Sharon's proposed mapping table needs probably to be amended by increase by one all values of alarmModelState. If you mean that all models will map into cleared state, yes - I agree. 

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

All models will have a mapping into alarm cleared state defined in their mapping table.  

>     3) what causes deletion of rows in these tables?

for example the removal of a subsystem that supports a specific model in the system and is the only one that does it.

> Randy

I hope this helps. 

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 11:57:48 +0200

Let me try.

I hope this helps. 

Regards,

Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Oct 2003 08:52:21 -0400

Hi

<sharon>
> > alarmModelState = 0; ituAlarmPerceivedSeverity = 1 alarmModelState = 
> > 1; ituAlarmPerceivedSeverity = 2 alarmModelState = 2; 
> > ituAlarmPerceivedSeverity = 6 alarmModelState = 3; 
> > ituAlarmPerceivedSeverity = 5 alarmModelState = 4; 
> > ituAlarmPerceivedSeverity = 4 alarmModelState = 5; 
> > ituAlarmPerceivedSeverity = 3
> >
<dan>
Not clear. Actually the SYNTAX of alarmModelState is Unsigned32
(1..4294967295). Sharon's proposed mapping table needs probably to be
amended by increase by one all values of alarmModelState. If you mean that
all models will map into cleared state, yes - I agree.
</dan>

No, that is a typo in my mapping. The numbers in the mapping shoulds start
at 1. 

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Oct 2003 08:52:21 -0400

Hi

<sharon>
<dan>

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Oct 2003 08:55:20 -0400

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 -

...
> 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.
>
> ituAlarmPerceivedSeverity, then rows can automatically be created on 
> systems capable of supporting the ITU-T extensions.
>
> 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: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Oct 2003 08:55:20 -0400

Hi

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 -

...
...

Randy