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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 9 Nov 2003 00:52:04 +0200

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

yes.

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

A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear alarm state'. Concurrent specific models MAY support a clear alarm state. 

> Randy

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 9 Nov 2003 00:52:04 +0200

yes.

Dan

---

From: Randy Presuhn <[email-masked]>
Date: Sun, 9 Nov 2003 15:34:38 -0600 (GMT-06:00)

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> Sent: Nov 8, 2003 4:52 PM
> To: Randy Presuhn <[email-masked]>,
>	"Disman (E-mail)" <[email-masked]>
...
> A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear alarm state'.
> Concurrent specific models MAY support a clear alarm state. 
...

It'd be very difficult to define an extension model without a clear state, since that
notion is built into both the alarmModelTable and the alarmClearTable.  Anyway,
in a case like this, where there would be entries in both extension tables,
to which one would the alarmModelSpecificPointer point?

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Sun, 9 Nov 2003 15:34:38 -0600 (GMT-06:00)

Hi -

...
...

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Nov 2003 07:38:48 -0500

Hi

As Dan indicated, this is a feature. It doesn't matter which one the
specific pointer points at. 

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, November 09, 2003 4:35 PM
To: Romascanu, Dan (Dan); Randy Presuhn; Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

Hi -

...
> A feature. 'A value of 1 (for alarmModelState) MUST indicate a clear 
> alarm state'. Concurrent specific models MAY support a clear alarm 
> state.
...

It'd be very difficult to define an extension model without a clear state,
since that notion is built into both the alarmModelTable and the
alarmClearTable.  Anyway, in a case like this, where there would be entries
in both extension tables, to which one would the alarmModelSpecificPointer
point?

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Nov 2003 07:38:48 -0500

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, November 09, 2003 4:35 PM
To: Romascanu, Dan (Dan); Randy Presuhn; Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

Hi -

...
...

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 10 Nov 2003 12:17:19 -0600 (GMT-06:00)

Hi -

> From: Sharon Chisholm <[email-masked]>
> Sent: Nov 10, 2003 6:38 AM
...
...

Then I suggest that the DESCRIPTION of the specific pointer should
explicitly say that its value doesn't matter.  (I assume this is true
even if it is set to {0 0}.  (Of course, that also begs the question
of why the object is needed at all.))  If there are stronger constraints
on what values are permitted (e.g., must point to a possible, not-already-
existing row in an extension table) then we should be explicit.  If there
are no constraints, we should also be explicit about that.  If the set of
permissible values is implementation dependent, then the process by
which a management system comes to learn what those values are should
be documented.

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 10 Nov 2003 12:17:19 -0600 (GMT-06:00)

Hi -

...
...

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Nov 2003 15:43:59 -0500

Hi

Well, if we MUST bother specifying something then we should say it should
point at the ITU one if it exists. My point was that which ever way the
implementation chooses to do things, nothing will break. 

You seem to be confusing whether an object is useful and how micro-managed
its definition needs to be.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Monday, November 10, 2003 1:17 PM
To: Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

Hi -

...
...

Then I suggest that the DESCRIPTION of the specific pointer should
explicitly say that its value doesn't matter.  (I assume this is true even
if it is set to {0 0}.  (Of course, that also begs the question of why the
object is needed at all.))  If there are stronger constraints on what values
are permitted (e.g., must point to a possible, not-already- existing row in
an extension table) then we should be explicit.  If there are no
constraints, we should also be explicit about that.  If the set of
permissible values is implementation dependent, then the process by which a
management system comes to learn what those values are should be documented.

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Nov 2003 15:43:59 -0500

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Monday, November 10, 2003 1:17 PM
To: Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

Hi -

...
...

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Nov 2003 13:06:17 -0500

Hi

So, Dan and I are in agreement that we don't want to over engineer this and
that it is the primary responsibly of the additional alarm model to provide
any additional mappings that it may require. If there are no further
objections, I propose we close this issue with the previously suggested
resolution:

"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

With

      ::= { ituAlarmTable 1 }"

Sharon
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, November 10, 2003 5:40 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Nov 2003 13:06:17 -0500

Hi

Replace

With

