Skip to main content

Sensor Measurement Lists (SenML)
RFC 8428

Revision differences

Document history

Date Rev. By Action
2021-11-03
16 (System) Received changes through RFC Editor sync (added Errata tag)
2021-03-29
16 Francesca Palombini Closed request for Last Call review by ARTART with state 'Overtaken by Events'
2021-02-03
16 Suhas Nandakumar Assignment of request for Last Call review by ARTART to Julian Reschke was marked no-response
2018-09-04
16 (System) IANA registries were updated to include RFC8428
2018-08-31
16 (System)
Received changes through RFC Editor sync (created alias RFC 8428, changed abstract to 'This specification defines a format for representing simple sensor measurements and …
Received changes through RFC Editor sync (created alias RFC 8428, changed abstract to 'This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML).  Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model.  A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.', changed pages to 54, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-08-31, changed IESG state to RFC Published)
2018-08-31
16 (System) RFC published
2018-08-29
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-07-19
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-07-12
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-06-06
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-06-06
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-06-06
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-05
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-06-05
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-04
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-06-04
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-01
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-05-30
16 (System) IANA Action state changed to In Progress from On Hold
2018-05-29
16 (System) IANA Action state changed to On Hold from Waiting on ADs
2018-05-25
16 (System) IANA Action state changed to Waiting on ADs from In Progress
2018-05-21
16 (System) RFC Editor state changed to EDIT
2018-05-21
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-05-21
16 (System) Announcement was received by RFC Editor
2018-05-21
16 (System) IANA Action state changed to In Progress
2018-05-21
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-05-21
16 Amy Vezza IESG has approved the document
2018-05-21
16 Amy Vezza Closed "Approve" ballot
2018-05-21
16 Amy Vezza Ballot approval text was generated
2018-05-21
16 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-05-21
16 Alexey Melnikov RFC Editor Note was changed
2018-05-21
16 Alexey Melnikov RFC Editor Note for ballot was generated
2018-05-21
16 Alexey Melnikov RFC Editor Note for ballot was generated
2018-05-18
16 Ben Campbell
[Ballot comment]
Thank you for addressing my DISCUSS by adding the additional text to section 13, and for addressing my other comments.

The change to …
[Ballot comment]
Thank you for addressing my DISCUSS by adding the additional text to section 13, and for addressing my other comments.

The change to section 13 is sufficient for me to clear the discuss, but I suggest adding a sentence to the following effect to the end of the new paragraph:

“Malicious use of SenML to change system state could have severe consequences, potentially including violation of physical security, property damage, and even loss of life."
2018-05-18
16 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2018-05-18
16 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my comments!

I am changing my position to Abstain, because I am still uncomfortable
with the possibility for non-hierarchical, …
[Ballot comment]
Thank you for addressing my comments!

I am changing my position to Abstain, because I am still uncomfortable
with the possibility for non-hierarchical, interleaving use of
base values, but recognize that the WG has consensus to do so, and
I will not stand in the way.

Original ballot text preserved below.

DISCUSS

I agree with Ben's DISCUSS.

Additionally, I have serious reservations about introducing the
concept of "base fields" that apply to subsequent array elemnets
unless overridden.  It seems to violate an abstraction barrier for
at least some of the serialization formats, and prevents snippets
from being composable and commutable absent the
resolution/normalization process.  It does not seem like the markup
language and the document contain suffient safeguards against misuse
to prevent security holes (both sensor data and commands could be
misinterpreted).  It seems that some substantially expanded text
should be added on the hazards of the non-resolved format and giving
guidance on when resolution/normalization must be performed in order
to avoid correctness and security issues.

There also seem to be sizeable risks associated with the semantics
for time values.  In particular, both with the use of an
implicit-"now-ish", and with positive and negative values being
interpreted with respect to a different absolute time base.  (The
involvement of base time is a further complication -- I do not
remember any discussion of the interaction of a (positive) base time
and a negative regular time, for example.  I also do not remember
any discussion of how the "now-ish" semantics make it actively
harmful to do things like store-and-forward or archive SenML data
(again, absent normalization), or what sort of granularity the
"now-ish" semantics are expected to adhere to.  (Is "yesterday"
still considered "roughly now"?)  I understand the desire for this
sort of semantics, but the current specification seems to leave many
potential problems exposed.

COMMENT

Section 4.4

Just "Considerations" is an unusual subject title.

Having no Unit and no Base Unit is allowed, but you don't say what
the semantics are in that case (presumably just a dimensionless
counter for integers, with units not really being applicable to
non-numeric types).  Interestingly, Section 5.1.7 deems it fit to
use "/" for the unit for a boolean value, even though "/" is
supposed to be a (continuous/floating-point) ratio.


Section 4.5

Just to double-check: you really do want to privilege this
specification's version for eternity, for the purpose of being
omitted from resolved records?


Section 12.1 is there not some other units registry we can use?  I
fear begetting https://xkcd.com/927/  .  Also, how is/should the
table be sorted?


Also in Section 12.1, number 9, is the need for case sensitivity in
Units (or otherwise?) normatively covered anywhere?  If not, should
it?



Section 12

Are Base fields supposed to get negative CBOR labels
(and not other fields)?  Is this mentioned explicitly somewhere?
(Yes, I know that the intent is for no more CBOR lablels to be
allocated, but that is only a SHOULD-level requirement.)

In
  Extensions that are mandatory to understand to correctly process the
  Pack MUST have a label name that ends with the '_' character.
should that say something about "mandatory to understand but not
defined in this document"?  (Also in 12.3.1 et seq?)


Section 13

Why are we talking about "executable content" at all?  It seems
quite unrelated to the rest of the document.
2018-05-18
16 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Abstain from Discuss
2018-05-18
16 Carsten Bormann New version available: draft-ietf-core-senml-16.txt
2018-05-18
16 (System) New version approved
2018-05-18
16 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2018-05-18
16 Carsten Bormann Uploaded new revision
2018-05-07
15 Adam Roach [Ballot comment]
Thanks for addressing my DISCUSS and comments.
2018-05-07
15 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2018-05-07
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-05-07
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-05-07
15 Ari Keränen New version available: draft-ietf-core-senml-15.txt
2018-05-07
15 (System) New version approved
2018-05-07
15 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2018-05-07
15 Ari Keränen Uploaded new revision
2018-05-07
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2018-04-26
14 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2018-04-19
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-04-19
14 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-04-19
14 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-04-19
14 Alexey Melnikov
[Ballot comment]
Authors also need to reply to the IANA review from Klaus Hartke. He has rejected some CoAP registrations as they currently stand (IANA …
[Ballot comment]
Authors also need to reply to the IANA review from Klaus Hartke. He has rejected some CoAP registrations as they currently stand (IANA ticket #1055261), and he hasn't heard back from the authors yet.
2018-04-19
14 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-04-19
14 Adam Roach
[Ballot discuss]
Thanks to everyone who contributed to this document.

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

§9 defines a URI fragment identification scheme that is intended to apply to
senml+xml …
[Ballot 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.
2018-04-19
14 Adam Roach
[Ballot 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 …
[Ballot 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.

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

§4.3:

>    |    Data Value | vd    |          8 | String (*) | string (*) |

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

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

§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/
2018-04-19
14 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2018-04-18
14 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-04-18
14 Benjamin Kaduk
[Ballot discuss]
I agree with Ben's DISCUSS.

Additionally, I have serious reservations about introducing the
concept of "base fields" that apply to subsequent array elemnets …
[Ballot discuss]
I agree with Ben's DISCUSS.

Additionally, I have serious reservations about introducing the
concept of "base fields" that apply to subsequent array elemnets
unless overridden.  It seems to violate an abstraction barrier for
at least some of the serialization formats, and prevents snippets
from being composable and commutable absent the
resolution/normalization process.  It does not seem like the markup
language and the document contain suffient safeguards against misuse
to prevent security holes (both sensor data and commands could be
misinterpreted).  It seems that some substantially expanded text
should be added on the hazards of the non-resolved format and giving
guidance on when resolution/normalization must be performed in order
to avoid correctness and security issues.

There also seem to be sizeable risks associated with the semantics
for time values.  In particular, both with the use of an
implicit-"now-ish", and with positive and negative values being
interpreted with respect to a different absolute time base.  (The
involvement of base time is a further complication -- I do not
remember any discussion of the interaction of a (positive) base time
and a negative regular time, for example.  I also do not remember
any discussion of how the "now-ish" semantics make it actively
harmful to do things like store-and-forward or archive SenML data
(again, absent normalization), or what sort of granularity the
"now-ish" semantics are expected to adhere to.  (Is "yesterday"
still considered "roughly now"?)  I understand the desire for this
sort of semantics, but the current specification seems to leave many
potential problems exposed.
2018-04-18
14 Benjamin Kaduk
[Ballot comment]
Section 4.4

Just "Considerations" is an unusual subject title.

Having no Unit and no Base Unit is allowed, but you don't say what …
[Ballot comment]
Section 4.4

Just "Considerations" is an unusual subject title.

Having no Unit and no Base Unit is allowed, but you don't say what
the semantics are in that case (presumably just a dimensionless
counter for integers, with units not really being applicable to
non-numeric types).  Interestingly, Section 5.1.7 deems it fit to
use "/" for the unit for a boolean value, even though "/" is
supposed to be a (continuous/floating-point) ratio.


Section 4.5

Just to double-check: you really do want to privilege this
specification's version for eternity, for the purpose of being
omitted from resolved records?


Section 12.1 is there not some other units registry we can use?  I
fear begetting https://xkcd.com/927/  .  Also, how is/should the
table be sorted?


Also in Section 12.1, number 9, is the need for case sensitivity in
Units (or otherwise?) normatively covered anywhere?  If not, should
it?



Section 12

Are Base fields supposed to get negative CBOR labels
(and not other fields)?  Is this mentioned explicitly somewhere?
(Yes, I know that the intent is for no more CBOR lablels to be
allocated, but that is only a SHOULD-level requirement.)

In
  Extensions that are mandatory to understand to correctly process the
  Pack MUST have a label name that ends with the '_' character.
should that say something about "mandatory to understand but not
defined in this document"?  (Also in 12.3.1 et seq?)


Section 13

Why are we talking about "executable content" at all?  It seems
quite unrelated to the rest of the document.
2018-04-18
14 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-04-18
14 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-04-18
14 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2018-04-18
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-04-18
14 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-04-18
14 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-04-17
14 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2018-04-16
14 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4594







COMMENTS

>  Abstract

>      This specification defines media types for representing simple …
[Ballot 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.


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


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


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



>      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


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


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


>                      | Encoding | Size | Compressed Size |
>                      +----------+------+-----------------+
>                      | JSON    |  573 |            206 |
>                      | XML      |  649 |            235 |
>                      | CBOR    |  254 |            196 |
>                      | EXI      |  161 |            184 |

Compression not working out so well for EXI



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



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


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


>      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
2018-04-16
14 Eric Rescorla Ballot comment text updated for Eric Rescorla
2018-04-16
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-04-15
14 Ben Campbell
[Ballot 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 …
[Ballot 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.
2018-04-15
14 Ben Campbell
[Ballot comment]
Substantive:

§4.4: "If this value is a version number larger than the version which the
  system understands, the system SHOULD NOT use …
[Ballot 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
2018-04-15
14 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2018-04-15
14 Spencer Dawkins [Ballot comment]
Thank you for doing this work. It's impressive.
2018-04-15
14 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2018-04-15
14 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4594







COMMENTS

>  Abstract

>      This specification defines media types for representing simple …
[Ballot 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.


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


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


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



>      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


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


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


>                      | Encoding | Size | Compressed Size |
>                      +----------+------+-----------------+
>                      | JSON    |  573 |            206 |
>                      | XML      |  649 |            235 |
>                      | CBOR    |  254 |            196 |
>                      | EXI      |  161 |            184 |

Compression not working out so well for EXI



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



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


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


>      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
2018-04-15
14 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-04-14
14 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2018-04-14
14 Alexey Melnikov Ballot has been issued
2018-04-14
14 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-04-14
14 Alexey Melnikov Created "Approve" ballot
2018-04-14
14 Alexey Melnikov Ballot writeup was changed
2018-04-08
14 Roni Even Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list.
2018-04-05
14 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2018-04-05
14 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2018-04-02
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-04-02
14 Ari Keränen New version available: draft-ietf-core-senml-14.txt
2018-04-02
14 (System) New version approved
2018-04-02
14 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2018-04-02
14 Ari Keränen Uploaded new revision
2018-04-01
14 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2018-04-01
14 Ari Keränen Uploaded new revision
2018-04-01
13 Alexey Melnikov Ballot writeup was changed
2018-03-30
13 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-03-29
13 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-03-29
13 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-core-senml-13. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-core-senml-13. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are twelve actions which we must complete.

First, a new registry will be created called the SenML Unit Symbols registry. The new registry will be manged via Expert Review as defined in RFC 8126.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

There initial registrations and notes for the new registry as follows:

+----------+------------------------------------+-------+----------------+
| Symbol | Description | Type | Reference |
+----------+------------------------------------+-------+----------------+
| m | meter | float | [ RFC-to-be ] |
| kg | kilogram | float | [ RFC-to-be ] |
| g | gram* | float | [ RFC-to-be ] |
| s | second | float | [ RFC-to-be ] |
| A | ampere | float | [ RFC-to-be ] |
| K | kelvin | float | [ RFC-to-be ] |
| cd | candela | float | [ RFC-to-be ] |
| mol | mole | float | [ RFC-to-be ] |
| Hz | hertz | float | [ RFC-to-be ] |
| rad | radian | float | [ RFC-to-be ] |
| sr | steradian | float | [ RFC-to-be ] |
| N | newton | float | [ RFC-to-be ] |
| Pa | pascal | float | [ RFC-to-be ] |
| J | joule | float | [ RFC-to-be ] |
| W | watt | float | [ RFC-to-be ] |
| C | coulomb | float | [ RFC-to-be ] |
| V | volt | float | [ RFC-to-be ] |
| F | farad | float | [ RFC-to-be ] |
| Ohm | ohm | float | [ RFC-to-be ] |
| S | siemens | float | [ RFC-to-be ] |
| Wb | weber | float | [ RFC-to-be ] |
| T | tesla | float | [ RFC-to-be ] |
| H | henry | float | [ RFC-to-be ] |
| Cel | degrees Celsius | float | [ RFC-to-be ] |
| lm | lumen | float | [ RFC-to-be ] |
| lx | lux | float | [ RFC-to-be ] |
| Bq | becquerel | float | [ RFC-to-be ] |
| Gy | gray | float | [ RFC-to-be ] |
| Sv | sievert | float | [ RFC-to-be ] |
| kat | katal | float | [ RFC-to-be ] |
| m2 | square meter (area) | float | [ RFC-to-be ] |
| m3 | cubic meter (volume) | float | [ RFC-to-be ] |
| l | liter (volume)* | float | [ RFC-to-be ] |
| m/s | meter per second (velocity) | float | [ RFC-to-be ] |
| m/s2 | meter per square second | float | [ RFC-to-be ] |
| | (acceleration) | | |
| m3/s | cubic meter per second (flow rate) | float | [ RFC-to-be ] |
| l/s | liter per second (flow rate)* | float | [ RFC-to-be ] |
| W/m2 | watt per square meter (irradiance) | float | [ RFC-to-be ] |
| cd/m2 | candela per square meter | float | [ RFC-to-be ] |
| | (luminance) | | |
| bit | bit (information content) | float | [ RFC-to-be ] |
| bit/s | bit per second (data rate) | float | [ RFC-to-be ] |
| lat | degrees latitude (note 1) | float | [ RFC-to-be ] |
| lon | degrees longitude (note 1) | float | [ RFC-to-be ] |
| pH | pH value (acidity; logarithmic | float | [ RFC-to-be ] |
| | quantity) | | |
| dB | decibel (logarithmic quantity) | float | [ RFC-to-be ] |
| dBW | decibel relative to 1 W (power | float | [ RFC-to-be ] |
| | level) | | |
| Bspl | bel (sound pressure level; | float | [ RFC-to-be ] |
| | logarithmic quantity)* | | |
| count | 1 (counter value) | float | [ RFC-to-be ] |
| / | 1 (Ratio e.g., value of a switch, | float | [ RFC-to-be ] |
| | note 2) | | |
| % | 1 (Ratio e.g., value of a switch, | float | [ RFC-to-be ] |
| | note 2)* | | |
| %RH | Percentage (Relative Humidity) | float | [ RFC-to-be ] |
| %EL | Percentage (remaining battery | float | [ RFC-to-be ] |
| | energy level) | | |
| EL | seconds (remaining battery energy | float | [ RFC-to-be ] |
| | level) | | |
| 1/s | 1 per second (event rate) | float | [ RFC-to-be ] |
| 1/min | 1 per minute (event rate, "rpm")* | float | [ RFC-to-be ] |
| beat/min | 1 per minute (Heart rate in beats | float | [ RFC-to-be ] |
| | per minute)* | | |
| beats | 1 (Cumulative number of heart | float | [ RFC-to-be ] |
| | beats)* | | |
| S/m | Siemens per meter (conductivity) | float | [ RFC-to-be ] |
+----------+------------------------------------+-------+----------------+

o Note 1: Assumed to be in WGS84 unless another reference frame is known for the sensor.

o Note 2: A value of 0.0 indicates the switch is off while 1.0 indicates on and 0.5 would be half on. The preferred name of this unit is "/". For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio!

Second, a new registry will be created called the SenML Label registry. The new registry will be manged via Expert Review as defined in RFC 8126.

IANA QUESTION --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

There are initial registrations in the new registry as follows:

+--------------+-------+----+-----------+----------+----+-----------------+
+ Name | Label | CL | JSON Type | XML Type | EI | Reference |
+--------------+-------+----+-----------+----------+----+-----------------+
| Base Name | bn | -2 | String | string | a | [ RFC-to-be ] |
| Base Time | bt | -3 | Number | double | a | [ RFC-to-be ] |
| Base Unit | bu | -4 | String | string | a | [ RFC-to-be ] |
| Base Value | bv | -5 | Number | double | a | [ RFC-to-be ] |
| Base Sum | bs | -6 | Number | double | a | [ RFC-to-be ] |
| Base Version | bver | -1 | Number | int | a | [ RFC-to-be ] |
| Name | n | 0 | String | string | a | [ RFC-to-be ] |
| Unit | u | 1 | String | string | a | [ RFC-to-be ] |
| Value | v | 2 | Number | double | a | [ RFC-to-be ] |
| String Value | vs | 3 | String | string | a | [ RFC-to-be ] |
| Boolean | vb | 4 | Boolean | boolean | a | [ RFC-to-be ] |
| Value | | | | | | |
| Data Value | vd | 8 | String | string | a | [ RFC-to-be ] |
| Value Sum | s | 5 | Number | double | a | [ RFC-to-be ] |
| Time | t | 6 | Number | double | a | [ RFC-to-be ] |
| Update Time | ut | 7 | Number | double | a | [ RFC-to-be ] |
+--------------+-------+----+-----------+----------+----+-----------------+

Third, in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: senml+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fourth, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: sensml+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fifth, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: senml+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Sixth, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: sensml+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Seventh, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: senml+xml
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Eighth, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: sensml+xml
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Ninth, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: senml+exi
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Tenth, also in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a new Media Type will be registered as follows:

Name: sensml+exi
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Eleventh, in the namespace (ns) registry on the IETF XML registry page located at:

https://www.iana.org/assignments/xml-registry/

a new registration will be made as follows:

ID: senml
URI: urn:ietf:params:xml:ns:senml
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Twelveth, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

the following, eight assignments are to be made:

Media Type: application/senml+json
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: application/sensml+json
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: application/senml+cbor
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: applicatisml+cboron/sen
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: application/senml+xml
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: application/sensml+xml
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: application/senml-exi
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media Type: application/sensml-exi
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA QUESTION --> Should the value for "Encoding" be left blank for these CoAP Content-Formats be blank?

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-03-28
13 Suhas Nandakumar Request for Last Call review by ARTART is assigned to Julian Reschke
2018-03-28
13 Suhas Nandakumar Request for Last Call review by ARTART is assigned to Julian Reschke
2018-03-27
13 Roni Even Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list.
2018-03-12
13 Alexey Melnikov Placed on agenda for telechat - 2018-04-19
2018-03-08
13 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2018-03-08
13 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2018-03-08
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Steve Hanna
2018-03-08
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Steve Hanna
2018-03-02
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2018-03-02
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2018-03-02
13 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-03-02
13 Amy Vezza
The following Last Call announcement was sent out (ends 2018-03-30):

From: The IESG
To: IETF-Announce
CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-senml@ietf.org, Jaime Jimenez , …
The following Last Call announcement was sent out (ends 2018-03-30):

From: The IESG
To: IETF-Announce
CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-senml@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Media Types for Sensor Measurement Lists (SenML)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Media Types for Sensor
Measurement Lists (SenML)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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
  (JSON), Concise Binary Object Representation (CBOR), eXtensible
  Markup Language (XML), and Efficient XML Interchange (EXI), which
  share the common SenML data model.  A simple sensor, such as a
  temperature sensor, could use one of these media types in protocols
  such as HTTP or CoAP to transport the measurements of the sensor or
  to be configured.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-senml/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-senml/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-03-02
13 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-03-02
13 Amy Vezza Last call announcement was changed
2018-03-02
13 Alexey Melnikov Last call was requested
2018-03-02
13 Alexey Melnikov IESG state changed to Last Call Requested from Last Call Requested::AD Followup
2018-03-02
13 Alexey Melnikov Last call was requested
2018-03-02
13 Alexey Melnikov Last call announcement was generated
2018-03-02
13 Alexey Melnikov Ballot approval text was generated
2018-03-02
13 Alexey Melnikov Ballot writeup was generated
2018-03-02
13 Alexey Melnikov IESG state changed to Last Call Requested::AD Followup from AD Evaluation::AD Followup
2018-03-02
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-03-02
13 Ari Keränen New version available: draft-ietf-core-senml-13.txt
2018-03-02
13 (System) New version approved
2018-03-02
13 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2018-03-02
13 Ari Keränen Uploaded new revision
2018-01-11
12 Alexey Melnikov IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2018-01-10
12 Alexey Melnikov Changed consensus to Yes from Unknown
2018-01-10
12 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2017-12-19
12 Jaime Jimenez
Full writeup and summary is available at: http://jaimejim.github.io/temp/draft-ietf-core-senml

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This specification defines …
Full writeup and summary is available at: http://jaimejim.github.io/temp/draft-ietf-core-senml

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

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
(JSON), Concise Binary Object Representation (CBOR), eXtensible
Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model.  A simple sensor, such as a
temperature sensor, could use this media type in protocols such as
HTTP or CoAP to transport the measurements of the sensor or to be
configured.

The document is intended for Standards Track.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out. The document creates two new registries, a content type and various media types.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`Q: Are the new media type IDs assigned sequentially or do we request something concrete to IANA? URL to check http://www.iana.org/assignments/core-parameters/core-parameters.xhtml`
`A: I think a sequence of 8 values starting from a round number (for easy mnemonic) would make sense. But could check with the experts what's the policy here`

* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?`I believe so, double check with Carsten on the new registries.`
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? `There was one update coming for this regarding Jim Schaad review comment`
2017-12-19
12 Jaime Jimenez IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2017-12-19
12 Jaime Jimenez IESG state changed to Publication Requested from AD is watching
2017-12-14
12 Jaime Jimenez
Full writeup and summary is available at: http://jaimejim.github.io/temp/draft-ietf-core-senml

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This specification defines …
Full writeup and summary is available at: http://jaimejim.github.io/temp/draft-ietf-core-senml

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

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
(JSON), Concise Binary Object Representation (CBOR), eXtensible
Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model.  A simple sensor, such as a
temperature sensor, could use this media type in protocols such as
HTTP or CoAP to transport the measurements of the sensor or to be
configured.

The document is intended for Standards Track.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out. The document creates two new registries, a content type and various media types.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`Q: Are the new media type IDs assigned sequentially or do we request something concrete to IANA? URL to check http://www.iana.org/assignments/core-parameters/core-parameters.xhtml`
`A: I think a sequence of 8 values starting from a round number (for easy mnemonic) would make sense. But could check with the experts what's the policy here`

* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?`I believe so, double check with Carsten on the new registries.`
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? `There was one update coming for this regarding Jim Schaad review comment`
2017-12-14
12 Ari Keränen New version available: draft-ietf-core-senml-12.txt
2017-12-14
12 (System) New version approved
2017-12-14
12 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2017-12-14
12 Ari Keränen Uploaded new revision
2017-10-30
11 Ari Keränen New version available: draft-ietf-core-senml-11.txt
2017-10-30
11 (System) New version approved
2017-10-30
11 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Zach Shelby , Cullen Jennings , Ari Keranen , Jari Arkko
2017-10-30
11 Ari Keränen Uploaded new revision
2017-09-06
10 Jaime Jimenez Notification list changed to Jaime Jimenez <jaime.jimenez@ericsson.com>
2017-09-06
10 Jaime Jimenez Document shepherd changed to Jaime Jimenez
2017-07-07
10 Jaime Jimenez IETF WG state changed to In WG Last Call from WG Document
2017-07-03
10 Ari Keränen New version available: draft-ietf-core-senml-10.txt
2017-07-03
10 (System) New version approved
2017-07-03
10 (System) Request for posting confirmation emailed to previous authors: Jari Arkko , Zach Shelby , Cullen Jennings , Ari Keranen , Carsten Bormann
2017-07-03
10 Ari Keränen Uploaded new revision
2017-06-29
09 Cullen Jennings New version available: draft-ietf-core-senml-09.txt
2017-06-29
09 (System) New version approved
2017-06-29
09 (System) Request for posting confirmation emailed to previous authors: Jari Arkko , Zach Shelby , Cullen Jennings , Ari Keranen , Carsten Bormann
2017-06-29
09 Cullen Jennings Uploaded new revision
2017-05-23
08 Cullen Jennings New version available: draft-ietf-core-senml-08.txt
2017-05-23
08 (System) New version approved
2017-05-23
08 (System) Request for posting confirmation emailed to previous authors: Jari Arkko , core-chairs@ietf.org, Carsten Bormann , Zach Shelby , Cullen Jennings , =?utf-8?q?Ari_Ker=C3=A4nen?=
2017-05-23
08 Cullen Jennings Uploaded new revision
2017-05-04
07 Cullen Jennings New version available: draft-ietf-core-senml-07.txt
2017-05-04
07 (System) New version approved
2017-05-04
07 (System) Request for posting confirmation emailed to previous authors: Jari Arkko , core-chairs@ietf.org, Carsten Bormann , Zach Shelby , Cullen Jennings , =?utf-8?q?Ari_Ker=C3=A4nen?=
2017-05-04
07 Cullen Jennings Uploaded new revision
2017-05-04
06 Cullen Jennings New version available: draft-ietf-core-senml-06.txt
2017-05-04
06 (System) New version approved
2017-05-04
06 (System) Request for posting confirmation emailed to previous authors: Jari Arkko , core-chairs@ietf.org, Carsten Bormann , Zach Shelby , Cullen Jennings , =?utf-8?q?Ari_Ker=C3=A4nen?=
2017-05-04
06 Cullen Jennings Uploaded new revision
2017-03-13
05 Cullen Jennings New version available: draft-ietf-core-senml-05.txt
2017-03-13
05 (System) New version approved
2017-03-13
05 (System) Request for posting confirmation emailed to previous authors: Jari Arkko , core-chairs@ietf.org, Carsten Bormann , Zach Shelby , Cullen Jennings , =?utf-8?q?Ari_Ker=C3=A4nen?=
2017-03-13
05 Cullen Jennings Uploaded new revision
2016-10-31
04 Cullen Jennings New version available: draft-ietf-core-senml-04.txt
2016-10-31
04 (System) New version approved
2016-10-31
03 (System) Request for posting confirmation emailed to previous authors: "Cullen Jennings" , "Carsten Bormann" , "Zach Shelby" , "Ari Keranen" , "Jari Arkko"
2016-10-31
03 Cullen Jennings Uploaded new revision
2016-10-07
03 Cullen Jennings New version available: draft-ietf-core-senml-03.txt
2016-10-07
03 (System) New version approved
2016-10-07
02 (System) Request for posting confirmation emailed to previous authors: "Cullen Jennings" , "Carsten Bormann" , "Zach Shelby" , "Ari Keranen" , "Jari Arkko"
2016-10-07
02 Cullen Jennings Uploaded new revision
2016-07-08
02 Cullen Jennings New version available: draft-ietf-core-senml-02.txt
2016-07-08
01 Cullen Jennings New version available: draft-ietf-core-senml-01.txt
2016-04-23
00 Alexey Melnikov Intended Status changed to Proposed Standard
2016-04-23
00 Alexey Melnikov IESG process started in state AD is watching
2016-04-23
00 (System) Earlier history may be found in the Comment Log for /doc/draft-jennings-core-senml/
2016-04-19
00 Carsten Bormann This document now replaces draft-jennings-core-senml instead of None
2016-04-19
00 Cullen Jennings New version available: draft-ietf-core-senml-00.txt