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

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 30 Jan 2002 07:45:19 -0500

hi

I'm trying to close out some of the open issues.

I like Juergen's view on this. I'll add some 
clarifying text on what happens, or rather
doesn't happen, before the row is in service,
and that alarm suppression is beyond the scope
of the Alarm MIB and indicate that putting the
row into notInService cannot be used for this purpose.

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 12:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: resend Re: alarmModelEntry notInService

>>>>> David L Partain writes:

>> Note well that the notInService value of the RowStatus textual
>> convention is probably NOT appropriate as a "control" value here,
>> since the row may disappear due to the provisions at the bottom of
>> page 16 of RFC 2579.

David> That's true, but it also seems to be the best alternative.
David> 2579 also says "It is the responsibility of the DESCRIPTION
David> clause of the status column to indicate what an abnormally long
David> period of time would be."  As such, it would be possible to use
David> notInService as this "control" value as long as the DESCRIPTION
David> clause clearly states what garbage collection should do.

I generally recommend against mixing row creation/deletion machinery
details with the actual enabled/disabled status control of a row. If
there is a need to disable a row (or better the function represented
by a row), then add proper status control objects. This is clear and
clean and gives you extensibility in case you find out that the row
may need to distinguish additional status values over time.  And even
implementation wise, I find it simpler to implement additional control
objects than tweaking the RowStatus machinery to do additional stuff.

Of course, you still have to say what the implications of notInService
are - in case this is the original question and there is no
requirement to be able to disable things.

/js

-- 
Juergen Schoenwaelder      University of Osnabrueck
<[email-masked]>       Dept. of Mathematics and Computer Science
Phone: +49 541 969 2483    Albrechtstr. 28, 49069 Osnabrueck, Germany
Fax:   +49 541 969 2770    <http://www.informatik.uni-osnabrueck.de/>

---

From: David Partain <[email-masked]>
Date: Wed, 30 Jan 2002 14:03:34 +0100

Hi,

> row into notInService cannot be used for this purpose.

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

Thanks!

dlp

---

From: "Stefan Wallin" <[email-masked]>
Date: Wed, 30 Jan 2002 15:20:50 +0100

make sure following is clear:
if a row in alarmModelTable is notInService:
- will the alarmActiveTable be updated or not, when the corresponding
notification occurs?

-----Ursprungligt meddelande-----
Från: [email-masked]
[mailto:[email-masked]]För Sharon Chisholm
Skickat: den 30 januari 2002 13:45
Till: [email-masked]
Kopia: [email-masked]; Juergen Schoenwaelder
Ämne: RE: resend Re: alarmModelEntry notInService (Alarm Issue #15)

hi

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 12:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: resend Re: alarmModelEntry notInService

/js