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

[Ari Keränen <[e-mail]>]

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

> On 16 Apr 2018, at 8.15, Ben Campbell <[e-mail]> wrote:
> 
> 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.

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.


> ----------------------------------------------------------------------
> 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?

Good point. Changed to "MUST NOT".

> Editorial/Nits:
> 
> 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)"

> §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..."

> §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.

> §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).

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

Fixed.

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

Fixed.