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

[Carsten Bormann <[e-mail]>]

On 2020-02-21, at 22:10, Alissa Cooper <[e-mail]> 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




> 
> Thanks,
> Alissa
> 
> 
>> On Feb 19, 2020, at 8:31 PM, Carsten Bormann <[e-mail]> wrote:
>> 
>> 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 <[e-mail]> wrote:
>>> 
>>> Hi Carsten,
>>> 
>>> A few responses below.
>>> 
>>>> On Feb 19, 2020, at 2:40 PM, Carsten Bormann <[e-mail]> wrote:
>>>> 
>>>> Hi Alissa,
>>>> 
>>>> Thank you for your concern about interoperability.
>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> 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,
>>>> 
>>>> (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
>>>>> 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?
>>>> 
>>>> Because we don’t want to prejudice the decision how this is indicated.
>>> 
>>> Why not? What value is derived from having two ways of doing the same thing?
>> 
>> 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.)
>> 
>>>> (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.)
>>> 
>>> 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).
>> 
>>>>> 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.
>>>> 
>>>> 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.
>> 
>> 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.
>> 
>>>> 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
>>>>> some need to be defined in order for the normative MAY in this text to be
>>>>> actionable?
>>>> 
>>>> See above.
>>>> 
>>>>> 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?
>>>> 
>>>> In the definition of the label.
>>> 
>>> 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
>> 
>