Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

"weigengyu" <weigengyu@bupt.edu.cn> Fri, 21 April 2017 05:08 UTC

Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D3112940F for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 22:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.462
X-Spam-Level:
X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 z8ZncMYqoIOa for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 22:08:47 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 25A291293F5 for <ietf@ietf.org>; Thu, 20 Apr 2017 22:08:47 -0700 (PDT)
Received: from WeiGengyuPC (unknown [114.255.40.36]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 37D7919F36D; Fri, 21 Apr 2017 13:08:43 +0800 (HKT)
Message-ID: <A3E5E7239DC042BD8206DB35CD1A305F@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: Brian Raymor <Brian.Raymor@microsoft.com>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, tsv-art@ietf.org
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org
References: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com> <BY2PR21MB0084E781B2831EBC6A5F4E88831B0@BY2PR21MB0084.namprd21.prod.outlook.com>
In-Reply-To: <BY2PR21MB0084E781B2831EBC6A5F4E88831B0@BY2PR21MB0084.namprd21.prod.outlook.com>
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07
Date: Fri, 21 Apr 2017 13:08:43 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
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: <https://mailarchive.ietf.org/arch/msg/ietf/tF_S7DTcj_fw90-xgDcLXN2wOuY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 05:08:49 -0000

Hi,

> It's possible to add language similar to the abort case, along the lines 
> of "When the underlying TCP connection is closed or reset,
> the CoAP connection is closed and in flight messages may be lost".

It is not necessary when CoAP over WEBSocket is concerned, I think.
By the API or the interface, CoAP only interacts with WEB socket, does not 
need to touch issues of TCP.
CoAP would react to the events of WebSokcet.

But, issues on TCP should be concerned if it is CoAP over TCP.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Brian Raymor
Sent: Friday, April 21, 2017 3:31 AM
To: Yoshifumi Nishida ; tsv-art@ietf.org
Cc: draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf.org ; ietf@ietf.org
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07


Thanks for your feedback.

> 1: It is not clear how the protocol reacts the errors from transport 
> layers (e.g. connection failure).
>    The protocol will just inform apps of the events and the app will 
> decide what to do or the protocol itself will do something?

The WebSockets case is addressed by RFC6455:

   When the underlying TCP connection is closed, it is said that _The
   WebSocket Connection is Closed_ and that the WebSocket connection is
   in the CLOSED state.  If the TCP connection was closed after the
   WebSocket closing handshake was completed, the WebSocket connection
   is said to have been closed _cleanly_.

-and-

   If at any point the underlying transport layer connection is
   unexpectedly lost, the client MUST _Fail the WebSocket Connection_.

It's possible to add language similar to the abort case, along the lines of 
"When the underlying TCP connection is closed or reset, the CoAP connection 
is closed and in flight messages may be lost".

> 2: There will be situations where the app layer is freezing while the
> transport layer is still working. Since transport layers cannot detect
> this type of failures, there should be some mechanisms for it somewhere in 
> the protocol or in the app layer.  The doc needs to address
> this point. For example, what will happen when a PONG message is not 
> returned for a certain amount of time?

PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither 
provides any guidance for this case. It's expected that an application 
framework would define and enforce the appropriate policy for timeouts or 
retries.

> 3: Since this draft defines new SZX value, I think the doc needs to update 
> RFC7959. This point should be clarified more in the doc.

Carsten responded to this issue and the final exchange is here - 
https://www.ietf.org/mail-archive/web/core/current/msg08562.html

My sense is that we should treat this as an update to RFC7959 based on the 
original language:

     The value 7 for SZX (which would
      indicate a block size of 2048) is reserved, i.e., MUST NOT be sent
      and MUST lead to a 4.00 Bad Request response code upon reception
      in a request.

and the use of "extension" in coap-tcp-tls:

    The ’Block-wise Extension for Reliable Transport (BERT)’ extends the 
Block protocol
    to enable the use of larger messages over a reliable transport.

The existing IANA entries for Block1 and Block2 will also need to reference 
coap-tcp-tls in addition to RFC7959.

Tracking in https://github.com/core-wg/coap-tcp-tls/issues/129


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core