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

Marco Tiloca <marco.tiloca@ri.se> Tue, 16 March 2021 16:43 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 063743A138E; Tue, 16 Mar 2021 09:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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 MzJeYQR07kqC; Tue, 16 Mar 2021 09:43:19 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00056.outbound.protection.outlook.com [40.107.0.56]) (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 E0FA03A138B; Tue, 16 Mar 2021 09:43:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B24VE3RTvd52nJVvdxgmqHQbfvY6JyHfmGjEVikRadUWOLgJH/dn74Y8LikMHAoQno1Bqwove6ShfRZf2jmXGMqmcLBrsvgUPlal33pxJS1KGtGWhh4gl+erNU05h8/lUgoGxtf8I+QiEM1QYEbciDG3i1IqYJOgQeMKn2uEE85240SgF3LDlcqS6Kvj3W5YOPiD1hZCpOjSCRWkH3HVO3sYnb8OgrAVNwD2Muswfkq2RlA7jWE3abMM95nTth08EPHpTS7WlQySFRdQ3RoO+JSX2I+AQmyWdkOKfC73qA1XjBLFVgdI33kJ2207TQhuaSapqqSYd39tYz8l5ZQA+A==
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=PleulWYIgPZw4vFJ7YiQjqJ4bKdIHoQYy1f/PWzrvz8=; b=n3K7j3/EXk426IhkezwWP7zkQ3sFx7Dwuu2LeM9KNkZxZlKe53f46kXz0kvi0S9Cd2BMEf0f5WISaB/CWglp+CyxRFvlUIARbEehmBNj4Qcldv7vQ0kncUcr7zMfPWPCCszsgabXVS5IIkXVT47Xl4s627aJwhDxI7WSCEjh5JknAL5HNQnERXcicBnfw951tSQVdPIq/kfXrM0xeyOEkJcG0LmOJcgCkToLEEyy2h35e6yPY3CHeBTjm5rkc93rXz0gcMpUqzPFyBdhArhG8agfR8Y+mN89HEcXJ969LIRhttITbRxzBaKNiNmGBTuBbVoH0tp+bl2WfxBYTiGjqA==
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=PleulWYIgPZw4vFJ7YiQjqJ4bKdIHoQYy1f/PWzrvz8=; b=LxuCB2tqWmmqcBtQstVn/OEY8pt6CIl+ELms7ynThLWDtsBQ02VeNcFB+8NveQ+nYXclW2ClgdIlltq/6nMIs1bubI4NsufWlY6KFp5eYwPrZafECo8iQbFWgdyKpOYHJgj1Za5DE4kFdG0RsZHxZ/vw7SYtI3WW27Qy62uW/A0=
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 DB6P189MB0440.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Tue, 16 Mar 2021 16:43:15 +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; Tue, 16 Mar 2021 16:43:15 +0000
To: draft-ietf-core-new-block@ietf.org
Cc: "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
From: Marco Tiloca <marco.tiloca@ri.se>
Message-ID: <9069143b-ae5b-467e-4987-498e35c5c72a@ri.se>
Date: Tue, 16 Mar 2021 17:43:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="uCCnvMrVtirrycBcJBXsDSUHmMXmXUcP7"
X-Originating-IP: [92.34.17.243]
X-ClientProxiedBy: MN2PR07CA0029.namprd07.prod.outlook.com (2603:10b6:208:1a0::39) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.68] (92.34.17.243) by MN2PR07CA0029.namprd07.prod.outlook.com (2603:10b6:208:1a0::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32 via Frontend Transport; Tue, 16 Mar 2021 16:43:14 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 879e70ce-1144-46ec-1eee-08d8e89a9842
X-MS-TrafficTypeDiagnostic: DB6P189MB0440:
X-Microsoft-Antispam-PRVS: <DB6P189MB04404D930A9B10E6F1876B00996B9@DB6P189MB0440.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:5797;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: eFxE7qYSgxepqymZCU2k5nU8PypDXGW35mOlRrSktVpL4DReqmJPe/M3fCaIcG0QGyVmCYVFdkg41lRH5+wh0ikN/3BWi1WwUFbAyGlJ62MR810A0M0pOAGhjiR/qvQT8PbvAeWGdOyh7+2jXBP2PiagyZoTI4N5dahMP/nTzReiQog4CfpuU7B09V2wXQmLPrPoVX0LjxNrES7b75Idg/Zs7dlE/Q9mykpi5pIoNhPpEEI5ekw1RECtp09hPIgq5hd66pylGQJh5vBSkixqGn4Q09TAhhTbiROdOy54giUkOHvNg7lWGvN8F5bUT8R0HS2Y85CtHAC/HFkTKMppcctuZrRxZ6bKg+xx0izJDwKyZMEOfT1NFR1qd3mVA2v0VMWslZxkaeKFPrmXP27phK1JeUH6ojz/sxWRJC+1r03cjYmI+CKPFGhYwjupxAHpHdH335/Lq3flF+9fzEvyJi+ERVkLIujSqfQoXe0iDY4dT3icYBWgk2tKtPHn+AVgMGM8wn3EwXfoJefIGU2POx6A9Maszc0HildxTeLjBgeeMI0vz3nzlS7gU4GwwtXHvr4EuTlLi2stcFAK/1E9YBaY4wO0XWwub6aUEUBGbuOuKeoFVxNAA1yx3Pb/mvJk0UrsRQaOYlNn3GxVIqhxM/JPt/J8rAAgMGuE0raMGRvgnWJnW9OR5XhR+F2opu599sxLRSLFf3/Cz3sG7k/KJv89OxDOGiyyxvphSAI1Qnk=
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)(39850400004)(136003)(346002)(396003)(366004)(33964004)(8676002)(52116002)(450100002)(19627235002)(26005)(66946007)(478600001)(83380400001)(8936002)(6916009)(31686004)(6666004)(66556008)(6486002)(21480400003)(31696002)(2906002)(2616005)(36756003)(956004)(316002)(966005)(66574015)(16576012)(5660300002)(16526019)(186003)(235185007)(86362001)(66476007)(44832011)(4326008)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: K43Rm9ZulWIh5IOOdlDud0ZVtiQDdQHYAkZBXEUPQOnflePaXSO9cJ3ZtZosbRuijDgClix+gYlZBXx95zc9/DsldYMPEZnMzDYHq+bfNZ8HIQ+KFVwjDk5wgJduI4EcydMY1QINn7AvwS9/V39iBFoxOOrK9wTRU8e7YspDNzK00URvZwKOJO3YwLgWoh+3NTqOtGjn8Ma40zuRyfXVCA6sac2B6T7Icp+oONxrRbhwYaXCigkuOCFVnLzNpNw5JC1TJP20NBLQ9eZeHleqKqTo9TtO2gKAil9mWguHsV1ovgs2nnodRkqS864Gxy/MbNoWxZX5Q3OulRPhGHLMtk6VnjkOr8T/CvpIgSp7gFUGvlklJ2JNfnO6iUCgOmOaeFCUn9Wa+3JG+KKm1TfslsAdgmsxkTIcCQ+GhlbdCB62xLRhVkhge//rXHJQDNYeszIXzcfWJUax9BygdlUJhgcRUwlUYSi0NiWZSsIFzqD7vd11I00GURFpwcJLmrCeo1UkF/jgM4Q9yR5jf/SHSQjEdfNNOWpgU9gXS+CfFGlcBfA8g/LcVAgQKsR40I9KqBOxbgnQvAQQLjQykEOqzDJxjlzIGwClV+OhJKrwMSTe7jgoQPHjrdNwXNBPMbwJrLaH9ypYoXn9fHCNRvyQrekHZrLL6u6JmLioDQ26YSeA9KvjVxXzNlk/QqbTYek0RhCjTs6w+RXetlZn0zm1Fi8x2dqYYYgFZd9kgNyX4lNdHzuIxxpo9VXe252bugRzRqpUU/G9DcJTAxX7lc+I7CSQm3cuT2GyTDIzX+fa1/jIPMi0lCRrxpHJcxo4sZ7cWYUvxi9b91I7QqKi6BoVlxc8p3ygagRrv4DXzwZkuJGxX3DsZ9edGOY0qDHoY2J2zIqnsTLELAGm9ytA3Eb24vwhX1Tblo7AVl0ntv6BHFcPQVZndEVnC2SRRSkf9NHy3gswE8Cuq6ELGgspo575WYQ38GZkvixd0Oe3GD32RiIQXMM1UDpqBKm3EaPiEfvhgsZwNic2as6bhqwM1o8pZYy0W2AifhgD38eWPakwqzpVLGjEmAnsrGSFxmpE/nBIX73VNzkeE3cTECYj0SHY79QCdhJT/LklKVml/bfst6Awe738ddk7GWtn62zCwW0+K621YNugyVDxJ4iAVe4i3En6UAlHfZXg4ck9NL+6OwGkXvgzWMJ4t3z1CE95MC0MI2Vec9Br5HUnUKx5CAntS+U16WvcXn5fff+w7x0t1HB1ZZ5uh6Mpg8DYXhDyMQGaM7Q1Bwle/5/V1A6xkeibsWmK8x5NRzrfLFiKqJvF8wHSGM58FUAsUups7MB597lP
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 879e70ce-1144-46ec-1eee-08d8e89a9842
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2021 16:43:15.2123 (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: A9iYtngeLelEA2zUPCNfOTlyQMbDFrakVY9oJbSxQKcOcyQxynHu3NTntogqAoWM4pPjXCVurwk2WlqOdEZ0fw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0440
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/GsW4RRRonj_-Vnm3fvqxOgtZg0M>
Subject: [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: Tue, 16 Mar 2021 16:43:23 -0000

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://www.ri.se