[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RowStatus questions

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi -

> Message-Id: <>
> Date: Fri, 10 May 2002 09:11:20 -0700
> To: Wes Hardaker <wes@hardakers.net>
> From: Andy Bierman <abierman@cisco.com>
> Subject: Re: RowStatus questions
> Cc: eos@ops.ietf.org
> In-Reply-To: <sdsn50pqdy.fsf@wanderer.hardakers.net>

I also prefer (4), but would like to add a note to Andy's
stipulation that

>  b) there are no cascading tables (like RMON2 usrHistory) that 
>     need to be configured before the row can be activated

One of the issues we worked through in the work on VACM
was how to represent complex relationships without making
the row-creation process overly complex.  On thing I think
we got right was the elimination of all constraints on the
order in which rows in the various tables could be created
or activated.  The cost was simply the requirement that we
describe what it meant to reference, for example, a group
which did not yet have any active entries.  Ultimately,
this turns out to be far simpler to reason about and
implement than "cascaded" logic.

 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San Josť, California 95131  USA
 My opinions and BMC's are independent variables.