Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.txt

[Marco Tiloca <[e-mail]>]

Hi Jon,

On 2021-01-15 12:24, [e-mail] wrote:
> Hi Marco,
>
> Thanks from this.
>
> So moving forward, requests for missing Q-Block2 blocks will follow Section 2.7 RFC7959 being modelled on (assuming the request was using Q-Block1)
> " To continue this Block2 transfer, the client
>    continues to send requests similar to the requests in the Block1
>    phase, but leaves out the Block1 Options and includes a Block2
>    request option with non-zero NUM."
>
> Otherwise, please see inline which has a couple of questions.
>
> Regards
>
> Jon
>> -----Original Message-----
>> From: Marco Tiloca [mailto: [e-mail]]
>> Sent: 14 January 2021 19:58
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
>>
>> Hi Med,
>>
>> Thanks for the new document version.
>>
>> Please, see below some comments on the latest additions, also related to what
>> Jon raised at [1].
>>
>> Best,
>> /Marco
>>
>> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-gtPQZloDT9_1E%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E4lIccwYQyVGHxxl9v9iBr70hU6BuxRrzAQoZHnZt%2B8%3D&reserved=0
>>
>>
>> * Section 3.5 - This seems to mix aspects specific to Observe, with more general
>> aspects applicable to requests with a payload, i.e. FETCH (with or without
>> Observe), PUT, POST and PATCH/iPATCH.
> [Jon] Now that we understand what needs to be done with requesting missing Q-Block2 blocks, working with Observe can be simplified.
>
> [Jon] Requesting Observe is only valid for GET and FETCH.  Hence Observe request/cancellation setting when using Q-Block1 is only appropriate for FETCH.
>
> [Jon]  Unfortunately, RFC8132 does not specify in which of the payloads of as Block1 based FETCH request  should contain the Observe option assuming observe is required (The first, the last or all of the payloads). So, here, I believe the safest way to go is with all the payloads carry the observe option if observe is being requested or cancelled.  Thus any missing payloads should be resent with the observe configured to be consistent with all the other payloads. Are you happy with this?

==>MT
It makes sense to me.
<==

>
>>   What is specific of Observe is the first paragraph; and the usage of the Observe
>> option in the second and third paragraph. Anything else seems generic and
>> applicable to requests with payload, so it might be moved up to some earlier
>> section.
>>
> [Jon] Sure - will be updated in the simplification tidy up.
>> * Section 3.5 - In the third paragraph, I'm not sure you necessarily need a
>> payload to be present in the requests asking for missing response payloads. For
>> instance, consider:
> [Jon] Agreed.  Now going with Section 2.7 RFC7959 where both Block1 and payload are not included.
>>   - The examples in Figure 10 and Figure 11 of RFC 7959, with the note "(no
>> payload for requests with Block2 with NUM != 0)" , during the phase where the
>> client consecutively asks for the next response payload.
>>
>>   - The examples in Figure 2 and Figure 3 of [2], where each request for the next
>> response payload using Block2 has no payload of its own.
>>
>> This would of course affect the example in Figure 15.
> [Jon] Yes, will be updated.
>> [2] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est-18&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7O7%2BQ%3D&amp;reserved=0
>>
>>
>> * Section 3.5 - About the last sentence regarding the Observe option, there
>> seems to be an exception to this rule (at least based on the later examples),
>> where the server actually does include the Observe option in the response.
> [Jon] If the Observe option is just included with the first payload (NUM = 0) as RFC7959, there is a recovery special case should the first payload not arrive, but subsequent ones do.  In the general case, blocks that are missing are re-requested by the client and the server responds with the appropriate block, but without the Observe option. For the special case when the client requests missing payload with NUM = 0 the server needs to know that it must include the Observe in the response so that the client following the body re-assembly knows that it is a Observe triggered additional response.
>
> [Jon] I had gone with the Observe should be in all the payloads in the response apart from specifically re-requested blocks (including NUM = 0).  The 'Continue' Q-Block2 was just to indicate a continue so the server can send the remaining payloads without delay - hence why remaining payloads had Observe set.  
>
> [Jon] I am beginning to lean to having it in the first payload and special case the response to re-request of NUM = 0.  What do you think?

==>MT
Ok, I didn't think also of the case for NUM = 0, but that makes sense too.

Then it's certainly something better to clarify in the main text and
also to show/comment in the example of Figure 10.
<==

>
>>    That is, consider the example in Figure 10, where the response with M:0xba is
>> lost. Later on, the client asks for that response payload by sending the request
>> with M:0x87, which correctly does not include the Observe option.
>>
> [Jon] Yes
>>    However, the following response with M:oxc3 and (from the point of view of
>> the server) retransmitting that response payload with block number 10 does
>> include the Observe option.
>>
>>    The exception seems due to the fact that the retransmission request from the
>> client is specifically what you call 'Continue' Q-Block-2 in Section 3.4. The
>> Observe option is in fact not included for the previously retransmitted response
>> payloads with M:0xbb ... M:0xc2, as still part of the current payload set.
> [Jon] Correct, but obviously not obvious from the text.

==>MT
Right, I mostly focused on that.

I think it's worth clarifying in the main text what the normal case is
for the server (client) to include (expect) the Observe option in a
response payload; and then highlight the exceptions for the re-request
with NUM=0 (see above) and for the 'Continue' Q-Block2.

Best,
/Marco
<==

>>
>> * Section 3.6 - Part of the first sentence in the second paragraph seems to
>> repeat what already said in the third paragraph of Section 3.5.
>>
> [Jon] Will clean up in the simplification.
> ~Jon

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