Subject: Re: Protocol Operations - message response formating

From: "Putzolu, David" <[email-masked]>
Date: Wed, 9 Feb 2005 11:00:26 -0800

I am in agreement that I would just prefer the CE do a GET after the SET
if the ack is not sufficient.  Every flag/option we can remove without 
significantly hurting functionality is a step in the right direction.

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 09, 2005 8:11 AM
To: [email-masked]
Subject: Re: [FORCES] Protocol Operations - message response formating

I understand the description.

What I don't understand is why we need to support this mode.

If the CE is that paranoid, it can do a GET after it does the SET.
Having 
an option to echo the data back in the SET response adds more protocol 
complexity without an added value I can understand.

On the rest of it, the issue seems to come back to the ganularity.  If
the 
WG agrees that an operation TLV always succeeds or fails together, then
I 
am happy not to introduce SETRESULT TLVs buried inside the OPERATION
response.

Yours,
Joel

At 10:58 AM 2/9/2005, Jamal Hadi Salim wrote:
>4) Like mentioned so far you may want the dataraw to be reported back.
>
>Essentially what sent is responded to in full with status regardless of
>whether it failed or succeeded.
>
>Use case:
>This is paranoia mode which uses a lot more bandwidth than other modes
>(allows sender to validate what was sent).
>
>
> > (As an aside, could someone explain the value of a verbose set 
> response.  I
> > seem to have missed the use case that motivates it?)
>
>Refer to 4 above.