Subject: [core] AD review of draft-ietf-core-new-block-09

From: Francesca Palombini <[email-masked]>
Date: Sat, 3 Apr 2021 19:31:55 +0000

Thanks for the work on this document.  I have a number of comments about things that I think need clarification or rewording in my review below, so I’m setting the state on the document to “revised I-D needed”, and hope we can get an update solving those before we move to IETF last call.  Please keep me in the "to" field to make sure I see any reply.

Please note that the comments are reported while reading the document from top to bottom - some comments could be avoided by referencing the right sections or restructuring the document. If I notice that this is the case, I make a suggestion in the comment - if I do miss something that is explained later on, please consider the comment a suggestion to add a reference to improve readability and add clarifications.

General:

1. 
[FP]: Throughout the text, it seems that "payload" is used as a synonym to "CoAP request/response" or "block". This is incorrect and should be fixed. (See for example "received payload")

-----

2.
[FP]: Throughout the document, SHOULD is used without explanation of why the recommendation is just that - a recommendation - and not a requirement. There needs to be more clarification to implementers when it is ok and can be expected to deviate from the recommendations. I noted those that jumped to my attention, but I suspect a general re-read of the document with this comment in mind should be done, as there might be more I missed.

=====

Section 1:

3. 
   o  They can operate in environments where packet loss is highly
      asymmetrical.

[FP]: Please clarify: Block1 and Block2 can also be used in environments where packet loss is asymmetrical. What do these new options add in that case? 

-----

4.
   o  To reduce the transmission times for CON transmission of large
      bodies, NSTART needs to be increased from 1, but this affects

[FP]: NSTART appears here for the first time, please add a reference to where this is defined (fw reference to a section of this specification or to a different document).

-----

5.
   Block2 Options when the different transmission properties are
   required.  If the new options are not supported by a peer, then

[FP]: I hope these transmission properties are explained into detail later on. If so, please add a fw reference. If not, please clarify what these properties are.

-----

6.
   The No-Response Option was considered but was abandoned as it does

[FP]: No-Response Option needs a reference.

=====

Section 2:

7.
[FP]: Because of the way the document is structured, the subsections of section 1 use terminology that is given for granted, and mentioned in section 2. This create some confusion in the reader. I suggest to re-structure the sections so that Terminology is right after 1. Introduction and before 1.1

=====

Section 3:

8.
   The Content-Format Option applies to the body, not to the payload
   (i.e., it must be the same for all payloads of the same body).

[FP]: I think this is missing that the previous sentence is true "when present together with the Q-Block1 or Q-Block2 Option".

-----

9.
   include the Q-Block2 Option in a GET or similar request, the Q-Block2
   Option in a PUT or similar request, or the Q-Block1 Option in a PUT
   or similar request so that the server knows that the client supports

[FP]: I am confused by the meaning of "similar request": what is considered a similar request to a GET request? How is a PUT request different from a GET request? Additionally, how does the client decides if it needs to include a Q-Block1 or Q-Block2 Option in a PUT (or similar) request to indicate support for these two options?

-----

10.
   Note that if Q-Block1 or Q-Block2 Options are included in a packet as
   Inner options, Block1 or Block2 Options MUST NOT be included as Inner
   options.  Similarly there MUST NOT be a mix of Q-Block and Block for

[FP]: Maybe this is described later on, but - what is the node to do if it receives a message with both? Is the message to be rejected with an error? This should be clarified.

-----

11.
   being transferred.  It is also used to identify a particular payload
   of a body that needs to be retransmitted.  The Request-Tag is opaque,

[FP]: If it is the same for all the requests carrying one same body, how does it identify one particular payload? Also I am assuming that "a particular payload of a body" means a block of the body - if that is not correct, I think the "payload of a body" should be rephrased.

-----

12.
   Each individual payload of the body is treated as a new request
   (Section 5).

[FP]: Again, I suspect the meaning of this sentence will be clarified in section 5, but I think it is incorrect to say that each payload is treated as a new request - each payload is treated as a payload. I think this needs to be rephrased, but at this point in the text I can't say what the intent of this sentence was, so can't suggest a rephrasing.

-----

13.
      and that the resource was created.  The token used SHOULD be from
      the last received payload.  The client should then release all of

[FP]: I think it would be worth to highlight that the last received block is not necessarily the block with the highest block number. (note this appears in more than one occurrence)

-----

14.
      M bit set) have been successfully received.  The token used SHOULD
      be from the last received payload.

[FP]: "SHOULD" must be motivated: why is this not a MUST? What are the conditions where it is acceptable that the token is different from the one in the request with the last received payload? (note: several occurrences)

