Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses

From: "Dijk, Esko" <[email-masked]>
Date: Sun, 1 May 2016 21:40:24 +0000

Hello Abhijan,

> Mandating such server behaviour from the client side will be a bit out-of-sync with the spirit of the specification.
This is not fully clear to me yet ... the client does not mandate anything from the server; it just expresses its interest (0-bits) and disinterest (1-bits). The server can always not parse the option (elective) or choose not to bother about it.
This does keep the client waiting for a possible response that never comes; but that is the same in the general multicast case : the client can never know if or when a response will come, the server MAY always choose to not respond.

So what I propose is to use the "indication of interest" to specific response classes in a new way; namely to enable certain response classes that are suppressed by default.  It just happens that the same Option syntax is very well suited for that purpose. A separate draft could be written for that perhaps if you think it does not fit in draft-tcs-coap-no-response-option or if it is too late for that. The we can point to the syntax of the No-Response Option and re-use it completely.

regards
Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Friday, April 22, 2016 17:17
To: Dijk, Esko <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; Nevil Brownlee <[email-masked]>
Subject: Re: Using draft-tcs-coap-no-response-option to *enable* responses

Hi Esko,
Thanks for your mail.
First of all let me just bring this to your (as well as the mailing list's) notice that the latest version of the draft is:            https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-16.txt

This version "officially" closes the technical reviews and is with the RFC editor through the IS track.

Now coming to your use case (and indeed it is an interesting one) one thing that we should consider is that the No-Response option was deliberately designed not to mandate anything for the server side mainly to ensure that it does not disrupt the many usefulness of the usual request/response symantics. The draft all along deals with the requesting client's behaviour and its expression of interest to the server. Since this option is elective we leave it upto the server implementation to honour the client's interest.

Now, as per usual request/response symantics the responses are always enabled. The behaviour in groupcomm server in terms of suppressing the responses on its own is something special and, generally speaking, the clients are not aware of such special behaviour.

So, it would be justified to handle the situation at the server's end. Here is the idea:
While No-Response is to expresses client's dis-interest in some or all of the responses depending on the option value, it is also true that the option automatically expresses interest in all other responses (marked by 0's in the respective positions). The client is going to wait for these responses upto a given timeout. Now, if the server behaviour is modified like this : "I have closed my door for all out going response. **BUT**, if I see a fellow requesting with No-Response and keeping windows open to some responses then I assume that this guy really needs those kind of responses. In that case let me be linient and let me open the door for such responses. This fellow must be available to listen to them as per the prescribed behaviour in the No-Response specification."

Mandating such server behaviour from the client side will be a bit out-of-sync with the spirit of the specification.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]<mailto:[email-masked]>
Website: http://www.tcs.com<http://www.tcs.com/>
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

From:        "Dijk, Esko" <[email-masked]<mailto:[email-masked]>>
To:        Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
Cc:        Nevil Brownlee <[email-masked]<mailto:[email-masked]>>, "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Date:        04/22/2016 05:43 PM
Subject:        Using draft-tcs-coap-no-response-option to *enable* responses
________________________________

Hello Abhijan,

in our project we see a clear use case of using the No-Response Option to *enable* certain responses that are by default suppressed.  CoAP allows suppression of multicast responses by default, which is what we use for a lighting multicast use case. However for diagnostic usage we'd like to enable these responses again using the No-Response option which is perfectly suited for that. However, the draft text currently only talks about suppressing responses (not enabling).

Hence my request: could we modify/add some text to show that also the option can be used to enable responses in case where they are normally (by default -- server decision) suppressed?
Just to clarify such usage; which is quite useful in my view.

regards
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 2 May 2016 08:48:53 +0530

Hi Esko,
The existing version -16 has the following text in section 2.1 (page 5) : 
"The server MUST send back responses of the classes for which the client 
has not expressed any dis-interest." 
So, that way the client has actually expressed its interest (or request 
for enablement) in all the responses for which it has not expressed 
explicit disinterest. Does that help to control the special server-side 
behaviour as the server knows which all responses the client is interested 
in and it MUST send a response back ? I shall submit another version with 
some editorial changes before the draft goes to IESG. So we have some more 
room for modification. If you have some comments on this in the line of 
the discussion we are having, please let us know. I shall wait for your 
views before submitting the updated version. 

Anyway, a separate draft (or, possibly, an updated groupcomm RFC?) is a 
good idea. No-Response assumes the usual request/response symantics and it 
mainly addresses the client side behaviour and issues. Considering such 
special behaviour of groupcomm servers, it would be good to handle 
separately.

Waiting to hear from you.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

