Subject: Re: Result TLV

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

Thanks for the clarification, Joel! That's completely fine with me.
So it looks like....

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

This is more granular and makes sense to me (what I would have expected
to see in the response). Therefore I asked for the clarification below.

Regards
Hormuzd

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2005 12:34 PM
To: Khosravi, Hormuzd M; [email-masked]
Subject: RE: [FORCES] Result TLV

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

At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote:
>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: Robert Haas <[email-masked]>
Date: Thu, 28 Jul 2005 17:32:32 +0200

Hormuzd,
Also, mention that the format is not necessarily one Path-data TLV and 
one Result TLV: there could be multiple.

Regards,
-Robert

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha