Subject: [issue22] Overview - Response Formatting

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 16 Jun 2005 11:52:44 -0400

Can we work on closing issue #22? Knocking it off will allow us to
resolve a few outstanding issues.

Url is: http://www.mip4.org/issues/tracker/forces/issue22

cheers,
jamal

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 25 Jun 2005 14:48:30 -0700

Jamal,

It seems like I misunderstand what you mean by Full Response...from your
email and that of Alex, looks like you mean is sending back the Request
Message in every response, right? If that is the case then this is not
what we have done nor what we need for the protocol....we are in
complete agreement.

What I mean by full Response, is getting back a message for each
Request... e.g. Config Response for Config Request, that tells me
whether it was successful or it failed. We already have provisions for
this in the protocol...the ACK flags allow us to do this.
      - ACK indicator(2 bit)
           The description for using the two bits is:
               'NoACK' (00)
               'SuccessACK'(01)
               'UnsuccessACK'(10)
               'ACKAll' (11)

The RESULT TLV is probably also about the details of what should be
returned in response to the request.

It seems to me like this issue should be closed since we already have
agreement on the ACK flags. Let me know your thoughts?

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Friday, June 24, 2005 6:12 AM
To: [email-masked]
Subject: Re: [FORCES] [issue22] Overview - Response Formatting

On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> I briefly looked at this...
> 
> I don't agree with what is said about 3.xx.1 Full response in the
text.
> We have sent responses for all messages, its worked out very well and
> its important for building a reliable product.
> 

Parse error. What do you mean by so far you have sent response for all
messages?
(cliches like "reliable product" to justify anything technical will end
up diverting the focus of the discussion -  and I am pretty sure we dont
have marketing people participating that need to be confused with such
terms. Why not be explicit?).

I think the Full response will have to go; it's more there for
completion sake. I cant remember why it was rejected; i know it will
consume more bandwidth. It's value is in as mentioned to validate what
was sent. This is derived from looking at behaviors of certain hardware.
There is hardware out there (typically using CAMs) which returns you
both the question asked and answer to the question. 

> Also, stated...
> 3.xx.2.2 More than Basic
> Proposed by both Weiming and Joel: Introduce RESULT TLV
> to describe the results of a SET operation. The RESULT TLV will
> have more data in it than what 3.2.1 is proposing.
> 
> I don't understand the difference between this and Full response
above.
> Also, what does RESULT TLV look like?
> 

The RESULT TLV is still to be defined. Joel and Weiming were both
proposing it.

Thanks for taking the time to read the text.
It is amazing for a draft that we are trying to rush out to last call
not that many people are responding.

cheers,
jamal