Subject: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 11:24:25 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-core-senml-more-units-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have some questions and comments about the text below, which seems like it
creates significant scope for interoperability failures:

"Where the benefits of directly using a secondary unit in a SenML pack
   outweigh the above considerations, the use of secondary units in "u"
   fields MAY be enabled by indicating a new SenML version that
   specifically allows this and/or by using a field with a label name
   that ends with the "_" character ("must-understand" field) whose
   definition specifically allows this.  The definition of these
   versions and fields is outside the scope of the present
   specification; one such definition is proposed in
   [I-D.bormann-core-senml-versions]."

Do I understand correctly that this allows secondary units in (1) SenML packs
that use some version number besides 10, and (2) SenML fields named with "_"
that are in packs where the version number is 10? What is the motivation for
providing two different mechanisms to signal that secondary units are in use?
I.e., why isn't one or the other of these mechanisms sufficient?

Without defining either a new version that supports secondary units or fields
with "_", I don't understand how this update to RFC 8428 is complete enough to
be implementable. It says other versions and fields are out of scope, but don't
some need to be defined in order for the normative MAY in this text to be
actionable?

The label names registry policy is Expert Review, which does not require formal
documentation of the registry entry. Where is the "definition [that]
specifically allows this" expected to occur?

Presumably some implementations are already using SenML. What is an
implementation supposed to do if it encounters a label name containing "_" that
it does not understand in a version 10 pack?

It looks like this text went in a week ago but it's a pretty significant change
to the extensibility story for SenML, so I'm wondering if the WG had a chance
to come to consensus on it?

I'm not super familiar with SenML so apologies if the answers to some of these
questions are obvious.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

'The unit "degrees" is in wide use in practice for plane angles (as in
   heading, bearing, etc.).  It is marked with an asterisk because the
   preferred coherent SI unit is radian ("rad").'

Is this asterisk notation meant to be common across all units that have this
same property? If so, that seems worth specifying more generally, not just for
degrees.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Feb 2020 20:40:16 +0100

Hi Alissa,

Thank you for your concern about interoperability.

> that use some version number besides 10,

(If that version specifically allows the use of secondary units)

> and (2) SenML fields named with "_"
> that are in packs where the version number is 10?

(Or any other version number that may not on its own specifically allow the use of secondary units)
(If that “must-understand” field specifically allows the use of secondary units)

> What is the motivation for

Because we don’t want to prejudice the decision how this is indicated.
(If we had known about the considerations about enabling secondary units earlier, we could have done that in time for this specification.  The tight timeline of this specification is based on the use of the same secondary units registry in data model specifications that underly data exchanged in SenML and other formats.  So there is no need to decide this mechanism right now for the initial use of the registry.)

> be implementable.

We decided that this draft is not updating RFC 8428, so it is not implementable without defining either of the mechanisms or the data models defined by other SDOs.
draft-bormann-core-senml-versions-00 is my best guess of where we will come out with the discussion of the former; the latter is in progress, waiting for this draft to be published.

> It says other versions and fields are out of scope, but don't

See above.

> specifically allows this" expected to occur?

In the definition of the label.
If the label definition is not known by an implementation, it cannot accept SenML with such a “must-understand” label, so false interoperability is effectively excluded.

> it does not understand in a version 10 pack?

Do not accept the pack.  (Note that this kind of “must-understand” label is a feature of RFC 8428, not of this draft.)

> to come to consensus on it?

The WG consensus was more on the side of simply accepting SenML packs with secondary units.
But it was rough consensus, and a simple solution could be found, so we went for this.  We did announce the intent to make this change on the WG list, on 2020-02-11, after extensive discussion between many of the main stakeholders.

[…]

The asterisk indication is defined in Section 12.1 of RFC 8428, for which this section is a registration.

Grüße, Carsten

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 19 Feb 2020 15:16:25 -0500

Hi Carsten,

A few responses below.

> On Feb 19, 2020, at 2:40 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Alissa,
> 

Why not? What value is derived from having two ways of doing the same thing?

