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

From: Ben Campbell <[email-masked]>
Date: Sun, 15 Apr 2018 22:15:13 -0700

Ben Campbell 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:
----------------------------------------------------------------------

Hopefully this is easy to address:

§4.7  talks about how SenML can also be used to configure parameters and
controlling actuators. That capability has some rather significant security
implications, but I failed to find mention of it in the security
considerations. That needs to be explicitly discussed.

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

Substantive:

§4.4: "If this value is a version number larger than the version which the
   system understands, the system SHOULD NOT use this object."

Why not MUST NOT? Are there situations where an implementation might reasonably
use an object with a higher version number than the implementation understands?

Editorial/Nits:

The title is misleading. It makes it sound like the document is just
registering media types; in fact it defines SenML.

§1, first paragraph: "This format was defined...": The antecedent of "this" is
unclear, since the fact the document defines SenML has not yet been mentioned.

§4.3, table 1: What do the asterisks mean?

§5.1.2, paragraph starting with "Note that...": I'm surprised to find normative
requirements buried in a note in an example.

§10, first paragraph: " the an integrated sum...": competing articles.

§14: "Sensor data can range from information with almost no security
   considerations..."
s/security/privacy

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2018 08:24:33 -0600

> https://datatracker.ietf.org/doc/draft-ietf-core-senml/

The actuation and configuration functionality has always been
underspecified; I raised an issue about it last year:

https://www.ietf.org/mail-archive/web/core/current/msg08871.html

Although that concern was minimally addressed, more could be said to
lock this down.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Apr 2018 14:29:49 +0200

Here is my knee-jerk reaction to the other Ben’s review.

Indeed.
TBD.

Not really.
Fair point.

> registering media types; in fact it defines SenML.

Right, it is defining the media types.
(Hmm, if “media types” means “media type names and their registrations”, maybe we do need to change the title.)

> unclear, since the fact the document defines SenML has not yet been mentioned.

s/This format/The format established by these media types/

> §4.3, table 1: What do the asterisks mean?

(See my knee-jerk comments on Adam’s COMMENTS.)

> requirements buried in a note in an example.

We should decide the whole stream pile before fixing this (which is just a symptom of the less-than-well-definedness of streams).

> §10, first paragraph: “ the an integrated sum...": competing articles.

s/the an/an/

> §14: “Sensor data can range from information with almost no security
> considerations..."
> s/security/privacy

Yep.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Apr 2018 14:32:31 +0200

Sorry about not properly trimming the To: list — this was meant to be internal between the authors.
A consolidated response will be forthcoming, please disregard this internal message…

Grüße, Carsten

> On Apr 16, 2018, at 07:15, Ben Campbell <[email-masked]> wrote:
>