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

From: "Pete Resnick" <[email-masked]>
Date: Wed, 23 Oct 2019 00:33:01 +0900

[Cc'ing last-call.]

I have to agree with Cullen. In fact, the paragraph at the bottom of 
section 4 shows the confusion and harm:

    SenML packs MAY, but SHOULD NOT, use secondary units in place of
    SenML units, where the exception of the "SHOULD NOT" lies in the
    context of specific existing data models that are based on these
    secondary units.

You can't "MAY" do something and "SHOULD NOT" do it. Those are 
contradictory terms.

Either register these (and all SI prefixes) in the existing registry, or 
don't register these at all. Implementations are perfectly capable of 
multiplying and adding.

pr

On 22 Oct 2019, at 23:05, Cullen Jennings 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.
>
> 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.
>
> 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.
>
>
>
>
>
>> On Oct 16, 2019, at 11:42 AM, The IESG <[email-masked]> 
>> 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
>> [email-masked] mailing lists by 2019-10-30. Exceptionally, comments 
>> may be
>> sent to [email-masked] 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://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>> _______________________________________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/core

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Oct 2019 17:50:11 +0200

On Oct 22, 2019, at 17:33, Pete Resnick <[email-masked]> wrote:
> 
> Implementations are perfectly capable of multiplying and adding.

I think after 40+ years in the industry I can refute that statement :-)

But, seriously, this draft is based on a specific request from an SDO, OMA/IPSO, for which this secondary registry would enable porting their existing data models to ones based on the SenML units registry.  Other SDOs from this space might follow suit.

Clearly, when we did SenML, we didn’t want to go this route.  Currently, there is an amazing pull towards data model harmonization that has changed the fundamentals enough that this draft now makes sense.  I’ll leave it to IPSO people to explain this in more details.

“MAY, but SHOULD NOT” means exactly what it says; I don’t think there is a contradiction.
But of course we can contract this to “SHOULD NOT” if that helps.  Oh, and “cm” isn’t registered yet because OMA didn’t need it, not because it couldn’t be registered if that turns out to be desirable.

SenML is now in a position to play a centerpiece in the harmonized IoT data landscape.  Not going for this draft is likely to thwart this opportunity.

Grüße, Carsten

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 22 Oct 2019 11:07:55 -0500

> I think after 40+ years in the industry I can refute that statement 

The can successfully write code to convert to SenML, but can't write 
code to do simple arithmetic? Color me unconvinced. ;-)

> But, seriously, this draft is based on a specific request from an SDO, 
> OMA/IPSO, for which this secondary registry would enable porting their 
> existing data models to ones based on the SenML units registry.  Other 
> SDOs from this space might follow suit.
>
> Clearly, when we did SenML, we didn’t want to go this route.  
> Currently, there is an amazing pull towards data model harmonization 
> that has changed the fundamentals enough that this draft now makes 
> sense.  I’ll leave it to IPSO people to explain this in more 
> details.

But if that's true, it's also likely that these units will leak through 
to base RFC 8428 implementations. Do not make it optional for those 
implementations to deal with the new units; add them to the existing 
registry.

> But of course we can contract this to “SHOULD NOT” if that helps.

Save yourself the time of having Barry explain the problem to you in 
excruciating detail during IESG Review. :-)

That said, this is obviously not the path I want you to take.

> Oh, and “cm” isn’t registered yet because OMA didn’t need it, 
> not because it couldn’t be registered if that turns out to be 
> desirable.

I would put pretty good odds on it appearing pretty soon after this 
document is released; implementers will assume that any unit will do.

> SenML is now in a position to play a centerpiece in the harmonized IoT 
> data landscape.  Not going for this draft is likely to thwart this 
> opportunity.

Sounds like a fine thing to aim for. Again, that says to me to add these 
to the existing registry.

pr

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Oct 2019 18:16:33 +0200

On Oct 22, 2019, at 18:07, Pete Resnick <[email-masked]> wrote:
> Sounds like a fine thing to aim for. Again, that says to me to add these to the existing registry.

Right now the primary registry generally provides the preferred unit to encode some quantity.
By mixing in the secondary registrations into the same registry, this mild coercion would be diluted outside the use cases that require them, and all of SenML would stand in the cesspool of derivative units we now find in other IoT standards.

(Historically, if we had known we wanted to go this way, we would have chucked some of the units marked with an asterisk to the secondary registry.  But that horse has left the barn already.)

Grüße, Carsten

---

