[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf A non-trivial policyAction example
Juergen Schoenwaelder wrote:
> Steve> Regarding your second question, it doesn't mean "same context"
> Steve> (context is really more of a modelling concept than a physical
> Steve> concept anyway).
> He? SNMPv3 has scoped PDUs - is that not physical enough?
I meant something else.
The decision to place an object in a different context on the same agent is
based on information modeling desires. When an object is on another system
it simply reflects physical realities. The point is that architecturally
speaking, moving an object to another context on the same agent does not
make it harder to communicate with.
> Steve> And I don't think that there is any terminology in our
> Steve> architecture that helps. It's simply pointing out that if the
> Steve> PM agent and the target agent are on the same system, you can
> Steve> getint() without issuing a PDU. And if they are in different
> Steve> subagents on the same system, you can (probably) getint()
> Steve> without issuing a PDU. And if they are on different systems you
> Steve> probably have to send an SNMP PDU on the wire between the two
> Steve> systems.
> ... But given the fact that you stated (as I understood it)
> that an execution engine can act as a mid-level manager, then the
> distinction between a "local getint()" and a "remote getint()" does
> not really matter and you may as well remove that text.
I disagree - I believe the text is helpful to the implementor and should
"Note that no actual SNMP PDU needs to be generated and parsed when the
policy MIB module resides on the same system as the managed elements."
> Steve> You think I'm saying that error handling is not important in
> Steve> the general case. I'm not. Please re-read my comments and
> Steve> you'll see.
> When I started to write the scotty package, I introduced a job command
> which allows to schedule the execution of Tcl procedures regularily
> with the capability to suspend and resume jobs. However, I did not
> give jobs full control how they should behave on error situations. In
> fact, the scheduler was just scheduling them again. Experience with
> real world code later told me that this was a design mistake and there
> are now job properties which give complete control over what happens
> if things go crazy. This was needed to write robust code.
Thanks for the story. It is abundantly clear that we agree one hundred