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

Alissa Cooper <> Fri, 21 February 2020 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C806412008A; Fri, 21 Feb 2020 13:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Pkct3U+q; dkim=pass (2048-bit key) header.b=E4GdnmFW
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dM9PLAVyIgOx; Fri, 21 Feb 2020 13:10:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3624012008B; Fri, 21 Feb 2020 13:10:35 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 09CA56DD; Fri, 21 Feb 2020 16:10:33 -0500 (EST)
Received: from mailfrontend1 ([]) by compute7.internal (MEProxy); Fri, 21 Feb 2020 16:10:34 -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=V m/TXv2q3Frb2PO6uumCSXFWsJuetzNYOFqVdaV4q60=; b=Pkct3U+q26iRjpvsQ ZzMjEDWj1+U7yQ8LZ/cIgDou2u9iT94l4A5d2PtS05NUWRUa//zu3dVrb8d6IwZZ TbxLBVhYM3JQUayMZXk/4dif4ZGVin8CV9f7IA6sbFoz/6cEjPSuYeHxT0c+/o2u M8bVubakZzwFdhQ8ewyee3svJR8Xuw+dQydy+SWmw0KONNXxZwY+67dJSV3JtoVJ OkFNvreQH9D8cefivkWNLXPabX1LU+izd83Zhaq15ViRpcGJERttaC6wC2XlUdao 94daxAIfC1XcufGilzl3ZZmEVBKHRgvIXsAfgC8ZbjRvRBzf7mDQPrXjqBgimzCt kTUbQ==
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=Vm/TXv2q3Frb2PO6uumCSXFWsJuetzNYOFqVdaV4q 60=; b=E4GdnmFWYfN8kvXVajA+kpl/scMQOlY8nqGXlhJBhsMgY91fqZx3N2I2s X5pBRj2TqLbQKgmwBbvr0BhoEqOc8/62R75i11EY3cOMMGgyajC1hIlV/X0olhfV JHQGr55VdqjSwL3ZSoQ99I2Uli90e3bzqFqwgGmNa55m5mhgqAT2ZP/K0fwyrszu Psr8upev7eMucCRHq1qSANfmnFlwvXm+SANo6qt1/UbFOpDPQlx/niMTvwmMR9N6 knw2knZZPs2XS5xBP/0O00xiXZ1vVRIPkhGH1ppyVNc4Bfl3TrPiTRW7gRcHzsEP i4KPF50OnRD4iimeC+O5IJSsZSDqg==
X-ME-Sender: <xms:SUdQXuRwnsT7B2ZSEDNnZ-IkZtHOfpbVTy4GJF1oIV3xhmX9HoLySQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeggddugeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepsghorhhmrghnnhdqtghorhgvqdhsvghnmhhlqdhvvghrshhiohhnshdrughonecu kfhppedutdekrdehuddruddtuddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:SUdQXk2gw8IpcsmeGHcQECVv8o2YadhdAUre_uazR-tue5prTmIjxw> <xmx:SUdQXuxD1HLSuYTW4sRt5u3TEZByycm5_MkPNMKCQbALd0hZVMhY2A> <xmx:SUdQXns50TGcahqWQwS27MT_WcfpUaG88MVqiTmHNEtvxMyRjpNFEQ> <xmx:SUdQXqcv63iBPD9HAYDKnA6POATVlIggDr7EiTgAVPbS9qMgCErIag>
Received: from alcoop-m-c46z.fios-router.home ( []) by (Postfix) with ESMTPA id F1D57328005A; Fri, 21 Feb 2020 16:10:32 -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: Fri, 21 Feb 2020 16:10:31 -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: Fri, 21 Feb 2020 21:10:38 -0000

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


> On Feb 19, 2020, at 8:31 PM, Carsten Bormann <> 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 <> wrote:
>> 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?
> 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