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

["weigengyu" <[e-mail]>]

Hi Abhijan， 

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

Regards, 

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

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

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
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [e-mail]
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________



-----"weigengyu" <[e-mail]> wrote: -----

>To: "Abhijan Bhattacharyya" <[e-mail]>
>From: "weigengyu" <[e-mail]>
>Date: 11/05/2015 05:05PM
>Cc: <[e-mail]>, <[e-mail]>,
><[e-mail]>, <[e-mail]>
>Subject: Re: [core] New Version Notification for
>draft-tcs-coap-no-response-option-12.txt
>
>
>
>
>
>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
>Network Technology Center
>School of Computer 
>Beijing University of 
>Posts and Telecommunications
>
>
> 
>
>From: Abhijan Bhattacharyya 
>Sent: Monday, November 02, 2015 6:28 PM
>To: weigengyu 
>Cc: [e-mail] ; 
>[e-mail] ; [e-mail] ; [e-mail] 
>Subject: Re: [core] New Version Notification for 
>draft-tcs-coap-no-response-option-12.txt
> 
>
>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
>Scientist, Innovation Lab, Kolkata, India
>Tata 
>Consultancy Services
>Mailto: 
>[e-mail]
>Website: http://www.tcs.com
>____________________________________________
>Experience certainty. IT Services
>Business 
>Solutions
>Consulting
>____________________________________________
>
>
>-----"weigengyu" <[e-mail]> wrote: 
>-----
>
>>To: "Rahman, Akbar" 
><[e-mail]>, "Abhijan
>>Bhattacharyya" 
><[e-mail]>,
>><[e-mail]>, 
><[e-mail]>, <[e-mail]>
>>From: "weigengyu" 
><[e-mail]>
>>Date: 11/02/2015 09:08AM
>>Subject: 
>Re: [core] New Version Notification 
>for
>>draft-tcs-coap-no-response-option-12.txt
>>
>>
>>
>>
>>
>>
>><!--
>>/* 
>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
>>> 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 
>; [e-mail] ; [e-mail] ;
>>[e-mail] 
>>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:[e-mail]] 
>>Sent: Thursday, 
>>October 
>15, 2015 9:23 AM
>>To: [e-mail]; [e-mail]; 
>
>>[e-mail]; Rahman, Akbar 
>
>><[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]
>>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:        
>
>>[e-mail] 
>
>>
>>To:        
>>"Soma 
>
>>Bandyopadhyay" <[e-mail]>, 
>>"Soma 
>Bandyopadhyay" <[e-mail]>, 
>>"Abhijan 
>Bhattacharyya" <[e-mail]>, 
>>"Arpan Pal" 
><[e-mail]>, 
>>"Arpan Pal" <[e-mail]>, 
>
>>"Tulika Bose" <[e-mail]>, "Abhijan 
>
>>Bhattacharyya" <[e-mail]>, 
>>"Tulika 
>Bose" <[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-opti
>o
>>n-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-
>1
>>2
>>
>>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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/core
>>
>>
>