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

From: [email-masked]
Date: Wed, 13 Jan 2021 10:06:19 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments WG of the IETF.

        Title           : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission
        Authors         : Mohamed Boucadair
                          Jon Shallow
	Filename        : draft-ietf-core-new-block-05.txt
	Pages           : 42
	Date            : 2021-01-13

Abstract:
   This document specifies alternative Constrained Application Protocol
   (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.

   These options are similar to the CoAP Block1 and Block2 Options, not
   a replacement for them, but do enable faster transmission rates for
   large amounts of data with less packet interchanges as well as
   supporting faster recovery should any of the blocks get lost in
   transmission.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-new-block/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-new-block-05
https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Wed, 13 Jan 2021 18:13:40 +0000

Hi all, 

This version integrates the latest comments from Marco, especially the handling of FETCH. New examples were also added to illustrate the intended behavior. 

If there are still any pending issues, please let us know. 

Cheers,
Jon & Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]] De la part
> de [email-masked]
> Envoyé : mercredi 13 janvier 2021 19:06
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-core-new-block-05.txt
> 
> 
>         Title           : Constrained Application Protocol (CoAP)
> Block-Wise Transfer Options for Faster Transmission
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 14 Jan 2021 20:57:31 +0100

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://mailarchive.ietf.org/arch/msg/core/Orr8a1WlSu3Dk-gtPQZloDT9_1E/

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

  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.

* 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:
 
  - 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.
 
[2] https://tools.ietf.org/html/draft-ietf-ace-coap-est-18

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

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

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

On 2021-01-13 19:13, [email-masked] wrote:
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ud1P4lktmZSE6bfK3Z1IvqZdjSG6aZJNUNwAfUEliFQ%3D&amp;reserved=0
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-core-new-block-05&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=J4zJlB0x1WpQosEH3R0WBg2hoHuRpKiQVPpfwTk82n4%3D&amp;reserved=0
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-new-block-05&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=XzJsVE4fc8Bj8aoKqmVTjSztTnTqsr42QY3u3Fhu4BY%3D&amp;reserved=0
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-new-block-05&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=XfWCRY89NGPI%2BOH6rmg9BuJHjwIpsWAHadSIglqnDDE%3D&amp;reserved=0
>>
>>
>> https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=nDdHKBvQpuwnSsPvGghajJsaBKTXk295O%2BNDXEri9V4%3D&amp;reserved=0
>>
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2F3GBuD%2Fc2uCE9bAdXWxAy0bYvLIPMczzffzKYKv6Zc4%3D&amp;reserved=0
>> Internet-Draft directories: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2BEoWyGAyhlY0NmwyMvoe2vOeuXciF7kdnsZe1dIIHP0%3D&amp;reserved=0 or
>> https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Fietf%2F1shadow-sites.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588465405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=LDcmi9fJAgtoqVsl4AUpt0Xm8K1XEFguDVmCXg6we88%3D&amp;reserved=0
> core mailing list
> [email-masked]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588465405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=zF09t2u3ZkjRw1eRfzIMegbOZRTIVRGGUVKE9TZp0oY%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: +46 (0)70 60 46 501
https://www.ri.se

---

From: <[email-masked]>
Date: Fri, 15 Jan 2021 11:24:44 -0000

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: [email-masked]]
> Sent: 14 January 2021 19:58
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
> 
> Hi Med,
> 
> Please, see below some comments on the latest additions, also related to what
> Jon raised at [1].
> 
> Best,
> /Marco
> 
> * 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?

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

[Jon] Yes, will be updated.
> * 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?

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

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 15 Jan 2021 14:57:53 +0100

Hi Jon,

On 2021-01-15 12:24, [email-masked] wrote:
>> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-gtPQZloDT9_1E%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=E4lIccwYQyVGHxxl9v9iBr70hU6BuxRrzAQoZHnZt%2B8%3D&amp;reserved=0
>>
>>

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

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

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

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

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Mon, 18 Jan 2021 14:16:23 -0000

Hi Marco,

We have updated github [1] to take account of your latest comments for your review.

Regards

Jon

[1]https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-new-block.txt

