[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC-POLICY-MIB - Negotiation actions
>>>>> On Wed, 9 May 2001 14:07:00 -0400, "Casey Carr" <caseycarr@xxxxxxx> said:
Casey> Although, wouldn't augmenting be a truer representation of an
Casey> uninstantiated base class with two differing intantiated and
Casey> inheriting classes? Maybe not... just wondering. Yes it would
Casey> be more accurate. I'm not an SMI expert, but does it support
Casey> designing a table definition that has to be AUGMENTed in order
Casey> to have an instantiated row? I.E. Does can SMI support the
Casey> concept of an abstract base class? If SMI supports it, maybe
Casey> you could omit a RowStatus in the base table and but have one
Casey> in each of the tables that AUGMENT it.
Part of the problem here is that Mike and I came up with the initial
table breakdown, but Ricky and Cliff wrote the tables in question so
what Mike and I were thinking didn't get exactly mapped into reality.
I have many minor "corrections" I'll propose (when I get the time,
hopefully later this month, sigh) in this regard.
The problem is basically one of reuse. The idea was the notification
parameters that were common to both action sets should be defined in a
single table such that reuse of the definition would be possible.
IE, the table in question should have been "pointed to" by the other
two action tables such that it would be a reference saying "see here
for common parameters".
Now, it doesn't make sense for all instances and this is what we need
to determine. However, I'm admittedly opposed (from an admittedly
idealistic standpoint) to taking the exact same set of paramaters and
making them identical column sets in two other tables. Instead, we
should use a pointer of some kind (whether that's via a string index
(I think what was originally intended), or via a RowPointer, or via an
AUGMENTS (IE, MIB-specific) style of inheritance.