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

[Carsten Bormann <[e-mail]>]

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