[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can we make table indices accessible again?



HI,

As my friend Evan McGinnis would probably say, this problem is caused
by poorly designed APIs to get SNMP tabular data.

For example, if you have an API that you used to get the values
of columnar objects ifInOctets and ifOutOctets, then it should
return sequences of values for objects
    (ifIndex, ifInOctets, ifOutOctets)

Most APIs are at way too low a level. They require you to pass
in a list of "varBind" structures, and you get back a list of
varBind structures. That is just SAD, SAD, SAD.

I support Fred's desire to add aggregate objects. (I can do them
today with OCTET STRINGs, but getting the encoding/decoding
interoperable is hard, and I haven't yet seen a MIB browser
where you can tell it the encoding/decoding rules when you
are using an OCTET STRING.

Lets say we have support for an aggregate objects and one
is created has fields year, month, day, hour, minute, seconds,
named lastConfigured. And say, it is used to augment the IF
table. Then using my API from above, asking for lastConfigured,
ifDescr, and ifType, I would get back sequences of values
like the following:
    ( {year, month, day, hour, minute, second} ifDescr, ifType )

 
(With aggregates, you get the complete item as a value. You can't
ask for only a portion. When you change the value (with a set),
you specify the complete item as a value. You can't change
only a portion.)

Hope this illuminates.

On Wed, 26 Sep 2001, Fred Baker wrote:
> At 09:58 AM 9/26/2001, Sharon Chisholm wrote:
> >Back in SMIv1, table indices were accessible,
> >but in SMIv2, they became not-accessible.
> >As a manager, I find this really annoying...
> >
> >I've heard that table indices were made not-accessible
> >for efficiency reasons.
> 
> I tend to agree here, especially if we can support some variant of an 
> aggregate object - something that compactly displays the set of attributes 
> associated with a row rather than making us name each one fully.


Regards,
/david t. perkins