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

Re: Open/Closed Issues on SNMP Extended Protocol MIB



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