From: "Pete Resnick" <[email-masked]>
Date: Mon, 28 Oct 2019 13:57:45 -0500

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 <[email-masked]> On Behalf Of Ari Keränen
> Sent: Tuesday, October 22, 2019 6:37 PM
> To: Cullen Jennings <[email-masked]>
> Cc: [email-masked]; IETF Crazy <[email-masked]>; core 
> <[email-masked]>; [email-masked]
> 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 <[email-masked]> wrote:
> 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".
>
>> 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.
>
>> 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
>
>>
>>> final comments on this action. Please send substantive comments to
>>> the [email-masked] mailing lists by 2019-10-30. Exceptionally,
>>> comments may be sent to [email-masked] instead. In either case, 
>>> please
>>> retain the beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>> 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
>>> 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=
>>>
>>> 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=
>>>
>>>

---

From: Ari Keränen <[email-masked]>
Date: Mon, 28 Oct 2019 19:26:40 +0000

Hi Pete,

I don't have a strong objection for using the same registry for all units, but I think the second registry is a better approach since that allows us to keep the first registry in its original purpose: a minimal set of unscaled units where you would use the numeric part of the value to express the scale. This is still the best approach for many use cases / systems since it allows you to get by with a small amount of identifiers and keeps comparisons across values simple (you don't need to normalize values based on unit's scale before doing comparisons etc.). If we put all the units in the same registry, systems (or their specifications) that would like to have this property would have to state somehow which of the units in the single registry one should use.

Also the second registry has the "scale" column that indicates the relation (and enables automatic translation) to the units in the first registry. I guess we could get the same effect by extending the first registry with the scaling field, but at least to me the second registry feels like a cleaner option. And I don't see big downsides for having separate registries for these; both contain still valid SenML units.

Cheers,
Ari 

> On 28. Oct 2019, at 20.58, Pete Resnick <[email-masked]> wrote:
> 
> 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
> 
>> 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
>> 
>> Cc: [email-masked]; IETF Crazy <[email-masked]>; core <[email-masked]>; [email-masked]
>> 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.
>> 
>>> 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 <[email-masked]> wrote:
>>>> 
>>>> 
>>>> (core) to consider the following document: - 'Additional Units for SenML'
>>>> comments may be sent to [email-masked] instead. In either case, please

---

From: Hytonen Harri <[email-masked]>
Date: Tue, 29 Oct 2019 11:18:51 +0000

Hi,

If new units or new derived units can be added to the primary units registry with reasonable effort and time, then yes, it is sufficient from Vaisala perspective. However, Ari's points below make sense and I agree that a secondary registry would probably be a cleaner approach. 

BR,
Harri 

-----Original Message-----
From: Ari Keränen <[email-masked]> 
Sent: Monday, 28 October, 2019 21:27
To: Pete Resnick <[email-masked]>
Cc: Gillmore, Matthew <[email-masked]>; Cullen Jennings <[email-masked]>; [email-masked]; IETF Crazy <[email-masked]>; core <[email-masked]>; [email-masked]; Hytonen Harri <[email-masked]>; [email-masked]
Subject: Re: [core] Last Call: <draft-ietf-core-senml-more-units-02.txt> (Additional Units for SenML) to Proposed Standard

Hi Pete,

Cheers,
Ari

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 29 Oct 2019 09:16:45 -0500

Hi Ari,

What is the upside to having a minimal set of unscaled units when all 
implementations are going to have to be able to interpret all of the 
entries from both registries? An implementation can't keep comparisons 
simple, because it's going to have to deal with all of the new entries 
anyway. If an implementation is allowed to not implement the ones in the 
second registry, then that does lead to the interoperability problems 
Cullen is worried about. Even if if the document says that you MUST be 
able to interpret values from both registries, the downside is the 
possibility that implementations might simply ignore the second 
registry. And once you have the second registry, I don't see that 
there's any reason to prefer any of the entries in the original 
registry: You have to be able to handle both, and since everyone has to 
handle both, there's not reason not to send them either.

Add the scale column to the main registry and use one registry. There's 
no upside to keeping two, as far as I can tell, and there's definitely 
the potential for interoperability problems.

pr

On 28 Oct 2019, at 14:26, Ari Keränen wrote:

