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

[Alissa Cooper via Datatracker <[e-mail]>]

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.