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

RE: Open/Closed Issues on SNMP Extended Protocol MIB

> Well, first off, we had decided that subTree (subAgent) differences
> in support for EOS features was out of scope.  Is there rough 
> consensus that this should be a requirement?  It would be good to agree
> on that before solving it.
> Now, charging ahead to solve it before it is a requirement, the MIB table 
> I sent out this morning provides a simple means to determine which
> functionality a subtree supports above and beyond what the rest of 
> the system supports. 

As an alternative to this, the approach that Steve and I had proposed
using the aggregate row objects may be able solve some of this
without requiring that subtrees be registered in a SnmpXProtoSubTreeEntry.
The aggregate row objects use the naming convention of <table>.2
to uniquely identify aggregate rows (as compared to <table>.1 for
regular conceptual table rows). So, if you required that each
subagent wishing to support aggregate row objects must explicitly 
register those objects with the Master Agent then you can ensure
that if an EOS type operation is performed (e.g. CreateRow, DeleteRow,
EditRow) with aggregate row objects, then the request would only
be sent to the the subagent if that subagent indicated that it would
support the aggregate row objects requested.