-----

15.
      A response using this Response Code SHOULD NOT be generated for
      every received Q-Block1 Option request.  It SHOULD only be
      generated when all the payload requests are Non-confirmable and a
      set of MAX_PAYLOADS (Section 6.2) payloads have been received by
      the server.

      It SHOULD NOT be generated for CON.

[FP]: Same remark as previous comment - please motivate why this is SHOULD and is not MUST. When using SHOULD, guidance should be given to implementers about in which case it is ok to deviate from the recommendations.

-----

16.
   SHOULD "forget" all tracked tokens associated with the body's

   token in the 4.08 (Request Entity Incomplete) response.  The server
   on receipt of the reset message SHOULD delete the partial body.

   it SHOULD ignore the payload of the packet, but MUST still respond as

   A server SHOULD only maintain a partial body (missing payloads) for

[FP]: Same remark for the use of SHOULD. (I stopped nothing this down at this point in the review, but noted this in the general comments above)

-----

17.
   unset.  It is permissible to set the M bit to request this and
   missing blocks from this MAX_PAYLOADS set.  Further considerations

[FP]: "this and missing blocks" is unclear to me. Could you clarify?

-----

18.
   The requested missing block numbers MUST have an increasing block
   number in each additional Q-Block2 Option with no duplicates.  The

[FP]: What is the reason for mandating that the blocks requested must be in order (increasing block number)?

-----

19.
   packet.  The server acknowledges the initial request using an ACK
   with the payload, and then sends the subsequent payloads as CON

[FP]: I suspect that this means that the first response (containing the first block) is piggybacked on an ACK, see 5.2.1 of RFC 7252. That is though not always the case, see 5.2.2. I think this option of piggybacked should be kept, but from the text it sounds like it is the only option, so I believe some rephrasing to clarify that might be necessary.

-----

20.
   The ETag Option should not be used in the request for missing blocks

   client should treat the partial body with the old ETag as no longer

   response, the client should remove any partially received body held

[FP]: Why not replace the should (resp should not) with MUST (resp MUST NOT)?

=====

21.
Section 4:

   encoded as a CBOR Sequence [RFC8742].  It comprises of one or more
   CBOR encoded [RFC8949] missing block numbers.  The missing block

[FP]: I suggest to change to " missing block numbers encoded as CBOR unsigned integers [RFC8949]."

-----

22.
   response when created by the server; the client SHOULD drop any
   duplicates in the same 4.08 (Request Entity Incomplete) response.

[FP]: I think that "drop" here might be confusing, since the client is not dropping a packet - suggestion to change to "ignore".

-----

23.
   The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used
   in the 4.08 (Request Entity Incomplete) response.  It MUST be set to
   "application/missing-blocks+cbor-seq" (Section 11.3).

[FP]: This is in direct contradiction with the following paragraph from a previous section:

      This Response Code returned without Content-Type "application/
      missing-blocks+cbor-seq" (Section 11.3) is handled as in
      Section 2.9.2 [RFC7959].

-----

24.
   Request-Tag would work, but providing the one used in the last

[FP]: Suggestion to rephrase "would work" to "would allow to identify the correct body" (or something similar).

-----

25.
   single packet.  If this is the case, then the server can send
   subsequent 4.08 (Request Entity Incomplete) responses containing the
   missing other blocks on receipt of a new request providing a missing
   payload with the same Request-Tag.

[FP]: Just another check: is it specified anywhere that reception of an error response does not mean the client should stop sending requests when Q-Block options are used? If not, it would be good to explicitly state that.

-----

26.
   The missing blocks MUST be reported in ascending order without any
   duplicates.  The client SHOULD silently drop 4.08 (Request Entity

[FP]: Same question: why does order matter? 

=====

Section 5:

27.
   Implementation Note:  To minimize on the number of tokens that have
      to be tracked by clients, it is suggested that the bottom 32 bits
      is kept the same for the same body and the upper 32 bits contains
      the current body's request number (incrementing every request,
      including every re-transmit).  This allows the client to be

[FP]: This seems to imply that tokens are always 8 bytes, which is not necessarily the case. I suggest to add "in the case the token is 8 bytes".

=====

Section 6:

28.
   control parameters will need to be tuned to cover this change.  This
   tuning is out of scope of this document as it is expected that all
   requests and responses using Q-Block1 and Q-Block2 will be Non-
   confirmable.

[FP]: "it is expected ... Non-confirmable" Where does this come from? Maybe I misunderstand this sentence, could you please expand?

=====

Section 9:

29.
            +--------->| [[Payloads 3 - 9 not detailed]]

