[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC-POLICY-MIB - Negotiation actions
Wes Hardaker wrote:
> >>>>> 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.
> Make sense?
> Wes Hardaker
But as the tables stand today, the SANegotiationAction entries are not
re-usable by several ike or ipsec actions. Each saNegotiationAction must
point to only one IKEAction or one IPsecAction.
So here comes just a brain-storm type idea (ie.. not well thought out)
If We arranged our tables such that the actionName rowpointer in the
actionsInRuleEntry pointed at either an Ike or an IPsec action and then
the IKE/IPsec actions had a columb to point at saNegotiationAction....
then we could re-use common timout type parameters.
Ricky Charlet : Redcreek Communications : usa (510) 795-6903