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

Ari Keränen <> Mon, 28 October 2019 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9630E1200F1; Mon, 28 Oct 2019 12:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XSRk4LonN6A0; Mon, 28 Oct 2019 12:26:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27C3912006D; Mon, 28 Oct 2019 12:26:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=DzYhEs8P0LzyOMXNlSAghj78xlgvU0g2hlTcBqlbUAIB8NgZWiExxqCLRY2UL0qYjfglwFD9H/W2fESHLW8bEd8bLe8E3nxIT5LAZ5QNeyCKUYqKtDGny6p6nz95oh6yg/Y8aWixrQIkdE8pGHOzmPWvVxVYIvnsChUm/Dtth2J6IlMRBcKu0tHgfZFSnKv1mFdbJk3ZJ7GLpPZzgM142PPzNm91z6bp1R2ggYzLHfYTYRSUXnyVw7I6Zp/N5G9RpTmVfnxLHXa9lMnJANFbmqYvfc6ZC6M8NytE7VMm47IeHLf2feLQcq9ORNVRCzQ5HwA8aihNAvyFYKYo2iJzaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=212eniWInojR3I0urxOjyOLoKbuhP1TRnGBFBNO/klU=; b=R3vYeqnDEmYRxKuRBdBCl7jF69bSLaiMkIdQp0OuYa+tEAhHh8ZcoUVHQj8LpzlNq32cXaL7UocvgdgFsXa0q4/i1se7QdOGzjIYs1A/7W/Ekyv0NgQWf7cBPgodDcul6Dp8G8psIt6ZO6JsyAgZ03cdyO6qRfVOf+RFZ+Kgv6ZUcfveuqKR5reSG6h4fAUMqm5MlunILRzV18pU6boXe5h3jyNpDbXEcUv4iSTadVmzw0dzCrhw/FtqUGbqPWNP11zu+15vOGNu0hcRn3dfVBu12/Hv3szfcSDfwV7f+Sk+M14B4hZJj8BglXfO9azNy1aA8JReAJLXTK/DihjeNw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=212eniWInojR3I0urxOjyOLoKbuhP1TRnGBFBNO/klU=; b=NfRX1tnIJG9/6dg/08gEJzi+bGN2V1pe0/e9ecpgDWqCjqhMwan/RdXNRGa1a9qo7ywUAKNA85GR/AycU5ZSFGVH540SFK2y7/hWITyjc+tFhudY2WE70jLTtX9gpe8eKua5cm4xvjGQ4aHdbQuhIJCJ+b5y8TRPJJKDudT+wB0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.15; Mon, 28 Oct 2019 19:26:41 +0000
Received: from ([fe80::3840:ef4a:a3da:a6a6]) by ([fe80::3840:ef4a:a3da:a6a6%6]) with mapi id 15.20.2408.014; Mon, 28 Oct 2019 19:26:41 +0000
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= <>
To: Pete Resnick <>
CC: "Gillmore, Matthew" <>, Cullen Jennings <>, "" <>, IETF Crazy <>, core <>, "" <>, Hytonen Harri <>, "" <>
Thread-Topic: [core] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard
Thread-Index: AQHVhElvBc7gWk7Dm0GWEjW1rMWvnqdmutYAgACA54CACQfegIAANvyAgAAC9QA=
Date: Mon, 28 Oct 2019 19:26:40 +0000
Message-ID: <>
References: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 67ad5439-c56c-46ac-d902-08d75bdcc293
x-ms-traffictypediagnostic: HE1PR07MB3353:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0204F0BDE2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(39860400002)(346002)(376002)(136003)(199004)(189003)(13464003)(4326008)(71190400001)(76116006)(71200400001)(58126008)(54906003)(6246003)(66574012)(316002)(66066001)(8676002)(6436002)(85182001)(229853002)(99286004)(53546011)(6486002)(81156014)(8936002)(6506007)(6512007)(5660300002)(76176011)(256004)(102836004)(26005)(14444005)(446003)(2906002)(25786009)(2616005)(3846002)(81166006)(476003)(486006)(6116002)(186003)(6916009)(4001150100001)(478600001)(36756003)(305945005)(14454004)(7736002)(85202003)(66476007)(66556008)(86362001)(66446008)(64756008)(33656002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3353;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ECB6CXlrG7LcPawFp7f4gFi59DCvK9M373iCK2oMLNjg98gx9ydOY4SmRpzkWHjLlvi+j11fsuWQfs38R43FU5X4+kuFd6MRBU5bAtvfS9Aoqgo7XpRMsI157F+ADPbqW0jfNfY016APm/lY+PzWO1OPnVCefB2NRJkOldaRCo5GaARr3vBnNVfAW7NQTuGQDu6QIhOKwVgQSdzku3hAtu1fdzHGnG9TyaHoy3o2vzZXi7vkDzbMDll5J1libM/Y/S8+ss8V3D1WOYes9mr4msqQhLY6Fd83RiNBYl/UVapaWZyVSCgclMtPPvteCPcYlCeiww1oR90fYVn2HLUj2h0uz70dCK5q+q8Bz7ZKL4QGUff1XW40E4kdnILdyLp9nQKBBoskr4W2obeiUqABlFFGsPdz1HxuU8tFxVG9tXmnX53d5kz2GK6bcABaojsz
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 67ad5439-c56c-46ac-d902-08d75bdcc293
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2019 19:26:40.9697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: P+zXygbJnnW9Zx1RFZYJOX6qCRY+hI6T2icy1etSjLz3d/JRtlvnaZzbVq4wvSvMZkfqAPGWOLiI3K/fD9Uh/8mE9bPCi6+onHBMhxYjuv4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3353
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 19:26:48 -0000

Hi Pete,

I don't have a strong objection for using the same registry for all units, but I think the second registry is a better approach since that allows us to keep the first registry in its original purpose: a minimal set of unscaled units where you would use the numeric part of the value to express the scale. This is still the best approach for many use cases / systems since it allows you to get by with a small amount of identifiers and keeps comparisons across values simple (you don't need to normalize values based on unit's scale before doing comparisons etc.). If we put all the units in the same registry, systems (or their specifications) that would like to have this property would have to state somehow which of the units in the single registry one should use.

Also the second registry has the "scale" column that indicates the relation (and enables automatic translation) to the units in the first registry. I guess we could get the same effect by extending the first registry with the scaling field, but at least to me the second registry feels like a cleaner option. And I don't see big downsides for having separate registries for these; both contain still valid SenML units.


> On 28. Oct 2019, at 20.58, Pete Resnick <> wrote:
> 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 registry.
> pr
>> 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.