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 17:14 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 B6B741209B1; Tue, 29 Oct 2019 10:14:54 -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 3IxJcKOv7LzA; Tue, 29 Oct 2019 10:14:51 -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 4F5A51209A8; Tue, 29 Oct 2019 10:14:49 -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 472dVv2tRfzyQp; Tue, 29 Oct 2019 18:14:47 +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: <8B0F2225-E97C-4BEF-9DC7-1A47DEE9E88B@episteme.net>
Date: Tue, 29 Oct 2019 18:14:46 +0100
Cc: last-call@ietf.org, IETF <ietf@ietf.org>, core <core@ietf.org>
X-Mao-Original-Outgoing-Id: 594062085.286371-73e58c83d733f873ae4919cd81547fc0
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E744C58-C95B-42A9-B361-9D7EADB5EC2F@tzi.org>
References: <D37C00D0-FB7A-45AC-A137-59C79F4111FC@episteme.net> <95F1979B-1A23-41F3-9869-6CD133C75269@ericsson.com> <41C0F8EE-6A11-4B07-BA18-7DE106F03183@episteme.net> <D681F7B5-C313-4BC9-BA4E-83A4AAC76BD8@tzi.org> <8B0F2225-E97C-4BEF-9DC7-1A47DEE9E88B@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/5OG_1oJiyzwfoJlTcfF_oY7G0jM>
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 17:14:55 -0000

On Oct 29, 2019, at 16:51, Pete Resnick <resnick@episteme.net> wrote:
> 
>> 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.
> 
> That’s a job for the DE, and can be expressed in the instructions to the DE.

I can’t parse that.  The difference is a signal to implementers, not to the DE.
If you muddle the signal to the implementers, the DE can’t fix that (she would fix that by doing what?).

>> (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.)
> 
> Which is exactly why you should keep these in one registry: SDOs don’t have to have second class citizenship in the registry.

We want to encourage SDOs to go for SI base units.  We also want to embrace SDOs that have data models that use legacy units.  These know the units are legacy, new data models should be encouraged to use SI base units.

Being open for business is the overriding concern here, if you were asking us to write paragraph five in all upper case we would probably accede to that if that somehow helps make the change happen.  I would still be against it.

So, if that helps, we can merge the registries, add another column that is either LEGACY or empty, and hope that most implementers still get the message.  This is further away from optimal, but indeed does work.  It also serves to pollute the primary registry with legacy stuff that doesn’t belong there.

Grüße, Carsten