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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 19 February 2020 00:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 603A8120058; Tue, 18 Feb 2020 16:22:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-core-senml-more-units@ietf.org, Jaime Jimenez <jaime@iki.fi>, core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158207175238.13976.4748538225663851323.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 16:22:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/JcicbGq0NJpRz6tfqSPBXpW6Evc>
Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-more-units-04: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 00:22:32 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-senml-more-units-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-senml-more-units/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

   +-----------+-------------------+-------+-----------+-----+---------+
   | secondary | description       | SenML |     scale | off | refer-  |
   | unit      |                   | unit  |           | set | ence    |
   +-----------+-------------------+-------+-----------+-----+---------+
   [...]
   | km        | kilometer         | km    |      1000 |   0 | RFCthis |

The associated SenML unit would be just 'm', not 'km'.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I appreciate the compromise position that was achieved after the long
last-call discussions questioning the need for this work.  It seems like
a reasonably shaped "escape hatch" to me.

Section 2

I assume this is just a product of my personal background, but I am more
used to "mass density" than "mass concentration" for dimensionalities
such as kg/m3.

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?

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.


It's a little surprising to see kibibyte and gigabyte defined but not
gibibyte.

   names.  Guidelines to the difference between units (which can go into
   the registry) and quantities are widely available, see for instance
   [RS] and [BIPM].

I suggest a parenthetical "(which cannot)" after "quantities".

   Where the benefits of directly using a secondary unit in a SenML pack
   outweigh the obove considerations, the use of secondary units in "u"

nit: s/obove/above/

   specifically allows this and/or by using a field with a label name
   that ends with the "_" character ("must-understand" field) that
   specifically allows this.  The definition of these versions and

I suggest "whose definition specifically allows this".

   fields is outside the scope of the present specification; one such
   definition is provided in [I-D.bormann-core-senml-versions].

nit: I suggest "proposed definition" or "possible definition", as
internet-drafts are "works in progress".

Section 5

   potential single point of failure.  Instead of pulling the registry
   in each individual instance of the code, the software update
   mechanism (or a similar, less frequently triggered mechanism) SHOULD
   be used to disseminate updated units registries obtained from IANA
   towards the instances via common repositories.

I like how this blandly assumes that a software update mechanism is
available.  Optimistic for the present-day world, but still probably the
right thing to say.
nit: as written, "less frequently triggered mechanism" means "less
frequently triggered than the software update mechanism", which I
suspect is not the intent.

Section 6

I suggest reiterating the implications of the requirements at the end of
section 4, namely, that use of new units is "fail-safe", in that an
implementation processing a pack using secondary units is guaranteed to
have been developed with an awareness of the risks of having multiple
units available for the same logical type.  (It is not, of course,
guaranteed to know about the specific secondary unit in question when
just the "SenML Version" check is used, in the same way that current
SenML applications are not guaranteed to know about units not in the
initial allocation from RFC 8428.)

   The security considerations of [RFC8428] apply.  The introduction of
   new measurement units poses no additional security considerations
   except from a possible potential for additional confusion about the
   proper unit to use.

Nitpicking, but I think there's a related risk of confusion in terms of
what quantity has been measured and is indicated in a SenML pack, as
alluded to by the previous mention of "trigger[ing] on the presence of a
quantity in a certain unit".