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

[Abhijan Bhattacharyya <[e-mail]>]

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
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________




From:   Klaus Hartke <[e-mail]>
To:     Abhijan Bhattacharyya <[e-mail]>
Cc:     "[e-mail] WG" <[e-mail]>, Nevil Brownlee 
<[e-mail]>
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,

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
<[e-mail]> wrote:
> 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: [e-mail]
> 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:        [e-mail]
> To:        "Soma Bandyopadhyay" <[e-mail]>, "Abhijan
> Bhattacharyya" <[e-mail]>, "Arpan Pal"
> <[e-mail]>, "Tulika Bose" <[e-mail]>
> 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
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>