RE: Pls check some review pieces of: draft-ietf-ipsp-spd-mib-04.t xt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Monday, February 06, 2006 18:36
> To: Wijnen, Bert (Bert)
> Cc: Mreview (E-mail)
> Subject: 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.
> 

Thanks for the above.
More viewpoints (agreement or not) will be appreciated.

> 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!
> 

I basically agree with David here. At the other hand... 
It is their design. And here comes the "we should have
been there early in the process. In fact at least one
SNMP/MIB expert is part of the effort so should have
(maybe has) pointed that out way back then.
So not sure it is worth the (or valid to) pushback. 
But if enough of us agree that we should push back I 
may decide to do so.

Bert

> 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
>