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

From: "weigengyu" <[email-masked]>
Date: Mon, 2 Nov 2015 11:38:37 +0800

Hi Abhijan,

one question,

> 2. Option Definition
> Using this option with CON type of requests may not have any
      significance if piggybacked responses are triggered. But, in case
      the server responds with a separate response (which, may be, the
      client does not care about) then this option can be useful.
      Suppressing the separate response reduces one additional traffic
      in this case.

The No-reponse option is about request and response layer semantics. 
When No-response option works, why the piggybacked responses are triggered unless No-response is not recognized. 
If the No-Response option works, it would stop the response whether it is the piggybacked or the separated. 
It is uncleatr why it is different between the piggybacked and the separate.

When the receive ignore the No-Response option, it can response by piggybacked or separated way. 
Why does the draft suppose just to suppress the separate response?    

And when the No-Response works, the ACK of CON may contain an empty response. 
The following process of the sender side is the same as definitions for suppressing separate response.  

The CON/ACK is about the message layer semantics. 
It seems that the No-reponse does not touch the message layer semantics. 

Regards,

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Rahman, Akbar 
Sent: Sunday, October 18, 2015 8:17 AM
To: Abhijan Bhattacharyya ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt

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

Thanks, Abhijan.  Looks good.

One other question, why does the draft say “Expired” at the top  even though the expiry date is April 2016?

https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12

