Re: [core] Eric Rescorla's No Objection on draft-ietf-core-senml-14: (with COMMENT)

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

Thank you for the review Eric!

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 22.56, Eric Rescorla <[e-mail]> wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-core-senml-14: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4594
> 
> 
> COMMENTS
>> 
>> Abstract
>> 
>>    This specification defines media types for representing simple sensor
>>    measurements and device parameters in the Sensor Measurement Lists
>>    (SenML).  Representations are defined in JavaScript Object Notation
> 
> You're kind of burying the lede here. This document defines SenML, it
> doesn't just define media type.

True, and also commented by others. Changed now to:

  This specification defines a format for representing simple sensor
  measurements and device parameters in the Sensor Measurement Lists
  (SenML). 

>>    measurement every second, batch up 60 of them, and then send the
>>    batch to a server.  It would include the relative time each
>>    measurement was made compared to the time the batch was sent in each
>>    SenML Record.  The server might have accurate NTP time and use the
>>    time it received the data, and the relative offset, to replace the
>>    times in the SenML with absolute times before saving the SenML Pack
> 
> You use "Pack" here before you define it in  S 3.

Changed to:

  The server might have accurate NTP time and use the
  time it received the data, and the relative offset, to replace the
  times in the SenML with absolute times before saving the SenML
  information in a document database.

>>    kinds of fields: base and regular.  The base fields can be included
>>    in any SenML Record and they apply to the entries in the Record.
>>    Each base field also applies to all Records after it up to, but not
>>    including, the next Record that has that same base field.  All base
>>    fields are optional.  Regular fields can be included in any SenML
>>    Record and apply only to that Record.
> 
> It looks like it's permissible to intermix Base and Regular fields in
> the same record. Assuming that's so, it would be helpful to say so.

Yes, made this now more explicit:

  kinds of fields: base and regular.  Both the base fields and the
  regular fields can be included in any SenML Record.  The base fields
  apply to the entries in the Record and also to all Records after it
  up to, but not including, the next Record that has that same base
  field.  All base fields are optional.  Regular fields can be included
  in any SenML Record and apply only to that Record.


>>       ("vs" for "String Value") and binary data ("vd" for "Data Value").
>>       Exactly one value field MUST appear unless there is Sum field in
>>       which case it is allowed to have no Value field.
>> 
>>    Sum:  Integrated sum of the values over time.  Optional.  This field
>>       is in the unit specified in the Unit value multiplied by seconds.
> 
> This text is hard to read, but the dimensional analysis seems
> potentially wrong, for at least some measurements. I assume you're
> thinking of something like watts and watt-hours. but if the value is
> for instance bits, then "bit-seconds" is not a meaningful unit, and
> yet you might want to sum these.

True. The name "sum" is actually not fully correct, but there are historical reasons why it's called so. Updated the text to reflect this:

  Sum:  Integrated sum of the values over time.  Optional.  This field
     is in the unit specified in the Unit value multiplied by seconds.
     For historical reason it is named sum instead of integral.

Also clarified more the use of the sum in Section 10.

>>    The SenML format can be extended with further custom fields.  Both
>>    new base and regular fields are allowed.  See Section 12.2 for
>>    details.  Implementations MUST ignore fields they don't recognize
>>    unless that field has a label name that ends with the '_' character
>>    in which case an error MUST be generated.
> 
> How does this map to CBOR? I see you explain this later, but here
> would be helpful

We discussed this and concluded that the SenML is format agnostic in this matter so there should be no surprise here. 

>>    concatenated name MUST consist only of characters out of the set "A"
>>    to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_";
>>    furthermore, it MUST start with a character out of the set "A" to
>>    "Z", "a" to "z", or "0" to "9".  This restricted character set was
>>    chosen so that concatenated names can be used directly within various
>>    URI schemes (including segments of an HTTP path with no special
> 
> Assuming I am understanding this correctly, then "/" is a problem
> inside a path component.

Yes, clarified this with:

  URI schemes (including segments of an HTTP path with no special
  encoding; note that a name that contains "/" characters maps into
  multiple URI path segments) 

>>    specified above puts strict limits on the URI schemes and URN
>>    namespaces that can be used.  As a result, implementers need to take
>>    care in choosing the naming scheme for concatenated names, because
>>    such names both need to be unique and need to conform to the
>>    restricted character set.  One approach is to include a bit string
>>    that has guaranteed uniqueness (such as a 1-wire address).  Some of
> 
> citation for 1-wire please.

Added informative reference:

  [AN1796]   Linke, B., "Overview of 1-Wire Technology and Its Use",
             June 2008,
             <http://pdfserv.maximintegrated.com/en/an/AN1796.pdf>.

>>                    | Encoding | Size | Compressed Size |
>>                    +----------+------+-----------------+
>>                    | JSON     |  573 |             206 |
>>                    | XML      |  649 |             235 |
>>                    | CBOR     |  254 |             196 |
>>                    | EXI      |  161 |             184 |
> 
> Compression not working out so well for EXI

Indeed.

>>    To select a single SenML Record, the "rec" scheme followed by a
>>    single number is used.  For the purpose of numbering records, the
>>    first record is at position 1.  A range of records can be selected by
>>    giving the first and the last record number separated by a '-'
>>    character.  Instead of the second number, the '*' character can be
> 
> This is an odd notation as * usually means "all". Why not just omit
> the terminal #?

Yes, we re-used the fragment format from RFC7111 that was using the terminal "*":
https://tools.ietf.org/html/rfc7111#section-2.1

Seems to make sense to be consistent here, but no strong opinions.

>>    New entries can be added to the registration by Expert Review as
>>    defined in [RFC8126].  Experts should exercise their own good
>>    judgment but need to consider that shorter labels should have more
>>    strict review.  New entries should not be made that counteract the
>>    advice at the end of Section 4.4.
> 
> Note that you say earlier that you don't expect to define new CBOR
> integers. That should probably be repeated here.

We had a second look at this and the recommendation two paragraphs earlier seemed to be quite sufficient to cover this. This paragraph was now slightly modified to reference new structure of Section 4 though. 

>>    Sensor data can range from information with almost no security
>>    considerations, such as the current temperature in a given city, to
>>    highly sensitive medical or location data.  This specification
>>    provides no security protection for the data but is meant to be used
>>    inside another container or transport protocol such as S/MIME
>>    [RFC5751] or HTTP with TLS [RFC5246] that can provide integrity,
> 
> This is the wrong citation for HTTP over TLS. That's RFC 2818.

Fixed.

>>    We would like to thank Alexander Pelov, Alexey Melnikov, Andrew
>>    McClure, Andrew McGregor, Bjoern Hoehrmann, Christian Amsuess,
>>    Christian Groves, Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe
>>    Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa
>>    Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, Peter
>>    Saint-Andre, Roni Even, and Stephen Farrell, for their review
> 
> Nit: no comma after Farrell

Fixed.