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

"Pete Resnick" <resnick@episteme.net> Mon, 28 October 2019 18:57 UTC

Return-Path: <resnick@episteme.net>
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 E4FFC1200C7; Mon, 28 Oct 2019 11:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB9KNGZ1a3l7; Mon, 28 Oct 2019 11:57:55 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFB0120125; Mon, 28 Oct 2019 11:57:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 7E6BB922EA0C; Mon, 28 Oct 2019 13:57:47 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPKn_N3B2npz; Mon, 28 Oct 2019 13:57:46 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 1E0AE922EA03; Mon, 28 Oct 2019 13:57:46 -0500 (CDT)
From: "Pete Resnick" <resnick@episteme.net>
To: "Gillmore, Matthew" <Matthew.Gillmore@itron.com>
Cc: "Ari =?utf-8?q?Ker=C3=A4nen?=" <ari.keranen=40ericsson.com@dmarc.ietf.org>, "Cullen Jennings" <fluffy@iii.ca>, core-chairs@ietf.org, "IETF Crazy" <ietf@ietf.org>, core <core@ietf.org>, draft-ietf-core-senml-more-units@ietf.org, "Hytonen Harri" <harri.hytonen@vaisala.com>, last-call@ietf.org
Date: Mon, 28 Oct 2019 13:57:45 -0500
X-Mailer: MailMate (1.13r5655)
Message-ID: <D37C00D0-FB7A-45AC-A137-59C79F4111FC@episteme.net>
In-Reply-To: <SN6PR04MB5135DFDF6501B47BC4E71B7D98660@SN6PR04MB5135.namprd04.prod.outlook.com>
References: <C17F33E0-E060-4104-B9DD-6F48CCC9EF27@iii.ca> <10E8F425-E509-4849-AE06-D00313BFB2C4@ericsson.com> <SN6PR04MB5135DFDF6501B47BC4E71B7D98660@SN6PR04MB5135.namprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/GjxR-4laSIenNK_kbLkW2bCPkH4>
Subject: Re: [core] 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: 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 
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 <ietf-bounces@ietf.org> On Behalf Of Ari Keränen
> Sent: Tuesday, October 22, 2019 6:37 PM
> To: Cullen Jennings <fluffy@iii.ca>
> Cc: core-chairs@ietf.org; IETF Crazy <ietf@ietf.org>rg>; core 
> <core@ietf.org>rg>; draft-ietf-core-senml-more-units@ietf.org
> 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 <fluffy@iii.ca> 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 <iesg-secretary@ietf.org> 
>>> 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 ietf@ietf.org mailing lists by 2019-10-30. Exceptionally,
>>> comments may be sent to iesg@ietf.org 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
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>>> .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
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>>> .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.
>>>