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

mohamed.boucadair@orange.com Wed, 07 April 2021 05:44 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DC03A4097; Tue, 6 Apr 2021 22:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Level:
X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MHodPvHwOwQ; Tue, 6 Apr 2021 22:44:08 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89F43A4095; Tue, 6 Apr 2021 22:44:04 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4FFYH63hXsz5vlG; Wed, 7 Apr 2021 07:44:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1617774242; bh=SB45M+dy9Fj2741i+HxLN3WpQKAqOKUDuWq2eH0YGWo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=EVCsDOc7G09umuP+bJORDi4ANLdcBicJoNwA+gCN/AF/qNKk6SeoXoM3/YEKduWIw 3YrkGmE9KhgkgUf48CgZ68/76XsP/Ebt3A0+HUf2qQwlOnxzfp79zAIHl8SNQMi2eu 6fZTUDQQMLzGA35e93i5HP2M5mz+7zgwA5tQgvCllhWo+Q9YMENAjL2oK+j5xcXIwf L1JSWYkjyqf1ZO0sbnKEfjrfx3KNEFlgAbZH1ahHPVbdy1pGpGgEaOGSM3zCMUaelm 70ED/hECx+eObYhvYWCxyZdEV44OkUpJu+xQWrFKvJOMX9nTaXk/wawtGgvmrVlC6z uIIdnmnmp2hAQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4FFYH62jpKzCqk2; Wed, 7 Apr 2021 07:44:02 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: =?iso-8859-1?Q?Christian_Ams=FCss?= <christian@amsuess.com>
CC: "draft-bosh-core-new-block@ietf.org" <draft-bosh-core-new-block@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: draft-ietf-core-echo-request-tag (was RE: Request-Tag and Block ID)
Thread-Index: AdcrcQDYticQVE/tSK+k69ej3P1F3w==
Date: Wed, 7 Apr 2021 05:44:00 +0000
Message-ID: <17244_1617774242_606D46A2_17244_465_1_787AE7BB302AE849A7480A190F8B933035364E5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/t9i6VljzzfwgFum0b1VkoEFxil0>
Subject: [core] draft-ietf-core-echo-request-tag (was RE: Request-Tag and Block ID)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 05:44:13 -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:christian@amsuess.com]
> Envoyé : jeudi 11 juin 2020 13:46
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : draft-bosh-core-new-block@ietf.org; core@ietf.org
> Objet : Re: Request-Tag and Block ID
> 
> Hello Med,
> 
> On Thu, Jun 11, 2020 at 11:20:30AM +0000,
> mohamed.boucadair@orange.com 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.