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

Alissa Cooper <> Wed, 19 February 2020 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48267120639; Wed, 19 Feb 2020 12:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=AZPyZ7PA; dkim=pass (2048-bit key) header.b=yd/fZWEI
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e9AJ2ZYDKD3i; Wed, 19 Feb 2020 12:16:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2718412016E; Wed, 19 Feb 2020 12:16:27 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 47C0971D; Wed, 19 Feb 2020 15:16:25 -0500 (EST)
Received: from mailfrontend1 ([]) by compute7.internal (MEProxy); Wed, 19 Feb 2020 15:16:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=p AJ8q2mRTP+Ppu4MFK2fDYw2qTUNvmeY3kbHb7PS1JQ=; b=AZPyZ7PAIv6wqpU1H wD6HCwkuUx8mBxi/5wd6tRWEWDIh7pWTCqporp/9+HQLUD5BuEbXDg2faI+MCtbn efbopX/I6VilvjdGUXXx9WnPivNjd/wCSWlzYsjrlCukfNNCKRndiZKhFyyLBj6z 6d486/Ecng3tUhz7ckJNjSXeCYPrn5Z0bFYszvPL6Io1xEbn2G749agEofjsV3oZ vBOml3a2xOO2TwMmUXZAB3iNWGAY8euhHyESEex+0jG4jX5HY6otvqKMsKeTgJrt dJk0qc2QRuhFwLgeT6B+6J/3rZnA98fjOdEmCHbO41HM8ZtxoEDhUh0JgHiScPYI nhebQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=pAJ8q2mRTP+Ppu4MFK2fDYw2qTUNvmeY3kbHb7PS1 JQ=; b=yd/fZWEInUd9pmuEh2KaQhqdNa1gd/Ae99Sn+bB4ZF7xMhzKRUJU2xNWT DgMM6vYAZr3yyYXJV4HD8BrJfYtRbXe0jEpRE28b9/KbqpwgfDnEnen/K7eFiFJQ WH7StNF3fvsp/PocPw6ele4pk+zo1cvVpkiqFlvYovxDwlTljk6AezCd+lsIUMdL R4i1bvVrd3Jfj1pDmNWx6ydWb7Vv/AzB9IwJyc1Ugsvff0oDyL3rhNdbiql+hvtf dwj6hxWas//b1EQ8eEZ57CrHZwH/YgPbSC6xH7vjXkePNpi1nCQcGl4Jze13Brda nEmphBsK5ku0MQJh7GjtDepIhizrw==
X-ME-Sender: <xms:mJdNXulM8LbxgNFuzqHuIH75sEuQEkocWapHYaoNS5M8sS9uXUzBfg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedtgddufeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepsghorhhmrghnnhdqtghorhgvqdhsvghnmhhlqdhvvghrshhiohhnshdrughonecu kfhppedujeefrdefkedruddujedrkedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:mJdNXnU_10OT0lZCwrQuXu3kkT-rebsBof7zOh-BvuTDjvNNSEe2YQ> <xmx:mJdNXsvfmnBQQYdc79YHfPfRKdApACM6ioiaDFnA1T1hUkYuiOU40Q> <xmx:mJdNXiYFInSF5FuouVPvni1PUxoqh51gQDQibfFV3QW6zY9TyjGVUg> <xmx:mJdNXqZHF9Ft-1ktDcaBS_RjeeHQ-AhGO7aXdqTZqMiqIjRFOtrswQ>
Received: from (unknown []) by (Postfix) with ESMTPA id 2D431328005A; Wed, 19 Feb 2020 15:16:24 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 19 Feb 2020 15:16:25 -0500
Cc: IESG <>,, Jaime Jimenez <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Carsten Bormann <>
X-Mailer: Apple Mail (2.3445.9.1)
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 20:16:30 -0000

Hi Carsten,

A few responses below.

> On Feb 19, 2020, at 2:40 PM, Carsten Bormann <> wrote:
> 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.

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 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? What is driving it?

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

> 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? If that is what is envisioned, the text in the draft is misleading.

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

Apologies, I see this now in RFC 8428.


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