Subject: [core] draft-ietf-core-echo-request-tag -14 and Block2

From: <[email-masked]>
Date: Mon, 20 Dec 2021 16:29:40 -0000

Hi there,

I have run into an issue where multiple CoAP requests (not needing Block1)
to the same resource trigger potentially different responses that require
the use of Block2. If the responses overlap, then there is confusion as to
how to pull back the correct response to match the request.  For example
(grossly simplifying things)

POST /api/<service>/read   payload = { 'offset': 0, 'count': 1200 }

POST /api/<service>/read   payload = { 'offset': 2000, 'count': 1300 }
Or

FETCH /api/<service>/read   payload = { 'offset': 0, 'count': 1200 }

FETCH /api/<service>/read   payload = { 'offset': 2000, 'count': 1300 }

RFC7959 2.4 rightly states

   The Block2 Option provides no way for a single endpoint to perform

   multiple concurrently proceeding block-wise response payload transfer

   (e.g., GET) operations to the same resource.  This is rarely a

   requirement, but as a workaround, a client may vary the cache key

   (e.g., by using one of several URIs accessing resources with the same

   semantics, or by varying a proxy-safe elective option).

Which then brings in the possible use of Request-Tag option in the request
as a proxy-safe elective option. However.

draft-ietf-core-echo-request-tag -14 3.2 states

   The Request-Tag option is only used in requests that

   carry the Block1 option, and in Block2 requests following these.

Which implies that the examples above need to contain the Block1 option in
the first instance if there is any suspicion that Block2 is needed in the
response.

Then draft-ietf-core-echo-request-tag -14 3.4 states

   Note that Request-Tag options can be present in request messages that

   carry no Block option (for example, because a Request-Tag unaware

   proxy reassembled them), and MUST be ignored in those.

Apart from being hard to parse (what does "those" refer to?), this tells me
that Servers MUST ignore requests that have no Block option - so, I cannot
just add the Request-tag option to a request on the off-chance there may be
a Block2 needed response.

Is there a good reason for this MUST?

If it is too late for the draft to be updated, the only easy way forward
that I can see is to add in an unneeded Block1 to the request, or to add in
a Block2 option to the request so the Request-Tag can be used even if the
response fits into a single payload.

I have raised this as Issue #77
https://github.com/core-wg/echo-request-tag/issues/77 .

Regards

Jon

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Dec 2021 18:39:19 +0100

Hi Jon,

thank you for bringing this up.

> On 2021-12-20, at 17:29, [email-masked] wrote:
> 
> Hi there,
>  
> I have run into an issue where multiple CoAP requests (not needing Block1) to the same resource trigger potentially different responses that require the use of Block2. If the responses overlap, then there is confusion as to how to pull back the correct response to match the request.  For example (grossly simplifying things)

… and note that Request-Tag says:

3.2.1.  Request-Tag Option Format

   The Request-Tag option is not critical, is safe to forward,
   repeatable, and part of the cache key, see Figure 4, which extends
   Table 4 of [RFC7252]).

(No idea why “elective” is spelled “not critical”, but the point is that the option can be used to distinguish multiple ongoing sequences of requests, as is spelled out at the end of 3.2:

   In essence, it is an implementation of the "proxy-safe elective
   option" used just to "vary the cache key" as suggested in [RFC7959]
   Section 2.4.

)

> Which then brings in the possible use of Request-Tag option in the request as a proxy-safe elective option. However.

This is indeed weird, in particular since 3.2.1 then has the correct sentence:

   The Request-Tag option is only used in the request messages of block-
   wise operations.
 
> Which implies that the examples above need to contain the Block1 option in the first instance if there is any suspicion that Block2 is needed in the response.
>  
> Apart from being hard to parse (what does “those” refer to?),

“Those” = “request messages that carry no Block Option”.

> this tells me that Servers MUST ignore requests that have no Block option

No, that is definitely not what it says — it says the *option* is ignored in non-Block requests, not the entire request, and the context makes clear that what is meant is that the recipient MUST NOT throw an error just because the option is there.
The wording “MUST be ignored” is unfortunate, because they are still part of the cache key.

> – so, I cannot just add the Request-tag option to a request on the off-chance there may be a Block2 needed response.

You can (at least that is the intent).

The “Changes” have this snippet:

      -  Lift ban on Request-Tag options without Block1 (as they can
         legitimately be generated by an unaware proxy)

…which is confusing to me, but also see

https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-09.txt
 
> Is there a good reason for this MUST?

Your different reading demonstrates that we need to align the phrasing better with the intent.

This can be done in AUTH48, if the AD agrees.

Grüße, Carsten

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 20 Dec 2021 19:22:28 -0000

Hi Carsten,

Thanks for this.  I will go ahead using the Request-Tag in the request in the potential case there is a response requiring Block2.

Regards

Jon

> -----Original Message-----
> From: Carsten Bormann [mailto: [email-masked]]
> Sent: 20 December 2021 17:39
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [core] draft-ietf-core-echo-request-tag -14 and Block2
> 
> Hi Jon,
> 
.....