> Hi Pete,
>
> I don't have a strong objection for using the same registry for all 
> units, but I think the second registry is a better approach since that 
> allows us to keep the first registry in its original purpose: a 
> minimal set of unscaled units where you would use the numeric part of 
> the value to express the scale. This is still the best approach for 
> many use cases / systems since it allows you to get by with a small 
> amount of identifiers and keeps comparisons across values simple (you 
> don't need to normalize values based on unit's scale before doing 
> comparisons etc.). If we put all the units in the same registry, 
> systems (or their specifications) that would like to have this 
> property would have to state somehow which of the units in the single 
> registry one should use.
>
> Also the second registry has the "scale" column that indicates the 
> relation (and enables automatic translation) to the units in the first 
> registry. I guess we could get the same effect by extending the first 
> registry with the scaling field, but at least to me the second 
> registry feels like a cleaner option. And I don't see big downsides 
> for having separate registries for these; both contain still valid 
> SenML units.
>
>
> Cheers,
> Ari
>
>> 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
>>
>>> 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
>>>
>>> <draft-ietf-core-senml-more-units-02.txt> (Additional Units for 
>>> SenML) to Proposed Standard
>>>
>>> Hi Cullen,
>>>
>>>> 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.
>>> 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.
>>>
>>>> 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.
>>>
>>> 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
>>>
>>>>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Oct 2019 16:21:03 +0100

On Oct 29, 2019, at 15:16, Pete Resnick <[email-masked]> 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).
If we treat entries with scale different from entries without scale, this is exactly equivalent to having two registries.

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.

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.  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.

(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.)

> 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.

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.  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.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Oct 2019 16:23:28 +0100

[resending with trimmed CC list, as the IETF mailing list processor will delay the message otherwise.]

Grüße, Carsten

-- 
last-call mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/last-call

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 29 Oct 2019 10:51:51 -0500

> 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'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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Oct 2019 18:14:46 +0100

On Oct 29, 2019, at 16:51, Pete Resnick <[email-masked]> wrote:
> 
>> 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.

I can’t parse that.  The difference is a signal to implementers, not to the DE.
If you muddle the signal to the implementers, the DE can’t fix that (she would fix that by doing what?).

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

We want to encourage SDOs to go for SI base units.  We also want to embrace SDOs that have data models that use legacy units.  These know the units are legacy, new data models should be encouraged to use SI base units.

Being open for business is the overriding concern here, if you were asking us to write paragraph five in all upper case we would probably accede to that if that somehow helps make the change happen.  I would still be against it.

So, if that helps, we can merge the registries, add another column that is either LEGACY or empty, and hope that most implementers still get the message.  This is further away from optimal, but indeed does work.  It also serves to pollute the primary registry with legacy stuff that doesn’t belong there.

Grüße, Carsten

---

From: Ari Keränen <[email-masked]>
Date: Tue, 29 Oct 2019 20:58:42 +0000

Hi Pete,

Carsten replied to many of your questions/comments below, but perhaps one more point to mention is that the additional registry makes it simpler to build a system specification for SenML use where you can simply point that all implementations in that system should use the units from the first registry. Since all the units in the second registry have an equivalent non-scaled-and-shifted version in the first registry, that is rather feasible. Also many implementations are likely to "implement" only a small subset of the units since they would use them to simply check that a value is the kind of value they expected to receive. 

That said, the most important thing is to get these new units registered as soon as possible, in one or two registries, so that we don't hold back our stakeholders using SenML.

Cheers,
Ari

> On 29. Oct 2019, at 16.16, Pete Resnick <[email-masked]> wrote:
> 
> Hi Ari,
> 
> What is the upside to having a minimal set of unscaled units when all implementations are going to have to be able to interpret all of the entries from both registries? An implementation can't keep comparisons simple, because it's going to have to deal with all of the new entries anyway. If an implementation is allowed to not implement the ones in the second registry, then that does lead to the interoperability problems Cullen is worried about. Even if if the document says that you MUST be able to interpret values from both registries, the downside is the possibility that implementations might simply ignore the second registry. And once you have the second registry, I don't see that there's any reason to prefer any of the entries in the original registry: You have to be able to handle both, and since everyone has to handle both, there's not reason not to send them either.
> 
> Add the scale column to the main registry and use one registry. There's no upside to keeping two, as far as I can tell, and there's definitely the potential for interoperability problems.
> 
> pr
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 30 Oct 2019 09:21:00 -0600

If we are going to have add theses secondary scaled units, I do agree with Ari & Carten’s arguments that  having them in a secondary registry that is machine readable is the right way to do it. In fact would be better if IANA also made them available over git but that is a different topic. But here is the problems I see:

