Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.txt Fri, 15 January 2021 11:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5D4F3A0B18 for <>; Fri, 15 Jan 2021 03:24:31 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nGQ73dnoHF4d for <>; Fri, 15 Jan 2021 03:24:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC4EE3A0B12 for <>; Fri, 15 Jan 2021 03:24:28 -0800 (PST)
Received: from ([] helo=N01332) by with esmtp (Exim 4.92.3) (envelope-from <>) id 1l0NDN-0001xi-3g; Fri, 15 Jan 2021 11:24:25 +0000
From: <>
To: "Marco Tiloca" <>, <>, <>
Cc: <>, <>
References: <> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Date: Fri, 15 Jan 2021 11:24:44 -0000
Message-ID: <00d701d6eb31$05fe11f0$11fa35d0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQINhJL1nc88GwsEKn+AjV1kVr7Y4AGmsrCNATjbviqppE6oUA==
Content-Language: en-gb
Archived-At: <>
Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.txt
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: Fri, 15 Jan 2021 11:24:32 -0000

Hi Marco,

Thanks from this.

So moving forward, requests for missing Q-Block2 blocks will follow Section 2.7 RFC7959 being modelled on (assuming the request was using Q-Block1)
" To continue this Block2 transfer, the client
   continues to send requests similar to the requests in the Block1
   phase, but leaves out the Block1 Options and includes a Block2
   request option with non-zero NUM."

Otherwise, please see inline which has a couple of questions.


> -----Original Message-----
> From: Marco Tiloca [mailto:]
> Sent: 14 January 2021 19:58
> To:;
> Cc:;
> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
> Hi Med,
> Thanks for the new document version.
> Please, see below some comments on the latest additions, also related to what
> Jon raised at [1].
> Best,
> /Marco
> [1]
> * Section 3.5 - This seems to mix aspects specific to Observe, with more general
> aspects applicable to requests with a payload, i.e. FETCH (with or without
> Observe), PUT, POST and PATCH/iPATCH.

[Jon] Now that we understand what needs to be done with requesting missing Q-Block2 blocks, working with Observe can be simplified.

[Jon] Requesting Observe is only valid for GET and FETCH.  Hence Observe request/cancellation setting when using Q-Block1 is only appropriate for FETCH.

[Jon]  Unfortunately, RFC8132 does not specify in which of the payloads of as Block1 based FETCH request  should contain the Observe option assuming observe is required (The first, the last or all of the payloads). So, here, I believe the safest way to go is with all the payloads carry the observe option if observe is being requested or cancelled.  Thus any missing payloads should be resent with the observe configured to be consistent with all the other payloads. Are you happy with this?

>   What is specific of Observe is the first paragraph; and the usage of the Observe
> option in the second and third paragraph. Anything else seems generic and
> applicable to requests with payload, so it might be moved up to some earlier
> section.
[Jon] Sure - will be updated in the simplification tidy up.
> * Section 3.5 - In the third paragraph, I'm not sure you necessarily need a
> payload to be present in the requests asking for missing response payloads. For
> instance, consider:

[Jon] Agreed.  Now going with Section 2.7 RFC7959 where both Block1 and payload are not included.
>   - The examples in Figure 10 and Figure 11 of RFC 7959, with the note "(no
> payload for requests with Block2 with NUM != 0)" , during the phase where the
> client consecutively asks for the next response payload.
>   - The examples in Figure 2 and Figure 3 of [2], where each request for the next
> response payload using Block2 has no payload of its own.
> This would of course affect the example in Figure 15.

[Jon] Yes, will be updated.
> [2]
> * Section 3.5 - About the last sentence regarding the Observe option, there
> seems to be an exception to this rule (at least based on the later examples),
> where the server actually does include the Observe option in the response.

[Jon] If the Observe option is just included with the first payload (NUM = 0) as RFC7959, there is a recovery special case should the first payload not arrive, but subsequent ones do.  In the general case, blocks that are missing are re-requested by the client and the server responds with the appropriate block, but without the Observe option. For the special case when the client requests missing payload with NUM = 0 the server needs to know that it must include the Observe in the response so that the client following the body re-assembly knows that it is a Observe triggered additional response.

[Jon] I had gone with the Observe should be in all the payloads in the response apart from specifically re-requested blocks (including NUM = 0).  The 'Continue' Q-Block2 was just to indicate a continue so the server can send the remaining payloads without delay - hence why remaining payloads had Observe set.  

[Jon] I am beginning to lean to having it in the first payload and special case the response to re-request of NUM = 0.  What do you think?

>    That is, consider the example in Figure 10, where the response with M:0xba is
> lost. Later on, the client asks for that response payload by sending the request
> with M:0x87, which correctly does not include the Observe option.
[Jon] Yes
>    However, the following response with M:oxc3 and (from the point of view of
> the server) retransmitting that response payload with block number 10 does
> include the Observe option.
>    The exception seems due to the fact that the retransmission request from the
> client is specifically what you call 'Continue' Q-Block-2 in Section 3.4. The
> Observe option is in fact not included for the previously retransmitted response
> payloads with M:0xbb ... M:0xc2, as still part of the current payload set.

[Jon] Correct, but obviously not obvious from the text.
> * Section 3.6 - Part of the first sentence in the second paragraph seems to
> repeat what already said in the third paragraph of Section 3.5.
[Jon] Will clean up in the simplification.