Sensor Measurement Lists (SenML) Features and Versions
draft-ietf-core-senml-versions-05

[Ballot comment]
I only have a few nits to contribute here.

In Section 2:

  The present specification defines "SenML Features", each identified
  by a "feature name" (a text string) and a "feature code", an unsigned
  integer less than 53.

Why is the former descriptive clause parenthetical, while the latter is separated by a comma?

In Section 2.1, I think all the instances of "less" should actually be "fewer".

[Ballot comment]
Thank you for writing this, and in such a clear, understandable (and concise!) manner.

I have a nit on the -03 version - in the "image" we have a misrender:
 ⋅ 2

[Ballot comment]
Thanks, this is nicely written and a reasonable approach.

Section 3

I think I'm supposed to interpret this as being "the exact bit pattern
1010 in the last four bits indicates support for the base SenML version
defined in RFC 8428; any other bitstring in that position cannot be
taken as an indication of support for the base version".  In other
words, we're still getting a one-bit signal, just encoded in four bits.
Is that right?  Or maybe just "it's an error to see any other values for
those four bits"?  (If so, do we reject the entire pack?)

Section 5

I'd consider adding a sentence "the assignment of new feature bits is
done in a backwards-compatible manner, so existing implementations will
not erroneously assume support for a version (feature) that is defined
in the future" in the vein of an avoided security consideration.

[Ballot comment]
Hi,

Thanks for the this document.  Just a couple of minor comments.

It looked like the equation in section 2 was mucked up in the text version of the doc.  Presumably this will get fixed during the editing process:

I.e.,
              __ 52                      fc
  version = \        present(fc) ⋅ 2
            /__ fc = 0


  Quantitatively, the expert could for instance steer the allocation to
  not allocate more than 10 % of the remaining set per year.

Rather than setting this is a limit, I would suggest that it is better to set this as a target.  E.g., if it turns out that there is a good justification for an extension, it would be a shame if it had to be delayed by a year merely to fit into a somewhat arbitrary rate limiting scheme.

Besides, if you end up with 53 different optional extensions, then I suspect that the bigger problem will be that there are too many variants of what is supported by different implementations which will reduce interop, and you'll probably want to end up with batches of extensions that are expected to be supported together, i.e., some sort of hybrid between completely independent extensions and a strict linear version scheme.

Rob

[Ballot comment]
Thank you for the work put into this document.

Please find below one  non-blocking COMMENT points (but replies would be appreciated), and some nits.

Thanks to Jaime Jiménez for his shepherd's write-up (including the WG consensus) even if I regret that no motivation is given about the intended RFC status. Thank you Carsten for acknowledging Jaime's work.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.2 --
While the motivation for the update is explained, is there any reason why the usual OLD TEXT / NEW TEXT is not used here?


== NITS ==

-- Section 2 --
Even with the warning in section 1.1, it took me a while to 'see' the Sigma sign (and the   were not helping). Suggest to 'show' it in section 1.1. OTOH, congratulations for using the XMLv3 features for the SVG equivalent, quite neat.

The whole text of this section is quite convoluted as it is a plain bit mask.

[Ballot comment]
Given the very constrained space, I wonder if it's wise to reserve 0 and 2 for no real purpose. IIUC these would still result in version numbers > 10 and therefore not break anything, yes?

[Ballot comment]
Section 7.1, paragraph 4, comment:
>    [IANA.senml]
>              IANA, "Sensor Measurement Lists (SenML)",
>              .

Not sure if a normative reference to an IANA registry page is technically OK; it
should probably cite the RFC that created that registry instead, and maybe add
an informative reference to the registry page?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1, paragraph 4, nit:
-    decimal numbers, e.g. 26 (0b11010, 0x1a) for a version that adds the
+    decimal numbers, e.g., 26 (0b11010, 0x1a) for a version that adds the
+                        +

The text version of this document contains these HTML entities, which might
indicate issues with its XML source:  

Section 1, paragraph 2, nit:
> es additional features over time. However in the case of SenML it is expecte
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 3, paragraph 2, nit:
>  secondary unit names [RFC8798] MAY be be used in the "u" field of SenML Reco
>                                    ^^^^^
Possible typo: you repeated a word

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/senml

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the SenML Features registry. The new registry will be located on the Sensor Measurement Lists (SenML) registry page located at:

