Re: Open/Closed Issues on SNMP Extended Protocol MIB

[Lauren Heintz <lheintz@cisco.com>]

Hi,

Sharon Chisholm wrote:
> 
> hi
> 
> 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.

Hadn't realized anyone thought this was a decision.
In any case, I would think we should support
subagent diffs, and your table will help us do that.

In general, I would also hope that an NMS could
easily determine which set of proto-ops (old or new)
a given MIB region supports.  Right now, it appears
the table only allows EOS related proto-ops to be determined.

> 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.

Totally missed that! Guess I didn't scroll down far enough.

Lauren

> 
> I had originally also said that the traditional set support could
> also be done that way, but now I don't think that is the
> correct approach. The notWritable/notNewWritable currently makes more
> sense to me.
> 
> Sharon
> 
> -----Original Message-----
> From: Lauren Heintz [mailto:lheintz@cisco.com]
> Sent: Friday, June 29, 2001 1:06 PM
> To: Chisholm, Sharon [CAR:5K32:EXCH]
> Cc: Juergen Schoenwaelder; eos@ops.ietf.org
> Subject: Re: Open/Closed Issues on SNMP Extended Protocol MIB
> 
> Sharon Chisholm wrote:
> > notWritable - This object is not setable via traditional sets
> > notNewWritable - This object is not setable via new sets
> 
> One of the issues I've been trying to figure out with the
> current draft is how command responders behave when certain
> ops are supported or not:
> 
>                  ---------------
>                  | MasterAgent |
>                  ---------------
>                     |        |
>                     |        |
>               -----------   --------------
>               | EosSub1 |   | NonEosSub2 |
>               -----------   --------------
> 
> - this scenario assumes worst-case that the
> subagent protocol does not permit subagents
> to declare to the MA they are EOS-capable.
> 
> - if the MA doesn't recognize any given PDU at all,
> I had assumed it would simply handle it as
> per the rules of the message processing model
> in place.
> 
> - otherwise, say Sub1 accepts EOS requests
> but Sub2 doesn't (instead it expects conventional
> SNMP requests).  The MA dispatches an EOS
> rowOp to Sub1 and ostensibly a response
> or error is returned that the MA can dutifully
> return.  However, when it dispatches a similar
> EOS rowOp to Sub2, Sub2 treats it as a conventional
> request and very probably a normal error (e.g. NoSuchObject
> or other) is returned because the OID suppressions will
> confuse sub2, and notNewWritable can't be returned by the MA
> (cause it doesn't know that's the problem).
> 
> Thus, if we support these mixed-arch's (and I think we
> would) NMSs have to figure out when to send (and when not to
> send) EOS requests.  This is true even if the subagent
> protocol allows subs to declare whether they are EOS
> capable or not (though the MA could at least
> in this case return notNewWritable errors and avoid
> having to send a wasted EOS subop to Sub2).  Hopefully,
> NMSs won't have to use trial-error to figure out which
> MIB regions are EOS capable and which are not.
> 
> Not sure views are the asnwer because the views themselves
> may not be viewable, and even if they are, the NMS would
> have to first retrieve them (and would they use EOS requests
> or not?).  Could new AGENT-CAPs statements help here?  Does
> the extended protocol MIB have to address this issue of
> MIb region granularity for EOS capability?
> 
> Thanks, Lauren