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

[Carsten Bormann <[e-mail]>]

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