Re: [core] Barry Leiba's Yes on draft-ietf-core-senml-more-units-05: (with COMMENT)

Carsten Bormann <> Thu, 20 February 2020 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABC5C120041; Wed, 19 Feb 2020 17:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3vxM35oCgj1C; Wed, 19 Feb 2020 17:10:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1ABF12029C; Wed, 19 Feb 2020 17:10:31 -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 48NGjW65Cwz17y6; Thu, 20 Feb 2020 02:10:23 +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: Thu, 20 Feb 2020 02:10:22 +0100
Cc: The IESG <>,,,
X-Mao-Original-Outgoing-Id: 603853822.690876-fab891a1a7db756a9d6f29d793943684
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Barry Leiba <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [core] Barry Leiba's Yes on draft-ietf-core-senml-more-units-05: (with 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: Thu, 20 Feb 2020 01:10:35 -0000

Hi Barry,

Thanks for relaying Murray’s input.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> You have a typo in section 4: "obove", where "above" is meant.

Fixed in (now in -05).

> + + + + + + + + + + + + + + + + + + + +
> The following are comments from Murray Kucherawy, incoming ART AD.  Murray is
> getting an early start on doing reviews, and I’m including his comments into my
> ballots during the overlap period before he’s officially an Area Director.
> - - - - - - - - - - - - - - - - - - - -
> Section 2: Just out of curiosity, why are some of the newly registered "VA"s
> all-caps and some all-lowercase?

I don’t really know the history of the “var” moniker, but “VA” is just the product of “V” and “A” — the same coherent unit as “W”, but not meant as real power transfer ("active power"), but as “apparent power”.  V is for volt and A for ampere, two units that have been named after humans and therefore are always written in uppercase according to SI unit naming logic. 

“var” is an acronym/shorthand for “VA reactive”, i.e. the imaginary part of the apparent power if viewed as a complex number (“complex power”), and since it’s not named after a real person (Hal Varian? :-), it is in lower case, as are other artificial unit names such as meter (m), liter (l (*)), etc.  IEEE 1459 is the definitive document here, and IEC 80000-6 has legitimized this under item 6-60.b (in turn pointing to IEC 60050-131, which I don’t have).

> Section 4: I'm a bit uneasy about saying the rules for this new registry are
> the same as for that older registry, with exceptions.  That means if the rules
> for the old registry change, someone needs to remember to consider whether the
> rules for the new registry should change in parallel, or whether something else
> should happen.  But if there's precedent for doing that, or the result is
> unambiguous, then we're probably fine.

I don’t know about precedent, but I agree that any future updates to the rules for the primary registry should be considered for potential inclusion (or not) to an update to the rules for the secondary registry.  Since both are subregistries of the same top level registry, this will be hard to miss.

> Also, "six columns" followed by five bullets... I think I'd rather coax the
> scale/offset line apart.

I think any potential confusion is alleviated by the table that immediately follows and really has six columns.

> Seems to me that Section 2 and all but the last two paragraphs of Section 4
> should be in Section 7.  I've never seen an "IANA Considerations" section be a
> complete indirection like that.  But if we allow that, then OK.

Since the whole document is about creating registries and registering items, completely avoiding indirections would put everything into the IANA considerations section.
I’ll leave it to IANA to say whether the instructions are clear the way they are…
(We definitely have precedent with Security Considerations sections saying that a document is entirely about security.)

Grüße, Carsten

(*) I hit on the reluctantly granted exception here: according to some, but not other sources, liter may exceptionally also be abbreviated as “L” to make it typographically more different from “1”.

> _______________________________________________
> core mailing list