[FP]: Minor: I think it would make more sense to change "3 - 9" to "2 - 8" (and same for examples below)

-----

Thank you for the examples! Very clear and easy to follow.

-----

30.
           +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
           |   ...    |
        [[NON_RECEIVE_TIMEOUT (server) delay expires]]
           |     [[The server realizes a block is still missing and asks
           |        for the missing one]]
           |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10]

[FP]: I am not sure this is already stated somewhere, and if so please ignore this comment, but there should be some considerations about NON_RECEIVE_TIMEOUT in comparison to the client's CoAP timer to deal with the response: what I am thinking about is the scenario from the following example, where the client has for some reason discarded the token 0xef (for example to free up space) and is unable to process the 4.08 response from the server correctly, since it doesn't know with which request it associates with. What happens then? I assume the server should try again and then eventually stop and release the partial body. Is this described?

-----

31.
          |<---------+ [[Payloads 3 - 8 not detailed]]

[FP]: This is inconsistent and should be either 3 - 9 or 2 - 8 as noted above.

-----

32.
[FP]: Figure 16: I am not sure how the server knows which block the client is requesting when it sends the following message:

          +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024

[FP]: In fact, if I understand correctly this could either be a request for the missing block from the second set of blocks, or the client could have not received block 1 from the previous set of blocks and could be requesting the same as in:

          +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024

[FP]: If all the following responses from the server would have been lost. The two requests contain the same RT. What am I missing?

=====

Francesca

---

From: <[email-masked]>
Date: Tue, 6 Apr 2021 15:02:10 +0000

Hi Francesca, 

Thank you for the review. 

Changes can be tracked at: https://tinyurl.com/new-block-latest.

Please find our replies inline. 

Cheers,
Jon & Med

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de Francesca
> Palombini
> Envoyé : samedi 3 avril 2021 21:32
> À : [email-masked]
> Cc : [email-masked]
> Objet : [core] AD review of draft-ietf-core-new-block-09
> 
> Thanks for the work on this document.  I have a number of comments
> about things that I think need clarification or rewording in my
> review below, so I’m setting the state on the document to “revised I-
> D needed”, and hope we can get an update solving those before we move
> to IETF last call.  Please keep me in the "to" field to make sure I
> see any reply.
> 
> Please note that the comments are reported while reading the document
> from top to bottom - some comments could be avoided by referencing
> the right sections or restructuring the document. If I notice that
> this is the case, I make a suggestion in the comment - if I do miss
> something that is explained later on, please consider the comment a
> suggestion to add a reference to improve readability and add
> clarifications.
> 
> General:
> 
> 1.
> [FP]: Throughout the text, it seems that "payload" is used as a
> synonym to "CoAP request/response" or "block". This is incorrect and
> should be fixed. (See for example "received payload")
> 

[Med] The definition we are using is called out in the text:

  "The terms "payload" and "body" are defined in [RFC7959].  The term
   "payload" is thus used for the content of a single CoAP message
   (i.e., a single block being transferred)"

> -----
> 
> 2.
> [FP]: Throughout the document, SHOULD is used without explanation of
> why the recommendation is just that - a recommendation - and not a
> requirement. There needs to be more clarification to implementers
> when it is ok and can be expected to deviate from the
> recommendations. I noted those that jumped to my attention, but I
> suspect a general re-read of the document with this comment in mind
> should be done, as there might be more I missed.
> 

[Med] Will double check. Thanks. 

> [FP]: Please clarify: Block1 and Block2 can also be used in
> environments where packet loss is asymmetrical. What do these new
> options add in that case?

