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

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 <cabo@tzi.org> 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
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> 
>