"Dijk, Esko" <[email-masked]> wrote on 05/02/2016 03:10:24 AM:

> From: "Dijk, Esko" <[email-masked]>
> To: Abhijan Bhattacharyya <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>, Nevil Brownlee <rfc-ise@rfc-
> editor.org>
> Date: 05/02/2016 03:10 AM
> Subject: RE: Using draft-tcs-coap-no-response-option to *enable* 
responses
> 
> Hello Abhijan,
> 
> > Mandating such server behaviour from the client side will be a bit
> out-of-sync with the spirit of the specification.
> This is not fully clear to me yet … the client does not mandate 
> anything from the server; it just expresses its interest (0-bits) 
> and disinterest (1-bits). The server can always not parse the option
> (elective) or choose not to bother about it.
> This does keep the client waiting for a possible response that never
> comes; but that is the same in the general multicast case : the 
> client can never know if or when a response will come, the server 
> MAY always choose to not respond.
> 
> So what I propose is to use the "indication of interest" to specific
> response classes in a new way; namely to enable certain response 
> classes that are suppressed by default.  It just happens that the 
> same Option syntax is very well suited for that purpose. A separate 
> draft could be written for that perhaps if you think it does not fit
> in draft-tcs-coap-no-response-option or if it is too late for that. 
> The we can point to the syntax of the No-Response Option and re-use 
> it completely.
> 
> regards
> Esko
> 
> First of all let me just bring this to your (as well as the mailing 
> list's) notice that the latest version of the draft is: 
> 
https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-16.txt

> Now coming to your use case (and indeed it is an interesting one) 
> one thing that we should consider is that the No-Response option was
> deliberately designed not to mandate anything for the server side 
> mainly to ensure that it does not disrupt the many usefulness of the
> usual request/response symantics. The draft all along deals with the
> requesting client's behaviour and its expression of interest to the 
> server. Since this option is elective we leave it upto the server 
> implementation to honour the client's interest. 
> 
> Now, as per usual request/response symantics the responses are 
> always enabled. The behaviour in groupcomm server in terms of 
> suppressing the responses on its own is something special and, 
> generally speaking, the clients are not aware of such special behaviour. 
 
> While No-Response is to expresses client's dis-interest in some or 
> all of the responses depending on the option value, it is also true 
> that the option automatically expresses interest in all other 
> responses (marked by 0's in the respective positions). The client is
> going to wait for these responses upto a given timeout. Now, if the 
> server behaviour is modified like this : "I have closed my door for 
> all out going response. **BUT**, if I see a fellow requesting with 
> No-Response and keeping windows open to some responses then I assume
> that this guy really needs those kind of responses. In that case let
> me be linient and let me open the door for such responses. This 
> fellow must be available to listen to them as per the prescribed 
> behaviour in the No-Response specification." 
> 
> Mandating such server behaviour from the client side will be a bit 
> out-of-sync with the spirit of the specification. 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Mailto: [email-masked]
> Website: http://www.tcs.com
> From:        "Dijk, Esko" <[email-masked]> 
> To:        Abhijan Bhattacharyya <[email-masked]> 
> Cc:        Nevil Brownlee <[email-masked]>, "[email-masked] WG" <
> [email-masked]> 
> in our project we see a clear use case of using the No-Response 
> Option to *enable* certain responses that are by default suppressed.
> CoAP allows suppression of multicast responses by default, which is 
> what we use for a lighting multicast use case. However for 
> diagnostic usage we'd like to enable these responses again using the
> No-Response option which is perfectly suited for that. However, the 
> draft text currently only talks about suppressing responses (not 
enabling).
> 
> Hence my request: could we modify/add some text to show that also 
> the option can be used to enable responses in case where they are 
> normally (by default -- server decision) suppressed?
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended 
> solely for the addressee(s). If you are not the intended recipient, 
> you are hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 2 May 2016 19:55:01 +0000

Hi,

> "The server MUST send back responses of the classes for which the client has not expressed any dis-interest." -
This covers part of my use case; however it is not clear how this "MUST" interacts with the "MAY suppress" of RFC 7252 for the multicast case. Can the server still decide to suppress the multicast response even if the No-Response Option sent by the client says not to? Thinking about it, it would be perhaps good if draft-tcs-coap-no-response-option would make that clear. The "MUST" and the use case 4.2.1 suggest that the default suppression choices of the server are overridden by the No-Response option but that is not written explicitly yet.  If that is the case, my use case is fully covered by your draft I think.

An update or successor to the Groupcomm RFC could indeed describe how the No-Response Option can be used for multicast use cases. It would be great if that could be done without needing further modifications to draft-tcs-coap-no-response-option!

regards
Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Monday, May 02, 2016 5:19
To: Dijk, Esko <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; Nevil Brownlee <[email-masked]>
Subject: RE: Using draft-tcs-coap-no-response-option to *enable* responses
Importance: High

Hi Esko,
The existing version -16 has the following text in section 2.1 (page 5) :
"The server MUST send back responses of the classes for which the client has not expressed any dis-interest."
So, that way the client has actually expressed its interest (or request for enablement) in all the responses for which it has not expressed explicit disinterest. Does that help to control the special server-side behaviour as the server knows which all responses the client is interested in and it MUST send a response back ? I shall submit another version with some editorial changes before the draft goes to IESG. So we have some more room for modification. If you have some comments on this in the line of the discussion we are having, please let us know. I shall wait for your views before submitting the updated version.

Anyway, a separate draft (or, possibly, an updated groupcomm RFC?) is a good idea. No-Response assumes the usual request/response symantics and it mainly addresses the client side behaviour and issues. Considering such special behaviour of groupcomm servers, it would be good to handle separately.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]<mailto:[email-masked]>> wrote on 05/02/2016 03:10:24 AM:

> Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>, Nevil Brownlee <rfc-ise@rfc-
> editor.org>
> Subject: RE: Using draft-tcs-coap-no-response-option to *enable* responses
>
> Hello Abhijan,
>
> To: Dijk, Esko <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>; Nevil Brownlee <[email-masked]<mailto:[email-masked]>>
> draft text currently only talks about suppressing responses (not enabling).
>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 4 May 2016 01:22:45 +0530

Hi Esko,
Thanks for responding. The discussion is leading to exactly what I was 
thinking about.
So, if we enhance the text as below would it be good for the purpose? 
Please comment.

"The server MUST send back responses of the classes for which the client 
has not expressed any dis-interest. There are instances where a server, on 
its own, may decide to suppress responses like the multicast servers as 
described in section 2.7 of  [RFC7390]. If the server receives a request 
with No-Response showing 'interest' in certain responses then such 
behaviour of suppressing responses by servers MUST be over-ridden for 
those responses which are of interest to the client. The server MUST send 
those responses for which the client has not expressed any disinterest 
(i.e., expressed 'interest'). So, for example, if a multicast server 
decides to suppress all responses and receives a request with No-Response 
option expressing disinterest only in success responses but not in errors 
then the server MUST send back a response if the concerned request causes 
an error. "

 Hopefully, this will solve a potential problem when the client actually 
wants to debug the lights through granular No-Response but the servers 
decide not to send a response as default behaviour and the client is never 
aware of that. However, it would be good if the above could be 
reciprocated by some specification which deals with the server-side 
behaviour.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]> wrote on 05/03/2016 01:25:01 AM:

