Re: Call for censensus on path forward

[Wes Hardaker <hardaker@tislabs.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

>>>>> On Fri, 20 Sep 2002 19:04:46 -0400, Mark Ellison <ellison@ieee.org> said:

Mark> OK- you're referring to page 8 the "index-request-list[]" and
Mark> "column-request-list[]" and corresponding description on page
Mark> 11?

Yes.

Mark> I'm wondering if the distinction between the two lists is useful?
Mark> each attribute has a component-id whether index or `column'.

Because you can have externally defined indexes which don't have a
column number assignment within the current table, and hence there are
two choices:

1) use negative integer values for specifying external indexes, which
   I think looks and feels hackish plus will not work if we have a
   column number > 2^31
2) use a separate sequence, which is cleaner.  This is the option I chose.

Mark> I realize it is still early in the development of these
Mark> concepts- I'm also wondering why a max-depth field is needed as
Mark> this could be signalled within an `attributes-wanted[]' list
Mark> (combines the index+column-request-list, and extends for
Mark> sub-objects.

Lets discuss this after I put the SMIng structures back in (which I'll
do within a few weeks post Monday if the consensus indicates I should
keep plugging away).

Mark> For example, assume `0.0' indicates "This object", so `0.0.1` would be
Mark> the first component/attribute of the object.  If the fifth component
Mark> contained a subobject, and we wanted the first and second attribute,
Mark> we would add `0.0.5.1' and `0.0.5.2'

Yes, a structure "like that" is going to be added, but not "just like
that".  Again, see me later.

Mark> Also (I think already mentioned elsewhere by another poster), I'm not
Mark> sure the index-search-objects[] list is useful.

Ditto.  external indexes cause problems.

Mark> My area of comfort with column-search-objects[] should behave
Mark> more like secondary ISAM keys (old IBM file format...) And,
Mark> maybe that MIB designers should have control over what can be a
Mark> searchable attribute/column be specifying it within the SMI as
Mark> an alternative indice clause.  Taking this approach may serve to
Mark> minimize fears of complexity for the agent?

Generally, I think everything should be searchable at the agent with a
'=' comparison on any value.  Everyone can do a memcmp (or
equivalent), it's just not that hard.  However, as stated (briefly) in
the draft non-supported search operations are actually dealt with, and
there is a flag that indicates what to do in those cases [return an
error vs simply pretend the filter didn't exist and return the data as
if un-filtered by that particular filter].
-- 
Wes Hardaker
Network Associates Laboratories