> (If we had known about the considerations about enabling secondary units earlier, we could have done that in time for this specification.  The tight timeline of this specification is based on the u…

What is the timeline, exactly? What is driving it?

> We decided that this draft is not updating RFC 8428, so it is not implementable without defining either of the mechanisms or the data models defined by other SDOs.

I don’t understand how this draft could not be updating RFC 8428. RFC 8428 says:

"Systems reading one of the objects MUST check for the Base Version
   field.  If this value is a version number larger than the version
   that the system understands, the system MUST NOT use this object.
   This allows the version number to indicate that the object contains
   structure or semantics that is different from what is defined in the
   present document beyond just making use of the extension points
   provided here."

This drafts seems to be saying you can include fields with different structure and semantics from what is specified in RFC 8428, but still use version 10.

> In the definition of the label.

So, that can be in a private email to the designated expert? If that is what is envisioned, the text in the draft is misleading.

> Do not accept the pack.  (Note that this kind of “must-understand” label is a feature of RFC 8428, not of this draft.)

Apologies, I see this now in RFC 8428.

Alissa

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Feb 2020 02:31:08 +0100

Hi Alissa,

Let me try to answer this quickly, but there is a complex history around this that may easier be explained in person.

> On 2020-02-19, at 21:16, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Carsten,
> 
> A few responses below.
> 

I don’t think we will have two ways in the end.  If we agree that draft-bormann-core-senml-versions is a good way to do this, I don’t think people will come up with other ways of specifically indicating this.  (There may be contexts outside of SenML packs where SenML units are being used that might merit other ways of indicating primary-only vs. primary/secondary.  So far I haven’t met those.)

> What is the timeline, exactly?

“ASAP”… (I think the original timeline was CES 2020, and we are already behind it.)

> What is driving it?

The use of the SenML unit registry as a general purpose registry for units used in IoT standards, specifically those being developed by other SDOs (OMA LWM2M/IPSO is leading this).

> This drafts seems to be saying you can include fields with different structure and semantics from what is specified in RFC 8428, but still use version 10.

RFC 8428 is not too specific on what the semantics for a newly defined field could be.
I would expect that it can supply additional semantics to existing fields, opening the avenue of using must-understand fields for what could also be considered version upgrades.
Section 12.2 of RFC 8428 says:

   Extensions that are mandatory to understand to correctly process the
   Pack MUST have a label name that ends with the "_" character.

I personally would prefer us going the draft-bormann-core-senml-versions way, where the version number is strengthened to be the main extension point, but consensus building on this has only just begun.

> So, that can be in a private email to the designated expert?

Yes, RFC 8428 allows that.  But that secrecy would make a “must-understand” field (with a label ending in “_”) hard to use except by those that are privy to this specification.

Grüße, Carsten

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 21 Feb 2020 16:10:31 -0500

Hi Carsten, all,

I guess I’m not really following the logic here. If it’s so urgent that this specification be approved today, are there implementations out there ready to interpret version 10 SenML packs containing fields labeled with “_” that are using secondary units? If so, why can’t this spec just update RFC 8428 to clarify the ambiguity that you can have different structure/semantics without changing the version number, and drop the idea of signaling secondary units with a new version number? Conversely, if there aren’t implementations prepared to use “_” fields for secondary units, why can’t the WG take the time to specify versioning correctly and use versioning as the signaling mechanism?

Thanks,
Alissa

> On Feb 19, 2020, at 8:31 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Alissa,
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 Feb 2020 06:55:43 +0100

On 2020-02-21, at 22:10, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Carsten, all,
> 
> I guess I’m not really following the logic here. If it’s so urgent that this specification be approved today, are there implementations out there ready to interpret version 10 SenML packs containing fields labeled with “_” that are using secondary units?

Hi Alissa,

the initial user of this spec will be OMA, with the IPSO objects.  These use SenML in an interesting way: Unit information (and other meta information) is maintained at the data model level, so the actual Packs interchanged do not contain “u” fields, at least not now.  So senml-more-units becomes immediately applicable for the unit names in those data models, before we define how to do interchange with unit names in the data packets.  The data models currently use primary SenML units and/or the units that will constitute the secondary registry, currently by maintaining their own copy/subset of the secondary registry at https://github.com/OpenMobileAlliance/lwm2m-registry/blob/test/LWM2M_senml_units.xml
We need to get rid of this duplication (and potential for divergence), which is also pretty much a prerequisite for other SDOs accepting SenML units as the common way to go for their data model initiatives.

Eventually, “u” fields *will* need to turn up in some of the SenML data being interchanged, and that is the time when we will have to have developed a common position on how to indicate usage of this feature in a SenML Pack.

> If so, why can’t this spec just update RFC 8428 to clarify the ambiguity that you can have different structure/semantics without changing the version number, and drop the idea of signaling secondary units with a new version number? Conversely, if there aren’t implementations prepared to use “_” fields for secondary units, why can’t the WG take the time to specify versioning correctly and use versioning as the signaling mechanism?

That is a discussion still to be had, and draft-bormann-core-senml-versions is a result of preliminary discussions how to best do this.  I know I have an opinion on this, after a month or so of discussion of the specific proposals developed so far, but we need to finish this discussion and run a normal IETF decision process on this and any other proposals coming up.

What we need to do now is establish the second registry, make this available for data modeling projects in OMA/IPSO and the other organizations participating in the One Data Model liaison group, and continue to register any additional secondary units that may be needed for the latter.  The specific way these secondary units are enabled for use directly in SenML Packs can be left open for a short while, even if this may seem unusual; the important thing is to make the SenML ecosystem available now as the supplier of the harmonized unit names used all over IoT.

Grüße, Carsten