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

["Dijk, Esko" <[e-mail]>]

Hello Abhijan,

Thanks for the update. Here a few more remarks to consider:

1.  Table 2, DELETE method: "MAY NOT" is not defined in RFC 2119 - so better not used.
Here the current text does not give much guidance. And there seems to be no need for requirements language I think? What about:
"If the client wants to ensure that the deletion really happened, it should not make use of the No-Response option. No use cases have been identified so far for DELETE."
I would not capitalize the "should not" in this text, like we have for the GET case.

2. I would separate the option definition from the applicability table 2. So, the text starting with "This option contains values to indicate disinterest in ..." and the table itself could go into a new subsection called "Applicability for CoAP Methods" or similar. Because strictly speaking it is not part of the option definition.

3. The text in the Table 2 on GET talks about 'usual circumstances' which may leave the reader wondering if GET to cancel an observe relation is usual or unusual.
In fact we could say that the option MAY be used in a GET request intended to cancel an Observe relationship; and the option SHOULD NOT be used by the client in other cases - with the exception being that a clear use case for this is identified. Still a server MUST support a combination of GET with the No-Response option.

4. Section 4.3 on the HC Proxy: returning 204 No Content seems not applicable in many cases - e.g. some HTTP methods may not allow for a 204 response (I didn't check it though).
Also the HC Proxy doesn't know whether the request was successful (which 204 implies) or not.   So I don't see why we can give this guideline without knowing the specific (use) cases.
What we can say at least is that: a HTTP PUT request SHOULD be answered with HTTP 204 , if the HC Proxy chose to suppress all classes of responses in the corresponding CoAP PUT request.
(For example if the HC Proxy does partial suppression of only class 2.xx, then it gets more complicated - I could program my HC Proxy to wait a 20 seconds and only if no CoAP error response comes the proxy decides to answer with HTTP 204. This is more intricate than "always answer 204".)

Regards,
Esko

From: Abhijan Bhattacharyya [mailto:[e-mail]]
Sent: Thursday, October 15, 2015 15:23
To: Dijk, Esko <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Fw: New Version Notification for draft-tcs-coap-no-response-option-12.txt

Hi Carsten, Esko, Akbar and all,

Based on the recent inputs we have shared a new version of the No-Response draft.

Esko, I have actually removed the 'Leisure' stuff for unicast. Thought it was making things a bit complicated.

Akbar, The reverse proxy consideration have been included as a new section 4.3.

Carsten, requesting your suggestion regarding the next step forward.

Hoping to see you all in Yokohama.

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

----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM -----

From:        [e-mail]<mailto:[e-mail]>
To:        "Soma Bandyopadhyay" <[e-mail]<mailto:[e-mail]>>, "Soma Bandyopadhyay" <[e-mail]<mailto:[e-mail]>>, "Abhijan Bhattacharyya" <[e-mail]<mailto:[e-mail]>>, "Arpan Pal" <[e-mail]<mailto:[e-mail]>>, "Arpan Pal" <[e-mail]<mailto:[e-mail]>>, "Tulika Bose" <[e-mail]<mailto:[e-mail]>>, "Abhijan Bhattacharyya" <[e-mail]<mailto:[e-mail]>>, "Tulika Bose" <[e-mail]<mailto:[e-mail]>>
Date:        10/15/2015 06:45 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-12.txt
________________________________




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

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

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.