Reviewer: Elwyn Davies Review result: Almost Ready 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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
