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

Carsten Bormann <cabo@tzi.org> Sun, 09 April 2017 07:25 UTC

Return-Path: <cabo@tzi.org>
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 CD89A129456; Sun, 9 Apr 2017 00:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 Or48n5sLs9Ea; Sun, 9 Apr 2017 00:25:26 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D3B129329; Sun, 9 Apr 2017 00:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v397PMHT000531; Sun, 9 Apr 2017 09:25:22 +0200 (CEST)
Received: from client-0060.vpn.uni-bremen.de (client-0060.vpn.uni-bremen.de [134.102.107.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w14bQ1yhBzDHdT; Sun, 9 Apr 2017 09:25:22 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com>
Date: Sun, 09 Apr 2017 09:25:21 +0200
Cc: tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org
X-Mao-Original-Outgoing-Id: 513415521.674309-e6e2b439554923e512814b6ee2040d7e
Content-Transfer-Encoding: quoted-printable
Message-Id: <F715AB89-D9FA-414E-83F5-E29F0BBB0904@tzi.org>
References: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/G5xyB42vs73aRCg4gf-hi93sXFY>
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 07:25:28 -0000

Hi Yoshi,

thank you very much for your thoughtful review.

For now, let me pick one of your comments:

> 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.

The spec does indeed define a new SZX value, for use with the environments this document is used in (reliable transports).  It does not change or add anything to the way RFC 7959 is used with the existing unreliable transports; as such it does not really update RFC 7959 as much as it does extend it for its own purposes.
(However, the same argument could be made for RFC 7641, which we do say we update.)

Maybe we are not making the point forcefully enough that SZX=7 is meant for use within this spec?
(Again, however: any other future COAP transports that have larger messages might pick up SZX=7 as well.)

I don’t have a strong opinion on how to populate the “updates” graph of RFCs in these boundary cases; it might help to get some more guidance here.

Grüße, Carsten