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

Discussion:

Adam Roach

2018-04-19 07:14:13 UTC

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.

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

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

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.

---------------------------------------------------------------------------

I find nowhere in the document that explains what these "(*)" notations mean.

---------------------------------------------------------------------------

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/

Alexey Melnikov

2018-04-19 12:43:07 UTC

Permalink

Hi Adam,

Post by Adam Roach
§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
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

Hmm, I forgot about that!

Post by Adam Roach
In particular, +xml has requirements around citing section 5 of RFC 7303
(which this document doesn't), as well as requiring support for element()
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.

I don't think there is a need to deviate from generic +xml fragment handling.

I suggest that the Section 9 of this draft:

9. Fragment Identification Methods

is updated to reference Section 5 of [RFC7303], plus your example is added. Then the media type registrations don't need to be updated, as they already reference the fragment handling in Section 9. Does this work for you?

Best Regards,
Alexey

Adam Roach

2018-04-19 13:02:15 UTC

Permalink

This works for me as well, as long as the WG doesn’t object.

/a

Post by Alexey Melnikov
Hi Adam,

Hmm, I forgot about that!

I don't think there is a need to deviate from generic +xml fragment handling.
9. Fragment Identification Methods
is updated to reference Section 5 of [RFC7303], plus your example is added. Then the media type registrations don't need to be updated, as they already reference the fragment handling in Section 9. Does this work for you?
Best Regards,
Alexey

Carsten Bormann

2018-04-19 14:56:42 UTC

Permalink

Hi Alexey,

Post by Alexey Melnikov
Hi Adam,

Hmm, I forgot about that!

I don’t think there is a need to deviate from generic +xml fragment handling.

Klaus pointed out that this is counterproductive in a content-negotiation setting.

If I have

Post by Alexey Melnikov

Post by Adam Roach
coap://example.com/temp#rec=3

Post by Alexey Melnikov

Post by Adam Roach
coap://example.com/temp#element(/1/3)

The server is not going to see the fragment identifier, so it doesn’t know that, in the first case, all SenML variants could be handled by the client, and in the second case, only XML should be sent.

So we really want the fragment identifiers for all SenML variants to be the same.

RFC 7303 says:

If [XPointerFramework] and [XPointerElement] are inappropriate for
some XML-based media type, it SHOULD NOT follow the naming convention
‘+xml’.

Maybe choosing “-xml” is actually the (radical) answer (which also would reestablish symmetry between -xml and -exi).

(We are still discussing whether this observation is also disqualifying +json and +cbor.)

Grüße, Carsten

Ari Keränen

2018-05-07 18:00:06 UTC

Permalink

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

Post by Adam Roach
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.
https://datatracker.ietf.org/doc/draft-ietf-core-senml/
----------------------------------------------------------------------
----------------------------------------------------------------------
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
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()
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

Post by Adam Roach
----------------------------------------------------------------------
----------------------------------------------------------------------
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).

Post by Adam Roach
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.

Post by Adam Roach
---------------------------------------------------------------------------

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.

Post by Adam Roach
---------------------------------------------------------------------------

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.