IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Wed, 23 November 2022 16:31 UTC

Return-Path: <cabo@tzi.org>
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 079A6C14CE44 for <core@ietfa.amsl.com>; Wed, 23 Nov 2022 08:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH0o32eenT-Y for <core@ietfa.amsl.com>; Wed, 23 Nov 2022 08:31:18 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632DAC1522AF for <core@ietf.org>; Wed, 23 Nov 2022 08:31:15 -0800 (PST)
Received: from client-0188.vpn.uni-bremen.de (client-0188.vpn.uni-bremen.de [134.102.107.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4NHRTC30fbzDCbK; Wed, 23 Nov 2022 17:31:11 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20180718144754.8CFA2B810BB@rfc-editor.org>
Date: Wed, 23 Nov 2022 17:31:11 +0100
Cc: Zach Shelby <zach.shelby@arm.com>, hartke@tzi.org, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, jaime.jimenez@ericsson.com, marian.buschsieweke@ovgu.de, core@ietf.org
X-Mao-Original-Outgoing-Id: 690913870.780624-d42406518072fb8ca8e77c13c14d4d03
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA7560FC-255D-4CE0-BEB5-2741887EBA40@tzi.org>
References: <20180718144754.8CFA2B810BB@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/xNnPJKCQJnFDj64H13d_AljuB50>
Subject: Re: [core] [Technical Errata Reported] RFC7252 (5429)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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, 23 Nov 2022 16:31:21 -0000

We picked up this errata report in the CoRE interim meeting today.

Main content, with some typos corrected:
> […]
> Corrected Text
> --------------
> An Acknowledgement or Reset message is related to a Confirmable
> message or Non-confirmable message by means of a Message ID along
> with additional address information of the corresponding endpoint.
> The Message ID is a 16-bit unsigned integer that is generated by the
> sender of a Confirmable or Non-confirmable message and included in
> the CoAP header.  Message IDs of subsequent messages sent to the
> same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending
> (wrapping around at a value of 65535).  Additionally, two
> subsequently send Message IDs to the same endpoint SHOULD have a
> difference of at most 16.  
[…]

This is clearly a new technical proposal, which is different from what the WG intended.
So it does not make good errata material.

Note that there is extensive discussion of CoAP message ID usage in
draft-ietf-lwig-coap, see:
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-coap-06#section-2.3
and in particular
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-coap-06#section-3.5

While draft-ietf-lwig-coap is not currently moving forward in the LWIG WG, some of its content might make a good fit to the clarifications part of the corr-clar document, which the CoRE WG might want to reinvigorate:
https://datatracker.ietf.org/doc/draft-bormann-core-corr-clar/

This (or an LWIG-coap actually taken to completion) then might provide a space to further discuss the technical proposal buried in this errata report.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email