[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pls check some review pieces of: draft-ietf-ipsp-spd-mib-04.txt
HI,
Bert - good catches. Yes, they were a little bit sloppy in
saying "pointing to a table", when they really mean pointing
to a row by pointing to an instance of the first accessible
column in the row.
And yes, I believe the error code is incorrect, and you provided
the correct error code.
However, I really DO NOT believe that this is good design!
What if the row exists when the reference is created, but
then later the row is deleted. Is deletion blocked? Is the
row containing the reference deleted? In general, I believe
that it is BAD DESIGN to enforce referential integrity
between unrelated items.
What you have to do instead is to specify the behavior
when the reference does not exist!
On Mon, 6 Feb 2006, Wijnen, Bert (Bert) wrote:
> OK, now, during my review, I am running into this object:
>
> spdGroupContFilter OBJECT-TYPE
> SYNTAX VariablePointer
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "spdGroupContFilter points to a filter which is evaluated
> to determine whether the spdGroupContComponentName within
> this row should be exercised. Managers can use this object
> to classify groups of rules or subgroups together in order
> to achieve a greater degree of control and optimization
> over the execution order of the items within the group. If
> the filter evaluates to false, the rule or subgroup will be
> skipped and the next rule or subgroup will be evaluated
> instead.
>
> An example usage of this object would be to limit a
> group of rules to executing only when the IP packet
> being process is designated to be processed by IKE.
> This effectively creates a group of IKE specific rules.
>
> This MIB defines the following tables and scalars which
> may be pointed to by this column. Implementations may
> choose to provide support for other filter tables or
> scalars as well:
>
> diffServMultiFieldClfrTable
> spdIpOffsetFilterTable
> spdTimeFilterTable
> spdCompoundFilterTable
> spdTrueFilter
> spdIpsoHeaderFilterTable
>
> If this column is set to a VariablePointer value which
> references a non-existent row in an otherwise supported
> table, the inconsistentName exception should be
> returned. If the table or scalar pointed to by the
> VariablePointer is not supported at all, then an
> inconsistentValue exception should be returned."
> DEFVAL { spdTrueFilter }
> ::= { spdGroupContentsEntry 3 }
>
> They use the SYNTAX of VariablePointer, so they can point to a scalar
> as well as to a row in a table (or so I suspect because of "tables
> and scalars may be pointed to by this column").
> So here are my questions:
> - do we think this is OK? (I think it is).
> - do we want them to be more specific about pointing to a table?
> (I think I'd like them to be clear that the Variable Pointer
> MUST point to the first accessible column in a specific row.
> So in the case of diffServMultiFieldClfrTable the VariablePointer
> must point to an instance of diffServMultiFieldClfrAddrType.)
> - Their suggestion to return a inconsistentName is in conflict with
> the for example diffServClfrElementNext in the DIFFSERV-MIB
> which suggests to return an inconsistentValue (and that one
> is correct according to rfc3415 I think). Is this acceptable?
> (I think not.
> I think I'd rather have them be consistent with the DIFFSERV-MIB.
> So that would mean to switch the use of their inconsistentValue
> and inconsistentName. In fact, I think that inconsistentName is
> totally impossible given the list of error codes in RFC3416
> sect 4.2.5. If they want to pass back a value for the case
> described in the last sentence, then maybe resourceUnavailable
> could be used, but I can't say that I like that either.
> I think I don't see how they can differentiate the two cases
> with an errorCode.)
>
>
> Comments please.
>
> Bert
>
Regards,
/david t. perkins