Re: [core] Genart last call review of draft-ietf-core-senml-more-units-02

Carsten Bormann <cabo@tzi.org> Thu, 31 October 2019 17: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 6019112008B; Thu, 31 Oct 2019 10:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.864
X-Spam-Level:
X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ss5mR54lzDkp; Thu, 31 Oct 2019 10:21:06 -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 992F212006A; Thu, 31 Oct 2019 10:21:03 -0700 (PDT)
Received: from client-0191.vpn.uni-bremen.de (client-0191.vpn.uni-bremen.de [134.102.107.191]) (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 473sYB0FSjzyTg; Thu, 31 Oct 2019 18:21:02 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <157254010642.30489.13409170000311799067@ietfa.amsl.com>
Date: Thu, 31 Oct 2019 18:21:01 +0100
Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-core-senml-more-units.all@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 594235259.739297-cb108e5fcfabd7cf9338bf62014895e0
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C6A661E-CDA5-4E99-96E4-5DDC1A03B6A1@tzi.org>
References: <157254010642.30489.13409170000311799067@ietfa.amsl.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jBqXPmu_cWxtPUPQbeGCoBAVXlI>
Subject: Re: [core] Genart last call review of draft-ietf-core-senml-more-units-02
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, 31 Oct 2019 17:21:09 -0000

Hi Linda,

thank you for this review.

> On Oct 31, 2019, at 17:41, Linda Dunbar via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-core-senml-more-units-??
> Reviewer: Linda Dunbar
> Review Date: 2019-10-31
> IETF LC End Date: 2019-10-30
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:  The document is very light, describing IANA registration for acronyms
> for various UNITs, such as "ms" for Millisecond, "min" for Minute, "kW" for
> Kilowatt, etc. While there is no problem of those acronyms, I don't really
> understand why it is necessary to have an RFC for this purpose. Many IETF areas
> don’t even allow Gap Analysis drafts to be published as RFCs.

Registrations to an existing registry indeed do not require an RFC.

However, beyond registering a few values, this draft also

— creates a new registry and defines its expert review instructions,
— updates Standards Track RFC 8428 to accept values from this registry in a place previously governed only by a different registry.

While there is still some ongoing debate about whether this was the right approach to address the requirements, if we uphold this approach we will require an RFC.

Grüße, Carsten