Subject: RE: resend Re: alarmModelEntry notInService (Alarm Issue #15)

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 30 Jan 2002 08:34:38 -0500

hi

David> I understand.  Jürgen's approach is certainly cleaner than
David> mucking around with RowStatus.  The important thing, from my
David> perspective, is that the text clearly states what happens with
David> notInService.  Specifically, it should address the concerns
David> voiced by Stefan on 16 Jan 2002 in mail with the subject
David> "SV: alarmModelEntry notInService"

I believe they are all covered. Here is the proposed text:

     "Control for creating and deleting entries.  Entries may be
     modified while active. Alarms whose alarmModelRowStatus is
     not active will not appear in either the alarmActiveTable
     or the alarmClearTable. 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 it is being 
     referenced by a value of alarmActiveModelPointer."

Sharon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jan 2002 14:56:16 +0100

>>>>> Sharon Chisholm writes:

Sharon>      This row can not be modified or deleted while it is being
Sharon>      referenced by a value of alarmActiveModelPointer."

It might be service for implementors and improve interoperability to
say precisely which of the RFC 1905 error codes applies in this case.

/js