[Med] Please refer to the introduction where this is introduced. See for example: 

   There is a requirement for these blocks of data to be transmitted at
   higher rates under network conditions where there may be asymmetrical
   transient packet loss (i.e., responses may get dropped).  An example
   is when a network is subject to a Distributed Denial of Service
   (DDoS) attack and there is a need for DDoS mitigation agents relying
   upon CoAP to communicate with each other (e.g.,
   [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]
   recommends the use of Confirmable (CON) responses to handle potential
   packet loss.  However, such a recommendation does not work with a
   flooded pipe DDoS situation.

> [FP]: NSTART appears here for the first time, please add a reference
> to where this is defined (fw reference to a section of this
> specification or to a different document).

[Med] This is already cited in the OLD text: 

   o  To reduce the transmission times for CON transmission of large
      bodies, NSTART needs to be increased from 1, but this affects
      congestion control where other parameters need to be tuned
      (Section 4.7 of [RFC7252]). 
       ^^^^^^^^^^^^^^^^^^^^^^^^
> [FP]: I hope these transmission properties are explained into detail
> later on. If so, please add a fw reference. If not, please clarify
> what these properties are.
> 

[Med] Added a pointer to Section 3.1.

> [FP]: No-Response Option needs a reference.

[Med] Done. 

> 
> =====
> 
> Section 2:
> 
> 7.
> [FP]: Because of the way the document is structured, the subsections
> of section 1 use terminology that is given for granted, and mentioned
> in section 2. This create some confusion in the reader. I suggest to
> re-structure the sections so that Terminology is right after 1.
> Introduction and before 1.1
> 

[Med] Fair comment. Rearranged the text. 

> [FP]: I think this is missing that the previous sentence is true
> "when present together with the Q-Block1 or Q-Block2 Option".

[Med] Sure, this is only if it is present. FWIW, we are using the same wording as in RFC7959: 

   "The Content-Format Option applies to the body, not to the
   payload; in particular, the boundaries between the blocks may be in
   places that are not separating whole units in terms of the structure,
   encoding, or content-coding used by the Content-Format."

We can add a "when present" if you think this is more accurate.

> [FP]: I am confused by the meaning of "similar request": what is
> considered a similar request to a GET request?

[Med] We meant similar requests that are used to retrieve the representation of a resource. We have FETCH in mind but we also wanted a text that is future proof if such similar requests are defined in the future.

 How is a PUT request
> different from a GET request? Additionally, how does the client
> decides if it needs to include a Q-Block1 or Q-Block2 Option in a PUT
> (or similar) request to indicate support for these two options?
> 

[Med] This can be driven by a local configuration knob, triggered by an application (DOTS, for example), etc. How this is done, is out of the scope of the spec. 

> [FP]: Maybe this is described later on, but - what is the node to do
> if it receives a message with both? Is the message to be rejected
> with an error? This should be clarified.

[Med] Good catch. Added a sentence to indicate that 4.02 (Bad Option) is used in such case.

> [FP]: If it is the same for all the requests carrying one same body,
> how does it identify one particular payload?

[Med] After reading this, we agree the sentence is confusing. We meant that it is ALSO a required information to identify a missing block. That identification requires additional information (block number). Because this is detailed when describing 4.08, we suggest to delete this sentence. 

 Also I am assuming that
> "a particular payload of a body" means a block of the body - if that
> is not correct, I think the "payload of a body" should be rephrased.

[Med] The use is aligned with the definition: 

 " The term
   "payload" is thus used for the content of a single CoAP message
   (i.e., a single block being transferred), while the term "body" is
   used for the entire resource representation that is being transferred
   in a block-wise fashion."

> [FP]: Again, I suspect the meaning of this sentence will be clarified
> in section 5, but I think it is incorrect to say that each payload is
> treated as a new request - each payload is treated as a payload.

[Med] As indicated above, the wording assumes the following: 

" "payload" is thus used for the content of a single CoAP message"
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 I
> think this needs to be rephrased, but at this point in the text I
> can't say what the intent of this sentence was, so can't suggest a
> rephrasing.
> 

[Med] The main message here is that each individual message is to be treated as a new request, and be thus assigned a new token as per draft-ietf-core-echo-request-tag-12#section-4. 

We used to have token details included here, but given the comments we received from the WG, we discuss token issue in a separate section that is called in the text you quoted: Section 5. 

> [FP]: I think it would be worth to highlight that the last received
> block is not necessarily the block with the highest block number.
> (note this appears in more than one occurrence)

[Med] No problem to mention it: "Note that the last received payload may not be the one with the highest block number."

We don't think it is worth to restate it for each code, though.

> [FP]: "SHOULD" must be motivated: why is this not a MUST? What are
> the conditions where it is acceptable that the token is different
> from the one in the request with the last received payload? (note:
> several occurrences)
> 

[Med] We do already have this text to explain the rationale for SHOULD:   

   "Note that the use of any received token with the same
   Request-Tag would work, but providing the one used in the last
   received payload will aid any troubleshooting.  The client will use
   the token to determine what was the previously sent request to obtain
   the Request-Tag value to be used."

The same applies for the other occurrences you pointer to. 

> [FP]: Same remark as previous comment - please motivate why this is
> SHOULD and is not MUST. When using SHOULD, guidance should be given
> to implementers about in which case it is ok to deviate from the
> recommendations.

[Med] The text does not use "MUST NOT" for the first part of the text you quoted because there might be situations where MAX_PAYLOADS is set to 1. This is discussed in in 6.2:

   are no other network issues over that period, then the value of
   MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1)

