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

Re: Open/Closed Issues on SNMP Extended Protocol MIB




>>>>> Dave Shield writes:

[...]

Dave> So it would seem reasonable for a command generator to treat an
Dave> unrecognised value as more-or-less equivalent to 'genErr'.

Dave> But is this the Right Thing To Do?

I have no clue what the right thing is what the RFCs requires to do in
this case. From an application point of view, there is virtually no
difference between genErr and an unknown error code. Both tell the
application that you got a response and that the operation failed in
some wired way which you do not understand.

I checked my scotty source code and it returns an "unkown" error to
the application for all error codes that are not defined in RFC 1905
and it considers the operation to be complete. The glib snmp library
used in scli/stop and gxsnmp just forwards the unknown error code to
the application and considers the operation to be complete - so its up
to the application to handle it. I think net-snmp is doing the same if
I understand the code right.

Perhaps mapping every undefined error-status to genErr is a good thing
so that applications do not get surprised - regardless what the RFCs
suggest. Another option could be to consider an unknown error-status
an ASN1 parse error - however a timeout will finally have the same
effect in the application except that it might take longer and
increases the changes that the application draws the wrong
conclusions.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  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/>