Re: Problem with defining custom data type (TEXTUAL-CONVENTION)

On Fri, 1 Feb 2008, Dave Shield wrote:

> On 31/01/2008, Manfred Wassmann <[email protected]> wrote:
[...]
> No - you can't do that.
> The value returned *MUST* be the same as the value that was
> being set.  That's part of the SNMP specs.
>   You can return an error value as part of the SNMP response,
> but this takes a limited range of values (and again, the specs
> are fairly precise about what errors are returned when).

OK, returning to the specs I read RFC 3416 section 4.2.5:

   "All fields of the Response-PDU have the same values as the
    corresponding fields of the received request except as indicated
    below."

That's definite, but it looks like I can return one of the errors
listed in steps 6 and 10 to 12 of the validations performed when
processing the variable bindings of a SetRequest-PDU.

(6)  "wrongValue", if the version specified is invalid (but not simply
      not available).
(10) "inconsistentValue", if the version specified is not appropriate
      (or not available in case I download immediately).
(11) "resourceUnavailable", if the download fails.
(12) "genErr" on other errors, if any.

>> If the version specified is not available when the update is performed the
>> update will just fail. The manager can check for a failed update by
>> checking the currentVersion OID.
>
> That would allow the manager to detect that the upload has failed.
> Similarly, you could probably return an error to this effect as part
> of processing the SET request  (assuming that the upload is applied
> immediately and you're happy to wait for this to complete before
> sending the SNMP response).

It looks like a good idea to have the device trying to download the
version while processing the set request. But the manager would need to
specify a fairly long timeout with the set command and I should
probably note that fact in the relevant DESCRIPTION clause?

> But if you wanted to provide some indication of *why* the upload
> failed  (couldn't contact the server, the server said no, which
> server should I use anyway, etc), then you might need to provide
> a separate MIB object to report this information.

This also looks like a good idea.

>   Primarily I'm trying to get you to think about these sorts of issues,
> and (particularly) to document them in the DESCRIPTION clauses.
> Remember, if you get hit by a bus tomorrow, then the descriptions
> in the MIB file are all that your successor will have to work on when
> they have to pick up where you left off.
>
>   Think of this as the design spec for your SNMP interface.
> Try to include the same level of detail as you'd need to put into a
> formal program design document in order to keep the suits upstairs
> happy.   Well, maybe not quite that much, but you get the idea...

Thanks for your advice, I thought I had been fairly elaborate when
writing the MIB text but now I see I have missed a lot.

Manfred

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users