Re: Call for censensus on path forward

Wes,

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

I'm wondering if the distinction between the two lists is useful?  each attribute
has a component-id whether index or `column'.  I realize it is still early in the
development of  these concepts- I'm also wondering why a max-depth field is needed
as this could be signalled within an `attributes-wanted[]' list (combines the
index+column-request-list, and extends for sub-objects.

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

This just seems different to me than that which is the oops-01 draft.

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

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

Regards,

Mark

Wes Hardaker wrote:

> >>>>> On Fri, 20 Sep 2002 15:05:29 -0400, Mark Ellison <[email protected]> said:
>
> Mark> (2) apply the attibute/column filter before packing into the
> Mark> response.  Send along only the set of object attributes
> Mark> requested for each (and every) object of a given object-type
> Mark> selected by (1) within a PDU instead of the set of all
> Mark> attributes for each object.
>
> That's already in the draft.  There is already a list of attributes to
> be returned which is independent from the filtering portion.  Not
> every attribute has to be returned, and you don't need to return
> attributes for which you performed filtering on.
>
> --
> Wes Hardaker
> Network Associates Laboratories