Subject: RE: [Disman] ituAlarmGenericModel is redundant?

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Oct 2003 09:57:06 -0400

Hi

It's a useful object. The working felt it was a useful object. I think it's
a useful object. We've never claimed that there wasn't another means to get
this mapping. Why are we suddenly deciding we don't want this object?

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2003 8:53 PM
To: Disman (E-mail)
Subject: Re: [Disman] ituAlarmGenericModel is redundant?

Hi -

I think we'll need to keep this one open until we reach a conclusion on
69-1, since the more recent proposals in that thread would change the
underlying assumptions about the relationship (or lack thereof) between
alarmModelState and ituAlarmPerceivedSeverity.  If for each
ituAlarmPerceivedSeverity value the corresponding alarmModelState ends up
having the same value, then ituAlarmGenericModel would end up being totally
redundant.

Randy

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Sunday, October 19, 2003 12:09 PM
> Subject: RE: [Disman] ituAlarmGenericModel is redundant?
>

> Hi
>
> The following is the proposed resolution to Randy-68. Assuming no 
> objection, this item will is closed with no changes to the draft.
>
> Sharon
>
> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Thursday, October 16, 2003 12:18 PM
> To: Disman (E-mail)
> Subject: Re: [Disman] ituAlarmGenericModel is redundant?
>
>
> Hi -
>
> > From: "Sharon Chisholm" <[email-masked]>
> > To: "Disman (E-mail)" <[email-masked]>
> > Sent: Wednesday, October 15, 2003 10:14 AM
> > Subject: RE: [Disman] ituAlarmGenericModel is redundant?
> ...
> > The following is the proposed resolution to Randy-68. Assuming no 
> > objection, this item will is closed with no changes to the draft.
> >
> > ituAlarmGenericModel is useful, not redundant.
> >
> > alarmModelTable has
> >
> >       INDEX       { alarmListName, alarmModelIndex, alarmModelState }
> >
> > ituAlarmTable has
> >
> >       INDEX       { alarmListName, alarmModelIndex,
> >                    ituAlarmPerceivedSeverity }
> >
> > Where alarmModelState != ituAlarmPerceivedSeverity
> >
> > You may be able to figure out which row in the alarmModelTable this 
> > refers to but maintaining the pointer makes this much faster and 
> > reliable.
> ...
>
> Ah.  Thank you.  The purpose of this object is to avoid having to scan 
> the alarmModelSpecificPointers for a given model to figure out the 
> mapping. Though I think that's kinda weak, I'm willing to accept the 
> rationale.
>
> HOWEVER,
>
> Now I *really* want to know how these itu entries come into (and go 
> out of) existence as alarm models come and go.
>
> Randy
>
>
>
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2003 11:01:04 -0700

Hi -

> Sent: Wednesday, October 22, 2003 6:57 AM
...
...

Redundant objects have long been discouraged.  If you believe that there is
overwhelming support to retain it, then I suggest we follow Bert's advice from
the Mreview mailing list:

| In general I discuourage people to create redundant MIB
| objects. But ... if they have good reasons, I think we
| should try to understand them and make them document it
| in the MIB documents, preferebaly in the "duplicate" object
| DESCRIPTION clause.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2003 11:01:04 -0700

Hi -

...
...

Randy