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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sun, 09 April 2017 21:24 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C501C1293FC; Sun, 9 Apr 2017 14:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJZ-ZfgyzHgm; Sun, 9 Apr 2017 14:24:15 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD04127A97; Sun, 9 Apr 2017 14:24:14 -0700 (PDT)
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 05AB129CC3C; Mon, 10 Apr 2017 06:24:12 +0900 (JST)
Received: by mail-oi0-f47.google.com with SMTP id g204so56639005oib.1; Sun, 09 Apr 2017 14:24:11 -0700 (PDT)
X-Gm-Message-State: AFeK/H2dD9jOkdWNRDjqiQIGTRG25G6qIOjQXAtG7c5+hoiOhdx4xfQlhLGz863SX3wjjH/k+OcdUQPSzgAjZw==
X-Received: by 10.157.45.163 with SMTP id g32mr29278825otb.274.1491773050374; Sun, 09 Apr 2017 14:24:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.132 with HTTP; Sun, 9 Apr 2017 14:24:09 -0700 (PDT)
In-Reply-To: <F715AB89-D9FA-414E-83F5-E29F0BBB0904@tzi.org>
References: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com> <F715AB89-D9FA-414E-83F5-E29F0BBB0904@tzi.org>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sun, 09 Apr 2017 14:24:09 -0700
X-Gmail-Original-Message-ID: <CAO249yfRU+bPXf7yCOsg7yccijS=PwM22_2kZpG8qXBL4dBPCA@mail.gmail.com>
Message-ID: <CAO249yfRU+bPXf7yCOsg7yccijS=PwM22_2kZpG8qXBL4dBPCA@mail.gmail.com>
Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07
To: Carsten Bormann <cabo@tzi.org>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c04fb4ac0d40c054cc27a04"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1nDCNt1iAMCT_rbTKRu6FjOu8bo>
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 21:24:17 -0000

Hi Carsten,

On Sun, Apr 9, 2017 at 12:25 AM, Carsten Bormann <cabo@tzi.org> wrote:

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

Ok, I see the point. I don't have a strong opinion here either as I am not
a COAP expert.
It could be enough if the draft has more texts to articulate that it won't
cause conflict with unreliable transport COAP.
--
Yoshi