Subject: Re: Result TLV

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 16 Jul 2005 22:47:22 -0700

Sure, not a problem. I would request Avri to take care of this in her
editorial updates to the draft.

So I guess this issue can be closed as well. That's good.

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: Friday, July 15, 2005 5:14 AM
To: [email-masked]
Subject: Re: [FORCES] Result TLV

Hormuzd,

I highly suggest to separate the Operation TLV figure from the whole LFB
select TLV figure in the config message, like what shown in the Qeury
message.  The reason is, with the following figure shown, it may be
easily lead to an ambiguity that the Operation TLV is parallel with
LFBselect TLV rather than being a nested TLV.

This also saves some space, for you otherwise need to duplicates the
text, and it also makes the text more consistent with other messages in
look.

Thanks,
Weiming

----- Original Message ----- 
From: "Khosravi, Hormuzd M" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 14, 2005 12:58 PM
Subject: Re: Result TLV

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