Re: [core] WG Last Call on draft-ietf-core-new-block

[Marco Tiloca <[e-mail]>]

Hi all,

Please, see below some comments for this WGLC.

Best,
/Marco

 
[General]

* s/CoAP endpoint sender/CoAP sender endpoint

* Please, replace the references to RFC 7049 with references to RFC 8949.

* There are six instances of "CoAP session", which is not defined in RFC
7252 or RFC 7959. Do you simply mean "block-wise transfer" ?


[Section 1]

* I think that the heading of the current Section 1.1 can be removed, so
that Section 1 starts simply with "The Constrained Application Protocol ..."

* s/and further updated/and was further updated

* s/loss; which/loss, which

* s/informs the CoAP endpoint sender either successful receipt or/either
informs the CoAP sender endpoint of a successful receipt or

* s/that have been not yet been received/that have not yet been received

* s/will both generally/will both be generally

* The last paragraph in Section 1.4 can be expanded to mention OSCORE as
an alternative when DTLS is not used.


[Section 3.4]

* As to "If the server receives multiple requests (implied or otherwise)
for the same block ..." , I guess the word "requests" does not mean CoAP
requests, since the paragraph is talking about a single actual CoAP
request. In fact, it seems to refer to the multiple needed blocks
indicated by the multiple Q-Block2 options in a same CoAP request.

   If I'm interpreting correctly, this tries to cover a strange behavior
from the client that sends multiple Q-Block2 Options in a same CoAP
requests with the M bit set, such as: 2/1/1024 , 3/1/1024, 4/1/1024; but
still the server has to send back blocks 2, 3, 4 ... until the last one
only once each.
  
   If this is correct, how about the following rephrasing?
  
   "If the request includes multiple Q-Block2 Options and asks for a
same block multiple times (e.g., through the M bit set), the server MUST
only send back one instance of that block.

* s/if this is the case/if this is not the case

* s/Option whichever is/Option, whichever is


[Section 3.7]

* s/and MUST have the same value/and MUST preserve the same value in
each of those payloads.

(just to avoid reading it as Size1 and Size2 must have the same value)


[Section 9]

* I suggest to add one more example in the end, where Q-Block2 is used
in a request with the M bit set. As a separate continuation of the
example in Figure 7, this can be the case where, after observe being
triggered one more time, only the first block for a new ET=24 reaches
the client, which can use a single QB2:1/1/1024.


[Section 11]

* As mentioned for Section 1, more can be said here for when OSCORE is used.



On 2020-12-07 18:35, Marco Tiloca wrote:
> Dear all,
>
> Following the recent clarifications from the authors [1], this mail
> starts a Working Group Last Call on:
>
> https://tools.ietf.org/html/draft-ietf-core-new-block-02
>
> This WGLC will end on Tuesday, 22nd of December.
>
> This WGLC is also copied to the DOTS WG mailing list.
>
> Best,
> Marco and Jaime
>
> [1] https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvjiLI/
>

-- 
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