> Date: 05/03/2016 01:25 AM
responses
> 
> Hi,
> 
> > "The server MUST send back responses of the classes for which the 
> client has not expressed any dis-interest." - 
> This covers part of my use case; however it is not clear how this 
> "MUST" interacts with the "MAY suppress" of RFC 7252 for the 
> multicast case. Can the server still decide to suppress the 
> multicast response even if the No-Response Option sent by the client
> says not to? Thinking about it, it would be perhaps good if draft-
> tcs-coap-no-response-option would make that clear. The "MUST" and 
> the use case 4.2.1 suggest that the default suppression choices of 
> the server are overridden by the No-Response option but that is not 
> written explicitly yet.  If that is the case, my use case is fully 
> covered by your draft I think.
> 
> An update or successor to the Groupcomm RFC could indeed describe 
> how the No-Response Option can be used for multicast use cases. It 
> would be great if that could be done without needing further 
> modifications to draft-tcs-coap-no-response-option!
> 
> regards
> Esko
> 
responses
> "The server MUST send back responses of the classes for which the 
> client has not expressed any dis-interest." 
> So, that way the client has actually expressed its interest (or 
> request for enablement) in all the responses for which it has not 
> expressed explicit disinterest. Does that help to control the 
> special server-side behaviour as the server knows which all 
> responses the client is interested in and it MUST send a response 
> back ? I shall submit another version with some editorial changes 
> before the draft goes to IESG. So we have some more room for 
> modification. If you have some comments on this in the line of the 
> discussion we are having, please let us know. I shall wait for your 
> Anyway, a separate draft (or, possibly, an updated groupcomm RFC?) 
> is a good idea. No-Response assumes the usual request/response 
> symantics and it mainly addresses the client side behaviour and 
> issues. Considering such special behaviour of groupcomm servers, it 
> would be good to handle separately. 
> 
responses 
> > Cc: [email-masked] WG <[email-masked]>; Nevil Brownlee 
<[email-masked]
enabling).

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 3 May 2016 21:14:08 +0000

