[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Open/Closed Issues on SNMP Extended Protocol MIB
I think there are several reasons why it may
be valuable if it were possible to translate
EOS requests into conventional requests:
- proxies could bridge EOS-capable and EOS-noncapable
- master agents could be adapted to provide
some EOS capabilities to conventional subagents.
- would preclude the need for a snmpXProtoSubtree-like MIB
and thus simplify NMS appls (and agents). One of the
probable-core requirements is to simplify NMS and agent
coding efforts, and I think the need to have this kind of
a MIB would make at least some NMS's (those that don't or
can't abstract the details of whether or not to send EOS
requests) a bit more complex. For most impls, this MIB
is probably not a big thing, but it is one more thing
you'll have to provide to get to EOS (and there's gonna
be plenty of pain doing that, even without this MIB).
I think this requirement was proposed due to several
comments from different sources, but I gather it's becoming
more a secondary objective more than a requirement.
Even so, with each proposed EOS solution, it is important
to understand to what degree request translation is
or is not possible. My previous email suggests
the approach in the current draft probably does allow some
transitional benefits. Something to keep in mind as we
evaluate differing solutions.
Sharon Chisholm wrote:
> Ira> Separately, even if SubAgent behavior was deemed out of scope for EOS,
> Ira> I don't see how EOS is useful unless SubAgent behavior _is_ specified
> Ira> and (my opinion) AgentX is compatibly extended.
> Ira> I agree, though I assume the rowOp doc is not
> Ira> the place to specify this (other than to point
> Ira> out something has to be done).
> Ira> The problem of discovering which subtree supports EOS is terrible
> Ira> for NMS scripts to cope with.
> Lauren> I agree. And I think I can think of a general way of
> Lauren> avoiding this problem (if the NMSs follow some rules):
> Lauren> <description of translating row operations into traditional stuff>
> Is this the only reason for trying to ensure that eos operations can
> translated into traditional operations? I've been wondering
> where this requirement came from. If there is no other reason, considering
> is solved by allowing the capabilities by sub-tree, then I think we would
> want to make this a non-compliant requirement.