[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Open/Closed Issues on SNMP Extended Protocol MIB
> Sandra> As an alternative to this, the approach that Steve and I had
> Sandra> using the aggregate row objects may be able solve some of this
> Sandra> without requiring that subtrees be registered in a
> Sandra> The aggregate row objects use the naming convention of <table>.2
> Sandra> to uniquely identify aggregate rows (as compared to <table>.1 for
> Sandra> regular conceptual table rows). So, if you required that each
> Sandra> subagent wishing to support aggregate row objects must explicitly
> Sandra> register those objects with the Master Agent then you can ensure
> Sandra> that if an EOS type operation is performed (e.g. CreateRow,
> Sandra> EditRow) with aggregate row objects, then the request would only
> Sandra> be sent to the the subagent if that subagent indicated that it would
> Sandra> support the aggregate row objects requested.
> Well, that might work for row operations, but I think we need a general
> that can be used for any EOS feature, present and future.
It would be nice if certain behavior and support could be implied
based on what is registered by the subagent. But, it's true that in
this case this doesn't really cover all of the possible EOS features
besides RowOps that may be introduced on a subtree level such as subtree
deletion if this were to rise again.