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

[[e-mail]]

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

> -----Message d'origine-----
> De : Marco Tiloca [mailto:[e-mail]]
> Envoyé : mardi 19 janvier 2021 12:50
> À : [e-mail]; BOUCADAIR Mohamed TGI/OLN
> <[e-mail]>; [e-mail]
> Cc : [e-mail]; [e-mail]
> 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
> 
> * 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%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
> >
> >
> >> -----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%2Fm
> >>>> ai
> >>>> 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.
> >>>>
> >>> [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%2Ft
> >>>> oo
> >>>> 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%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
> 
> 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.