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

[Marco Tiloca <[e-mail]>]

Hi Jon,

Thanks, please see below some minor points, otherwise it looks good to me.

Best,
/Marco

* Section 3.1 - In the paragraph right above Table 2, s/with CoAP over
TCP/with CoAP over reliable transports.

* Section 3.1 - I think that the new final paragraph "Note that if
Q-Block1 (or Q-Block2) ... MUST NOT be included." fits better before the
paragraph discussing the use of OSCORE, i.e. "The Q-Block1 and ...
fragmentation of requests."

* Section 3.3 - "For Non-confirmable transmission, no response is
required until the successful receipt of the body by the server or some
of the payloads have not arrived after a timeout and a retransmit
missing payloads response is needed."

   Shouldn't this also mention the case where the server sends a 2.31
response to have the client continue sending the next MAX_PAYLOADS payloads?

* Section 3.3 - Proposed clarification for the 4.02 response code:

    "Either this Response Code (in case of Confirmable request) or a
reset message (in case of Non-confirmable request) MUST be returned if
the server does not support the Q-Block1 Option."


On 2021-01-18 15:16, [e-mail] wrote:
> Hi Marco,
>
> We have updated github [1] to take account of your latest comments for your review.
>
> Regards
>
> Jon
>
>
> [1]https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-block.txt&data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uGB%2BGu0PztRvMh4hUFutHMItkR5AJXCJqpt440nphj4%3D&reserved=0
>
>
>> -----Original Message-----
>> From: Marco Tiloca [mailto: [e-mail]]
>> Sent: 15 January 2021 13:58
>> To: [e-mail]; [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
>>
>> 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%2Fmai
>>>> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-
>> gtPQZloDT9_1E%2
>> F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d
>> 8b
>> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674
>> 04024
>> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>> CJBTi
>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E4lIccwYQyVGHxxl9v9iBr70
>> hU6
>>>> BuxRrzAQoZHnZt%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%2Ftoo
>>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est-
>> 18&amp;data=04%7C01%7Cma
>> rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb
>> 4
>> 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT
>> WFpbGZs
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>> %3
>> D%7C1000&amp;sdata=cSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7
>> O7%2B
>>>> Q%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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LE%2FKQOOUq5aEBbgVRdtqmLiOz8n%2Bt60OuEYgM%2FwCrJg%3D&amp;reserved=0
>>
>

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