Re: [Dots] [core] [Technical Errata Reported] RFC7252 (5284)
mohamed.boucadair@orange.com Thu, 09 April 2020 13:42 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAE63A0B58; Thu, 9 Apr 2020 06:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, 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 t2On1DXXx2Mt; Thu, 9 Apr 2020 06:42:14 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899293A0B67; Thu, 9 Apr 2020 06:42:10 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48yj4J6tQlz2xlx; Thu, 9 Apr 2020 15:42:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586439729; bh=BHrrI1P+TbqUHebKS5HgC37l4U7HwPJuvOE5yWznXfY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=t5HFa7v0ZKVmsCcQQ7kTOu8tef4uJJcE5llh92sYgXDyNDh9LI+miDW8UdWbCsHA3 +CoWN/ao+q2rvcjihnTR6fOZBT02b6pLf5B6xZ+BF61LwNtOWOQXOqnP3nWf5VbBRT qQYy/u+7Sx/ezMNMz2TQI+/xyHOPLUqHC7rVaOREHdFlc3uGUgcAyQdfqKepUlBAig MG05TsAXNwzsPuQOI+tUWvH+/Cw8yzBkqKDnVH9eBQXx+j7WsnkD5HaMh66mg2ph0B GXkva1na1ASuc1udQzvSXELc7xumcL7glZi/3dtRugXlBRMO1FRRdO2iLRD7dH6JvB rBq/VBqBSEi+g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48yj4J5v0Sz1xpv; Thu, 9 Apr 2020 15:42:08 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: "core@ietf.org" <core@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [core] [Technical Errata Reported] RFC7252 (5284)
Thread-Index: AQHTt4ndJXGy2My7rUmHIFbO9dEyFKPPl8uAhKXgpcA=
Date: Thu, 09 Apr 2020 13:42:07 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303149256F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <20180309093425.91095B81706@rfc-editor.org> <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com>
In-Reply-To: <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com>
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/dots/Omum_pyMYJf04XQQ1t7IbBAfMYA>
Subject: Re: [Dots] [core] [Technical Errata Reported] RFC7252 (5284)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 13:42:20 -0000
Hi all, I lost the context about the resolution for this errata. Any update on this one? Thank you. Cheers, Med > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of RFC Errata > System > Sent: Freitag, 9. März 2018 10:34 > To: zach.shelby@arm.com; hartke@tzi.org; cabo@tzi.org; > ben@nostrum.com; aamelnikov@fastmail.fm; adam@nostrum.com; > cabo@tzi.org; jaime@iki.fi > Cc: mohamed.boucadair@orange.com; core@ietf.org; rfc-editor@rfc- > editor.org > Subject: [core] [Technical Errata Reported] RFC7252 (5284) > > The following errata report has been submitted for RFC7252, "The > Constrained Application Protocol (CoAP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5284 > > -------------------------------------- > Type: Technical > Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com> > > Section: 5.3.1 > > Original Text > ------------- > The client SHOULD generate tokens in such a way that tokens currently > in use for a given source/destination endpoint pair are unique. > > Corrected Text > -------------- > The client SHOULD generate tokens in such a way that tokens currently > in use for a given source/destination endpoint pair are unique per > request. > > Notes > ----- > Multiple requests may be active for a given source/destination > endpoint pair. The OLD text is thus broken. > > The NEW text is aligned with the definition of the Token: > > A token is intended for use as a client-local identifier for > differentiating between concurrent requests (see Section 5.3); it > could have been called a "request ID". > > Further, using the same token for a given source/destination endpoint > pair have some implications, for example, for applications which > require the support of multiple observe queries because RFC7641 states > the following: > > The entry in the list of observers is keyed by the client endpoint > and the token specified by the client in the request. If an entry > with a matching endpoint/token pair is already present in the list > (which, for example, happens when the client wishes to reinforce > its interest in a resource), the server MUST NOT add a new entry > but MUST replace or update the existing one. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or rejected. > When a decision is reached, the verifying party can log in to change > the status and edit the report, if necessary. > > -------------------------------------- > RFC7252 (draft-ietf-core-coap-18) > -------------------------------------- > Title : The Constrained Application Protocol (CoAP) > Publication Date : June 2014 > Author(s) : Z. Shelby, K. Hartke, C. Bormann > Category : PROPOSED STANDARD > Source : Constrained RESTful Environments APP > Area : Applications > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core
- Re: [Dots] [core] [Technical Errata Reported] RFC… mohamed.boucadair