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

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

On 29 Oct 2019, at 10:23, Carsten Bormann wrote:

> On Oct 29, 2019, at 15:16, Pete Resnick <[e-mail]> wrote:
>>
>> Add the scale column to the main registry and use one registry.
>
> The two registries have different policies (not in RFC 8228 
> nomenclature but in DE practice).

But you haven't justified not simply changing the policy for the primary 
registry. Make the DE practice, "Add it to the registry if it's a base 
unit or if it's in common use in another SDO."

> If we treat entries with scale different from entries without scale, 
> this is exactly equivalent to having two registries.

But that has not been the recommendation.

> Except that it is trivial to write a program to curl the second 
> registry and convert a random SenML file to a clean main-registry-only 
> file.  If these are muddled, you of course can write a slightly longer 
> program.

I don't understand that statement.

> The main difference remains one of signaling. How the signals 
> emanating from a standards document actually influence the world is 
> usually
> not very well understood, so I can see why different people would have 
> different opinions here.

There's signaling to implementers ("You have to deal with all of these 
entries") and then there's signaling to the outside world. We certainly 
want to get the former right, and there should be little difference of 
opinion there. On the latter, I actually think we agree:

> I’d still prefer to signal that there is a clear difference between 
> using SI base units and furlongs per fortnight, and decent SenML 
> processors, given a choice, should do the former.

That's a job for the DE, and can be expressed in the instructions to the 
DE.

> (And I definitely want to signal that SenML is open for business, but 
> I think we are discussing alternatives that are roughly equivalent in 
> that respect, not sending away those other SDOs at the door.)

Which is exactly why you should keep these in one registry: SDOs don't 
have to have second class citizenship in the registry.

>> There's no upside to keeping two, as far as I can tell, and there's 
>> definitely the potential for interoperability problems.
>
> I think Ari’s point stands.

I'm not sure which one.

> What we could do is make it more explicit that a SenML implementation 
> now has to heed both registries.  But there never was a MUST on 
> actually being able to process all registry 1 entries anyway, so I 
> don’t quite know what that would mean for registry 2.

If the two registries have equivalent rules of use, that further 
justifies one registry to make sure they don't get treated differently.

> We did everything that is needed to make it *easy* to implement 
> registry 2, apart maybe from asking IANA to provide a JSON file with 
> the registrations.

It seems that ease of use is increased with one registry instead of two.

Your justifications for the second registry really make no sense to me; 
it seems to me that all of them lead you to the conclusion that there 
should be one registry.

Singapore is 3 weeks away. Perhaps you'd like to have 5-10 minutes on 
the agenda?

pr
-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best