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

From: Ari Keränen <[email-masked]>
Date: Mon, 7 May 2018 18:00:06 +0000

Thank you for the review Adam!

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 19 Apr 2018, at 10.14, Adam Roach <[email-masked]> wrote:
> 
> Adam Roach 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:
> ----------------------------------------------------------------------
> 
> Thanks to everyone who contributed to this document.
> 
> ---------------------------------------------------------------------------
> 
> §9 defines a URI fragment identification scheme that is intended to apply to
> senml+xml / sensml+xml. Since this uses the "+xml" structured syntax suffix, it
> has to comply with the fragment identifier considerations associated with that
> suffix. See:
> 
> https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
> 
> In particular, +xml has requirements around citing section 5 of RFC 7303
> (which this document doesn't), as well as requiring support for element()
> fragments; e.g.:
> 
> coap://example.com/temp#element(/1/3)
> 
> must be allowed as an alias for
> 
> coap://example.com/temp#rec=3
> 
> If you want to restrict other aspects of XPointerFramework fragment identifiers,
> I believe you'll have to say so explicitly.

We added XPointerFramework as alternative way for XML and EXI:
https://github.com/core-wg/senml-spec/pull/115/files

https://tools.ietf.org/html/draft-ietf-core-senml-15#section-9.2

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I share Benjamin's concerns about the ambiguity of time handling, and Ben's
> concerns about the security implications of writing to devices.

Fixed (see Benjamin's and Ben's review threads for details).

> I also have concerns about the notion of "now" and relative times with the
> streaming formats: is it relative to the time the stream was opened? Or
> relative to the time the record was received? Given that the document highlights
> time precisions down to the sub-microsecond level, and given that the record
> sizes are likely to be much smaller than the TCP maximum segment size, this
> presumably needs to take into consideration possible buffering effects due to
> Nagle's algorithm.

We clarified the "now" aspect in section 4.5.3:

  Obviously, "now"-referenced SenML records are only useful within a
  specific communication context (e.g., based on information on when
  the SenML pack, or a specific record in a SensML stream, was sent) or
  together with some other context information that can be used for
  deriving a meaning of "now"; the expectation for any archival use is
  that they will be processed into UTC-referenced records before that
  context would cease to be available.  This specification deliberately
  leaves the accuracy of "now" very vague as it is determined by the
  overall systems that use SenML.  In a system where a sensor without
  wall-clock time sends a SenML record with a "now"-referenced time
  over a high speed RS 485 link to an embedded system with accurate
  time that resolves "now" based on the time of reception, the
  resulting time uncertainty could be within 1 ms.  At the other
  extreme, a deployment that sends SenML wind speed readings over a LEO
  satellite link from a mountain valley might have resulting reception
  time values that are easily a dozen minutes off the actual time of
  the sensor reading, with the time uncertainty depending on satellite
  locations and conditions.

> ---------------------------------------------------------------------------
> 
> §4.3:
> 
>>  |    Data Value | vd    |          8 | String (*) | string (*) |
> 
> I find nowhere in the document that explains what these "(*)" notations 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.

> ---------------------------------------------------------------------------
> 
> §8:
> 
>> 8.  EXI Representation (application/senml-exi)
> 
> All the other MIME types here use the structured syntax format, which makes
> this one stick out as unnecessarily different. Given that the barrier for
> registering +exi as a suffix is "expert review," and the only real requirement
> that expert is going to check is a reference suitable for normatively citing
> (which EXI is by virtue of its appearance in the "Normative
> References" section of this document), it seems that the correct (and easy)
> thing to do here is simply go ahead and register "+exi".
> 
> As an example: we just did this for +gzip; see the RFC Editor Note at
> https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/writeup/

We have tried that path already, multiple times, and draft-shelby-exi-registration has been discussed earlier as potential solution, but it didn't progress well. At this moment we can't afford to wait anymore unfortunately.