(all apply to SetRequest() )
a) from my reading RFC1448 (at least the latest draft successor and Rose
and Stallings) does not indicate a noAccess exception for uncreatable
objects, rather a noAccess error plus index.
b) I can see updateing response value not so easy from check phase, having
already built in set/create phase, but because of a), could the response
var bind list be built up in check phase?
c) In commit phase the error return from binding can be used to implement:
i) commitFailed (plus index of offending item) error.
However implies then doing undo ...
ii) Simpler just wimp out with GenErr for snmpV1 and undoFailed for
snmpV2. Leaves Q. of what to do about remaining commits?
iii) Or may be (yuck!) introduce another binding commit-undo, and on
failure run all rollback bindings and appropriate commit-undo.
iv) Or may be yet another phase between check and commit/rollback,
called action?
As you can see I am undecided, and what it comes down to is in my agent I have
actions which are slightly unreliable and impossible to undo.
At a minimum I should like to report failure back to user but minimise the
undo possibilities. This suggests ii) and plough on with others.
Do others have this problem?
Peter Polkinghorne, Internet: peter.polkinghorne@gec-rl-hrc.co.uk
Hirst Division,
GEC-Marconi Materials Technology, Ext. 6282 Gnet Code 711
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)