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

"weigengyu" <weigengyu@bupt.edu.cn> Mon, 02 November 2015 03:38 UTC

Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9700F1ACEEA for <core@ietfa.amsl.com>; Sun, 1 Nov 2015 19:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcxqKS3SZZYx for <core@ietfa.amsl.com>; Sun, 1 Nov 2015 19:38:40 -0800 (PST)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id E87901ACEE4 for <core@ietf.org>; Sun, 1 Nov 2015 19:38:39 -0800 (PST)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id BBE1E19FCC0 for <core@ietf.org>; Mon, 2 Nov 2015 11:38:38 +0800 (HKT)
Received: from WeiGengyuPC (unknown [10.103.240.137]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 7739919FCB3; Mon, 2 Nov 2015 11:38:37 +0800 (HKT)
Message-ID: <8FE79AD6A80C4B8A83BAF485D6B3A489@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>, esko.dijk@philips.com, cabo@tzi.org, core@ietf.org
References: <OF55B799DA.86E1939E-ON65257EDF.0048D455-65257EDF.004979E1@tcs.com> <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com>
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com>
Date: Mon, 02 Nov 2015 11:38:37 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01D11563.0360B4B0"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/UCA9MlLhKCiMiU9pVcQkRyv9jlM>
Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 03:38:44 -0000

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 ; esko.dijk@philips.com ; cabo@tzi.org ; core@ietf.org 
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:abhijan.bhattacharyya@tcs.com] 
Sent: Thursday, October 15, 2015 9:23 AM
To: esko.dijk@philips.com; cabo@tzi.org; core@ietf.org; Rahman, Akbar <Akbar.Rahman@InterDigital.com>
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: abhijan.bhattacharyya@tcs.com
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:        internet-drafts@ietf.org 
To:        "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com> 
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
core@ietf.org
https://www.ietf.org/mailman/listinfo/core