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

Carsten Bormann <> Wed, 19 February 2020 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C72B120130; Wed, 19 Feb 2020 11:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5N0BMn3w6fDD; Wed, 19 Feb 2020 11:40:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 448D8120112; Wed, 19 Feb 2020 11:40:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 48N7Nd5Br0z10t0; Wed, 19 Feb 2020 20:40:17 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 19 Feb 2020 20:40:16 +0100
Cc: The IESG <>,, Jaime Jimenez <>,,
X-Mao-Original-Outgoing-Id: 603834016.45249-e7bce1bd1497a3ad5b9f7876fc942b97
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Alissa Cooper <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-senml-more-units-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Feb 2020 19:40:24 -0000

Hi Alissa,

Thank you for your concern about interoperability.

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

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

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

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

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

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

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

Grüße, Carsten