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

"Pete Resnick" <> Tue, 29 October 2019 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D739E120802; Tue, 29 Oct 2019 08:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NL2yQOtHjeIj; Tue, 29 Oct 2019 08:51:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E75CD120830; Tue, 29 Oct 2019 08:51:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEDC592456D3; Tue, 29 Oct 2019 10:51:55 -0500 (CDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PrJO257dtCci; Tue, 29 Oct 2019 10:51:54 -0500 (CDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 477EE92456C9; Tue, 29 Oct 2019 10:51:54 -0500 (CDT)
From: "Pete Resnick" <>
To: "Carsten Bormann" <>
Cc: IETF <>, core <>,
Date: Tue, 29 Oct 2019 10:51:51 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [core] [Last-Call] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Oct 2019 15:51:59 -0000

On 29 Oct 2019, at 10:23, Carsten Bormann wrote:

> On Oct 29, 2019, at 15:16, Pete Resnick <> 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).

But you haven't justified not simply changing the policy for the primary 
registry. Make the DE practice, "Add it to the registry if it's a base 
unit or if it's in common use in another SDO."

> If we treat entries with scale different from entries without scale, 
> this is exactly equivalent to having two registries.

But that has not been the recommendation.

> 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.

I don't understand that statement.

> 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.

There's signaling to implementers ("You have to deal with all of these 
entries") and then there's signaling to the outside world. We certainly 
want to get the former right, and there should be little difference of 
opinion there. On the latter, I actually think we agree:

> 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 

> (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.

>> 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.

I'm not sure which one.

> 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.

If the two registries have equivalent rules of use, that further 
justifies one registry to make sure they don't get treated differently.

> 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.

It seems that ease of use is increased with one registry instead of two.

Your justifications for the second registry really make no sense to me; 
it seems to me that all of them lead you to the conclusion that there 
should be one registry.

Singapore is 3 weeks away. Perhaps you'd like to have 5-10 minutes on 
the agenda?

Pete Resnick
All connections to the world are tenuous at best