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
- [core] I-D Action: draft-ietf-core-stateless-03.t… internet-drafts
- [core] draft-ietf-core-stateless-03.txt: very con… Carsten Bormann
- Re: [core] I-D Action: draft-ietf-core-stateless-… Thomas Fossati
- [core] Chairs' review of draft-ietf-core-stateles… Carsten Bormann
- Re: [core] Chairs' review of draft-ietf-core-stat… Thomas Fossati
- Re: [core] Chairs' review of draft-ietf-core-stat… Carsten Bormann
- Re: [core] Chairs' review of draft-ietf-core-stat… Thomas Fossati
- Re: [core] Chairs' review of draft-ietf-core-stat… Carsten Bormann
- Re: [core] Chairs' review of draft-ietf-core-stat… Michael Richardson
- Re: [core] Chairs' review of draft-ietf-core-stat… Carsten Bormann
- Re: [core] Chairs' review of draft-ietf-core-stat… Klaus Hartke