Re: [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: 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 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, 9 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/core/L4bMJ6JMIR4LJiUWllWW2iQfGiM>
Subject: Re: [core] [Technical Errata Reported] RFC7252 (5284)
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: 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