Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 4 Apr 2016 17:26:19 +0530

Dear list,
A new version of the No-Response draft has been submitted addressing the 
final review comments received through the RFC editor's desk. This 
document is now in RFC editor's queue through the individual submission 
track.
Thanks to Matthias for the review comments.

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
____________________________________________

----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 04/04/2016 05:22 PM 
-----

From:   [email-masked]
To:     "Soma Bandyopadhyay" <[email-masked]>, "Abhijan 
Bhattacharyya" <[email-masked]>, "Arpan Pal" 
<[email-masked]>, "Tulika Bose" <[email-masked]>
Date:   04/04/2016 05:18 PM
Subject:        New Version Notification for 
draft-tcs-coap-no-response-option-15.txt

A new version of I-D, draft-tcs-coap-no-response-option-15.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name:                            draft-tcs-coap-no-response-option
Revision:                15
Title:                           CoAP option for no server-response
Document date:           2016-04-04
Group:                           Individual Submission
Pages:                           18
URL:            
https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-15.txt

Status:         
https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       
https://tools.ietf.org/html/draft-tcs-coap-no-response-option-15
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-15

Abstract:
   There can be M2M scenarios where responses from a server against
   requests from client are redundant. This kind of open-loop exchange
   (with no response path from the server to the client) may be desired
   to minimize resource consumption in constrained systems while
   updating a bulk of resources simultaneously, or updating a resource
   with a very high frequency. CoAP already provides Non-confirmable
   (NON) messages that are not acknowledged by the recipient. However,
   the request/response semantics still require the server to respond
   with a status code indicating "the result of the attempt to
   understand and satisfy the request".

   This specification introduces a CoAP option called 'No-Response'.
   Using this option the client can explicitly tell the server to
   suppress all responses against the particular request. This option
   also provides granular control to enable suppression of a particular
   class of response or a combination of response-classes. This option
   may be effective for both unicast and multicast requests. This
   document also discusses a few exemplary applications which benefit
   from this option.

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=====-----=====-----=====
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: Klaus Hartke <[email-masked]>
Date: Tue, 5 Apr 2016 17:08:57 +0200

Hi Abhijan,

I've taken a brief look at the new revision. It worries me that the
draft does not contain the words "safe-to-forward", "proxy" (besides
HTTP-to-CoAP reverse proxy) and "cache". The interaction of a new
option with these CoAP features is an important aspect and needs
careful analysis. I don't think it's a good idea to publish the draft
as an RFC before the text addresses the following questions:

* What's the rationale for the No-Response option being safe-to-forward?

* What's the impact of the No-Response option on a chain of
CoAP-to-CoAP proxies?

* What's the impact of the No-Response option on caches?

Klaus

On 4 April 2016 at 13:56, Abhijan Bhattacharyya
<[email-masked]> wrote:
> final review comments received through the RFC editor's desk. This document
> is now in RFC editor's queue through the individual submission track.
> ________________________________
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 6 Apr 2016 00:22:19 +0530

Hi Klaus,
Thanks for your comments. 
Actually, yesterday I got to know from Matthias that you have rightly 
pointed out the safe-to-forward issue. I have taken some action on the 
draft and shared the modified text with Carsten and Matthias earlier 
today. I really should have included you as well. Sorry about that. 

The option should be Unsafe-to-forward. The option definition has been 
modified as below:

"
The properties of No-Response option are given in Table 1. 
+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R |   Name      | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
|   258  |   | X | - |   | No-Response |  uint  |  0-1   |    0    |
+--------+---+---+---+---+-------------+--------+--------+---------+
                        Table 1: Option Properties
This option is a request option. It is Elective and Non-Repeatable. This 
option is Unsafe-to-forward as the intermediary MUST know how to interpret 
this option. Otherwise the intermediary, without knowledge about the 
special unidirectional nature of the request, would wait for responses.
"

Now regarding the other two points:
>> What's the impact of the No-Response option on a chain of
CoAP-to-CoAP proxies?

Since, this option is unsafe-to-forward, the intermediaries must have 
knowledge about the option. So, the intermediaries should not wait for any 
responses if the option value is 127. For granular suppression it should 
wait for up to some given time out as described in the "Note" in section 
2.1. 

>> What's the impact of the No-Response option on caches?
Since the cacheability of the CoAP responses depends on the Response Code 
so the No-Response option should not have any effect on the cacheability. 
Suppose, we have a request which triggers a cacheable response. But, if 
the request has No-Response then the response should be cached but will 
not be delivered to the client (assuming that server has implementation of 
No-Response). If a similar request without No-Response arrives next time 
then the response may be delivered from Cache if considered fresh.

Does the above sound good? Please share your views. 

Regards
Abhijan Bhattacharyya
Associate Consultant

From:   Klaus Hartke <[email-masked]>
To:     Abhijan Bhattacharyya <[email-masked]>
Cc:     "[email-masked] WG" <[email-masked]>, Nevil Brownlee 
<[email-masked]>
Date:   04/05/2016 08:39 PM
Subject:        Re: [core] Fw: New Version Notification for 
draft-tcs-coap-no-response-option-15.txt

Hi Abhijan,

Klaus

> final review comments received through the RFC editor's desk. This 
document

submission

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 5 Apr 2016 22:03:58 +0200

Abhijan Bhattacharyya wrote:
> "[...] This
> this option. [...]"

Unsafe-to-forward does not mean that every intermediary has the
requirement to implement your option. Unsafe-to-forward determines the
behaviour of intermediaries that do *not* implement an option. If an
intermediary receives a request with an unrecognised option that is
unsafe-to-forward, then it must not include that option in its request
towards the origin server.

> Now regarding the other two points:

(Note that these points need to be addressed in the document, not just
on the mailing list.)

> knowledge about the option.

No. See above.

> So, the intermediaries should not wait for any
> responses if the option value is 127.

What do you mean? If an intermediary receives a request with the
No-Response option, should it include the option in its request
towards the origin server? That's a bad idea. See below.

And a client should probably listen to responses even if it suppresses
all responses because a server might still want to send a response,
e.g., to slow down the client. See below.

> Since the cacheability of the CoAP responses depends on the Response Code so
> the No-Response option should not have any effect on the cacheability.

If a server returns a 4.04 response (or any other cacheable error
response) with Max-Age != 0, then a cache will return that response as
long as Max-Age has not elapsed instead of making a request towards
the origin server. So the caching of error responses protects a server
a bit from clients repeatedly triggering the same error. The
No-Response option destroys this protection. To limit the damage, I
would say that intermediaries MUST NOT include the No-Response option
in their requests.

How does the No-Response option interact with the 4.29 response code
[1]? I would expect that a server is permitted to send this response
even if the client suppresses this response code.

An unrelated nit: Section 2.1 says "To suppress all possible
responses: The maximum reserved response code for CoAP is 7.31". The
range 6.00 to 7.31 is reserved, but not for response codes. The
maximum response code is 5.31.

Klaus

[1] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-04#section-9.3