TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sun, 09 April 2017 03:53 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E798B128DE7; Sat, 8 Apr 2017 20:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xcxBljahfKUU; Sat, 8 Apr 2017 20:53:16 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E112B126E3A; Sat, 8 Apr 2017 20:53:15 -0700 (PDT)
Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com []) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2A03A29C9DC; Sun, 9 Apr 2017 12:53:13 +0900 (JST)
Received: by mail-oi0-f43.google.com with SMTP id l63so12047633oig.2; Sat, 08 Apr 2017 20:53:13 -0700 (PDT)
X-Gm-Message-State: AFeK/H2OnXmfqg2iRi8GkVofIn8CGqBPchEFjaGPCVLn+FBG2EFFtIbxtdm04TXPDmgJtSRRehr7j+cKhXazPw==
X-Received: by with SMTP id v6mr11468290oib.214.1491709991791; Sat, 08 Apr 2017 20:53:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 8 Apr 2017 20:53:11 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sat, 8 Apr 2017 20:53:11 -0700
X-Gmail-Original-Message-ID: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com>
Message-ID: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com>
Subject: TSV-ART review of draft-ietf-core-coap-tcp-tls-07
To: tsv-art@ietf.org
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary=001a113d4fee2b36e8054cb3ccb5
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Q95NELltcBUBCoCRE50KHtv2yHQ>
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: Sun, 09 Apr 2017 03:53:18 -0000

Document: draft-ietf-core-coap-tcp-tls-07
Reviewer: Yoshifumi Nishida

I've reviewed this document as part of TSV-ART's ongoing effort to review
key IETF documents. These comments were written primarily for the transport
area directors, but are copied to the document's authors for their
information and to allow them to address any issues raised.When done at the
time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Summary: This document is well-written. It is almost ready to be published
as a PS draft once the following points are addressed.

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?

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?

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.