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

[Carsten Bormann <[e-mail]>]

Hi Jon,

thank you for bringing this up.

> On 2021-12-20, at 17:29, [e-mail] 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)
> 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).

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

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.
>  
> 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?),

“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