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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Apr 2018 19:33:15 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-senml-14: 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/

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

I agree with Ben's DISCUSS.

Additionally, I have serious reservations about introducing the
concept of "base fields" that apply to subsequent array elemnets
unless overridden.  It seems to violate an abstraction barrier for
at least some of the serialization formats, and prevents snippets
from being composable and commutable absent the
resolution/normalization process.  It does not seem like the markup
language and the document contain suffient safeguards against misuse
to prevent security holes (both sensor data and commands could be
misinterpreted).  It seems that some substantially expanded text
should be added on the hazards of the non-resolved format and giving
guidance on when resolution/normalization must be performed in order
to avoid correctness and security issues.

There also seem to be sizeable risks associated with the semantics
for time values.  In particular, both with the use of an
implicit-"now-ish", and with positive and negative values being
interpreted with respect to a different absolute time base.  (The
involvement of base time is a further complication -- I do not
remember any discussion of the interaction of a (positive) base time
and a negative regular time, for example.  I also do not remember
any discussion of how the "now-ish" semantics make it actively
harmful to do things like store-and-forward or archive SenML data
(again, absent normalization), or what sort of granularity the
"now-ish" semantics are expected to adhere to.  (Is "yesterday"
still considered "roughly now"?)  I understand the desire for this
sort of semantics, but the current specification seems to leave many
potential problems exposed.

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

Section 4.4

Just "Considerations" is an unusual subject title.

Having no Unit and no Base Unit is allowed, but you don't say what
the semantics are in that case (presumably just a dimensionless
counter for integers, with units not really being applicable to
non-numeric types).  Interestingly, Section 5.1.7 deems it fit to
use "/" for the unit for a boolean value, even though "/" is
supposed to be a (continuous/floating-point) ratio.

Section 4.5

Just to double-check: you really do want to privilege this
specification's version for eternity, for the purpose of being
omitted from resolved records?

Section 12.1 is there not some other units registry we can use?  I
fear begetting https://xkcd.com/927/  .  Also, how is/should the
table be sorted?

Also in Section 12.1, number 9, is the need for case sensitivity in
Units (or otherwise?) normatively covered anywhere?  If not, should
it?

Section 12

Are Base fields supposed to get negative CBOR labels
(and not other fields)?  Is this mentioned explicitly somewhere?
(Yes, I know that the intent is for no more CBOR lablels to be
allocated, but that is only a SHOULD-level requirement.)

In
   Extensions that are mandatory to understand to correctly process the
   Pack MUST have a label name that ends with the '_' character.
should that say something about "mandatory to understand but not
defined in this document"?  (Also in 12.3.1 et seq?)

Section 13

Why are we talking about "executable content" at all?  It seems
quite unrelated to the rest of the document.