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

"Pete Resnick" <> Mon, 28 October 2019 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4FFC1200C7; Mon, 28 Oct 2019 11:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fB9KNGZ1a3l7; Mon, 28 Oct 2019 11:57:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DFB0120125; Mon, 28 Oct 2019 11:57:55 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E6BB922EA0C; Mon, 28 Oct 2019 13:57:47 -0500 (CDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NPKn_N3B2npz; Mon, 28 Oct 2019 13:57:46 -0500 (CDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 1E0AE922EA03; Mon, 28 Oct 2019 13:57:46 -0500 (CDT)
From: "Pete Resnick" <>
To: "Gillmore, Matthew" <>
Cc: "Ari =?utf-8?q?Ker=C3=A4nen?=" <>, "Cullen Jennings" <>,, "IETF Crazy" <>, core <>,, "Hytonen Harri" <>,
Date: Mon, 28 Oct 2019 13:57:45 -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: <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: Mon, 28 Oct 2019 18:57:58 -0000

Matt, Ari, and Harri,

While you give good support for adding these units, and I am OK with 
that idea, do you have any objection to adding them to the main 
registry, which was the other suggestion that Cullen made? I still have 
not seen a convincing argument not to make these part of the main 


On 28 Oct 2019, at 10:40, Gillmore, Matthew wrote:

> Hi Cullen,
> I am the chair of the IPSO working group in OMA and also support what 
> Ari wrote.  During the last IETF in Montreal, stakeholders from the 
> IPSO working group along with the Core working group met and it was 
> consensus amongst both working groups that the second registry is how 
> we would like to move forward.
> Cheers,
> Matt
> -----Original Message-----
> From: ietf <> On Behalf Of Ari Keränen
> Sent: Tuesday, October 22, 2019 6:37 PM
> To: Cullen Jennings <>
> Cc:; IETF Crazy <>rg>; core 
> <>rg>;
> Subject: Re: [core] Last Call: 
> <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) 
> to Proposed Standard
> Hi Cullen,
> Carsten already replied to some of these issues later in the thread, 
> but let me add some more viewpoints.
>> On 22. Oct 2019, at 17.06, Cullen Jennings <> wrote:
>> I am strongly opposed to the secondary registry - it will 
>> significantly harm interoperability. This could be resolved by not 
>> adding the items in the secondary repository or by adding them to the 
>> main repository.
>> Having a registry of stuff that may or may not work simply means that 
>> we will have less interoperability because what you can not decide 
>> what is valid SenML or not.  Sure some of the device vendors making 
>> things that produce SenML have thought this was a good idea in the 
>> past but I’d like to hear from a bunch of the people that have to 
>> process the SenML data that is produced and see if they think it is a 
>> good idea.
> Both registries would work and their use would result in valid SenML. 
> In a sense the second registry is almost the same as "adding them to 
> the main repository", but having the second registry enables us to 
> give better guidance which units to use/prefer and also provide the 
> translation to the "main registry units".
>> The working group discussed this for a long time and was against the 
>> items that are being added to the secondary repository.
>> If there is a large group of people that agree the consensus has 
>> changed, then this should simply be put in the main registry. Many 
>> people believe that since SenML is not meant to be human readable, 
>> having a canonical form of just meters with a floating point number 
>> is better than having both km, mm, and god only knows what else.
> Yes, the canonical form of "just meters" is still the recommended way 
> in general, but that approach did not work as well as we hoped for all 
> use cases. For example when your sensor value is always in integers of 
> mm/h, it's more convenient and efficient to send integer values than 
> multiples of 2.777e-7. Also in many use cases there is a 
> well-established scaled unit that is used in the industry and forcing 
> to use a different one didn't turn out to be very productive (we can 
> still recommend, though, and that's one of the reasons why we are 
> proposing an additional registry). Finally, legacy models that use 
> non-scaled units but would like to use SenML as the wire format and 
> units registry would be expensive to update to use only non-scaled 
> units.
>> I note the secondary repository add mm but not cm. How is this 
>> insanity going to work out? How will analytics code trying to process 
>> this data know what it can use or not use. If we are going down this 
>> path, this is the wrong way to do it. The right way is to define a 
>> set of all SI prefixes and say they can be used with any unit.
> Any implementation should not try to use anything that is not in the 
> IANA registry. We did also consider to enable all SI prefixes, but 
> concluded that it is still useful to have the smallest reasonable set 
> of units to facilitate interoperability. If there's a real use case 
> that uses a unit with SI prefix that is missing, it can be simply 
> registered. Also not all units in the additional registry would work 
> with just different SI prefix (e.g., min or dBm).
> Cheers,
> Ari
>>> On Oct 16, 2019, at 11:42 AM, The IESG <> 
>>> wrote:
>>> The IESG has received a request from the Constrained RESTful
>>> Environments WG
>>> (core) to consider the following document: - 'Additional Units for 
>>> SenML'
>>> <draft-ietf-core-senml-more-units-02.txt> as Proposed Standard
>>> The IESG plans to make a decision in the next few weeks, and 
>>> solicits
>>> final comments on this action. Please send substantive comments to
>>> the mailing lists by 2019-10-30. Exceptionally,
>>> comments may be sent to instead. In either case, 
>>> please
>>> retain the beginning of the Subject line to allow automated sorting.
>>> Abstract
>>>  The Sensor Measurement Lists (SenML) media type supports the
>>> indication of units for a quantity represented.  This short document
>>> registers a number of additional unit names in the IANA registry for
>>> Units in SenML.  It also defines a registry for secondary units that
>>> cannot be in SenML's main registry as they are derived by linear
>>> transformation from units already in that registry; RFC 8428 is
>>> updated to also accept these units.
>>> The file can be obtained via
>>> .org_doc_draft-2Dietf-2Dcore-2Dsenml-2Dmore-2Dunits_&d=DwIGaQ&c=pqcuz
>>> KEN_84c78MOSc5_fw&r=UdGshIy7O85QbjoqbIdb_K7GJN4Vxe8yisqNq0oQtS4&m=1HS
>>> mPnFlr7WEiLKKLxMke_BtKIEXMq-xPdsDRzT3I1k&s=wIciltspG7rnX8nThlkp4SeFlD
>>> uiYAwaeqZEOxVBC9Y&e=
>>> IESG discussion can be tracked via
>>> .org_doc_draft-2Dietf-2Dcore-2Dsenml-2Dmore-2Dunits_ballot_&d=DwIGaQ&
>>> c=pqcuzKEN_84c78MOSc5_fw&r=UdGshIy7O85QbjoqbIdb_K7GJN4Vxe8yisqNq0oQtS
>>> 4&m=1HSmPnFlr7WEiLKKLxMke_BtKIEXMq-xPdsDRzT3I1k&s=cS56g5iiq-KyNYhVVTz
>>> l1c5-ZTApK90BoaWReY-zR3Y&e=
>>> No IPR declarations have been submitted directly on this I-D.