Re: [core] [Technical Errata Reported] RFC7252 (5284)

"Kraus Achim (INST/ECS4)" <Achim.Kraus@bosch-si.com> Wed, 14 March 2018 11:58 UTC

Return-Path: <Achim.Kraus@bosch-si.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 8DCD412AF83 for <core@ietfa.amsl.com>; Wed, 14 Mar 2018 04:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.021
X-Spam-Level:
X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 f0VpNuukzM-N for <core@ietfa.amsl.com>; Wed, 14 Mar 2018 04:58:54 -0700 (PDT)
Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EF5127286 for <core@ietf.org>; Wed, 14 Mar 2018 04:58:54 -0700 (PDT)
Received: from fe0vm1649.rbesz01.com (lb41g3-ha-dmz-psi-sl1-mailout.fe.ssn.bosch.com [139.15.230.188]) by si0vms0217.rbdmz01.com (Postfix) with ESMTPS id 401VcX4TBPz4f3kSC; Wed, 14 Mar 2018 12:58:52 +0100 (CET)
Received: from fe0vm1740.rbesz01.com (unknown [10.58.172.176]) by fe0vm1649.rbesz01.com (Postfix) with ESMTPS id 401VcX47mGz20; Wed, 14 Mar 2018 12:58:52 +0100 (CET)
X-AuditID: 0a3aad14-5cfff7000000330d-bd-5aa90e7d3d30
Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm1740.rbesz01.com (SMG Outbound) with SMTP id 57.BA.13069.D7E09AA5; Wed, 14 Mar 2018 12:58:53 +0100 (CET)
Received: from SI-MBX2033.de.bosch.com (si-mbx2033.de.bosch.com [10.3.230.36]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 401VcX2LfPzBctd; Wed, 14 Mar 2018 12:58:52 +0100 (CET)
Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2033.de.bosch.com (10.3.230.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 14 Mar 2018 12:58:52 +0100
Received: from SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c]) by SI-MBX2033.de.bosch.com ([fe80::834:a457:b40f:62c%4]) with mapi id 15.01.1415.002; Wed, 14 Mar 2018 12:58:52 +0100
From: "Kraus Achim (INST/ECS4)" <Achim.Kraus@bosch-si.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "zach.shelby@arm.com" <zach.shelby@arm.com>, "hartke@tzi.org" <hartke@tzi.org>, "cabo@tzi.org" <cabo@tzi.org>, "ben@nostrum.com" <ben@nostrum.com>, "aamelnikov@fastmail.fm" <aamelnikov@fastmail.fm>, "adam@nostrum.com" <adam@nostrum.com>, "cabo@tzi.org" <cabo@tzi.org>, "jaime@iki.fi" <jaime@iki.fi>
CC: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] [Technical Errata Reported] RFC7252 (5284)
Thread-Index: AQHTuwGrQ6udEjsE5EGyRvMUl7bu96PPoTww
Date: Wed, 14 Mar 2018 11:58:51 +0000
Message-ID: <3bf7a04492be4f4c882e344cafd4e188@bosch-si.com>
References: <20180309093425.91095B81706@rfc-editor.org>
In-Reply-To: <20180309093425.91095B81706@rfc-editor.org>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.22.82.203]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wbZRjHee+u7VF75LjC+lAhwzpcogGBzezcFI0m2hij/qExNlncYQ9a oS32Cg6cCaJjwDSZDNhWGT8mqUA62GRl3YCVlemkLE7NxupgZhuMFFjd3IS4CMQrB6N/+M/l eb/P83m+z/u8ORJnpkktabY6eLuVK9TJlYRy69GU9E/jOgyZZ0/Esb47foztXzyiYJurRxTs ubprMvZMuBtne/fPYOxQIJUdCt9SsBW+OTn72+ik4kWl3t3kRvpTgUG5vq3tAaYfmmsl9M5T k4T+i6lhub688keZvuGI+S3SoHzOyBeaS3j70zk7lKaOqV1FdSk7v/bElqNLmhoUSwK9GUYH 9hA1SEky9AEMunpnFdKhD8Hc6L2VQxjBjboAkg79CMY6g4oIL6e3Qm3L0HJVAn0Lgwr3nCyS wGkjDN5oRpFYTefA+Us+LBIn0C9Az92TK3E27B47uFxD0GngHO8mIjFFb4ObNZXLNQy9BWpa j4oGJBlLs/Bt+PWIjOgUOHbsIi5ZaeDqZDMm3YeGtn5JBzoRpieWZFKcCr3thwipPgOC9XVy KX4KXK2zuGQbD8OHJol9SOOMauuMQpxRiDMKaUFEJ0rM4zNLLFlbNmdm2HN5oSwzK+MDm+V7 JD14ghe1j7zjRzSJdCrqcEyHgZFxJUKpxY+eITFdIuWrazcwcbk2Y6mJE0zv24sLeUGnpVBM TAyjfigLxbkWsyCYbVY/AhLXJVCeZJGjjFxpGW+3SZgfPUoSOg31pXGXgaHzOQdfwPNFvH01 u40kdUAtqcQZ4u18Pr8zz1zoWE3rUiTPddGZaFuMjPWjTaRK9K6lxBaUUMRZBHP+Cp4k4cyq uoYG0Jvk/MD1SpwMhmbF7+l9X+3FGcJqs/JaDZUd6UVHKFOx9eE02mRqu8plYBKjEmsdZ1AQ iftUU5sisEr8x9bmAMqrbnyPiV8R16DsNpGha+Pgn9YCaLp/GYH7xG0E7dUeDB7s+QWDqpsh HPyuKwSM/zpPQF/LbhksnJ+XQWjqnBy8wU4F9Ax2KaBvyktC6I+LsdDc2KkC3zdiz9DSDA09 la1quBPwJEDw9lAiHGxwaWD/YhVA/fGfk6DhrlsLx13/amGh589kCF6/vB58Uz+lgmf4Sios dXmfAG+DZ+OMuGNM3LG5N/K+goNz/M+OV9S1y2nLkSM97/NPnj9QPr/I/7Wj+pXxV2caax57 JIx/yMwjx7V4r9r0bllF+KOXTycX3KtvKeCubvx43VnZaDGF3hCMBWkbxt1vf5az/kLoDJ1X 4rEtJd3/2zXxw4TDwj6+NxCzUJ3XPJA2VnWy/vftF6qe7V546TujpWlDPjcyevg1G5s+3VGt IwQTl/Ukbhe4/wARPfp+/AQAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/m1UK0TkYjafOljyH9jOWxRx6yw8>
X-Mailman-Approved-At: Wed, 14 Mar 2018 08:40:58 -0700
Subject: Re: [core] [Technical Errata Reported] RFC7252 (5284)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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, 14 Mar 2018 11:58:57 -0000

Hi,

if the current definition "tokens currently in use" is interpreted as for "all pending requests", I can't see, that adding "per request" improves the RFC. 
If something is added, I would recommend to precise that also with the time-scope, 
e.g. "per simultaneous request".

Mit freundlichen Grüßen / Best regards

 Achim Kraus

(INST/ECS4) 
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

-----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