Last Call Review of draft-ietf-core-senml-versions-02
review-ietf-core-senml-versions-02-genart-lc-davies-2021-05-03-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-core-senml-versions-02
Reviewer: Elwyn Davies
Review Date: 2021-05-03
IETF LC End Date: 2021-05-03
IESG Telechat date: Not scheduled for a telechat

Summary:  Almost ready.  There is one issue that needs to be sorted out.  This
document removes the ordering relationship between the values of version..
Section 4.4 of RFC 8428 relies on that ordering relationahip.  Accordingly
there needs to be explicit new text for Section 4.4 in this document.  Also the
concept of 'must understand' items is used in this document but is not
explicitly defined in RFC 8428.  This needs to be fixed - which could happen in
the new version of Setion 4.4.

Major issues:
None

Minor issues:

The redefinition of version means that this document should contain an explicit
update of (at least)  paragraph 3 of Section 4.4 of RFC 8428,  That section
assumes that there is an ordering relationship between version field values
which is invalidated by this document.

Also the concept of 'must understand' fields is supposed to be explained in
that section as well as discussed in s2.1 of this document.  That term is not
explicitly used in RFC 8428 but I take it that it is supposed to refer to field
names ending wth an underscore character ('_').  This should be fixed with a
rewrite of s4.4 of RFC 8428.

Nits/editorial comments:

General:  The RFC Editor preferes the US convention for quoting items using
exclusively singe quote rather than double quote marks.

s1, para 2:  I found this paragraph difficult to parse, especially the second
sentence.  Here is an alternative suggestion. OLD: The traditional idea of
using a version number for evolving an interchange format presupposes a linear
progression of that format. A more likely form of evolution of SenML is the
addition of independently selectable _features_ that can be added to the base
version (version 10) in a fashion that these are mostly independent of each
other. A recipient of a SenML pack can check the features it implements against
those required by the pack, processing the pack only if all required features
are provided in the implementation. NEW: The traditional idea of using a
version number to indicate the evolution of an interchage format generally
assmes an incremental progression of the version number as the format develops
over time. However in the case of SenML it is expected that the likely
evolution mechanism will be for independently selectable capabiity _features_
to be added to the basic system indicated by 'version' 10. To support this
model, this document repurposes the single version number accompanying a pack
of SenML records so that it is interpreted as a bitmap indicating the set of
features a recipient would need to have implemented to be able to process the
pack. ENDS

s2:  Personally I would have used the left shift operator rather then 2^fc but
that is a personal view.

s2,1, para 2: s/lower-most bit positions Section 3./least significant bit
positions for the base version as described in Section 3./

s2.1, para 2:  s/Section 4/by the feature defined in Section 4/

s2.1, para 2: 'boutique' is slang:  s/boutique/less generally applicable/

s3: s/already/effectively already/

s6:  I am not we really care but are feature names case sensitve?