Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (with DISCUSS and COMMENT)

Carsten Bormann <> Wed, 19 February 2020 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0938112083F; Wed, 19 Feb 2020 10:07:25 -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 oBCSn1Yu696K; Wed, 19 Feb 2020 10:07:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B5331208B3; Wed, 19 Feb 2020 10:07:21 -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 48N5KJ4BgPzyRm; Wed, 19 Feb 2020 19:07:16 +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 19:07:15 +0100
Cc: The IESG <>,, Jaime Jimenez <>,,
X-Mao-Original-Outgoing-Id: 603828435.299191-de11cc49f0886353e5fb78c322b16ce4
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (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 18:07:25 -0000

Hi Ben,

> On 2020-02-19, at 18:01, Benjamin Kaduk <> wrote:
> Hi Carsten,
> Thanks for the updates; the changes in the -05 look good with just one
> exception.  That, and some other comments, inline.
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> Section 3
>>>  o  The Byte.  [IEC-80000-13] defines both the bit (item 13-9.b) and
>>>     the byte (item 13-9.c, also called octet) as alternative names for
>>>     the coherent unit one for the purpose of giving storage capacity
>>>     and related quantities.  While the name octet is associated with
>>> nit: is "one" misplaced, here?
>> The coherent unit actually is “one”; see Section 3.8, Note 3, and Section 3.12, Note 4 in ISO 80000-1 as cited above.
>> To make this easier to read, we could place it in quotes, except it is not a string, it is really the number 1.
> I guess I kind of gave it away that I didn't follow the reference, here :)
> It's probably too verbose to try something like "the coherent unit used for
> dimensionless quantities and indicated by the numeral one".

Maybe not the whole thing, but I like "the coherent unit used for
dimensionless quantities” instead of "coherent unit one”.  People who understand the latter will always understand the former.

>>> Section 4
>>>  o  scale, offset: two rational numbers, expressed in decimal
>>>     (optionally, with a decimal exponent given) or as a fraction
>>>     divided by a "/" character.
>>> nit: doesn't "a fraction divided by a '/' character" involve two '/'
>>> characters?  That is, "1/2" is a fraction, so "1/2 divided by a '/'
>>> character" would be like "1/2/" or "1/2/2" or something nonsensical like
>>> that.
>> “divided” as in “separated into two halves”, i.e., “1/2” is divided by a “/“ into a 1 and a 2.  Maybe we need better phrasing here.
> Perhaps, "a fraction represented using a '/' character to separtae
> numerator and denominator"?

That works very well.

>> […]
>> I have turned this into
>> (or a similar
>> mechanism visiting IANA less frequently)
> This is better, but I think that "less frequently" is still an implied
> comparison, and the comparison against software-update is more local than
> the (intended) comparison against the generic/abstract "usual frequency" or
> "every time an instance of the system starts up or checks".  I might
> suggest "a similar mechanims that only visits IANA infrequently".

I think the criticism of visiting IANA from every instance should be clear here, so it seems to me people should be able to relate the “visit IANA less frequently” to the “download … from IANA frequently” above.  (I’m not sure what infrequently means; I think once an hour would be fine for a major software package that then distributes updates via software update mechanism.)
Maybe “that leads to less frequent IANA visits” is even clearer?
(Because it’s not the software update mechanism itself that visits IANA.)


Proposed updates in

Grüße, Carsten