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

["Pete Resnick" <[e-mail]>]

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 <[e-mail]> On Behalf Of Ari Keränen
> Sent: Tuesday, October 22, 2019 6:37 PM
> To: Cullen Jennings <[e-mail]>
> Cc: [e-mail]; IETF Crazy <[e-mail]>; core 
> <[e-mail]>; [e-mail]
> 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 <[e-mail]> 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 <[e-mail]> 
>>> 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 [e-mail] mailing lists by 2019-10-30. Exceptionally,
>>> comments may be sent to [e-mail] 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.
>>>