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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 9 Mar 2015 16:13:16 +0530

Hi Matthias, Esko, Akbar, Carsten and the group,
Thanks for your continued interest on the topic. Good that you find this 
option useful.
 We have tried to address the review comments on the previous version and 
a new version has been uploaded. 

The major changes can be summarized as below:

* The restriction on the message type (NON/CON) has been removed. The 
option is now completely independent of any messaging layer dependency. 
However, a note has been added describing the effect of using this option 
for different message types and response patterns.

* The description text in table 2 have been modified to make it more 
succinct.

* More clarifications has been added to the examples in section 3 to 
uniquely bring out the benefits out of using No-Response. Particularly, 
example in 3.1 clearly points out why update with No-Response is more apt 
in this case rather than Observe with NON notifications.

* More clarification has been added to the example in 3.2 to make it more 
explicit how client-side granular control can be helpful in certain 
scenario. This is to clearly differentiate with a similar server side 
control in the groupcomm RFC.

* The examples combining No-Response and Observe has been removed.

* The section 4.1 on Token re-use has been further modified to clearly 
define all the terms to make it more understandable.

* Few editorial changes have been made as suggested in the review 
comments.
 
Looking forward to hear feedbacks on the draft and whether it is fit for 
acceptance in the WG.

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 03/09/2015 03:34 PM 
-----

From:   [email-masked]
To:     "Soma Bandyopadhyay" <[email-masked]>, "Abhijan 
Bhattacharyya" <[email-masked]>, "Arpan Pal" 
<[email-masked]>, "Arpan Pal" <[email-masked]>, "Soma Bandyopadhyay" 
<[email-masked]>, "Abhijan Bhattacharyya" 
<[email-masked]>
Date:   03/09/2015 03:28 PM
Subject:        New Version Notification for 
draft-tcs-coap-no-response-option-09.txt

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

Name:                            draft-tcs-coap-no-response-option
Revision:                09
Title:                           CoAP option for no server-response
Document date:           2015-03-09
Group:                           Individual Submission
Pages:                           16
URL:            
http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-09.txt

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

Abstract:
   There can be M2M scenarios where responses from server against
   requests from client might be considered 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 simultaneously updating a bulk of
   resources or updating a resource with a very high frequency. CoAP
   already provides a non-confirmable (NON) mode of message exchange
   where the server end-point does not respond with ACK. However,
   obeying the request/response semantics, the server end-point
   responds back with a status code indicating "the result of the
   attempt to understand and satisfy the request".

   This draft introduces a header option for CoAP called 'No-Response'.
   Using this option the client explicitly tells the server to suppress
   responses against the particular request. This option also provides
   granular control to enable suppression of a particular class or a
   combination of response-classes. This option may be effective for
   both unicast and multicast requests. Present draft also discusses
   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