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

"Pete Resnick" <> Tue, 22 October 2019 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AC3312009E; Tue, 22 Oct 2019 09:08:06 -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 IFkP65jR8_hX; Tue, 22 Oct 2019 09:08:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DA3212004A; Tue, 22 Oct 2019 09:08:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91D05916F14C; Tue, 22 Oct 2019 11:07:57 -0500 (CDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3DLWSwzMclrQ; Tue, 22 Oct 2019 11:07:56 -0500 (CDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id F2EA0916F143; Tue, 22 Oct 2019 11:07:55 -0500 (CDT)
From: "Pete Resnick" <>
To: "Carsten Bormann" <>
Cc: "Cullen Jennings" <>,,, IETF <>, core <>,
Date: Tue, 22 Oct 2019 11:07:55 -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; markup=markdown
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, 22 Oct 2019 16:08:06 -0000

On 22 Oct 2019, at 10:50, Carsten Bormann wrote:

> On Oct 22, 2019, at 17:33, Pete Resnick <> wrote:
>> Implementations are perfectly capable of multiplying and adding.
> I think after 40+ years in the industry I can refute that statement 
> :-)

The can successfully write code to convert to SenML, but can't write 
code to do simple arithmetic? Color me unconvinced. ;-)

> But, seriously, this draft is based on a specific request from an SDO, 
> OMA/IPSO, for which this secondary registry would enable porting their 
> existing data models to ones based on the SenML units registry.  Other 
> SDOs from this space might follow suit.
> Clearly, when we did SenML, we didn’t want to go this route.  
> Currently, there is an amazing pull towards data model harmonization 
> that has changed the fundamentals enough that this draft now makes 
> sense.  I’ll leave it to IPSO people to explain this in more 
> details.

But if that's true, it's also likely that these units will leak through 
to base RFC 8428 implementations. Do not make it optional for those 
implementations to deal with the new units; add them to the existing 

> “MAY, but SHOULD NOT” means exactly what it says; I don’t think 
> there is a contradiction.
> But of course we can contract this to “SHOULD NOT” if that helps.

Save yourself the time of having Barry explain the problem to you in 
excruciating detail during IESG Review. :-)

That said, this is obviously not the path I want you to take.

> Oh, and “cm” isn’t registered yet because OMA didn’t need it, 
> not because it couldn’t be registered if that turns out to be 
> desirable.

I would put pretty good odds on it appearing pretty soon after this 
document is released; implementers will assume that any unit will do.

> SenML is now in a position to play a centerpiece in the harmonized IoT 
> data landscape.  Not going for this draft is likely to thwart this 
> opportunity.

Sounds like a fine thing to aim for. Again, that says to me to add these 
to the existing registry.

Pete Resnick
All connections to the world are tenuous at best