The second SHOULD is not a MUST because sending a "continue" signal is an optimization and that the peer endpoint will send the next set of blocks after a timer is reached. This is discussed in 6.2:

   For the server receiving NON Q-Block1 requests, it SHOULD send back a
   2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
   payloads to prevent the client unnecessarily delaying.  Otherwise the
   server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled
   based on the repeat request count for a payload), before sending the
   4.08 (Request Entity Incomplete) Response Code for the missing
   payload(s).

> [FP]: Same remark for the use of SHOULD. (I stopped nothing this down
> at this point in the review, but noted this in the general comments
> above)

[Med] Point taken. Will double check and tweak the text as appropriate. 

> [FP]: "this and missing blocks" is unclear to me. Could you clarify?

[Med] We meant **this block and later blocks from** the current set. This is discussed in the first part of 3.4. 

Reworded as it seems this is confusing for you. 

> be in order (increasing block number)?

[Med] This is a way to force the client to check for duplicates and remove them. This also helps with troubleshooting.

> [FP]: I suspect that this means that the first response (containing
> the first block) is piggybacked on an ACK, see 5.2.1 of RFC 7252.
> That is though not always the case, see 5.2.2. I think this option of
> piggybacked should be kept, but from the text it sounds like it is
> the only option, so I believe some rephrasing to clarify that might
> be necessary.
> 

[Med] Changed to: "Typically, the server acknowledges ..."

> [FP]: Why not replace the should (resp should not) with MUST (resp

[Med] We used to have "MUST NOT" but removed it to address this valid comment received during the WGLC:

==
* "The ETag Option MUST NOT be used": This is more a factural than a
  normative statement; it *can* not be used there as the server would
  respond thusly. It may be used, but then that indicates that the
  client is trying to verify a freshness. (However, the client should
  not *start* sending an ETag once it learned the current resource's
  ETag when still attempting to pull out more blocks, but that's also not
  a normative requirement but a consequence of those two requests not
  being matchable any more.)
==

> unsigned integers [RFC8949]."

[Med] OK. 

> [FP]: I think that "drop" here might be confusing, since the client
> is not dropping a packet - suggestion to change to "ignore".
> 

[Med] Fixed, thanks. 

>       missing-blocks+cbor-seq" (Section 11.3) is handled as in

[Med] That text is a reminder of the base 4.08 behavior that we are updating in this spec.  

> [FP]: Suggestion to rephrase "would work" to "would allow to identify
> the correct body" (or something similar).
> 

[Med] Changed to "would be acceptable".

> [FP]: Just another check: is it specified anywhere that reception of
> an error response does not mean the client should stop sending
> requests when Q-Block options are used? If not, it would be good to
> explicitly state that.
> 

[Med] There is text in 3.3 to indicate the behavior when a given error is received. We updated 4.08 text with this NEW sentence: 

"Such message must not treated by the client as a fatal error."  

> [FP]: Same question: why does order matter?

[Med] Same answer as above: ease troubleshooting and have a way to force the server to detect/remove duplicates. 

> [FP]: This seems to imply that tokens are always 8 bytes, which is
> not necessarily the case. I suggest to add "in the case the token is
> 8 bytes".
> 

[Med] OK. Update the text to mention that the use of 8-byte tokens allows to minimize the number of tokens to be tracked by clients.  

> [FP]: "it is expected ... Non-confirmable" Where does this come from?
> Maybe I misunderstand this sentence, could you please expand?
> 

[Med] This is actually referring to the applicability scope of the document, especially this part:
    
   The mechanism specified in this document provides
   roughly similar features to the Block1/Block2 Options.  It provides
   additional properties that are tailored towards the intended use case
   of Non-Confirmable transmission.  Concretely, this mechanism
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   primarily targets applications such as DDoS Open Threat Signaling
   (DOTS) that cannot use CON responses to handle potential packet loss^
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
   and that support application-specific mechanisms to assess whether
   the remote peer is able to handle the messages sent by a CoAP
   endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]).

Added a pointer to that section. 

> - 8" (and same for examples below)

[Med] I prefer the current one where we count payloads from 1, not from 0. Of course, payload 1 corresponds to the one with block num=0. 

> [FP]: I am not sure this is already stated somewhere, and if so
> please ignore this comment, but there should be some considerations
> about NON_RECEIVE_TIMEOUT in comparison to the client's CoAP timer to
> deal with the response: what I am thinking about is the scenario from
> the following example, where the client has for some reason discarded
> the token 0xef (for example to free up space) and is unable to
> process the 4.08 response from the server correctly, since it doesn't
> know with which request it associates with. What happens then? I
> assume the server should try again and then eventually stop and
> release the partial body. Is this described?

