Subject: [core] draft-ietf-core-echo-request-tag (was RE: Request-Tag and Block ID)

From: <[email-masked]>
Date: Wed, 7 Apr 2021 05:44:00 +0000

Hi Christian,

It seems this one was missed when revising draft-ietf-core-echo-request-tag.

Can you please fix the text discussed in this thread? Thanks.   

Cheers,
Med

> -----Message d'origine-----
> De : Christian Amsüss [mailto:[email-masked]]
> Envoyé : jeudi 11 juin 2020 13:46
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked]
> Objet : Re: Request-Tag and Block ID
> 
> Hello Med,
> 
> On Thu, Jun 11, 2020 at 11:20:30AM +0000,
> [email-masked] wrote:
> > I would relax those statements. For example, can you please
> consider updating statements such as this one:
> >
> >    "The Request-Tag option is only used in requests that
> >
> >                               ^^^^
> >    carry the Block1 option, and in Block2 requests following
> these."
> >
> > to cover block options as those defined in draft-bosh-core-new-
> block.
> 
> While the original understanding of Request-Tag was that it'd only be
> necessary where Block1 (or Block3) mode is involved, yesterday's
> examples show a use case outside as well.
> 
> The above is not normative text -- you'll note that there is barely
> any at all, for all the option's mechanism already follows from being
> NoCacheKey. There is normative text for that very case, though it
> might be problematic ("MAY be present in request messages that carry
> no Block option[...], and MUST be ignored in those.")
> 
> I think it would be topically suitable to relax things a bit here to
> ensure applicability with a future Blockwise mechanism.
> 
> Procedurally, as this is post WGLC (but waiting for an updated
> version for the writeup), I think I can pull those in (together with
> other comments received during and after the WGLC), but will need to
> accompany those changes with an explicit mail to the WG informing
> everyone of those with detail and rationale.
> 
> > You may also update the terminology section to define block-wise in
> a
> > more generic manner.
> 
> As an immediate reaction I'm tempted to call those users of Request-
> Tag "block-wise transfer or other applications that associate
> requests by their cache key where such an association is broken
> deliberately by the client". I'll see whether that fits with the rest
> of the text, but don't think there's trouble if it does not: For with
> Request-Tag preceding Block34, the latter can just state that in
> interaction with Request-Tag,
> Block34 are treated like Block12.
> 
> Kind regards
> Christian
> 
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom

_________________________________________________________________________________________________________________________

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.