Re: RowStatus questions
Randy Presuhn <[email protected]>
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <[email protected]> |
[ 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: <[email protected]> > Date: Fri, 10 May 2002 09:11:20 -0700 > To: Wes Hardaker <[email protected]> > From: Andy Bierman <[email protected]> > Subject: Re: RowStatus questions > Cc: [email protected] > In-Reply-To: <[email protected]> ... 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 [email protected] 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------