From: Abhijan Bhattacharyya [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 9:23 AM
To: [email-masked]; [email-masked]; [email-masked]; Rahman, Akbar <[email-masked]>
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: [email-masked]
Website: 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:        [email-masked] 
To:        "Soma Bandyopadhyay" <[email-masked]>, "Soma Bandyopadhyay" <[email-masked]>, "Abhijan Bhattacharyya" <[email-masked]>, "Arpan Pal" <[email-masked]>, "Arpan Pal" <[email-masked]>, "Tulika Bose" <[email-masked]>, "Abhijan Bhattacharyya" <[email-masked]>, "Tulika Bose" <[email-masked]> 
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

--------------------------------------------------------------------------------
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 2 Nov 2015 15:58:18 +0530

Hi Gengyu,
The description you quoted tries to clarify that No-Response may not have any effect in saving network traffic (e.g. for a PUT request) when it is used in CON mode and the response is supposed to be piggybacked. Because in case of piggybacking you still have the fields for the response code in the response message even if you are not sending any response. 

Regards
Abhijan Bhattacharyya
Associate Consultant

-----"weigengyu" <[email-masked]> wrote: -----

>To: "Rahman, Akbar" <[email-masked]>, "Abhijan
>Bhattacharyya" <[email-masked]>,
><[email-masked]>, <[email-masked]>, <[email-masked]>
>From: "weigengyu" <[email-masked]>
>Date: 11/02/2015 09:08AM
><!--
>/* Font Definitions */
>@font-face
> {font-family:"Cambria Math";
>	panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
>	{font-family:Calibri;
>	panose-1:2 15 5 2 2 2 4 3 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
>	{margin:0in;
>	margin-bottom:.0001pt;
>	font-size:12.0pt;
>	font-family:"Times New Roman",serif;}
>a:link, span.MsoHyperlink
>	{mso-style-priority:99;
>	color:blue;
>	text-decoration:underline;}
>a:visited, span.MsoHyperlinkFollowed
>	{mso-style-priority:99;
>	color:purple;
>	text-decoration:underline;}
>p
>	{mso-style-priority:99;
>	mso-margin-top-alt:auto;
>	margin-right:0in;
>	mso-margin-bottom-alt:auto;
>	margin-left:0in;
>	font-size:12.0pt;
>	font-family:"Times New Roman",serif;}
>tt
>	{mso-style-priority:99;
>	font-family:"Courier New";}
>span.EmailStyle19
>	{mso-style-type:personal-reply;
>	font-family:"Calibri",sans-serif;
>	color:#1F497D;}
>.MsoChpDefault
>	{mso-style-type:export-only;
>	font-family:"Calibri",sans-serif;}
>@page WordSection1
>	{size:8.5in 11.0in;
>	margin:1.0in 1.0in 1.0in 1.0in;}
>div.WordSection1
>	{page:WordSection1;}
>-->
>
>
>
>
>Hi Abhijan,
> 
>one question,
> 
>> 2. Option Definition
>When No-response option works, why the piggybacked responses are
>triggered 
>unless No-response is not recognized. 
>If the 
>No-Response option works, it would stop the response whether it is
>the 
>piggybacked or the separated. 
>It is 
>uncleatr why it is different between the piggybacked and the
>separate.
> 
>When the 
>receive ignore the No-Response option, it can response by piggybacked
>or 
>separated way. 
>Why does 
>the draft suppose just to suppress the separate response?    
>
> 
>And when 
>the No-Response works, the ACK of CON may contain an empty response. 
>The 
>following process of the sender side is the same as definitions for
>suppressing 
>separate response.  
> 
>The CON/ACK 
>It seems 
>that the No-reponse does not touch the message layer semantics. 
> 
>Regards,
> 
>Gengyu 
>WEI
>>Akbar, The reverse 
>proxy consideration have been included as a new section 4.3.
> 
>Thanks, 
>Abhijan.  Looks good.
> 
> 
> 
>One 
>other question, why does the draft say &#8220;Expired&#8221; at the top  even
>though 
>the expiry date is April 2016?
> 
>From: Abhijan 
>Bhattacharyya [mailto:[email-masked]] 
>Sent: Thursday, 
>October 15, 2015 9:23 AM
>To: [email-masked]; [email-masked]; 
>[email-masked]; Rahman, Akbar 
><[email-masked]>
>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
>Experience 
>certainty.        IT 
>Services
>Business 
>Solutions
>----- 
>Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM
>----- 
>
>
>From:ÿÿÿÿÿÿÿ 
>[email-masked] 
>
>To:ÿÿÿÿÿÿÿ 
>"Soma 
>Bandyopadhyay" <[email-masked]>, 
>"Soma Bandyopadhyay" <[email-masked]>, 
>"Abhijan Bhattacharyya" <[email-masked]>, 
>"Arpan Pal" <[email-masked]>, 
>"Arpan Pal" <[email-masked]>, 
>"Tulika Bose" <[email-masked]>, "Abhijan 
>Bhattacharyya" <[email-masked]>, 
>"Tulika Bose" <[email-masked]> 
>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-optio
>n-12.txt
>Status:ÿÿÿÿÿÿÿÿ 
>https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
>Htmlized:ÿÿÿÿÿÿ 
>Diff:ÿÿÿÿÿÿÿÿÿÿ 
>https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-1
>2
>
>Abstract:
>ÿ 
>ÿ 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'.
>ÿ 
>ÿ 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.
>
>
>ÿÿÿÿÿÿÿÿÿÿÿ 
>
>
>
>The IETF 
>Secretariat
>core mailing 
>list

---

From: "weigengyu" <[email-masked]>
Date: Thu, 5 Nov 2015 16:03:59 +0800

Hi Abhijan,

In your draft, there is not other contexts about piggybacked and separate response. 
With these statements,
“Using this option with CON type of requests may not have any
      significance if piggybacked responses are triggered. But, in case
      the server responds with a separate response (which, may be, the
      client does not care about) then this option can be useful.
      Suppressing the separate response reduces one additional traffic
      in this case. “ ,

the piggybacked response may be sent back and the separate response may be suppressed. 
Why not to suppress the piggybacked response? 
Even though an ACK of CON is needed, the ACK could be with an empty response instead of a nomormal response.

And if the piggybacked response is not suppressed,  
should the sender expect the suppressed separate response? 

Regards,

Gengyu WEI

From: Abhijan Bhattacharyya 
Sent: Monday, November 02, 2015 6:28 PM
To: weigengyu 
Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt

Hi Gengyu,

Regards
Abhijan Bhattacharyya
Associate Consultant

>other question, why does the draft say “Expired” at the top  even
>though 
>To:        
>Date:        
>Subject:        
>Revision:                 
>date:                 
>Group:                                  
>Pages:                                  
>URL:            
>Status:         
>Htmlized:       
>Diff:           
>  obeying the 
>  responds 
>  This draft 
>  few exemplary

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 5 Nov 2015 21:21:21 +0530

Hi Gengyu,
You can suppress any type of responses. No distinction. We just wanted to mention the 'significance' in terms of resource saving. Hope this clarifies.  

Regards
Abhijan Bhattacharyya
Associate Consultant

>To: "Abhijan Bhattacharyya" <[email-masked]>
>Date: 11/05/2015 05:05PM
>Cc: <[email-masked]>, <[email-masked]>,
><[email-masked]>, <[email-masked]>
>In your draft, there is not other contexts about piggybacked and
>separate 
>response. 
>With these statements,
>&#8220;Using this option with CON type of requests may not have any
>      in this case. &#8220; ,
>the piggybacked response may be sent back and the separate response
>may be 
>suppressed. 
>Cc: [email-masked] ; 
>[email-masked] ; [email-masked] ; [email-masked] 
>The description you quoted tries to clarify that No-Response may not
>have 
>any effect in saving network traffic (e.g. for a PUT request) when it
>is used in 
>CON mode and the response is supposed to be piggybacked. Because in
>case of 
>piggybacking you still have the fields for the response code in the
>response 
>message even if you are not sending any response. 
>
>Regards
>Abhijan 
>Bhattacharyya
>Associate Consultant
>Tata 
>Consultancy Services
>>To: "Rahman, Akbar" 
><[email-masked]>, "Abhijan
>>Bhattacharyya" 
>Re: [core] New Version Notification 
>for
>>draft-tcs-coap-no-response-option-12.txt
>>
>>
>>
>>
>>
>>
>><!--
>>/* 
>Font Definitions */
>>@font-face
>> {font-family:"Cambria 
>Math";
>>/* Style 
>Definitions */
>> {size:8.5in 
>11.0in;
>>Hi 
>Abhijan,
>>> 2. Option 
>Definition
>>      significance if piggybacked responses 
>are 
>>triggered. But, in case
>>      the 
>server responds with a separate response 
>>(which, may be, 
>the
>>      client does not care about) then this 
>option 
>>can be useful.
>>      Suppressing 
>the separate response reduces 
>>one additional 
>traffic
>>      in this case.
>> 
>>The 
>No-reponse option is about request and response layer semantics. 
>>When 
>No-response option works, why the piggybacked responses are
>>triggered 
>
>>No-Response 
>option works, it would stop the response whether it is
>>the 
>
>>uncleatr why it is 
>different between the piggybacked and the
>>separate.
>> 
>>When 
>the 
>>the draft 
>suppose just to suppress the separate response?ÿÿÿ 
>
>>
>> 
>>And when 
>>following process of the 
>sender side is the same as definitions for
>>suppressing 
>>separate 
>response.ÿ 
>> 
>>The CON/ACK 
>>is about the message layer 
>semantics. 
>>It seems 
>>Beijing University of 
>>Posts and 
>Telecommunications
>>To: Abhijan Bhattacharyya 
>; [email-masked] ; [email-masked] ;
>>[email-masked] 
>>Subject: 
>Re: [core] New Version Notification for 
>
>>draft-tcs-coap-no-response-option-12.txt
>> 
>
>>
>>
>>>Akbar, The reverse 
>>proxy consideration have 
>>Thanks, 
>>Abhijan.ÿ Looks good.
>>other question, why does the draft say &#8220;Expired&#8221; at the topÿ 
>even
>>though 
>[mailto:[email-masked]] 
>>Sent: Thursday, 
>>October 
>15, 2015 9:23 AM
>>Based on the 
>recent 
>>things a bit 
>complicated. 
>>Associate 
>Consultant
>>Tata 
>Consultancy Services
>>Website: 
>>http://www.tcs.com
>>certainty.ÿÿÿÿÿÿÿ IT 
>>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 
>>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 
>>"Abhijan 
>>A new 
>version of 
>>has been 
>successfully 
>>There can be M2M scenarios where responses from server 
>
>>against
>already provides a non-confirmable 
>>(NON) mode of message 
>exchange
>>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
>>ÿ few 
>exemplary 
>>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
>>confidential or 
>>privileged information. If you 
>are 
>>and/or 
>attachments to it 
>>are strictly prohibited. If 
>>you have received 
>>and any attachments. Thank 
>
>>you
>>
>>
>>core 
>mailing

---

From: "weigengyu" <[email-masked]>
Date: Mon, 9 Nov 2015 21:19:07 +0800

Hi Abhijan， 

Thank you for your explanations.
I wish that the draft contexts are clear. 

Regards, 

Gengyu WEI

From: Abhijan Bhattacharyya 
Sent: Thursday, November 05, 2015 11:51 PM
To: weigengyu 
Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt

Hi Gengyu, 

Regards
Abhijan Bhattacharyya
Associate Consultant

>Posts and Telecommunications
>
>
> 
>
>suppose just to suppress the separate response?    
>
>>
>> 
>>And when 
>>Abhijan.  Looks good.
>>From:        
>>Name:                                  
>>Title:                                  
>>  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 
>>  where the server end-point 
>>does not respond with 
>ACK. However,
>>  obeying the 
>>  attempt 
>>  granular control to enable suppression 
>>of a 
>particular class or a
>>  combination of response-classes. 
>
>>  both unicast and 
>multicast 
>>  few