Subject: RE: [Disman] ituAlarmGenericModel is redundant?

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 15 Oct 2003 13:14:55 -0400

Hi

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.

Sharon

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

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt

...
> 68) ituAlarmGenericModel: why is this object needed? the indexing
>     information needed to find the model entry is the same for both
>     tables.
...

ituAlarmGenericModel seems comepletely redundant.
All the information needed to find the alarmModelEntry corresponding to an
ituAlarmEntry is already present in that entry's indexes.  This object
serves no purpose.

Proposal:  remove ituAlarmGenericModel.

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 19 Oct 2003 15:09:02 -0400

Hi

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 -

> 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.
>
> 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: "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

> Sent: Sunday, October 19, 2003 12:09 PM

> 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: "Sharon Chisholm" <[email-masked]>
Date: Fri, 24 Oct 2003 15:05:03 -0400

Hi

Well, the object may be redundant but technically it's not really a
duplicate. It's a reasonable compromise though. Documenting that technically
this information could be derived from other sources is reasonable and may
be helpful for people less familiar with SNMP. Most of my complaints of the
"efficiencies" we do in SNMP is that they are often at the expense of the
understanding of less experienced users.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Thursday, October 23, 2003 2:01 PM
To: Disman (E-mail)
Subject: Re: [Disman] ituAlarmGenericModel is redundant?

Hi -

> Sent: Wednesday, October 22, 2003 6:57 AM
...
> 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?
...

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