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

Re: Open/Closed Issues on SNMP Extended Protocol MIB


But I think the issue of how an NMS
would know which MIB regions are EOS capable
(or not) would still be there.  Also, the table.2
notation I think would require duplicate subagent and
VACM registrations??  Thus, if a new subagent protocol
supported EOS, each region registration could simply
indicate which kids of proto-ops it supported.

Also, how would a MA know that foo.2 corresponds
to table.2?  Is that possible?

Thanks, Lauren

Sandra McLeod wrote:
> > 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.
>                         Sincerely,
>                           Sandra