Re: [core] [Last-Call] Genart last call review of draft-ietf-core-new-block-10 Wed, 28 April 2021 04:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C0463A183C; Tue, 27 Apr 2021 21:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FTA4z0173vmb; Tue, 27 Apr 2021 21:51:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D6603A183D; Tue, 27 Apr 2021 21:51:58 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 4FVR7H21Tzz5xRf; Wed, 28 Apr 2021 06:51:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1619585515; bh=NsT47S1ULPk9EdZxvCHaMOlvHvzV/DvuCbYZAEZ+7Vs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=s2lmU2BR9NSQHKpe9rrgr1bFnFpONLhjH9DiMpigDt1TqFC1vDFHh5u+awxiKHenQ HhJnRy6usN8x64S7QAUyQO+3f+zakDN6jk9Je2GtxrPbRQbW0Ec92fCwJyqwbnbJJm 6HC8pFi3/sOWnLBthRCAwK15aph6vxChuTZy34PzoPveZcRjd9sMNHz8k/mvHYvuxI NhXtvMgOqooz1qYJ9oMFUJ/nEvx68SGVu6ACLd5nMSWra7XYft09mWNOBF74/Il9K+ +zWgbODlNZwRjZBdR1FxK6n8DLjlIH7iQnrQu/GuuS+Mv5waZE4bDg7iHT1z71sc30 APiGl5s+U6tMg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by (ESMTP service) with ESMTP id 4FVR7H0kqgz8sYR; Wed, 28 Apr 2021 06:51:55 +0200 (CEST)
From: <>
To: Pete Resnick <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Last-Call] Genart last call review of draft-ietf-core-new-block-10
Thread-Index: AQHXO7reFX8E11iSokazYZcxuyxZOqrJXKsw
Date: Wed, 28 Apr 2021 04:51:54 +0000
Message-ID: <23836_1619585515_6088E9EB_23836_261_1_787AE7BB302AE849A7480A190F8B933035373AF7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <> <12236_1619433088_60869680_12236_240_2_787AE7BB302AE849A7480A190F8B933035371913@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035373AF7OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [core] [Last-Call] Genart last call review of draft-ietf-core-new-block-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Apr 2021 04:52:04 -0000

Hi Pete,

OK with the proposed editorial change. Fixed in the local copy.

Thank you.


De : last-call [] De la part de Pete Resnick
Envoyé : mercredi 28 avril 2021 01:11
Cc :;;;
Objet : Re: [Last-Call] Genart last call review of draft-ietf-core-new-block-10

Thanks for the followup. Just to close the loop on some of these:

On 26 Apr 2021, at 5:31,<> wrote:

In section 4.4:

I find this paragraph confusing:

The requested missing block numbers MUST have an increasing block
number in each additional Q-Block2 Option with no duplicates. The
server SHOULD respond with a 4.00 (Bad Request) to requests not
adhering to this behavior.

So, given the SHOULD in the second sentence, it appears that the MUST
in the first sentence doesn't apply to the server (i.e., to enforce
this), but rather to the client doing the request. You should
probably say it that way.

[Med] Yes. This text should be linked to the previous paragraph when the client issues the request for missing blocks. Anyway, I agree it is better to be explicit here. Fixed.

Excellent. Here's a purely editorial suggestion; entirely up to you whether to use it:

The missing block numbers requested by the client MUST have an

increasing block number in each additional Q-Block2 Option with no


Also, the SHOULD in the second sentence is
not entirely clear to me: Are you saying that the server can choose
to use some other response code, or are you saying that the server
can accept the request and do something interesting with it?

[Med] The latter. Normally the server must discard such request but given that one of the target use cases for this spec is DDoS mitigation, servers may be tolerant.

Ah, OK, then what you have is correct as-is.

In section 4.3:

In several response code definitions:

The token used MUST be any token that was received in a request
the same Request-Tag.

That doesn't really parse well. I think you either mean "The token
used MUST be a token" or you mean "The token used can be any token".

[Med] The second para of this section specifies that all block requests must use the same Request-Tag. The 4th para indicates that each of these block requests will use a new token. The server must use one of these tokens when replying.

Updated the text as follows:

The token used MUST be one of the tokens that were received in a request for this block-wise exchange.

I like it.

In section 7.2:

For the server receiving NON Q-Block1 requests, it SHOULD send
back a
2.31 (Continue) Response Code on receipt of all of the
payloads to prevent the client unnecessarily delaying.

When you say "Otherwise", Do you mean, "For other payloads"? Either
way, you should probably change that to make it clear.

[Med] Changed to: "If not all of the MAX_PAYLOADS payloads were received, ..."


All of the others look fine. Thanks again for the quick reply.



Pete Resnick
All connections to the world are tenuous at best


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.