[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf A non-trivial policyAction example
>>>>> Steve Waldbusser writes:
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.)
Steve> This is handled automatically by the execution environment
Steve> which knows the address of "this element".
>> Address? EngineID? EngineID + ContextName? Is it specified
>> anywhere what it is?
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.)
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.
Juergen Schoenwaelder Technical University Braunschweig
<firstname.lastname@example.org> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>