Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block

"Christian M. Amsüss" <> Tue, 16 February 2021 23:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2414B3A12F0; Tue, 16 Feb 2021 15:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VSQAYUerv_Ng; Tue, 16 Feb 2021 15:48:58 -0800 (PST)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC5243A12E9; Tue, 16 Feb 2021 15:48:55 -0800 (PST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id 9AEB540887; Wed, 17 Feb 2021 00:48:53 +0100 (CET)
Received: from ( [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id 6472FFD; Wed, 17 Feb 2021 00:48:52 +0100 (CET)
Received: from ( [IPv6:2a02:b18:c13b:8010::aa6]) by (Postfix) with ESMTPSA id 2FD9D44; Wed, 17 Feb 2021 00:48:52 +0100 (CET)
Received: (nullmailer pid 612178 invoked by uid 1000); Tue, 16 Feb 2021 23:48:51 -0000
Date: Wed, 17 Feb 2021 00:48:51 +0100
From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gBSk+H9RigFJnM2C"
Content-Disposition: inline
In-Reply-To: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <04a201d6d9d8$c7919ae0$56b4d0a0$>
Archived-At: <>
Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Feb 2021 23:49:01 -0000


where not explicitly responded to, the updates address my points, thank
you for updating the document.

> >   * The Q-Block options do not support stateless operation / random
> >     access.
> [Jon] Actually Q-Block2 does now support this following the redefinition of
> the M bit usage in a previous iteration (with M=0 you can ask for any
> individual block).

Random access can also be in the Block1 phase; a standalone `PUT
/resource Block1:5/0/6` can be used independenlty of other operations to
overwrite a particular part of a resource.

> [Jon] For stateless, Request-Tag is included so this should be fine.

By stateless, I was referring to the server not keeping state per body.
That is the opposite of using a Request-Tag.

> >   * Proxying of Q-Block is limited to caching full representations.
> > 
> >   (The latter might be mitigated by additional text around caching, but
> >   I doubt it's worth the effort given it's not part of the use case).
> [Jon] I am not entirely convinced that Block1/2 have got the caching by
> block properly sorted out - e.g. what happens when different clients make
> requests with different SZX and Block2 is part of the cache key.  The
> limiting to caching full representations is there so that a new can of worms
> is not opened up.

The Block options are not part of the cache key -- they are
not-safe-to-forward and thus come with rules as to the cache behavior,
rather than havign a cache-key property.

The behavior is sorted out: If an earlier client requested, say,
block2:0//6 (first 1KiB), then while that is fresh, it may be used to
serve any request for smaller chunks (say, block2:1//5 for bytes

The same is true in the other direction: A proxy may use its cached
3x256 bytes (even exceeding the Max-Age), ask the server for the 4th 256
byte block (which by its ETag confirms the others are still good), and
then serve them combined as a 1KiB response.

Thus, I think these two points (Incomplete support for random access,
and block-by-block proxying) still stand to be added to the

To give you background on why I'm so picky about this list: People
*will* still get the initial impression that this is the
later-and-greater version, and for the outlined purposes it is, but if
we don't set the expectations right here, there will be disappointment.


To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom