Re: mteOwner in Event MIB Notifications

Hi -

> From: <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, July 27, 2005 3:00 PM
> Subject: Re: [Disman] mteOwner in Event MIB Notifications
>

> I was able to successfully add mteTriggerComment to the VarBind list
> and when it comes accross, I get instance information.
>
> However, this requires configuring mteTriggerObjectsOwner and
> mteTriggerObjects for each entry in the mteTriggerEntry so that
> I can specify different attributes in mteObjectsEntry which includes
> the instance information for the mteTrigger attributes.
> This is quiet combersome.
>
> It would be nice to add mteOwner to the notification. However,
> as Randy pointed out that would require recycle at proposed.

That by itself is NOT, in my opinion, sufficient grounds for rejecting
the idea.  If what we have seems cumbersome, we should consider what it
would take to fix the problem.

> I am wondering if we could avoid this by changing the description
> of mteTriggerName by dropping "for the trigger within the scope of
> mteOwner". IE, make mteTriggerName unique. This would prevent having
> instances foo.x and bar.x, but would allow the manager to scan
> the table for x. Just throwing out some options.
>
> Thoughts?
...

I think this could cause more difficulties than it would fix.
An application creating entries would have to be prepared for
the possibility that the mteTriggerNames it (or its user) chose
might be unavailable because some other user has already used
them.  It wouldn't have a good way of finding out what names
were in use by users belonging to other groups, under a typical
VACM configuration.  Likewise, it would allow a user to disrupt
other users by "preemptive strikes" in naming.

It seems to me that this shortcoming really should be fixed.
I think this would mean:
    1) adding an object (accessible-for-notify) to carry the information
    2) adding a new, functionally idential notification-type that includes
       the new variable binding
    3) deprecating the existing notification-type
    4) adding new conformance material
    5) deprecating the existing conformance material

Is there a less disruptive way to do this?  Is the "cumbersome"
approach Karl outlined sufficient?

Randy