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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Sat, 28 Sep 2013 12:59:31 +0530

Hi all,
We have submitted a new draft on the No-Resp option. This draft contains significant changes than the previous versions. Thanks to the comments from Carsten, Esko and Bert. This draft incorporates few user scenarios before discussing the technical details. The user scenarios are described in the light of how application of this option might benefit resource constrained environments. Taking clue from the comments we received, this draft enhances this option to allow 'optional' granularity so that one can choose to suppress a particular class or a combination of classes of responses.

Please share your comments. 

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

-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/28/2013 12:49PM -----
To: Abhijan Bhattacharyya <[email-masked]>, Soma Bandyopadhyay <[email-masked]>, Arpan Pal <[email-masked]>
From: [email-masked]
Date: 09/28/2013 12:48PM
Subject: New Version Notification for draft-tcs-coap-no-response-option-02.txt

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

Filename:	 draft-tcs-coap-no-response-option
Revision:	 02
Title:	 CoAP option for no server-response
Creation date:	 2013-09-28
Group:	 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-02.txt
Status:          http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option
Htmlized:        http://tools.ietf.org/html/draft-tcs-coap-no-response-option-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-02

Abstract:
   There can be typical M2M scenarios where responses from the data
   sink to the data source against request/ notification from the
   source might be considered redundant. This kind of open-loop
   exchange (with no reverse path from the sink to the source) may be
   desired while updating resources or notifying about the updated
   status of a resource in constrained systems looking for maximized
   throughput with minimized resource consumption. CoAP already
   provides a non-confirmable (NON) mode of exchange where The
   receiving end-point does not respond with ACK. However, the
   receiving end-point responds the sender with a status code
   indicating "the result of the attempt to understand and satisfy the
   request".

   This draft introduces a header option: 'No-Resp' to suppress
   responses from the receiver and discusses exemplary use cases which
   motivated this proposition based on real experience. This option
   also provides granularity by allowing suppression of a particular
   class or a combination of classes of responses. This option is
   applicable for both request/ response as well as resource-observe
   mode and may be effective for both unicast and multicast scenarios.

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: "Rahman, Akbar" <[email-masked]>
Date: Mon, 30 Sep 2013 13:55:25 -0400

Hi Abhijan,

Thank you for the interesting draft.  I took a quick look at it and had
two comments for now:

1)      Editorial - You should re-title your draft name to be in the
form "draft-Bhattacharyya-core-no-response".  If you do not have the
word "core" in the draft name then it does not show up on the CORE
document page (http://datatracker.ietf.org/wg/core/).

2)      In your Exemplary scenarios (Section 3) you refer to the use of
your proposal for "PUT or POST".  I can see how it may work with PUT.
But I do not think it makes sense with POST.  This is because if your
read the base CoAP spec, you will see that a POST typically results in a
new URI (resource) created for the data sent with the POST (see
http://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.8.2).  So I
cannot easily envision sending a POST with a "No-Response" header.
That is, then the client would never know the URI that it caused to be
created by the POST, and therefore is not logical.  Am I missing
something?

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Abhijan Bhattacharyya
Sent: Saturday, September 28, 2013 3:30 AM
To: [email-masked]
Cc: Soma Bandyopadhyay; Arpan Pal
Subject: [core] Fw: New Version Notification
fordraft-tcs-coap-no-response-option-02.txt

Hi all,

We have submitted a new draft on the No-Resp option. This draft contains
significant changes than the previous versions. Thanks to the comments
from Carsten, Esko and Bert. This draft incorporates few user scenarios
before discussing the technical details. The user scenarios are
described in the light of how application of this option might benefit
resource constrained environments. Taking clue from the comments we
received, this draft enhances this option to allow 'optional'
granularity so that one can choose to suppress a particular class or a
combination of classes of responses.

Regards
Abhijan Bhattacharyya
Associate Consultant

-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 09/28/2013 12:49PM
-----

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

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

Filename: draft-tcs-coap-no-response-option
Revision: 02
Title: CoAP option for no server-response
Creation date: 2013-09-28
Group: Individual Submission
Number of pages: 12
URL:
http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-02
.txt
Status:
http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option
Htmlized:
http://tools.ietf.org/html/draft-tcs-coap-no-response-option-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-02

Abstract:

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Sep 2013 20:09:50 +0200

> 1)      Editorial - You should re-title your draft name to be in the form “draft-Bhattacharyya-core-no-response”.  If you do not have the word “core” in the draft name then it does not show up on the CORE document page (http://datatracker.ietf.org/wg/core/).

While using the WG name as the third word in the draft name is always a good idea, in this case at least the tools page for CoRE, http://tools.ietf.org/wg/core/, does show the draft.
(I made special arrangements a while ago to have documents with "coap" in the name show up there.)
Changing the name always causes some confusion.

>  2)      In your Exemplary scenarios (Section 3) you refer to the use of  your proposal for “PUT or POST”.  I can see how it may work with PUT.  But I do not think it makes sense with POST.  This is because if your read the base CoAP spec, you will see that a POST typically results in a new URI (resource) created for the data sent with the POST (seehttp://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.8.2).  So I cannot easily envision sending a POST with a “No-Response” header.   That is, then the client would never know the URI that it caused to be created by the POST, and therefore is not logical.  Am I missing something?

Indeed, without a response the client would not know the URI selected by the server for the new resource created.
There may still be applications where this is acceptable, e.g. if no further client access is required, or if the new resources are later picked up by a different client that finds them using a collection resource.
The draft probably should give an example for this.

One other comment I have is that the option uses uint in a way that is sensitive to the length.
It would be much better if the zero-byte version and any one-byte version of a zero had the same semantics.
To do this, the bits set (1/2/4 for 2.xx, 4.xx, 5.xx) could be defined to re-enable, not suppress, the response.

More generally speaking, I have a bit of trouble imagining how a client implementation would handle a response in one of these cases, as it no longer knows whether a response is to be expected and when it can stop expecting one (which also means the token can be re-used for another request).

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 30 Sep 2013 14:54:51 -0400

> There may still be applications where this is acceptable, e.g. if no
further client access is required, or if the new resources are later
picked up by a different client that finds them using a collection
resource. The draft probably should give an example for this.

Yes, I agree this is possible.  I just got an impression from the
existing I-D examples that the "No Response" feature was mostly targeted
towards high frequency updates (i.e. PUT) for which a response was not
required (to reduce congestion, reduce BW usage, etc).  But perhaps a
new class of examples showing how this would benefit POST can change
this perception.