Subject: Re: Result TLV

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 13 Jul 2005 09:30:47 -0700

Again a reasonable and simple approach to provide the Results.

To put some more context around it, is this how it would look like in a
Config Response message?

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = LFB select      |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          LFB Class ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        LFB Instance ID                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Operations (SET-RESP)      |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Result TLV                            |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Operations (DEL-RESP)      |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Result TLV                            |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pls do clarify, No path-data tlv in this format?

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, June 30, 2005 12:04 PM
To: [email-masked]
Subject: [FORCES] Result TLV

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2005 15:33:47 -0400

I would expect there to be path-data at least some of the time.
Assuming abbreviated responses (which are probably the norm) then for 
success it might suffice to just have one Result TLV, with no path-data.  I 
had not thought about allowing that.
If there are errors, there must at least be the path-data (possibly several 
nested path-data TLVs) that identify the target of the operation which 
failed, to provide context for the error code in the Result TLV.  (Remember 
that there can be multiple path-data in the request, so the CE needs to 
know which thing failed..
If we are in the try-all-operations mode, then at least each operation 
which failed will need its path-data.

And if we instead use verbose responses, then I expect the response to have 
all the path-data from the request, with result TLVs for each one 
indicating success or failure.

Basically, I am just putting the Result-TLV into the path-data where the 
data-raw would have gone.

Yours,
Joel