filters and channels

[Stephen Grau <[e-mail]>]

> From: Robin Iddon <[e-mail]>
> Date: Sat, 7 Dec 91 14:05:21 GMT
> To: [e-mail]
> In-Reply-To: Steve Witten's message of Sat, 07 Dec 91 03:23:34 GM
> Subject: Deleting channels...
> Status: R
> 
> 
> Hi,
> 
>    Given the following scenario:
> 
> 	   channel A
> 		   filter B "tied to" channel A
> 		   filter C "tied to" channel A
> 		   filter D "tied to" channel A
> 
> 
>    If one invalidates channel A, do filters B, C and D get invalidated as
>    well?  If not, what happens to them?
> 
>    Thanks in advance...
> 
> 
> In our implementation nothing happens to the filters.  They hang around
> waiting for channel A to re-appear, at which point they bind themselves back
> on to it.
> 
> IMHO it would be unfriendly to invalidate them - what if the application
> deleted the channel merely to re-insert it with different event indices ?  It
> wouldn't be too happy having to re-download all those tedious filters again.
> 
>    ============================================================================
>    Steve Witten                    [e-mail]
>    Intelligent Networks Operation  ...!hplabs!hpspd!stevewi
>    Hewlett-Packard Co.             [e-mail]
> 
> Anybody else?
> Robin
> Robin Iddon ([e-mail])
> Spider Systems Ltd
> Edinburgh
> Scotland
> 
The problem with leaving things laying around in the MIB that reference
non-existent rows in other tables is that it destroys the multiple
manager model.  In fact, there is also a problem in creating rows that
make references to other rows.  The row creation paradigm only deals
with resolving conflicts between managers accessing a single table.
I believe it needs to be extended to resolve contention between rows.

The problem is that if a row refers to another row that does not exist, there
is no way a management console can insure that no other manager will come
and use the non-existent row.  This is particularly bad in
the scenerio Robin has suggested since filters created by one manager
could conceivably be inadvertantly bound to a channel owned by another
manager.

I believe this is an issue in several places in the MIB (channels, filters,
and alarms).  One way to solve it is to not allow a valid row to refer to
a non-existent object and also disallow setting a variable to refer to a
row that does not exist.  This would force management consoles to allocate
rows prior to setting references to them, forcing resolution of
resource contention by using the row creation mechanism
already in the MIB.

This implies that invalidating a row in one table may also invalidate
rows in other tables.  I'm not sure what the best thing to do with the
invalid rows is - leave them hanging around on a timeout or just delete
them.

Any other ideas?

Steve Grau
Network Management Products Division
Novell, Inc.
[e-mail]