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

[[e-mail]]

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. 

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


_________________________________________________________________________________________________________________________

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.