[Med] If the token is unknown for whatever reason, then the client should be sending a RST for the unknown token. We have the following:

   If the client elects to stop the transmission of a complete body, it
   SHOULD "forget" all tracked tokens associated with the body's
   Request-Tag so that a reset message is generated for the invalid
   token in the 4.08 (Request Entity Incomplete) response.  The server
   on receipt of the reset message SHOULD delete the partial body.

RFC7252, Section 5.3.2 says:

   In case a message carrying a response is unexpected (the client is
   not waiting for a response from the identified endpoint, at the
   endpoint addressed, and/or with the given token), the response is
   rejected (Sections 4.2 and 4.3).

> [FP]: This is inconsistent and should be either 3 - 9 or 2 - 8 as

[Med] Why? 

Payload 9 is indicated in the example:

            +--------->| [[Payloads 3 - 8 not detailed]]
            +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024

> -----
> 
> 32.
> [FP]: Figure 16: I am not sure how the server knows which block the
> client is requesting when it sends the following message:
> 

[Med] It is only asking for Block 1.

> [FP]: In fact, if I understand correctly this could either be a
> request for the missing block from the second set of blocks,

[Med] ... which would be QB2:10/0/1024 or anything up to QB2:9/0/1024 for a missing block in the second MAX_PAYLOADS set. 

 or the
> client could have not received block 1 from the previous set of
> blocks and could be requesting the same as in:
> 
> [FP]: If all the following responses from the server would have been
> lost. The two requests contain the same RT. What am I missing?

[Med] Each client request needs to have an unique Token, hence the increment to T:0xc8.

_________________________________________________________________________________________________________________________

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: Francesca Palombini <[email-masked]>
Date: Wed, 14 Apr 2021 12:57:59 +0000

Hi Jon, Med!

Thank you for answering my questions and addressing my comments.

I will start IETF Last Call while we finish talking over the couple of issues left (which are minor, see inline). Feel free to post an update to the document, either right now or as soon as we are done with my review.

Thanks,
Francesca

On 06/04/2021, 17:02, "[email-masked]" <[email-masked]> wrote:
>Changes can be tracked at: https://protect2.fireeye.com/v1/url?k=48d42782-174f1e80-48d46719-869a14f4b08c-cb0b0b2867ee4cc6&q=1&e=f6649557-ada9-4d88-ab0a-b8a1509d8016&u=https%3A%2F%2Ftinyurl.com%2Fnew-block-latest.
>

FP: Yes, they are defined, but I still have a problem with how they are used, in particular as a synonym to "CoAP request". One example in the comment below.

>[Med] Will double check. Thanks.

FP: Thank you! (FYI, this comes up a lot during IESG evaluation, so better to address it now!)

   >flooded pipe DDoS situation.

FP: This is more of an editorial clarification: I was looking for a more explicit statement about Q-Block1 and Q-Block2 having higher transmission rates; how the bullet point is stated "they can operate" does not explain why they are a good fit for cases where packet loss is asymmetrical (and to be nit-picking, Block1 and Block2 strictly speaking can also be used, but probably with worse results, which is what should be highlighted here).

      >(Section 4.7 of [RFC7252]).

FP: My mistake, I took the referenece as a pointer to the other parameters, didn't check for NSTART. That's good enough.

>[Med] Added a pointer to Section 3.1.

FP: Thanks.

>> [FP]: No-Response Option needs a reference.

FP: Thanks.

>[Med] Fair comment. Rearranged the text.

FP: Looks good.

>We can add a "when present" if you think this is more accurate.

FP: It can't hurt to be explicit, IMO.

>[Med] We meant similar requests that are used to retrieve the representation of a resource. We have FETCH in mind but we also wanted a text that is future proof if such similar requests are defined…

FP: I see - then I would suggest adding "such as FETCH, for example", which gives the reader the intuition of what a "similar request" is without over specifying.

>[Med] This can be driven by a local configuration knob, triggered by an application (DOTS, for example), etc. How this is done, is out of the scope of the spec.

FP: Makes sense. Could you add this sentence to the document for clarification?

>[Med] Good catch. Added a sentence to indicate that 4.02 (Bad Option) is used in such case.

FP: Ok, thanks.

