Re: [core] CoRE @ IETF106: Summary and Minutes

[Carsten Bormann <[e-mail]>]

I have submitted an update to senml-more-units that should address the concerns:

Htmlized:       https://tools.ietf.org/html/draft-ietf-core-senml-more-units-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-more-units
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-more-units-04

The -04 version now no longer updates RFC 8428 to allow the use of units from the secondary registry, but leaves this to specific indicators that announce the presence of secondary units in the SenML Pack.  One early draft with a proposal of how to do this is now available as:

Htmlized:       https://tools.ietf.org/html/draft-bormann-core-senml-versions

(There is no intention to couple the secondary registry to this specific way of indicating the use of secondary units; the above draft, while intended to be normative when it is done, is only an informational reference in senml-more-units.)

In addition, the new version is more outspoken on the advantages of sticking to primary units in SenML packs, and it addresses the operational concerns that would result if IoT systems frequently and automatically updated their unit definitions directly from the IANA registry.

Thanks to all the people that made it clear in offline discussions that this is a better way forward than just charging ahead and enabling secondary units everywhere.

(Still with author hat on only:)
CoRE WG, please check whether this proposed resolution is acceptable to the WG.

Grüße, Carsten


> On 2020-01-27, at 18:03, Jaime Jiménez <[e-mail]> wrote:
> 
> Dear all,
> 
> Coming back to this issue, I have not seen a reply on the list
> regarding this. I would like to have it concluded so that we can move
> the document forward. I agree that the text should reflect that the
> secondary registry is not be the preferable option if units in the
> primary registry can be used. Maybe the authors could work out a
> modified draft that better explains that, after which we can do the
> document write up and ship it.
> 
> Ciao!
> -- Jaime
> 
> 
> On Tue, Jan 21, 2020 at 11:35:47AM +0200, Jaime Jimenez wrote:
>> Sending it to the core thread. 
>> 
>> -- 
>> Jaime Jiménez
>> 
>> On Mon, Jan 20, 2020, at 6:10 PM, Jaime Jimenez wrote:
>>> Hi,
>>> 
>>> comments below. 
>>> 
>>> On Fri, Dec 13, 2019 at 11:27:34AM -0700, Cullen Jennings wrote:
>>>> 
>>>> 
>>>>> On Dec 9, 2019, at 3:42 PM, Carsten Bormann <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> Concerns had been raised about opening up the second registry for
>>>>> derived units, making it harder for a SenML application to find out
>>>>> whether a unit encountered was actually of interest to it.
>>>>> Discussion in the first session resulted in the tentative proposal
>>>>> to mark secondary units with an asterisk (as in "*km/h", as opposed
>>>>> to unmarked "m/s").  Further discussion in the second session made
>>>>> clear that while this makes the use of secondary units stand out, it
>>>>> does not really improve the situation of SenML applications that
>>>>> want to quickly discard measurements for units they do not care
>>>>> about, unless they track the contents of the two registries, which
>>>>> would make the asterisks redundant.
>>>> 
>>>> I disagree that the asterisk does not improve the situation
>>>> 
>>>>> There also was some feedback
>>>>> the asterisks would make the adoption of the SenML units registry by
>>>>> other SDOs more difficult.  The in-room consensus not to go for the
>>>>> asterisks, but to include more explanatory text about implementation
>>>>> strategies, needs to confirmed on the mailing list.  
>>>> 
>>>> I strongly object to this.  RFC 8428 has a strong assertion that the units 
>>>> 
>>>>        For a given type of measurement, there will only be one unit
>>>>        type defined.  So for length, meters are defined and other
>>>>        lengths such as mile, foot, light year are not allowed.  For
>>>>        most cases, the SI unit is preferred.
>>>> There is running code that is based on that assumption that has been in production for many years. You can’t break that assumption without some backwards compatibility consideration that help theses deployed applications mitigate the breakage this causes.
>>> 
>>> I believe that the assumption of having only one unit per measurement
>>> was broken already with core-senml-more-units as it creates the
>>> secondary registry. So the asterisk does not fix that.  
>>> 
>>>> The ideas that millions of edge aggregation devices, many on far side of slow links, would query the IANA web server to track the units and decide how to process data seems like a very bad design. I would expect the IESG to reject anything that lead to cases like https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse <https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse>
>>>> 
>>> 
>>> I also do not see how the asterisk would make parsing easier. If
>>> existing edge devices are hardcoded to use a subset of all units -just
>>> the primary senml registry- then they would filter messages containing
>>> any unit they do not understand anyways. 
>>> 
>>> Also the asterisk does not tell an application processing a specific
>>> measurement (e.g., temperature in celsius) additional information about
>>> the unit (e.g., I am temperature in fahrenheit, this is important)
>>> indicating that this new unit  is something it should process, it only indicates
>>> that it is part of the secondary registry.
>>> 
>>> Regarding the querying of the senml registry, I think that would have to
>>> happen anyways, as new units will be registered over time, even if not
>>> very often. 
>>> 
>>> I think the real issue here is whether to signal "this unit belongs to a
>>> secondary registry, not the main one" or not. Flagging a unit with "*" or
>>> having a different field like "u2" can confuse developers unnecessarily, 
>>> as they do not need to know about historical standard decisions. It's
>>> more of a penalty to those using it :D 
>>> 
>>> And if you want to convey that the secondary registry is not the
>>> preferred one, then I think that is something that should be on the
>>> draft itself, right? With very strong wording and so on, but not on the
>>> wire in a senml record. 
>>> 
>>>> 
>>> 
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>> 
>>> 
>> 
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core