Subject: [core] Genart last call review of draft-ietf-core-senml-versions-02

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Mon, 03 May 2021 11:56:48 -0700

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?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 9 May 2021 21:51:57 +0200

Hi Elwyn,

I finally got around to process your review.

I have submitted a new version -03 based on this review.
I could make direct use of your text suggestions, but did edit them a little.
So you may want to have another look at the second paragraph of 1 (introduction) and the new section 2.2, which address your main points.

https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/
https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-03.html
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-03.txt

That was a great, thoughtful review.
Thanks again!

CoRE WG: Please also check the above documents and diffs!

Grüße, Carsten

> On 2021-05-03, at 20:56, Elwyn Davies via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Elwyn Davies

---

From: Lars Eggert <[email-masked]>
Date: Wed, 26 May 2021 12:58:38 +0300

Hi Elwyn,

have you had a chance to check whether the -03 version of the I-D addresses your review?

Thanks,
Lars

On 2021-5-9, at 22:51, Carsten Bormann <[email-masked]> wrote:
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Lars Eggert <[email-masked]>
Date: Wed, 26 May 2021 15:34:35 +0300

Elwyn, thank you for your review and thank you all for the following discussion. I have entered a No Objection ballot for this document. Based on my checks, the latest version addresses your review issues; please let me know if you disagree.

Lars

> On 2021-5-3, at 21:56, Elwyn Davies via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Elwyn Davies
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 26 May 2021 16:48:51 +0300

Hi Carsten, 

Small nit. I had a quick read of the diff and although section 2 looks good with the new HTML and CSS, the formula looks mangled in the data tracker format ("present(fc)&nbsp;⋅&nbsp;2").

Ciao!
-- 
Jaime Jiménez

On Sun, May 9, 2021, at 10:51 PM, Carsten Bormann wrote:
> So you may want to have another look at the second paragraph of 1 
> (introduction) and the new section 2.2, which address your main points.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 May 2021 16:25:49 +0200

Hi Jaime,

Beautiful.

This problem is not in the XML generated by kramdown-rfc or in the TXT or HTML generated from that by xml2rfc, it occurs from scratch only in xml2rfc’s (v 3.7.0) v2v3 conversion output generated from that.  This appears to be new, I haven’t seen it before.

Tracking down the bug now…

Grüße, Carsten

> On 2021-05-26, at 15:48, Jaime Jiménez <[email-masked]> wrote:
> 
> Hi Carsten, 
>