>[Med] After reading this, we agree the sentence is confusing. We meant that it is ALSO a required information to identify a missing block. That identification requires additional information (block…

FP: I concur, OK with deleting.

   >in a block-wise fashion."

FP: This is where we disagree - a payload is a payload of a single CoAP message, as you state above. A payload "of a body" does not make sense; "a block of a body" would make sense. What I am getting at is that a body is not made of payloads, they are 2 parallel concepts. This is really minor clarification, and will let it go if the wg does not think it's important, but I believe it's important to use the correct terminology and hope I explained my problem here.

>" "payload" is thus used for the content of a single CoAP message"

FP: right, payload is used for the content, i.e. the resource representation (and when the block options are used, a block of the resource representation), not the whole CoAP request, which includes the payload but also CoAP code, options etc. This is again a simple terminology issue.

>We don't think it is worth to restate it for each code, though.

FP: Looks good to me.

>The same applies for the other occurrences you pointer to.

FP: I think that in this case, since it is not strictly necessary for interoperability that the token used is the one from the last received request, BCP 14 SHOULD is maybe not the correct term. This could be instead rephrased with something on the sort of: "The token used MUST be one received from a request using the same Request-Tag. However, it is desirable to provide the one used in the last received request, since that will aid any troubleshooting."

   >MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1)

FP: Ok, thanks for clarifying, can we move/add the reference to 6.2 here?

   >4.08 (Request Entity Incomplete) Response Code for the missing

FP: Thanks for clarifying. I would clarify that this reference is where motivation is given, but I'll leave that up to you.

>[Med] Point taken. Will double check and tweak the text as appropriate.

FP: Thank you. As a pointer, please remember how SHOULD is defined:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

And that it is not the same as "it would be best, but if you can't oh well". If that is the meaning you want to give to it, then BCP 14 is probably not the right term.

>Reworded as it seems this is confusing for you.

FP: Thanks, yes it's clearer.

>[Med] This is a way to force the client to check for duplicates and remove them. This also helps with troubleshooting.

FP: I see. Could this clarification be added here?

>[Med] Changed to: "Typically, the server acknowledges ..."

FP: Thanks.

  >being matchable any more.)

FP: I see, thanks for clarifying. I think I was considering if this should be BCP 14 statement and you explained to me why it isn't. I think that without the context you just explained to me this might come up again in IESG evaluation.. but I am fine with it.

>> unsigned integers [RFC8949]."

FP: Thanks.

>> is not dropping a packet - suggestion to change to "ignore".

FP: Ack.

>[Med] That text is a reminder of the base 4.08 behavior that we are updating in this spec.  

FP: Ah, thanks for clarifying, yes it makes sense.

>[Med] Changed to "would be acceptable".

FP: Looks good.

>"Such message must not treated by the client as a fatal error."  

FP: Great, thank you.

>[Med] Same answer as above: ease troubleshooting and have a way to force the server to detect/remove duplicates.

FP: This could point to the previous section where this will be (hopefully) clarified.

>[Med] OK. Update the text to mention that the use of 8-byte tokens allows to minimize the number of tokens to be tracked by clients.  

FP: Great, thanks.

   >of Non-Confirmable transmission.  Concretely, this mechanism

FP: I knew I missed something... thank you for adding the pointer.

>[Med] I prefer the current one where we count payloads from 1, not from 0. Of course, payload 1 corresponds to the one with block num=0.

FP: Ok, as you prefer.

   >rejected (Sections 4.2 and 4.3).

FP: right. I think what I was missing while reading the paragraph above is "stop the transmission of a complete body _by the server_" as the first time I read this I assumed it wanted to stop transmission from itself (which with the following sentences made little sense, I agree).

            >+--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024

FP: Sorry, hard to understand which one I was referring to without the context :) I meant this one: 

          |     X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
          |<---------+ [[Payloads 3 - 8 not detailed]]
          |     X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024

I think this should be 3 - 9 if you keep the current notattion

>[Med] Each client request needs to have an unique Token, hence the increment to T:0xc8.

FP: Right, thanks for clarifying.

---

From: <[email-masked]>
Date: Wed, 14 Apr 2021 14:43:10 +0000

Hi Fransasca, 

Thank you for the follow-up. 

The full changes can be tracked at: https://tinyurl.com/new-block-latest. 

Please see inline. 

Cheers,
Med

> De : Francesca Palombini [mailto:[email-masked]]
> Envoyé : mercredi 14 avril 2021 14:58
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked]
> Objet : Re: AD review of draft-ietf-core-new-block-09
> 
> Hi Jon, Med!
> 
> I will start IETF Last Call while we finish talking over the couple
> of issues left (which are minor, see inline). Feel free to post an
> update to the document, either right now or as soon as we are done
> with my review.
> 
> Thanks,
> Francesca
> 
[..]
> FP: Yes, they are defined, but I still have a problem with how they
> are used, in particular as a synonym to "CoAP request". One example
> in the comment below.
> 

[Med] Changed to avoid this confusion. "payload of block" and similar are not anymore used. 

