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

From: Marco Tiloca <[email-masked]>
Date: Tue, 16 Mar 2021 17:43:09 +0100

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

---

From: <[email-masked]>
Date: Wed, 17 Mar 2021 06:26:13 +0000

Hi Marco, 

Thank you for the review.

An updated version that fixes almost all your points is online. Changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-09. 

> 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:[email-masked]] De la part de Marco Tiloca
> Envoyé : mardi 16 mars 2021 17:43
> À : [email-masked]
> Cc : [email-masked] WG ([email-masked]) <[email-masked]>
> Objet : [core] Shepherd review of draft-ietf-core-new-block-08
> 
> Hello Med and Jon,
> 
> * 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.
> 
> * 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."
> 
> endpoint of successful reception, or reports on all blocks in the
> body that have not yet been received.
> 
> * 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]
> 

_________________________________________________________________________________________________________________________

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.

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 17 Mar 2021 18:37:32 +0100

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, [email-masked] wrote:
> 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=0.
>
>> 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
>>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher