Subject: RE: alarmActiveState notification

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 17 Apr 2002 08:09:41 -0400

hi

<Randy>
In draft-ietf-disman-alarm-mib-06.txt, the definition of the
alarmActiveState notification includes references to two
accessible-for-notify objects, alarmModelIndexVarbind and
alarmModelStateVarbind.  It seems to me that it would be
quite a bit simpler to remove these two from the OBJECTS
list, and replace them with alarmActiveModelPointer.
</Randy>

But, the manager is more interested in the model index 
and the model state. Yes, these can be extracted out 
of the instance information in alarmActiveModelPointer,
but this is added complexity that, based on the number 
of questions I receive about notifications that do 
this sort of this, causes a lot of confusion.

<Randy>

This would allow us to get rid of two object definitions,
and all the varbinds in the OBJECTS clause would come from
the same row in the same table, simplifying implementation.
</Randy>

... for the device. Of course, being able to varbind table
indices would solve this for both of us.

<Randy>
While we're on the topic of these two notifications, I
think that alarmActiveResourceId is not particularly useful
without alarmActiveContextName, alarmActiveEngineAddressType,
alarmActiveEngineAddress, and alarmActiveEngineID.
</Randy>
Maybe. I'll add it to the issues list.

Sharon

---

From: David Partain <[email-masked]>
Date: Wed, 17 Apr 2002 14:28:33 +0200

Hi all,

I _entirely_ support Randy's suggestion.

> of the instance information in alarmActiveModelPointer,

And that is the way they are _supposed_ to do it.  That's why
the SMI rules are what they are.  In my opinion, adding in these
accessible-for-notify copies of modelstate and modelIndex is
an ugly hack to try to get around the rules.

> this sort of this, causes a lot of confusion.

This is perhaps the third round (maybe more) on this mailing
list about this rule in the SMI.  I think we need to just accept
that the SMI says what it does, not try to hack our way around
it, and expect people to write tools that do the right thing.

> ... for the device.

I'm sorry, but I just don't understand why parsing a varbind
to get the index information is so hard...

And, by the way, if the alarmModelTable is indexed by something
other than an empty alarmListName, they'll have to parse
something to get that out, or am I missing something?

> Of course, being able to varbind table

But you cannot.  Since we obviously disagree on the validity of
the rule (I continue to believe it's a Good Thing that promotes
better tools), I suppose that I'll just jump up and down and
holler that RFC 2578 forbids what you want to do, so don't
do it.  :-)  Even if the copy-and-make-it-accessible-for-notify
hack doesn't violate the letter of the law, it sure violates
the spirit.

Cheers,

David