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

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 17 Nov 2003 12:44:30 -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 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:
	
           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 }

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 -

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:
	
           alarmModelState -> ituAlarmPerceivedSeverity 
                  1        ->         clear (1) 
                  2        ->         indeterminate (2) 
                  3        ->         warning (6) 
                  4        ->         minor (5) 
                  5        ->         major (4) 
                  6        ->         critical (3)

           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: Mon, 17 Nov 2003 12:39:10 -0800

Hi -

Looks good to me.  Thanks!

Randy

----- Original Message ----- 
> From: "Sharon Chisholm" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 17, 2003 9:44 AM

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 17 Nov 2003 12:39:10 -0800

Hi -

Randy