Subject: resend Re: alarmModelEntry notInService

From: "David L. Partain" <[email-masked]>
Date: Thu, 17 Jan 2002 11:41:16 -0500

Greetings,

I sent this yesterday from a different account, but I haven't
seen it appear yet, so I'll retry from here...  Forgive any
duplication.

Cheers,

dlp
-----------------------------------------------------
Hi,

> > From: "Stefan Wallin" <[email-masked]>
> > To: "Sharon Chisholm" <[email-masked]>,
> >         "Disman" <[email-masked]>
> > Subject: SV: alarmModelEntry notInService
> > Date: Wed, 16 Jan 2002 09:03:10 +0100
> > Message-ID: <[email-masked]>
> > In-Reply-To:
> > <[email-masked]>
>
> ...
>
> > My question is how a alarmModelEntry in state notInService shall be
> > handled by the agent. My guess is that the correct behaviour is my
> > alternative 2:
> > activeAlarmTable is NOT updated when the corresponding event occurs.
> > Of course it does not affect notification sending.
>
> That would be my expectation.
>
> > See def of notInService in SMIv2-TC:
> > - `notInService', which indicates that the conceptual
> >          row exists in the agent, but is unavailable for use by
> >          the managed device
> >
> > Assuming that interpretation, we have a transactional concern, it is
> > confusing to make only some of the entries of the same alarmindex out of
> > service. It should affect all entries with the same alarmModelIndex.
>
> ...
>
> 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.

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

Cheers,

David Partain

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jan 2002 18:06:12 +0100

>>>>> David L Partain writes:

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