> Sent: 15 January 2021 13:58
> To: [email-masked]; [email-masked]; [email-masked]
> > 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
> >> 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&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d
> 8b
> >>
> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674
> 04024
> >>
> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTi
> >>
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=E4lIccwYQyVGHxxl9v9iBr70
> hU6
> >> BuxRrzAQoZHnZt%2B8%3D&amp;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.
> >>
> >> need a payload to be present in the requests asking for missing
> >> response payloads. For instance, consider:
> >>   - 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.
> >>
> >> [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
> >>
> >>
> >> 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
> 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
> >>    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.
> 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.
> >>

---

From: Marco Tiloca <[email-masked]>
Date: Tue, 19 Jan 2021 12:50:16 +0100

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, [email-masked] wrote:
> [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&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uGB%2BGu0PztRvMh4hUFutHMItkR5AJXCJqpt440nphj4%3D&amp;reserved=0
>
>
>> 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

---

From: <[email-masked]>
Date: Tue, 19 Jan 2021 12:24:01 +0000

Hi Marco, 

The proposed edits look good to me. Will be fixed in the github. 

2.31 is not mentioned in in the excerpt you quoted from Section 3.3 because 2.31 is not **required**. A server may decide to not reply with 2.31 as a function of its overall load and prefer to observe a pause before handling the next block. That’s is why we do have SHOULD, not a MUST.    

Cheers,
Med

> De : Marco Tiloca [mailto:[email-masked]]
> Envoyé : mardi 19 janvier 2021 12:50
> À : [email-masked]; BOUCADAIR Mohamed TGI/OLN
> <[email-masked]>; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
> 
> Hi Jon,
> 
> * Section 3.1 - In the paragraph right above Table 2, s/with CoAP
> over TCP/with CoAP over reliable transports.
> 
> 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
> ...
> 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?
> 
> reset message (in case of Non-confirmable request) MUST be returned
> if the server does not support the Q-Block1 Option."
> 
> 
> [1]https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fw
> > ww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-
> block%26url2%3Dhttp
> > s%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-
> block%2Fmaster%2Fd
> > raft-ietf-core-new-
> block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7
> >
> C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8
> %7
> >
> C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MD
> >
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uG
> B%
> > 2BGu0PztRvMh4hUFutHMItkR5AJXCJqpt440nphj4%3D&amp;reserved=0
> >
> >
> >>>> Please, see below some comments on the latest additions, also
> >>>> related to what Jon raised at [1].
> >>>>
> >>>> Best,
> >>>> /Marco
> >>>>
> >>>> [1]
> >>>>
> >>> [Jon] Now that we understand what needs to be done with
> requesting
> >>> missing
> >> 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.
> >> <==
> >>
> >>>> * 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 2 and Figure 3 of [2], where each
> >>>> request for the next response payload using Block2 has no
> payload of its own.
> >>>>
> >>>> * 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
> >>> [Jon] I had gone with the Observe should be in all the payloads
> in
> >>> the response
> >> 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
> >>>> 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.
> >>>>
> >>>> 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,
> >> 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
> >> <==
> >>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w
> >>
> .ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d
> 6
> >>
> a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374657
> 6
> >>
> 1738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> z
> >>
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LE%2FKQOOUq5aEBbgV
> R
> >> dtqmLiOz8n%2Bt60OuEYgM%2FwCrJg%3D&amp;reserved=0
> >>
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>

---

From: Marco Tiloca <[email-masked]>
Date: Tue, 19 Jan 2021 15:09:47 +0100

Got it, thanks.

Best,
/Marco

On 2021-01-19 13:24, [email-masked] wrote:
>> [1]https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%252
>> Fw
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C21a30f35d4534262c38c08d8bc751b7c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637466558517629762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5npricMtOuyVskAU%2FpP%2BnvzjAc%2Bazs%2BQ1G54jPNW6Wo%3D&amp;reserved=0
>>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Tue, 19 Jan 2021 15:21:03 +0000

Re-,

Great. Thanks. 

A version with the agreed changes is now public: 

URL:            https://www.ietf.org/archive/id/draft-ietf-core-new-block-06.txt 
Status:         https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ 
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block 
Htmlized:       https://tools.ietf.org/html/draft-ietf-core-new-block-06 
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-06

Cheers,
Med

> Envoyé : mardi 19 janvier 2021 15:10
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]; [email-masked]
> > 2.31 is not mentioned in in the excerpt you quoted from Section
> 3.3 because 2.31 is not **required**. A server may decide to not
> reply with 2.31 as a function of its overall load and prefer to
> observe a pause before handling the next block. That’s is why we do
> have SHOULD, not a MUST.
> >
> > Cheers,
> > Med
> >
> >> De : Marco Tiloca [mailto:[email-masked]] Envoyé : mardi 19
> >> janvier 2021 12:50 À : [email-masked]; BOUCADAIR
> Mohamed
> >> TGI/OLN <[email-masked]>; [email-masked] Cc :
> >> [email-masked]; [email-masked] Objet : Re:
> [core]
> >> I-D Action: draft-ietf-core-new-block-05.txt
> >>
> >> Hi Jon,
> >>
> >> Thanks, please see below some minor points, otherwise it looks
> good
> >> to me.
> >>
> >> Best,
> >> /Marco
> >>
> >>> We have updated github [1] to take account of your latest
> comments
> >> for your review.
> >>> Regards
> >>>
> >>> Jon
> >>>