Hello Abhijan,

Agreed; below a proposed updated text that separates the example from the specification part. The number of MUSTs is also reduced to two. (Might be even reduced to one – only the first, but leaving that to the editing process… I think an example typically does not have a MUST)

---
The server MUST send back responses of the classes for which the client has not expressed any disinterest. There are instances where a server, on its own, decides to suppress responses like the multicast servers described in Section 2.7 of  [RFC7390]. If such a server receives a request with a No-Response Option showing interest in specific response classes, then any default behaviour of suppressing responses – if present – MUST be overridden to deliver those responses which are of interest to the client.

So, for example, if a multicast server suppresses all responses by default and receives a request with a No-Response Option expressing disinterest in 2.xx success responses, and interest in error responses 4.xx/5.xx, then the server must send back a response if the concerned request caused an error.
---

regards,
Esko

Sent: Tuesday, May 03, 2016 21:53

Hi Esko,
Thanks for responding. The discussion is leading to exactly what I was thinking about.
So, if we enhance the text as below would it be good for the purpose? Please comment.

"The server MUST send back responses of the classes for which the client has not expressed any dis-interest. There are instances where a server, on its own, may decide to suppress responses like the multicast servers as described in section 2.7 of  [RFC7390]. If the server receives a request with No-Response showing 'interest' in certain responses then such behaviour of suppressing responses by servers MUST be over-ridden for those responses which are of interest to the client. The server MUST send those responses for which the client has not expressed any disinterest (i.e., expressed 'interest'). So, for example, if a multicast server decides to suppress all responses and receives a request with No-Response option expressing disinterest only in success responses but not in errors then the server MUST send back a response if the concerned request causes an error. "

 Hopefully, this will solve a potential problem when the client actually wants to debug the lights through granular No-Response but the servers decide not to send a response as default behaviour and the client is never aware of that. However, it would be good if the above could be reciprocated by some specification which deals with the server-side behaviour.

Regards
Abhijan Bhattacharyya
Associate Consultant

"Dijk, Esko" <[email-masked]<mailto:[email-masked]>> wrote on 05/03/2016 01:25:01 AM:

> > Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>; Nevil Brownlee <[email-masked]
<mailto:[email-masked]%0b>> >

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 4 May 2016 10:13:27 +0530

Hi Esko,
Thanks. I shall update the next version accordingly. I am happy that we 
could satisfy your use case finally. 

Regards
Abhijan Bhattacharyya
Associate Consultant

From:   "Dijk, Esko" <[email-masked]>
To:     Abhijan Bhattacharyya <[email-masked]>
Cc:     "[email-masked] WG" <[email-masked]>, Nevil Brownlee 
<[email-masked]>
Date:   05/04/2016 02:44 AM
Subject:        RE: Using draft-tcs-coap-no-response-option to *enable* 
responses

Hello Abhijan,
 
Agreed; below a proposed updated text that separates the example from the 
specification part. The number of MUSTs is also reduced to two. (Might be 
even reduced to one – only the first, but leaving that to the editing 
process… I think an example typically does not have a MUST)
 
---
The server MUST send back responses of the classes for which the client 
has not expressed any disinterest. There are instances where a server, on 
its own, decides to suppress responses like the multicast servers 
described in Section 2.7 of  [RFC7390]. If such a server receives a 
request with a No-Response Option showing interest in specific response 
classes, then any default behaviour of suppressing responses – if present 
– MUST be overridden to deliver those responses which are of interest to 
the client. 
 
So, for example, if a multicast server suppresses all responses by default 
and receives a request with a No-Response Option expressing disinterest in 
2.xx success responses, and interest in error responses 4.xx/5.xx, then 
the server must send back a response if the concerned request caused an 
error.
---
 
regards,
Esko
 
<[email-masked]>
 
Hi Esko, 

Regards
Abhijan Bhattacharyya
Associate Consultant

responses 
responses
responses 
> > Cc: [email-masked] WG <[email-masked]>; Nevil Brownlee <
[email-masked]
enabling).
> sender by return e-mail and destroy all copies of the original message. 

The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby 
notified that any use, forwarding, dissemination, or reproduction of this 
message is strictly prohibited and may be unlawful. If you are not the 
intended recipient, please contact the sender by return e-mail and destroy 
all copies of the original message.