> FP: This is more of an editorial clarification: I was looking for a
> more explicit statement about Q-Block1 and Q-Block2 having higher
> transmission rates; how the bullet point is stated "they can operate"
> does not explain why they are a good fit for cases where packet loss
> is asymmetrical (and to be nit-picking, Block1 and Block2 strictly
> speaking can also be used, but probably with worse results, which is
> what should be highlighted here).

[Med] This is what is supposed to be covered by the second bullet:

"They enable faster transmissions of sets of blocks of data with less packet interchanges."

> FP: It can't hurt to be explicit, IMO.

[Med] Fixed. Thanks.

> >[Med] We meant similar requests that are used to retrieve the
> representation of a resource. We have FETCH in mind but we also
> wanted a text that is future proof if such similar requests are
> defined in the future.
> 
> FP: I see - then I would suggest adding "such as FETCH, for example",
> which gives the reader the intuition of what a "similar request" is
> without over specifying.
> 

[Med] Good suggestion. Done. 

> >[Med] This can be driven by a local configuration knob, triggered by
> an application (DOTS, for example), etc. How this is done, is out of
> the scope of the spec.
> 

[Med] Happily. 

> FP: right, payload is used for the content, i.e. the resource
> representation (and when the block options are used, a block of the
> resource representation), not the whole CoAP request, which includes
> the payload but also CoAP code, options etc. This is again a simple
> terminology issue.
> 

[Med] Thank you for clarifying. Tweaked the text accordingly. Hope this is better.

> FP: I think that in this case, since it is not strictly necessary for
> interoperability that the token used is the one from the last
> received request, BCP 14 SHOULD is maybe not the correct term. This
> could be instead rephrased with something on the sort of: "The token
> used MUST be one received from a request using the same Request-Tag.
> However, it is desirable to provide the one used in the last received
> request, since that will aid any troubleshooting."

[Med] Fair point. Updated accordingly. 

> >>       generated when all the payload requests are Non-confirmable
> and
> >> a
> >>       set of MAX_PAYLOADS (Section 6.2) payloads have been
> received
> >> by
> >>       the server.
> >>
> >[Med] The text does not use "MUST NOT" for the first part of the
> text you quoted because there might be situations where MAX_PAYLOADS
> is set to 1. This is discussed in in 6.2:
> >

[Med] Done. Thanks. 

> >The second SHOULD is not a MUST because sending a "continue" signal
> is an optimization and that the peer endpoint will send the next set
> of blocks after a timer is reached. This is discussed in 6.2:
> >
> FP: Thanks for clarifying. I would clarify that this reference is
> where motivation is given, but I'll leave that up to you.
> 

[Med] Sure. Fixed. 

> >> [FP]: What is the reason for mandating that the blocks requested
> must
> >> be in order (increasing block number)?
> >>
> >
> >[Med] This is a way to force the client to check for duplicates and
> remove them. This also helps with troubleshooting.
> 

[Med] Done.

> >[Med] Same answer as above: ease troubleshooting and have a way to
> force the server to detect/remove duplicates.
> >
> 

[Med] ACK

> >> [FP]: Minor: I think it would make more sense to change "3 - 9" to
> "2
> >> - 8" (and same for examples below)
> >>
> >
> >[Med] I prefer the current one where we count payloads from 1, not
> from 0. Of course, payload 1 corresponds to the one with block num=0.
> >
> 
> FP: Ok, as you prefer.

[Med] Added new text to explain that payload N corresponds to block N-1 :-)

> I think this should be 3 - 9 if you keep the current notation

[Med] I confirm.

---

From: Francesca Palombini <[email-masked]>
Date: Wed, 14 Apr 2021 15:17:10 +0000

Thank you Med, I am happy with these changes. Please go ahead and submit a new version as soon as it's convenient, so the IETF Last Call can be started on the latest submission.

Thanks,
Francesca

On 14/04/2021, 16:43, "[email-masked]" <[email-masked]> wrote:

    Hi Fransasca, 

    The full changes can be tracked at: https://protect2.fireeye.com/v1/url?k=de93dc53-8108e562-de939cc8-86e2237f51fb-d7197ab415270d2d&q=1&e=958e3c0c-5c01-41e7-af80-9875c6952729&u=https%3A%2F%2Ftinyurl.com%2Fnew-block-latest. 

    Please see inline. 

    Cheers,
    Med

    [..]

    [Med] Fixed. Thanks.

    [Med] Happily. 

    [Med] Done. Thanks. 

    [Med] Sure. Fixed. 

    [Med] Done.

    [Med] ACK

    [Med] I confirm.