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

[Christian Amsüss <[e-mail]>]

Hello Jon, hello CoRE

On Mon, Dec 20, 2021 at 07:22:28PM -0000, Jon Shallow wrote:
> Thanks for this.  I will go ahead using the Request-Tag in the request
> in the potential case there is a response requiring Block2.

I've asked that this be altered in the currently open AUTH48 process;
quoting:

> I support that change. The concrete text change I suggest is:
> 
> OLD:
> Note that Request-Tag options can be present in request messages that
> carry no Block options (for example, because a proxy unaware of
> Request-Tag reassembled them) and MUST be ignored in those.
> 
> NEW:
> Note that Request-Tag options can be present in request messages that
> carry no Block options (for example, because a proxy unaware of
> Request-Tag reassembled them). Clients may set them for purposes not
> further discussed in this document.
> 
> (The "MUST" was also slightly inexact; the server would still have used
> them as part of the block-wise key in any later Block2 phase, but it
> must not do anything more with it, as 3.3 already describes).
> 
> OLD:
> The Request-Tag option is only used in requests that carry the Block1
> option and in Block2 requests following these.
> 
> NEW:
> The Request-Tag option is mainly used in requests that carry the Block1
> option and in Block2 requests following these.
> 
> (The reader might follow with a thought like "although it may later turn
> out that the operation was not as block-wise as the client had
> anticipated", or even "and if it's only to disambiguate with a request
> that is still ongoing and known to be block-wise", but that does not
> need to be put in the document IMO).

Thanks for pointing this out, it's a valuable change for a use case I
did not consider.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom