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

From: Christian Amsüss <[email-masked]>
Date: Mon, 31 Jan 2022 18:00:30 +0100

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

---

From: <[email-masked]>
Date: Mon, 31 Jan 2022 17:09:39 -0000

Hi Christian,

Thanks for doing this.  The proposed changes work for me.

Regards

Jon

> -----Original Message-----
> From: Christian Amsüss [mailto: [email-masked]]
> Sent: 31 January 2022 17:01
> To: Jon Shallow
> Cc: 'Carsten Bormann'; [email-masked]
> Subject: Re: [core] draft-ietf-core-echo-request-tag -14 and Block2
> 
> Hello Jon, hello CoRE
> 
> > (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 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
> Thanks for pointing this out, it's a valuable change for a use case I did
not
> consider.