Currently interoperability in IoT is a mess and the 20+ SDOs in this space does not help. Us trying to meet the conflicting needs of all theses SDOs will also not help. So let me try and clarity some of the problems with this draft as it stands.

Imagine that today the secondary table has mm but not cm. I write my software to process mm and ship it. Next week cm is added, my software can’t process that, and in many IoT cases, it will take years to be upgraded. At this point, standardizing the table does nothing for anyone and is harmful in that it suggests that things will work together since they are senml but they will not. It’s true that a new unit nothing to do with distance could be added to main table but the way that table is done, that would be rare, and very unlikely my software needs it if my software deals with distance. However, if my software knows and uses m and mm, very likely the cm makes sense for it to use but it can’t. 

The argument for having this second table seems to be an argument to avoiding a single floating point multiple on the IoT decide. Keep in mind this is a device that probably supports EC crypto to send the data. I have not heard any argument that this single multiple is too high a burden on the device. 

The expert review advice for this new table is woefully inadequate for thd broad range of questions the expert will need to answer. For example, will we add “furlongs per fortnight”? why not? Will we add micro-fortnights as a unit? Several RFC use fortnights  (Thank you Dave Oran)

The expert review advise does not cover what is probably the single biggest unit issue with uses. That is dose the type of thing being measured belong in the unit in some cases. For example, is parts per million of oxygen a different unit that parts per million of carbon dioxide? I realize the unit purist would say those are both simply a ratio but if you look at how practitioners use this stuff, theses are totally different units. This draft does not cover how to deal with that. On a side note, I would see way more value of this secondary table if we were clear that we were going to allow both ppm_O2 and ppm_CO2 . However in the past, we argued that was better placed in the name in SENML or in a secondary tag value. 

As a trivial side note  …. the draft is just wrong on how it modifies the expert guidance from the 2nd registry. It says remove rules 4 and 5 from  RFC8428. However the examples we are talking about for this will also probably violate rules 1, 2, 3, 7, 8. I think this would have to be addressed before approving this draft. 

So let's get back to the fundamental issue. Why are we doing this? Some other SDO wants it is not really an answer. Understanding why the other SDO wants it would be a good answer. Do the reasons cause more good than interoperability problems that come out of it. I tried to get info from a few other SDO about this but I failed. I’d like to hear more about why we should do this. I’m not seeing big value in the saving the floating point calc on the device but perhaps there is a compelling use case where that matters that I am not thinking of. 

I think if I understood why people want this, it might change my mind. 

> On Oct 29, 2019, at 2:58 PM, Ari Keränen <ari.keranen=[email-masked]> wrote:
> 
> Hi Pete,
>

---

From: Ari Keränen <[email-masked]>
Date: Wed, 30 Oct 2019 21:19:44 +0000

Hi Cullen,

The key thing the secondary table enables is the use of legacy models with the units that they are already using (where changing the existing models is too high cost). New models and uses of SenML can avoid the problems you described below by sticking to the units in the primary registry. Perhaps the right solution here is to write more guidance into the draft to make this more clear.

And yes, also more guidance for the designated expert is very welcome. And I would argue that what is being measured belongs to another tag, not to the unit.

Cheers,
Ari

> On 30. Oct 2019, at 17.21, Cullen Jennings <[email-masked]> wrote:
>

---

From: Hytonen Harri <[email-masked]>
Date: Thu, 31 Oct 2019 07:17:35 +0000

On Oct 30, 2019, at 17:21, Cullen Jennings <[email-masked]>  wrote:
>  So let's get back to the fundamental issue. Why are we doing this? Some other SDO wants it is not really an answer. Understanding why the other SDO wants it would be a
> good answer. Do the reasons cause more good than interoperability problems that come out of it. I tried to get info from a few other SDO about this but I failed. I’d like to
> hear more about why we should do this. I’m not seeing big value in the saving the floating point calc on the device but perhaps there is a compelling use case where that
> matters that I am not thinking of.

As explained before, it's not matter of saving floating point calculations, but preserving the original precision of the measurement. 

BR,
Harri Hytonen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 31 Oct 2019 08:54:37 -0600

> On Oct 31, 2019, at 1:17 AM, Hytonen Harri <[email-masked]> wrote:
> 
> On Oct 30, 2019, at 17:21, Cullen Jennings <[email-masked] <mailto:[email-masked]>>  wrote:

I am not at all understanding this. Can you work me through an example ? I suspect that you might be giving senml more credit than it deserves.