https://www.iana.org/assignments/senml/

The new registry will be managed via Specification Required as defined by RFC 8126. There are initial registrations in the new registry as follows:

+==============+=================+===============+
| Feature code | Feature name | Specification |
+==============+=================+===============+
| 0 | Reserved0 | RFC-to-be |
+--------------+-----------------+---------------+
| 1 | Reserved1 | RFC-to-be |
+--------------+-----------------+---------------+
| 2 | Reserved2 | RFC-to-be |
+--------------+-----------------+---------------+
| 3 | Reserved3 | RFC-to-be |
+--------------+-----------------+---------------+
| 4 | Secondary Units | RFC-to-be |
+--------------+-----------------+---------------+
| 5-53 | Unassigned |
+--------------+-----------------+---------------+

The IANA Functions Operator understands that this is the only action 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

The following Last Call announcement was sent out (ends 2021-05-03):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-versions@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SenML Features and Versions) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'SenML Features and Versions'
  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
last-call@ietf.org mailing lists by 2021-05-03. 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 short document updates RFC 8428, Sensor Measurement Lists
  (SenML), by specifying the use of independently selectable "SenML
  Features" and mapping them to SenML version numbers.




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



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

## Shepherd Writeup

This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which SenML "features" are active. Feature codes are used to express which features are available. The document registers feature codes 0,1,2,3 for the first 4 reserved features the 5th feature code is reserved for when RFC8798 is used.

A new subregistry is created within the SenML IANA registry, named "SenML features".

The document sets a hard limit for the number of SenML features that can be registered (with only 48 codes left). Expert reviewers should then be very conservative with the allocation of the remaining feature codes.

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

This document specifies how SenML versions are represented and creates a sub-registry of SenML Features, which are used to calculate the SenML version. The document is intended for Standards Track and updates RFC8428.

### Review and Consensus

The document was reviewed (https://mailarchive.ietf.org/arch/msg/core/5cWnixOE8nX4HTIy5w3rE4Whpo8/ ) and discussed in several IETF meetings. Most of the comments were regarding the hard limit to feature codes and therefore of version numbers.

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

The document creates a sub-registry named "SenML features" and updates the SenML RFC (RFC8428). The draft is easy to implement, there is one implementation from Ericsson.

### Checklist

[x] Means cleared.
[-] Means done but there are comments that should be checked by IESG.
[ ] Means not done.

- [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?
- [-] 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?

Idnits shows 13 errors https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-versions-02.txt however the tool seems to be broken.

- [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?
- [-] 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?

This draft updates 8428 and is stated so in the Abstract and the header. IMO the document is very clear in other sections about which are the updates to the current SenML registry and how they are updated. Please check if the current text is sufficiently explicit.

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

## Shepherd Writeup

This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which SenML "features" are active. Feature codes are used to express which features are available. The document registers feature codes 0,1,2,3 for the first 4 reserved features the 5th feature code is reserved for when RFC8798 is used.

A new subregistry is created within the SenML IANA registry, named "SenML features".

The document sets a hard limit for the number of SenML features that can be registered (with only 48 codes left). Expert reviewers should then be very conservative with the allocation of the remaining feature codes.

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

This document specifies how SenML versions are represented and creates a sub-registry of SenML Features, which are used to calculate the SenML version. The document is intended for Standards Track and updates RFC8428.

### Review and Consensus

The document was reviewed (https://mailarchive.ietf.org/arch/msg/core/5cWnixOE8nX4HTIy5w3rE4Whpo8/ ) and discussed in several IETF meetings. Most of the comments were regarding the hard limit to feature codes and therefore of version numbers.

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

The document creates a sub-registry named "SenML features" and updates the SenML RFC (RFC8428). The draft is easy to implement, there is one implementation from Ericsson.

### Checklist

[x] Means cleared.
[-] Means done but there are comments that should be checked by IESG.
[ ] Means not done.

- [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?
- [-] 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?

Idnits shows 13 errors https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-core-senml-versions-02.txt however the tool seems to be broken.

- [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?
- [-] 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?

This draft updates 8428 and is stated so in the Abstract and the header. IMO the document is very clear in other sections about which are the updates to the current SenML registry and how they are updated. Please check if the current text is sufficiently explicit.

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