Re: [core] [Last-Call] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard

Carsten Bormann <cabo@tzi.org> Tue, 29 October 2019 15:23 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 0DD45120827; Tue, 29 Oct 2019 08:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SXothHzgNG62; Tue, 29 Oct 2019 08:23:34 -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 EC75C120859; Tue, 29 Oct 2019 08:23:29 -0700 (PDT)
Received: from [192.168.217.102] (p548DCA87.dip0.t-ipconnect.de [84.141.202.135]) (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 472b2S43JwzySH; Tue, 29 Oct 2019 16:23:28 +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: <41C0F8EE-6A11-4B07-BA18-7DE106F03183@episteme.net>
Date: Tue, 29 Oct 2019 16:23:28 +0100
Cc: IETF <ietf@ietf.org>, core <core@ietf.org>, last-call@ietf.org
X-Mao-Original-Outgoing-Id: 594055406.586962-282ea5f3bfe820a7f845829e50f54012
Content-Transfer-Encoding: quoted-printable
Message-Id: <D681F7B5-C313-4BC9-BA4E-83A4AAC76BD8@tzi.org>
References: <D37C00D0-FB7A-45AC-A137-59C79F4111FC@episteme.net> <95F1979B-1A23-41F3-9869-6CD133C75269@ericsson.com> <41C0F8EE-6A11-4B07-BA18-7DE106F03183@episteme.net>
To: Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7JOsnAlBN6RZGBTuYnVezK_oGMI>
Subject: Re: [core] [Last-Call] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard
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: Tue, 29 Oct 2019 15:23:39 -0000

[resending with trimmed CC list, as the IETF mailing list processor will delay the message otherwise.]

On Oct 29, 2019, at 15:16, Pete Resnick <resnick@episteme.net> wrote:
> 
> Add the scale column to the main registry and use one registry.

The two registries have different policies (not in RFC 8228 nomenclature but in DE practice).
If we treat entries with scale different from entries without scale, this is exactly equivalent to having two registries.

Except that it is trivial to write a program to curl the second registry and convert a random SenML file to a clean main-registry-only file.  If these are muddled, you of course can write a slightly longer program.

The main difference remains one of signaling.  How the signals emanating from a standards document actually influence the world is usually not very well understood, so I can see why different people would have different opinions here.  I’d still prefer to signal that there is a clear difference between using SI base units and furlongs per fortnight, and decent SenML processors, given a choice, should do the former.

(And I definitely want to signal that SenML is open for business, but I think we are discussing alternatives that are roughly equivalent in that respect, not sending away those other SDOs at the door.)

> There's no upside to keeping two, as far as I can tell, and there's definitely the potential for interoperability problems.

I think Ari’s point stands.

What we could do is make it more explicit that a SenML implementation now has to heed both registries.  But there never was a MUST on actually being able to process all registry 1 entries anyway, so I don’t quite know what that would mean for registry 2.  We did everything that is needed to make it *easy* to implement registry 2, apart maybe from asking IANA to provide a JSON file with the registrations.

Grüße, Carsten

-- 
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call