Re: scotty agent doc & suggestions

Peter J M Polkinghorne (Peter.Polkinghorne@gec-hrc.co.uk)
Fri, 27 Oct 1995 15:14:28 +0100 (BST)

Firstly thanks for a comprehensive reply to my previous posting and this one.

The delay in my response is due to decorating at home (a change from network
management ... )

>
> I agree again. After some more thoughts about your mail, I have come
> to the following conclusion:
>
> 1) I will split the PDU processing into two different functions, one
> doing get/getnext/getbulk processing and the second doing set
> processing. (This will make the code a bit easier to understand.)
>
Good.

> 2) I will add a CHECK binding that will be evaluated after the first
> loop over the varbind list while processing set requests. The check
> binding may return an error result to signal consistency problems.

Yes this will be ideal.

>
> 3) The commit/rollback bindings will be invoked after the CHECK
> bindings have been evaluated, depending on the result of the
> previous PDU processing.
>
Good.

> 4) I will add some code to get the atomicity described in your mail,
> point d). Yesterday, I though about creating default bindings similar
> to the ones you described when instantiating writable variables.
> Creating default bindings would allow an advanced hacker to redefine
> them. However, today I think that it can't hurt to have this behavior
> hard coded in the agent. Therefore, you do not have to care about set
> bindings until you are required to do some side effects or your are
> required to maintain dependencies between MIB variables.

I think this is reasonable.

>
> Will these changes solve your problems? Should I do anything else to
> make `as if simultaneous' SNMP set processing easier?
>
It certainly will make things easier. This is indeed one of the areas where
the Simple in SNMP is untrue (well from the agent as opposed to the manager
perspective).

I will try out the new ideas and see how I go and make further suggestions
based on my experience. However I suspect tables too often have extra
semantics which makes further automation hard.

PS you refer to the code - is this accessible by FTP?

--
Peter Polkinghorne,               Email: pjmp@gec-rl-hrc.co.uk
GEC Hirst Research Centre,
Elstree Way, Borehamwood,      Tel. +44-181-732-0282 (or +44-181-953-2030)
Herts. WD6 1RX ENGLAND         Fax  +44-181-732-0200 (UK: 0181-732-0200)