Discussion:
[core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT)
Ben Campbell
2018-04-16 05:13:47 UTC
Permalink
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
Ben Campbell
2018-04-16 05:15:13 UTC
Permalink
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
Peter Saint-Andre
2018-04-16 14:24:33 UTC
Permalink
Post by Ben Campbell
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.
https://datatracker.ietf.org/doc/draft-ietf-core-senml/
----------------------------------------------------------------------
----------------------------------------------------------------------
§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.
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
Carsten Bormann
2018-04-19 12:29:49 UTC
Permalink
Here is my knee-jerk reaction to the other Ben’s review.
Post by Ben Campbell
----------------------------------------------------------------------
----------------------------------------------------------------------
§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.
Indeed.
TBD.
Post by Ben Campbell
----------------------------------------------------------------------
----------------------------------------------------------------------
§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?
Not really.
Fair point.
Post by Ben Campbell
The title is misleading. It makes it sound like the document is just
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.)
Post by Ben Campbell
§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.
s/This format/The format established by these media types/
Post by Ben Campbell
§4.3, table 1: What do the asterisks mean?
(See my knee-jerk comments on Adam’s COMMENTS.)
Post by Ben Campbell
§5.1.2, paragraph starting with "Note that...": I'm surprised to find normative
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).
Post by Ben Campbell
§10, first paragraph: “ the an integrated sum...": competing articles.
s/the an/an/
Post by Ben Campbell
§14: “Sensor data can range from information with almost no security
considerations..."
s/security/privacy
Yep.

Grüße, Carsten
Carsten Bormann
2018-04-19 12:32:31 UTC
Permalink
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
Post by Ben Campbell
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.
https://datatracker.ietf.org/doc/draft-ietf-core-senml/
----------------------------------------------------------------------
----------------------------------------------------------------------
§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.
----------------------------------------------------------------------
----------------------------------------------------------------------
§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?
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
Ari Keränen
2018-05-07 17:52:34 UTC
Permalink
Thank you for the review Ben!

We have now submitted a new revision of the SenML draft that addresses all the IESG review comments:
https://tools.ietf.org/html/draft-ietf-core-senml-15

For answers to your review comments, please see below.


Thanks,
Ari
Post by Ben Campbell
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.
https://datatracker.ietf.org/doc/draft-ietf-core-senml/
----------------------------------------------------------------------
----------------------------------------------------------------------
§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.
Now Section 13 mentions actuator use explicitly:

When SenML is used for configuration or
actuation, it can be used to change the state of systems and also
impact the physical world, e.g., by turning off a heater or opening a
lock.

The SenML formats alone do not provide any security and instead rely
on the protocol that carries them to provide security. Applications
using SenML need to look at the overall context of how these formats
will be used to decide if the security is adequate. In particular
for sensitive sensor data and actuation use it is important to ensure
that proper security mechanims are used.
Post by Ben Campbell
----------------------------------------------------------------------
----------------------------------------------------------------------
§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?
Good point. Changed to "MUST NOT".
Post by Ben Campbell
The title is misleading. It makes it sound like the document is just
registering media types; in fact it defines SenML.
Other reviewers mentioned the same. Changed this to "Sensor Measurement Lists (SenML)"
Post by Ben Campbell
§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.
Changed to "The SenML format is defined..."
Post by Ben Campbell
§4.3, table 1: What do the asterisks mean?
The first sentence after table was supposed to have asterisk to indicate explanation. Now it says:

(*) Data Value is base64 encoded string with URL safe alphabet as
defined in Section 5 of [RFC4648], with padding omitted.
Post by Ben Campbell
§5.1.2, paragraph starting with "Note that...": I'm surprised to find normative
requirements buried in a note in an example.
We moved the SensML normative text now to a new section (4.7).
Post by Ben Campbell
§10, first paragraph: " the an integrated sum...": competing articles.
Fixed.
Post by Ben Campbell
§14: "Sensor data can range from information with almost no security
considerations..."
s/security/privacy
Fixed.

Loading...