Re: Open/Closed Issues on SNMP Extended Protocol MIB

[Lauren Heintz <lheintz@cisco.com>]

Hi Mark,

The scenario where a MA incorrectly sends
EOS commands to a non-EOS sub happens
only when the MA has no knowledge of
whether subs are EOS-capable or not.
Hopefully, we will engineer things
so that will never happen.  Given that,
I agree with your analysis.

Thanks!! Lauren

Mark Ellison wrote:
> 
> Hi- comments inline....
> 
> Lauren Heintz wrote:
> 
> > 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.
> >
> 
> I agree.
> 
> >
> > - otherwise, say Sub1 accepts EOS requests
> > but Sub2 doesn't (instead it expects conventional
> > SNMP requests).
> 
> OK.
> 
> > The MA dispatches an EOS
> > rowOp to Sub1 and ostensibly a response
> > or error is returned that the MA can dutifully
> > return.
> 
> OK.
> 
> > 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).
> >
> 
> Why would the MA dispatch an EOS rowOp to Sub2 if Sub2 does not have EOS
> capability?
> I'd suggest it is the responsibility of the MA to either:
> 
> (1) translate the EOS operation into an equivalent sequence of (one or
> more) non-EOS commands, or,
> (2) initiate an error path when it is determined that the authoritative
> region does not support EOS.
>     (a) possibly some EOS capable subagent has registered the region at
> a lower priority, or,
>     (b) a return error code is prepared for an SNMP error response.
> 
> >
> > 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).
> 
> Agreed...additional text above.
> 
> > Hopefully,
> > NMSs won't have to use trial-error to figure out which
> > MIB regions are EOS capable and which are not.
> 
> I agree, it doesn't help if command generators have to guess.
> 
> Support in the form of a revision to the AgentxRegistrationEnty might
> include information regarding extensions supported by a subagent.  I
> didn't see anything in the snmpXProtoMIB that exposes a set of
> registrations as being EOS enabled.  Possibly I've missed a revision?
> 
> Alternatively, AgentX offers the agentx-AddAgentCaps-PDU message that
> would allow an EOS capable subagent to add an entry to the sysORTable.
> (This option goes a long way, but the NMS would still have to parse the
> information contained in the sysOREntry, so this only diminishes the
> amount of guessing required of the NMS)
> 
> >
> >
> > 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?
> >
> 
> I really think its more an MP issue than a view issue.  Besides, we'd
> effectively double the number of views otherwise needed for each MA.
> 
>  Unless there is some form of coexistence strategy, mapping message and
> payload from the EOS to non-EOS a la rfc2576 for non-EOS capable SAs,
> then there's a real protocol processing problem. (IMHO)
> 
> >
> > Thanks, Lauren
> 
> Oh no,  thank you for your effort and thoughts!
> 
> Regards,
> 
> Mark