Sharon
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, November 10, 2003 5:40 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; Disman (E-mail)
Subject: RE: [Disman] alarm comment 69-1

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 11 Nov 2003 12:56:00 -0600 (GMT-06:00)

Hi -

As technical contributor:

Although I *really* dislike the amount of magic this requires,
in the interest of getting this thing out, I'm willing to
give up on this issue *if* the language is tightened up *and*
the constraints on alarmModelSpecificPointer are spelled out.

Specific changes I'd like to see to the proposal:

   ituAlarmEntry OBJECT-TYPE
      SYNTAX      ItuAlarmEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "Entries appear in this table whenever an entry is created
           in the alarmModelTable with a value of alarmModelState in
           the range from 1 to 6.  Entries disappear from this table
           whenever the corresponding entries are deleted from the
           alarmModelTable, including in cases where those entries have
           been deleted due to local system action. The value of
           alarmModelSpecificPointer has no effect on the creation
           or deletion of entries in this table.
           Values of alarmModelState map to values of
           ituAlarmPerceivedSeverity as follows:

           Any other values of alarmModelState MUST NOT appear
           in this table, since the SYNTAX of ituAlarmPerceivedSeverity
           is limited to this range.

           This table MUST be persistent across system reboots, but
           this persistence MUST NOT result in a situation in which an
           entry exists in this table without a corresponding entry in
           the alarmModelTable."
      INDEX       { alarmListName, alarmModelIndex,
                   ituAlarmPerceivedSeverity }
      ::= { ituAlarmTable 1 }"

Likewise, if we're going to go with this approach, I'd like to see the
DESCRIPTION of alarmModelSpecificPointer clarified to say something
like:
      "If no additional, model-specific Alarm MIB is supported by the
      system, the value of this object MUST be { 0 0 }, and attempts
      to set it to any other value MUST be rejected appropriately.  If
      the system does support one or more model-specific Alarm MIBs,
      then, if creation of this row would result in creation of a row in one
      or more model-specific alarm MIBs, the value to which this object
      is set MUST refer to the first accessible object in a corresponding
      row of the model definition in one of these model-specific MIBs;
      attempts to set this object to { 0 0 } or any other
      value MUST be rejected appropriately. When a model-specific
      Alarm MIB is supported, this object is the instance pointer to
      the model-specific alarm definition."

As WG chair:

These words could use some polish, but we do need to make a serious
attempt to ensure that our definitions are sufficiently precise to make
interoperation of implementations reasonably likely. The semantics
Randy spelled out were his *guess* as to what the current i-d intended.
If he got it wrong, that's just one more reason to make the intent *clear*
and *explicit*.

Randy

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 11 Nov 2003 12:56:00 -0600 (GMT-06:00)

Hi -

	

As WG chair:

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 17 Nov 2003 12:44:30 -0500

hi

Replace

With

           or deletion of entries in this table. Values of 
           alarmModelState map to values of ituAlarmPerceivedSeverity 
           as follows:

On the description of alarmModelSpecificPointer, replace

      "If no additional, model-specific Alarm MIB is supported by the
      system the value of this object is `0.0'. When a model-specific
      Alarm MIB is supported, this object is the instance pointer to
      the model-specific alarm definition."

With

      "If no additional, model-specific Alarm MIB is supported by the
      system the value of this object is `0.0'and attempts
      to set it to any other value MUST be rejected appropriately.
     
      When a model-specific Alarm MIB is supported, this object MUST 
      refer to the first accessible object in a corresponding
      row of the model definition in one of these model-specific MIBs
      and attempts to set this object to { 0 0 } or any other
      value MUST be rejected appropriately."

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, November 11, 2003 1:56 PM
To: [email-masked]
Subject: RE: [Disman] alarm comment 69-1

Hi -

Although I *really* dislike the amount of magic this requires, in the
interest of getting this thing out, I'm willing to give up on this issue
*if* the language is tightened up *and* the constraints on
alarmModelSpecificPointer are spelled out.

	

As WG chair:

These words could use some polish, but we do need to make a serious attempt
to ensure that our definitions are sufficiently precise to make
interoperation of implementations reasonably likely. The semantics Randy
spelled out were his *guess* as to what the current i-d intended. If he got
it wrong, that's just one more reason to make the intent *clear* and
*explicit*.

Randy