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

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 7 Feb 2015 02:41:52 +0000

Dear Abhijan,
dear group

Here is my review of the No-Response draft. In general, I can see a benefit in the new option, but the draft still needs work:

First, the benefits and use cases of No-Response need to be stated earlier and clearer. For this, Section 1.1 should be moved to Section 2 and become a part of the option definition. Both Section 3 and 5 provide examples for the usage, but fail to clearly state the necessity of this new option. The main point here should be why Observe does not work for the intended use cases. The argument I can see here is a data collection endpoint that is unable to know all its data sources or has more sources than he can handle with its available (computing) resources. Here the classic model of POSTing clients is better suited than observing resources, where the collection service (CoAP client) must manage observe relationships to all origin servers.

The text on No-Response and Observe "combined together" (4.4 / 5.2) is very confusing. There is in fact no combination. REST is a layered architecture and one layer does not care how the next layer gets its data. Hence, it should be out of scope for the draft how a server receiving POST requests can provide the data to another clients (using Observe on changing resources is pretty straight forward).

The concept of transient resources and POST updating though resource creation (5.1.2.2) is quite weird and should also be out of scope. Using POST while encoding the data in the Uri-Query is a bad practice. It is also not clear to me, which resource is observed by the clients of the next layer. CoAP-MQ has a cleaner approach here and is probably the better place to describe this concept (if my assumption is correct that the transient resources in the No-Response draft should achieve the same thing).

The described suppression of response for multicast in Section 3.2 is already discussed in RFC 7390 (group-comm). I would rather like to see a clear definition how the No-Response option can make the suppression for group communication explicit. Disabling the suppression by setting the bits in the option bitmap for the code classes to receive could help debugging applications and networks. Since the option is elective, servers do not need to comply when this would cause too much energy drain.

I think it is a bad idea to mingle the concept of the infamous Patience option into the draft (4.2). I am also very confused by the reference to the Leisure for unicast.

Discussing congestion (4.3) must be more prominent in the draft. The requirement to "strategically interweave requests without No-Response" needs to be a MUST. The exact rule should be discussed by the working group (maybe in particular the CoCoA authors).

The messaging and request-response sub-layers should be kept separated. Hence, the behavior must be the same for NON and CON messages. Still there needs to be a discussion with message type makes sense in the targeted use cases. Also think about the TCP binding of CoAP there.

As a general remark, the draft needs to become normative by replacing the many SHOULDs and soft wording with clear specifications.

Editorial comments:
I saw heavy use of the word "typical," even when it did not quite fit.
Calling a CoAP endpoint "sensor-gateway" (3.1) can be very confusing.

Best regards
Matthias

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Wednesday, 21 January 2015 13:52
To: Kovatsch Matthias
Cc: [email-masked]
Subject: Fw: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt
Importance: High

Hi Matthias,
Wish, things are fine at your end. Hope you remember the discussion I had with you during last IETF meeting in Honolulu. I requested you for reviewing my draft. If you have noticed, I have submitted a new version of the draft (ver 8) (please refer to the mail below).
Requesting your review comments on the same please.

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
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 06:14 PM -----

From:        Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
To:        [email-masked]<mailto:[email-masked]>
Date:        01/21/2015 06:05 PM
Subject:        [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt
Sent by:        "core" <[email-masked]<mailto:[email-masked]>>
________________________________

Hi all,
A modified version of the No-Response draft has been submitted. This draft has so far addressed all the technical comments received during the past meetings and mailing list discussions. We would urge the CoRE members to do a review of the draft and share their comments. Also, would request people to implement this option.

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
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM -----

From:        [email-masked]<mailto:[email-masked]>
To:        Soma Bandyopadhyay <[email-masked]<mailto:[email-masked]>>, "Abhijan Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal" <[email-masked]<mailto:[email-masked]>>, Arpan Pal <[email-masked]<mailto:[email-masked]>>, "Soma Bandyopadhyay" <[email-masked]<mailto:[email-masked]>>, Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
Date:        01/21/2015 05:57 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-08.txt
________________________________

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

Name:                                  draft-tcs-coap-no-response-option
Revision:                 08
Title:                                  CoAP option for no server-response
Document date:                 2015-01-21
Group:                                  Individual Submission
Pages:                                  17
URL:            http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-08.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-08
Diff:           http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-08

Abstract:
 There can be typical M2M scenarios where responses from server
 against request from client might be considered redundant. This kind
 of open-loop exchange (with no reverse path from the server to the
 client) may be typically 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 exchange where the
 server end-point does not respond with ACK. However, 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'.
 The option explicitly tells the server to suppress responses about
 the state of the resource against the request from the client. This
 option also provides granular control by allowing suppression of a
 typical class or a combination of classes of responses. This option
 may be effective for both unicast and multicast requests. This draft
 discusses few exemplary applications which might 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core