Subject: Query on SNMP Error Fields

From: deepak rajaram <[email-masked]>
Date: Fri, 14 May 2010 16:48:33 +0530

Hi,
While the SNMP RFC(1157/2571/SNMPv3) mentions the behavior of "Error Status"
and "Error Index" field as "will be set in the response" and the value of
these fields in all set/get/getnext request is zero, It does not mention if
it is *mandatory* for these fields to have zero in set/get/getnext. Could
these fields be modifiable in set/get/getnext.
Regards,
Deepak

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 14 May 2010 11:28:40 -0700

Hi -

> From: "deepak rajaram" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, May 14, 2010 4:18 AM
> Subject: Query on SNMP Error Fields
...
> these fields be modifiable in set/get/getnext.

As the comments in the ASN.1 say, the values of these two fields are
sometimes ignored.  In my opinion it would be legal but unwise to
use non-zero values in those requests. Some over-zealous implementor's
code might actually check for zero, and you'd be in the position of explaining
why your implementation doesn't interoperate with deployed systems.

Be conservative in what you send...

Likewise, if your implementation checks those values in any situation other
than the situations spelled out in the specifications, you could also find
yourself explaining why your implementation doesn't interoperate with
deployed systems.

Be liberal in what you accept....

Randy
Randy

---

From: <[email-masked]>
Date: Sat, 15 May 2010 21:32:51 +0530

Hi Randy et al,
 
This is an strict expectation as per SNMP RFC specs , that the Set/GEt/GetNext requests set the error status and error-index field to 0. depending on this, Most of the SNMP agent implementations copy the request message buffer and modify the error status and error index to non-zero only if  an errror occured. if you already set it to non-zero , the response may actually be meant as a success but, will always show errored value. 
 
So, IMHO, thism is an unacceptable practice to set the error index /status to non-zero vaue in request.
 
regards,
shivendra
________________________________

From: [email-masked] on behalf of Randy Presuhn
Sent: Fri 5/14/2010 11:58 PM
To: [email-masked]
Subject: Re: Query on SNMP Error Fields

Hi -

...

Randy
Randy

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 15 May 2010 11:17:01 -0700

Hi -

> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Saturday, May 15, 2010 9:02 AM
> Subject: RE: Query on SNMP Error Fields
...
> This is an strict expectation as per SNMP RFC specs ,
> that the Set/GEt/GetNext requests set the error status
> and error-index field to 0.

Citation, please?  While it is very reasonable and good defensive
programming to set those two fields to zero in a request, I'm not
aware of  any text in the relevant RFCs that would actually *require*
it.  As long as the values present in the request are within the
bounds permitted by the ASN.1 grammar, and implementation
has no legitimate reason to reject them, as far as I know.

> depending on this, Most of the SNMP agent implementations
> copy the request message buffer

Not the ones with which I am most familiar.

> and modify the error status and error index to non-zero
> only if  an errror occured.

This would be contrary to the elements of procedure in, for
example, RFC 3416 clauses 4.2.1 and 4.2.5.  The elements
of procedure explicitly identify the cases when the error status
and error index are set to zero.

> if you already set it to non-zero , the response may actually be
> meant as a success but, will always show errored value. 

This is just bad programming, and is not justified by the relevant
elements of procedure.

> So, IMHO, thism is an unacceptable practice to set the error
> index /status to non-zero vaue in request.

It's unwise (albeit legal) for the sender of the request, since
an over-zealous receiver might (incorrectly) reject the request.
What is truly unacceptable is for the responder to ignore the
elements of procedure and not fill in the values of error status
and error index required in the response by the standard.

Randy