Subject: Result TLV

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Jun 2005 15:04:16 -0400

The following is what I suggest for handling results of operations.

SET and GET Requests do not have result information (they are requests).
SET and GET Responses have result information.
SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs.

For a GET responses, individual gets which succeed will have DATARAW TLVs 
added to the leaf paths to carry the requested data.  For GET elements that 
fail, instead of the DATARAW TLV there will be a RESULT TLV.

For a SET response, each DATARAW TLV in the original request will be 
replace with a RESULT TLV in the response.
If the request was for Ack-fail, then only those items which failed will 
appear in the response.  If the request was for ack-all, then all elements 
of the request will appear in the response with RESULT TLVs.

A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte) 
value.
The defined values are
   0 = success
   1 = no such object
   2 = permission denied
   3 = invalid value (the dataraw could not validly be stored in the field)
   4 = invalid array creation (when the subscript in an array create is not 
allowed)
  255 = unspecified error (for when the FE can not decide what went wrong)

We may need a few more values to cover other errors.
Note that if a SET request with a structure in a DATARAW is issued, and 
some field in the structure is invalid, the FE will not attempt to indicate 
which field was invalid, but rather will indicate that the operation failed.
Note further that if there are multiple errors in a single leaf path-data / 
DATARAW, the FE can select which error it chooses to return.  So if a 
DATARAW for a SET of a structure attempts to write one field which is read 
only, and attempts to set another field to an invalid value, the FE can 
return whatever error it likes.

Yours,
Joel M. Halpern