Re: [core] Shepherd review of draft-ietf-core-new-block-08

Marco Tiloca <marco.tiloca@ri.se> Wed, 17 March 2021 17:37 UTC

Return-Path: <marco.tiloca@ri.se>
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 523163A0CE7; Wed, 17 Mar 2021 10:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se
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 IyFqK6Jw0I7E; Wed, 17 Mar 2021 10:37:41 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2065.outbound.protection.outlook.com [40.107.21.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DED83A0CE5; Wed, 17 Mar 2021 10:37:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VvRfzvwGWIDprPnupkINOTXtPgPLsWPFPwYDvkEJhiZUrhGFXjiliA8BnIR7CFkIwpTXvuPtuzzI0Dm4fGI1s45wvVcia3w7SpRUEqkII8Gs9ERwOQb1UqWkLW1V/Z0elqCUm6YT3W47mHnAy++GnFdscEnxJNvjDrRXsM1f0lDNiALkS9LUlNf6lx3ObJ6DTdP2r6GHibnizvvQyJ5UurG7cZKp2o+cMIujtNs34UVdJrYIzhstBeK5qH+UL60vm/NGQGhTRv49PmKYmYZljU46Q+UUoq/tsuaaibfN0LKNr/ea3wu5NwVHkH7knCU0X9hGYiEvF8CecrfCw+WGUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yuXKz9S5qNuT13cRmWwiAjC//+pH9k3p7QiZAw32oz4=; b=byNX1WELumZsmA9nPsVt8bb3RM3nE7PxJtlaXWWI7cBpu1nUsjNkSGkwFOChDa4rghyVdg14HmWEnCtLHJk8Nlbs7blL7Nde6l4QmpZaAiAshSXk7FAY1VcET2MHb9p9oy+vUmSdQWiXfa2i9FPDVH+1pBQkZCpDCcxhF9XH8NEQP97U+YvBP81/Z34AD446wTUeHqiYQqlrqetuSmDjZNLHfp3lw4ofit4pEvnqUr7ub5fcf0FA1ql3g9elxOB7HCnUS5FS7lZvdKHpzA1RGzcPa5/tikyZDtDVILhmMvU75Hd05eXH5qTElGfK8uZk3bO97f8jI9IouY1WopyG4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yuXKz9S5qNuT13cRmWwiAjC//+pH9k3p7QiZAw32oz4=; b=i8HBGx0CHiSdEZHaDRF0o24inJmgdj+ipK0DXCZeqdXhtt4nML2iB/P/f7ft2fKcEVq621j3DJZW62m3Lg5pvN8RWEOoz3YWu3UMvL/66hJM05MxUEUVDTpPElKDpeAkrX9jnqrh/wKLrmDW0U076r5O/L/ecgV8/AkAqBYE3KY=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se;
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1771.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 17:37:34 +0000
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1df7:be0c:4934:88bf%9]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 17:37:34 +0000
To: mohamed.boucadair@orange.com, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>
Cc: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
References: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se> <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Marco Tiloca <marco.tiloca@ri.se>
Message-ID: <b1cd411d-c809-ed28-5fc8-b754ecb95c72@ri.se>
Date: Wed, 17 Mar 2021 18:37:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
In-Reply-To: <8652_1615962375_6051A107_8652_92_1_787AE7BB302AE849A7480A190F8B933035356DDD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T3hqoxfRgXGNsudS9ugtcB5C4zksK49WE"
X-Originating-IP: [45.83.91.228]
X-ClientProxiedBy: HE1PR0802CA0003.eurprd08.prod.outlook.com (2603:10a6:3:bd::13) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.8.2.10] (45.83.91.228) by HE1PR0802CA0003.eurprd08.prod.outlook.com (2603:10a6:3:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Wed, 17 Mar 2021 17:37:33 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 097f1839-1f44-47f8-c1f5-08d8e96b595c
X-MS-TrafficTypeDiagnostic: DB9P189MB1771:
X-Microsoft-Antispam-PRVS: <DB9P189MB1771D6D2341AFE97162288F8996A9@DB9P189MB1771.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:7691;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 7/XJfdSw+710gXq6yoBRJX4A0HF7UAaHZrMtny0tbFvDBFqPyyWsYrtVRsoJ5ae+Rl48USs9sAROG3yWPAak5pSzJT0pJ1LV+XMQ7DFDkSwFmciqBSFJYURuMztQkZhXBIVGhglB9yJIWxhNo0hEJX7GZaJmvL9636YqPoRLbKH3FJKt3jaumO5A0+yCJuRR+EDRk3u7oGUaisdsLzylDcHlLzYOPvNI28bbtI9nIdzs8or3GOUaP7bAoNsgxML7B5hay8qeGCB/eVefws67mIzCrHzEjWZSlfaSNv0MmZpi2EqexWWrzLFaG8mHz3XNT67MbvWP0OSlb4F4nO87aN8hmaS/qfqCM9MrC1kV3zw0tdnQIl7UxbKwBuirjLOb6setD+nEGU4icW/Z1nPBmpaKeMxWPA+M3fP+QV5C/StoDBABJAnqGRMNoF9DNHrvCyX6f4Eeqd1lR0tRsIARUEc3XU9PeYRi5tPdfd8o2GikhQlHyzjVlSbQn3Z4QKA6Z3btvUp5+/YJAqq6HwVjgZjglavMUYcqX83ve180aexbYr4nygVv7Uj+mxmGboeeAhPvG9HnmNBrjsxi0vsXX5N3lA0dyI3VLlCrwee0r/qwG92zBW/iy19g0Wx0xgrlCGtePjEgiOQvo6oMrK1BfiStEWqPd95iNIZlBrV3VmAWL3pKEfRtbHqrssBkJgxX7kY3TsMYNflaFrHi/xBnOWQPpmMxVFOA7nYhZOrxWlc=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(366004)(346002)(39850400004)(235185007)(966005)(2906002)(956004)(66574015)(6916009)(2616005)(86362001)(52116002)(19627235002)(53546011)(5660300002)(31696002)(33964004)(44832011)(6486002)(31686004)(83380400001)(66556008)(66616009)(30864003)(66946007)(66476007)(186003)(16526019)(4326008)(21480400003)(36756003)(8936002)(26005)(8676002)(45080400002)(316002)(16576012)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?M094L3ZWV3BVSmxLSzNqRm1SQ2ZhM084eEM5bVpqN0MxdGE1SmVmUHNXaXhC?= =?utf-8?B?WExIYUQ3RVZBV2JlZFFpcXBBZFdhZncxcXFBb2VrdG1aemROZThpQ3UyUld3?= =?utf-8?B?TFFuSnNEMFkxZDlIR2hOUFZoMFYxSllyTUFkaWlsMExuZ3lmU0lhQndERXZH?= =?utf-8?B?U21qZnZNT0p1YlptMEtUcFdRMTNWYTdTL2tyR3hKSlRZU0U2NEI4eG1lS092?= =?utf-8?B?ZytORHEyUWVtLzhKWmtpZnFqc1NraWwwdnFuclBlUjBVMEc5Rk0vS1NRQ1ZT?= =?utf-8?B?NEkwUXdJQVFFR25LN1dkM0IrNWNKSGQ4SHZBTHFmYk9CdjFjZmk5VFFrTFBO?= =?utf-8?B?SjRqNWw0SzhsVjN0aXZCQTl6ZmFvdU4xNmVWUUc5UHBtYWhzcnZlbnBDa2l4?= =?utf-8?B?em1iVGxndWl6eTA5ZVRQRld2QVVDWTNteGpxV1E0a1VaazJoM1dObEdzUVY0?= =?utf-8?B?ZTZLWEg5aEdZTHZCT0ppaEswVTB6VktDaXdqVGhuRnNHOEY2TEt4c3dBQU12?= =?utf-8?B?SEpXaUt5enNuaE1NNzdwQ0FEMnlxanNEaC9GRThYenVBQ3JPVmxPT2xqNDJW?= =?utf-8?B?OXN0a014VTU2djMxZ01NT290YzErYlBVRUVHaURoU1ZqVHJyS3FyTTh6elVQ?= =?utf-8?B?KzcyOVhwWVMzcXNMZW44bCtVVTZ1dnV5aElvLzFEYlNZK1RJMEE5SEc3TVI5?= =?utf-8?B?KytHNWxURVM3ZmpyeTNQNWVzWUpGblpwellpZUtPNlZML05YZGdHSFF4RUdx?= =?utf-8?B?bVZIRC8yM2xvVlJwZHovcjlwTzNrUHVreXBlOVVyS2VSbnhtYS8xTlF3UWZF?= =?utf-8?B?emo1bW9mMDMrSzhiMlFJdmRTbFg1L0MwNnRzbm1pR0RBUSt6djZXQzJVV1dL?= =?utf-8?B?RTQ2QjdEeFljZktVY216MkZwb3kxMTYzNjMzMzdJTStHUzFQdEtIYXJBaHdY?= =?utf-8?B?NXdXR3RkT2RGaDdac3ZjNDBHWTFBQWJuNVYxdTRUbnpnb2FlY1JIVGJHUi9Q?= =?utf-8?B?N1YyK3RBSEgzQ2dORWxyT2VwanFPZHpJY1I0TnhTcC9zaUE3Y0g3L0dkU3Iw?= =?utf-8?B?ajNmazE0OEhISUJ0MnFQTzVmRnZKU1haSGNKcXprdXEvZVpCQTUvYXRDLzJi?= =?utf-8?B?TjNYWHBIY3FpeUhQd1lnejAwQWdTOHFDeUxBNGtJdTZoOTNoZmEza0JSZ01B?= =?utf-8?B?bFJGZ05MNWVKUDJZQVBVV3pKQVBYb29ZVHZCZEkyZ3pVc2xTcTFHekNhdlhD?= =?utf-8?B?S04yaVB2dHBJanRQU3JLdzExOVlYWFRhczNkYXMvOGw0NVExeXBpSDlibHlP?= =?utf-8?B?aEVlK3NVUGNXWVBtSjdycGRrYVVacll4eGdUSWdScTdJZTdTOUxueTdWbnpV?= =?utf-8?B?ckhnZVp1aHZLWWVzbHdGTU1VVHliUFRQalE2eVlWeVc2OG8rbUhUNVM2R3Qy?= =?utf-8?B?K3Vlc1lmRFJhTXlud0FiWnFUZDNnc0hPWTI3QU1WK2k3NDNhTVVaUXMrSTlW?= =?utf-8?B?Y2l3a3VxVmdIN3RtK0YxMlNjN0xsM3ZCWGtsMStJRGZ2Q29JallMcXB2WXZF?= =?utf-8?B?eno1TFBOY2MzRE5UVno0STBERlFUUkJUS3NLSGtpanV5VCtabGdRbHlKb2Ew?= =?utf-8?B?QmcxTXlyOGJhYzE2NGRzYVFIMm00a21hN2F1cm53b1FIbjkxaW4rdkhhRmM3?= =?utf-8?B?V043dGZ0UGk1UGdGa2ZNWFFzVEhPUklMY3NGSTg1TXpqNFFsMGRvZHpXZ29m?= =?utf-8?Q?hnBmE895k4QLQWqYA2838lxhr2De25YdZqBhIwU?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 097f1839-1f44-47f8-c1f5-08d8e96b595c
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2021 17:37:34.7727 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: AEXPgFnHdmuEz2Pp4SF5ABhc/+COcG/Mts2XGsgKE1qnJDUsCVTUSD3JOZrfjWyx1Tlza5zUwqSs/ABSWSyu9w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1771
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/OJKFk3KP6L6fZkSILhKJQCGH_VU>
Subject: Re: [core] Shepherd review of draft-ietf-core-new-block-08
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, 17 Mar 2021 17:37:45 -0000

Hi,

Thanks for the quick update and the revised version!

It looks good to me. I will proceed with the write-up and the 
publication request.

Best,
/Marco

On 2021-03-17 07:26, mohamed.boucadair@orange.com wrote:
> Hi Marco,
>
> Thank you for the review.
>
> An updated version that fixes almost all your points is online. Changes can be tracked at: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-new-block-09&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cc0df8e881566480a281608d8e90d916a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637515591928458819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&amp;sdata=r7DuNZdtQQHk2zdk1D6du7rnzhcUx1be74JOha%2BG4AI%3D&amp;reserved=0p;reserved=0.
>
> We didn't went with the following change proposal:
>
>> * s/It is not recommended that these options are used/It is NOT
>> RECOMMENDED to use these options
> because it is redundant with this text in Section 10:
>
>     It is NOT RECOMMENDED that the NoSec security mode is
>     used if the Q-Block1 and Q-Block2 Options are to be used.
>
> Also, for this one:
>
> "
> Refer to version -13 of draft-ietf-core-echo-request-tag
> "
>
> I don't know why the latest version is not indicated as the entry is automatically populated.
>
> Cheers,
> Jon & Med
>
>> -----Message d'origine-----
>> De : core [mailto:core-bounces@ietf.org] De la part de Marco Tiloca
>> Envoyé : mardi 16 mars 2021 17:43
>> À : draft-ietf-core-new-block@ietf.org
>> Cc : core@ietf.org WG (core@ietf.org) <core@ietf.org>
>> Objet : [core] Shepherd review of draft-ietf-core-new-block-08
>>
>> Hello Med and Jon,
>>
>> Please, find below my comments from the shepherd review.
>>
>> Best,
>> /Marco
>>
>>
>>
>> [General]
>>
>> * In the document header, replace "CORE" with "CoRE Working Group"
>>
>>
>> [Abstract]
>>
>> * s/Block1 and Block2 Options/Block1 and Block2 Options defined in
>> RFC 7959
>>
>>      Don't include an actual link to RFC 7959, only mention it as
>> plaintext
>>
>> * s/interchanges as well/interchanges. Also, they support
>>
>>
>> [Section 1]
>>
>> * In the sentence "These options operate ... has completed.", what's
>> the subject for "can"? Also, "when the request" seems to relate only
>> to the previous "ask". Proposed overall rephrasing:
>>
>>      These options operate synchronously, i.e., each individual block
>> has to be requested. A CoAP endpoint can only ask for (or send) the
>> next block when the transfer of the previous block has completed.
>>
>> * s/Packet, and hence/Packet transmission rate, and hence
>>
>>
>> [Section 1.1]
>>
>> * s/(NON) without requiring/(NON) messages without requiring
>>
>> * s/in place for NON/in place when NON messages are used
>>
>> * s/in a single CoAP packet/in a single CoAP message
>>
>> * Proposed rephrasing for "... the receiving CoAP endpoint informs
>> the CoAP sender endpoint either successful receipt or reports on all
>> blocks in the body that have not yet been received."
>>
>>      ... the receiving CoAP endpoint either informs the CoAP sender
>> endpoint of successful reception, or reports on all blocks in the
>> body that have not yet been received.
>>
>> * s/If the new option is not supported/If the new options are not
>> supported
>>
>> * I think that the paragraph "Q-Block1 and Q-Block2 Options are
>> designed to work in particular with Non-confirmable requests and
>> responses." fits better right before the paragraph "Using NON
>> messages, the faster ..."
>>
>>
>> [Section 1.3]
>>
>> * s/that can't use/that cannot use
>>
>> * s/It is not recommended that these options are used/It is NOT
>> RECOMMENDED to use these options
>>
>>
>> [Section 2]
>>
>> * You would expect the reader to be familiar also with RFC 7959 and
>> RFC
>> 8132.
>>
>>
>> [Section 3.1]
>>
>> * s/properties of Q-Block1/properties of the Q-Block1
>>
>> * s/or similar so that/or similar request so that
>>
>> * s/both a class E and a class U in terms of OSCORE/both of class E
>> and
>> class U for OSCORE
>>
>>
>> [Section 3.3]
>>
>> * s/and the resource was created/and that the resource was created
>>
>> * s/and the resource was deleted/and that the resource was deleted
>>
>> * s/and the resource was updated/and that the resource was updated
>>
>> * s/and the appropriate representation/and that the appropriate
>> representation
>>
>> * When discussing the 2.05 (Content) code, why is the exact Token to
>> use
>> in each notification left unspecified? Shouldn't it be about using
>> the
>> one from the last received payload also in this case?
>>
>> * When discussing the 2.31 (Continue) code, I believe the words "in
>> the
>> response" are a remnant and should be removed. I think it should
>> read:
>>
>>      This Response Code can be used to indicate that all of the blocks
>> up
>> to and including the Q-Block1 Option block NUM (all having the M bit
>> set) have been successfully received.
>>
>> * Also about 2.31 (Continue): "... and MAX_PAYLOADS (Section 6.2)
>> payloads have been received by the server." Since when? Since the
>> acknowledgment of the previous MAX_PAYLOADS set?
>>
>> * On 4.00 (Bad Request), as non native speaker, I got a bit confused
>> by
>> the combination of "does not"+"both"+"and". Perhaps rephrase as:
>>
>>      "... if the request includes neither a Request-Tag Option nor a
>> Size1 Option but ..."
>>
>> * "If the server has not received all the payloads ... before sending
>> a
>> 4.08 (Request Entity Incomplete) response."
>>
>>      This seems better fitting as a last paragraph in the block of
>> text
>> above about the 4.08 code.
>>
>>
>> [Section 3.4]
>>
>> * "A client SHOULD only maintain a partial body (missing payloads)
>> for
>> up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age
>> Option ..."
>>
>>      Doesn't this also apply to the retention of the Tokens used
>> during
>> the body transfer from the server to the client? I couldn't find a
>> given
>> guidance about the client releasing those Tokens, analogous to the
>> one
>> given in Section 3.1, but I guess it would fit here.
>>
>> * s/with a 2.03 (Valid Response)/with a 2.03 (Valid) Response
>>
>> * s/a triggered Observe/a triggered Observe notification
>>
>>
>> [Section 6.2]
>>
>> * On NON_MAX_RETRANSMIT, "After this occurs, the local endpoint
>> SHOULD
>> consider the body stale and remove all references to it."
>>
>>      It's better to remind what such references are, i.e. Tokens and
>> Request-Tags on the client, as well as ETags on the server.
>>
>>
>> [Section 7]
>>
>> * s/Q-Block2s/Q-Block2 responses
>>
>>
>> [Section 9]
>>
>> * You can mention that the examples consider MAX_PAYLOADS = 10 and
>> NON_MAX_RETRANSMIT = 4, just as per the default values in Table 3.
>>
>>
>> [Section 9.1.3]
>>
>> * s/the token that was used in the last block number received
>> payload/the token that was used in the last received payload
>>
>>
>> [Section 9.3.3]
>>
>> * s/where there are some blocks are lost/where some blocks are lost
>>
>> * s/response is be the token/response is the token
>>
>> * s/last block number received payload/last received payload
>>
>> * In Figure 16, the final response with Message ID M:0xa7 should have
>> ET=24.
>>
>>
>> [Section 10]
>>
>> In all the following subsections, please replace "[RFCXXXX]" with
>> "[This
>> _Document]", as you do in Section 10.2.
>>
>>
>> [Section 10.1]
>>
>> * Rename the section as "CoAP Option Numbers Registry".
>>
>> * Expand the first sentence as "... "CoAP Option Numbers" sub-
>> registry
>> [Options] defined in [RFC7252] within the "Constrained RESTful
>> Environments (CoRE) Parameters" registry."
>>
>> * Any rationale behind suggesting 51 as option number for Q-Block2 ?
>> The
>> number is consistent with the intended option properties; however
>> other
>> consistent, smaller and unassigned values are 31, 43 and 47.
>>
>>
>> [Section 10.2]
>>
>> * Rename the section as "Media Type Registrations".
>>
>> * Expand the first sentence as "... [IANA-MediaTypes]. This
>> registration
>> follows the procedures specified in [RFC6838]." , and add RFC6838 as
>> normative reference.
>>
>> * Expand "Encoding considerations" as: " Must be encoded as a CBOR
>> sequence [RFC8742], as defined in Section 4 of [RFCXXXX].
>>
>> * In "Security considerations", add an actual link to the section.
>>
>> * In "Applications that use this media type", you should be more
>> specific, e.g.:
>>
>>      The type is used by applications relying on block-wise transfers,
>> allowing a server to specify non-received blocks and request for
>> their
>> retransmission, as defined in Section 4 of [This_Document].
>>
>> * It's fine to just have "Additional information: N/A".
>>
>>
>> [Section 10.3]
>>
>> * Rename the section as "CoAP Content-Formats Registry".
>>
>> * s/the CoAP Content-Format ID/the following CoAP Content-Format
>>
>> * Expand the first sentence as "... "CoAP Content-Formats" sub-
>> registry
>> [Format], defined in [RFC7252], within the "Constrained RESTful
>> Environments (CoRE) Parameters" registry."
>>
>>
>> [Section 11]
>>
>> * Please swap this section with the previous one. Security
>> considerations come before IANA considerations.
>>
>>
>> [Section 12]
>>
>> * The "Acknowledgements" section should be moved down and be right
>> before the final "Authors Addresses". Also, it must be a non-numbered
>> section.
>>
>>
>> [Section 13]
>>
>> * Refer to version -13 of draft-ietf-core-echo-request-tag
>>
>>
>> [Appendix A.1]
>>
>> * s/the use Q-Block1 Option/the use of Q-Block1 Option
>>
>> * In Figure 18, the notation "--->?" should still be "--->X", like
>> used
>> also in a similar fashion later at the end of Figure 19.
>>
>>
>> --
>> Marco Tiloca
>> Ph.D., Senior Researcher
>>
>> RISE Research Institutes of Sweden
>> Division ICT
>> Isafjordsgatan 22 / Kistagången 16
>> SE-164 40 Kista (Sweden)
>>
>> Phone: +46 (0)70 60 46 501
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cc0df8e881566480a281608d8e90d916a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637515591928458819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&amp;sdata=5Dt6Abd9NI%2Fxn02dCje6ESnpI4PRgidrxJdNzmpNVts%3D&amp;reserved=0
>>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se