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

[Marco Tiloca <[e-mail]>]

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, [e-mail] 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&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cc0df8e881566480a281608d8e90d916a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637515591928458819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=r7DuNZdtQQHk2zdk1D6du7rnzhcUx1be74JOha%2BG4AI%3D&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:[e-mail]] De la part de Marco Tiloca
>> Envoyé : mardi 16 mars 2021 17:43
>> À : [e-mail]
>> Cc : [e-mail] WG ([e-mail]) <[e-mail]>
>> 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: [phone]
>> 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: [phone]
https://www.ri.se