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

Re: snmpconf A non-trivial policyAction example

Juergen Schoenwaelder wrote:

> Steve> Another side note after looking at the TNM API: I see there is
> Steve> some optionality allowed for the parameters of varbind lists,
> Steve> but I'm surprised to see the middle parameter of the 3-tuple be
> Steve> omitted. It would seem to be very difficult to parse
> Steve> correctly. Was this just a mistake in your example?
> I do not find it hard to determine the number of arguments in a list
> and to parse the rest accordingly. In fact, Tmn even allows to omit
> the value when you do read requests. And you can write OIDs in many
> different ways. (But I guess this is not really relevant here.)

I just though that if I omit the middle of 3 arguments (leaving two), it is
difficult to tell which of the last 2 arguments was left off. For example,
if I send {, integer }, do I interpret that as sending
an unspecified integer value, or as sending a string whose value is

Most varargs schemes allow you to optionally remove items from the end of
the sequence only.

> Steve>        "The agent will retrieve the instance in the same SNMP
> Steve> context in which the element resides. Note that no actual SNMP
> Steve> PDU needs to be generated and parsed when the policy MIB module
> Steve> resides on the same system as the managed elements."
> Steve> This text can stand a bit of improvement, but I think it is
> Steve> basically clear.  Also, note that the last published draft has
> Steve> this text for 5 of the 6 SNMP functions but doesn't have it for
> Steve> the snmpsend function. You'll see this fix in the next draft.
> I think it is not clear since it is conditional. What happens if the
> MIB module does not reside on the same system as the managed elements?
> Note also that the terminology is not precise. Does the phrase "same
> system as the managed elements" mean it is the same context with the
> same SNMP engine? (We now have this great architecture to clearly
> say what we mean and we should thus use the right terminology.)

Your first question is answered in the email I just sent.

Regarding your second question, it doesn't mean "same context" (context is
really more of a modelling concept than a physical concept anyway). And I
don't think that there is any terminology in our architecture that helps.
It's simply pointing out that if the PM agent and the target agent are on
the same system, you can getint() without issuing a PDU. And if they are in
different subagents on the same system, you can (probably) getint() without
issuing a PDU. And if they are on different systems you probably have to
send an SNMP PDU on the wire between the two systems.

I think the "same system" phrase is pretty good but am willing to use any
better terminology.

> Steve> If we were to disable a policy on error (never to retry again),
> Steve> would a momentary misconfiguration (of security, say) cause the
> Steve> element to forever be out of policy? I don't think this is the
> Steve> right behavior.
> Steve> The issue of error handling comes up when (1) failure is
> Steve> expensive or (2) recovery was an option.
> Ignoring the problem is not an answer. You need to report and handle
> errors somehow. A policy system which shows all lights turned to green
> while at the same time the lower layers do not install any policies
> due to e.g. VACM configuration errors is IMHO useless.
> My experience so far is that programming distributed systems is always
> 80 % time spend on getting error handling right and 20 % spend on the
> functional stuff. I would be surprised if this rule does not apply
> here as well.

You think I'm saying that error handling is not important in the general
case. I'm not. Please re-read my comments and you'll see.