Re: [core] [Editorial Errata Reported] RFC7959 (6083)

Carsten Bormann <cabo@tzi.org> Thu, 09 April 2020 19:21 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 8BD223A0C81 for <core@ietfa.amsl.com>; Thu, 9 Apr 2020 12:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 X4tBkSy8v1CJ for <core@ietfa.amsl.com>; Thu, 9 Apr 2020 12:21:01 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F993A0C7B for <core@ietf.org>; Thu, 9 Apr 2020 12:21:00 -0700 (PDT)
Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48yrbG612Lzyfp; Thu, 9 Apr 2020 21:20:58 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20200409190011.A6CF2F40738@rfc-editor.org>
Date: Thu, 09 Apr 2020 21:20:58 +0200
Cc: Zach Shelby <zach.shelby@arm.com>, superuser@gmail.com, Barry Leiba <barryleiba@computer.org>, Jaime Jiménez <jaime@iki.fi>, Marco Tiloca <marco.tiloca@ri.se>, mohamed.boucadair@orange.com, core@ietf.org
X-Mao-Original-Outgoing-Id: 608152858.2533441-c1854d4842f218e769f85a4615703ba4
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DAA7A57-2F0D-4386-B3E7-9CDB52ED9C3E@tzi.org>
References: <20200409190011.A6CF2F40738@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/N6cKdvMOgJBQRvA1ezO4CnW7VyY>
Subject: Re: [core] [Editorial Errata Reported] RFC7959 (6083)
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 19:21:05 -0000

Hi Med,

indeed, we should probably align the usage of the tables over the different RFCs in their respective future document updates (currently upper or lower case X or repetition of the column label for yes, minus or space for no).  It should be obvious that minus is another way to say no from RFC 7252, so there is no potential for confusion; the second note therefore is redundant.

My verdict is “hold for document update”.

Grüße, Carsten


> On 2020-04-09, at 21:00, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7959,
> "Block-Wise Transfers in the Constrained Application Protocol (CoAP)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6083
> 
> --------------------------------------
> Type: Editorial
> Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>
> 
> Section: 2.1
> 
> Original Text
> -------------
>       +-----+---+---+---+---+--------+--------+--------+---------+
>       | No. | C | U | N | R | Name   | Format | Length | Default |
>       +-----+---+---+---+---+--------+--------+--------+---------+
>       |  23 | C | U | - | - | Block2 | uint   |    0-3 | (none)  |
>       |     |   |   |   |   |        |        |        |         |
>       |  27 | C | U | - | - | Block1 | uint   |    0-3 | (none)  |
>       +-----+---+---+---+---+--------+--------+--------+---------+
> 
>                       Table 1: Block Option Numbers
> 
> Corrected Text
> --------------
>       +-----+---+---+---+---+--------+--------+--------+---------+
>       | No. | C | U | N | R | Name   | Format | Length | Default |
>       +-----+---+---+---+---+--------+--------+--------+---------+
>       |  23 | x | x | - |   | Block2 | uint   |    0-3 | (none)  |
>       |     |   |   |   |   |        |        |        |         |
>       |  27 | x | x | - |   | Block1 | uint   |    0-3 | (none)  |
>       +-----+---+---+---+---+--------+--------+--------+---------+
> 
>                       Table 1: Block Option Numbers
> 
> Notes
> -----
> * This is to align with the conventions in Section 5.10 of RFC7252
> * These options are not repeatable as per:
> 
> "Either Block option MUST NOT occur more than once in a
>   single message."
> 
> 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. 
> 
> --------------------------------------
> RFC7959 (draft-ietf-core-block-21)
> --------------------------------------
> Title               : Block-Wise Transfers in the Constrained Application Protocol (CoAP)
> Publication Date    : August 2016
> Author(s)           : C. Bormann, Z. Shelby, Ed.
> Category            : PROPOSED STANDARD
> Source              : Constrained RESTful Environments
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG