Re: [core] Chairs' review of draft-ietf-core-stateless-03.txt

Klaus Hartke <hartke@projectcool.de> Wed, 20 November 2019 12:23 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5001207FE for <core@ietfa.amsl.com>; Wed, 20 Nov 2019 04:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 OTcVxicUwB97 for <core@ietfa.amsl.com>; Wed, 20 Nov 2019 04:23:45 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD64120052 for <core@ietf.org>; Wed, 20 Nov 2019 04:23:45 -0800 (PST)
Received: from mail-qv1-f41.google.com ([209.85.219.41]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iXP1K-0000rh-Bc; Wed, 20 Nov 2019 13:23:42 +0100
Received: by mail-qv1-f41.google.com with SMTP id v16so9601862qvq.6 for <core@ietf.org>; Wed, 20 Nov 2019 04:23:42 -0800 (PST)
X-Gm-Message-State: APjAAAWKblm+AVsUjrugtQq4yBI4aNOMQowkk4akN2CV0xKqvS1Svp2y a3vyJvgFWj4qMTuTq9SYlLud/8Oa2Y0MrZnmRw0=
X-Google-Smtp-Source: APXvYqwHaBbszhMQJQMvrWc9PERQ7OCTbXRv3qIbUF87GM77/5dQrZXP2GNDjET3RgUl3Q+t3xbR8YAVT8uB0qXoFJE=
X-Received: by 2002:a0c:85e4:: with SMTP id o91mr2268665qva.16.1574252621149; Wed, 20 Nov 2019 04:23:41 -0800 (PST)
MIME-Version: 1.0
References: <157237477119.11043.4363082013315464920@ietfa.amsl.com> <F964F5EF-96F7-49EC-BECB-0604B16F31FF@tzi.org>
In-Reply-To: <F964F5EF-96F7-49EC-BECB-0604B16F31FF@tzi.org>
From: Klaus Hartke <hartke@projectcool.de>
Date: Wed, 20 Nov 2019 13:23:04 +0100
X-Gmail-Original-Message-ID: <CAAzbHvYX7tjVp6XPCdTX1PzEL_9CYoJfZ1Y9guPhRcVt_Shgpw@mail.gmail.com>
Message-ID: <CAAzbHvYX7tjVp6XPCdTX1PzEL_9CYoJfZ1Y9guPhRcVt_Shgpw@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Core WG mailing list <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1574252625; d44ed02f;
X-HE-SMSGID: 1iXP1K-0000rh-Bc
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/P4LGZlEbkqHWwpy08FrDQAPk6YQ>
Subject: Re: [core] Chairs' review of draft-ietf-core-stateless-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 20 Nov 2019 12:23:48 -0000

Carsten Bormann wrote:
>            The option value MUST NOT be less than 8 or greater than 65804.  If
>            an option value outside this range is received, the value MUST be
>            clamped to this range.
>
> I am still not a fan of re-interpreting disallowed values.
> (Assuming there was later any reason to go beyond 65804, of course allowing
> larger values and interpreting these as 65804 because a client knowing
> just this specification cannot make use of lengths >65804 makes sense.
> Not so sure about the values 0..7 though.)

Well, the option is elective. So, for example, if a server says "I
support tokens only up to 3 bytes" and the client doesn't understand
the option, the client would still send requests with 4-8 byte tokens.
Requiring a client that does understand the option to send an error
for values 0..7 wouldn't change that.

Of course, we could use values 0..7 to signal special cases to clients
that understand the options (though I don't know why we wouldn't use
dedicated options for that). This document won't define any special
cases, so this is about a future possibility. The question then is,
how we would introduce these special cases in the future and what we
want clients to do with those values until then. IMO letting clients
that understand the option but not values 0..7 handle the option
exactly like clients that don't understand the option at all is the
best answer.

>            have been forwarded by an intermediary.  To ensure that this does not
>            lead to inconsistent resource state, a stateless intermediary MUST
>            include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in
>            block-wise transfers with a value that uniquely identifies the client
>            in the intermediary's namespace.
>
> -> To ensure that this does not lead to inconsistent resource state, a
> stateless intermediary that wants to forward requests with Block1
> options will need to also include a distinguishing option such as the Request-Tag Option
> [I-D.ietf-core-echo-request-tag] in a way that uniquely...

Done.

>            When using AES-CCM, repeated use of the same nonce under the same key
>
> Not just AES-CCM, just about any AEAD.  Maybe say: When using an
> encryption mode that depends on a nonce, such as AES-CCM, ...

Done.

> ## Nits
>
>            A client SHOULD NOT assume that extended token lengths are supported
>            by a server 60 minutes after receiving a response with an extended
>            token length, as network addresses may change.
>
> s/60/later than 60/

Done.

Klaus