filters and channels

[Robin Iddon <[e-mail]>]

Hi,

[My message deleted]

[Steve shows how filters can end up being used by other clients accidentally]

Good point - I hadn't realized that.

   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.  

I can see that forcing variables to reference existing rows (or 0 in some
cases) is useful.  I'm not in favor of invalidating existing rows that
reference recently deleted rows.  I believe that this restricts the
functionality available to the client.

   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.

The first constraint is sufficient to enforce this behaviour.  Indeed it is
possible for a client to create all the rows needed before setting any to
valid.  Once all the rows have been grabbed, the client can go back and patch
the references in the same PDU used to validate the rows.  If people followed
this approach then no new constraints are required.  I feel some text
explaining how to safely control multiple table configurations would be just
as useful.  The multiple manager model already relies on cooperating clients -
this is no different.

   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]

Robin
Robin Iddon ([e-mail])
Spider Systems Ltd
Edinburgh
Scotland