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

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

Thanks to Joe Salowey for the SECDIR review.

Nit:

-- Section 2.1. Typo. s/sightly/slightly/
-- Section 4.  Editorial.  s/be be/be/

Thanks for the effort here and thanks to all the reviewers.

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.

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.

Section 7.1, paragraph 4, comment:
>    [IANA.senml]
>               IANA, "Sensor Measurement Lists (SenML)",
>               <http://www.iana.org/assignments/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: &nbsp;

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

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?

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