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 <jaime@xxxxxx> wrote:
>
> 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) ⋅ 2").
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-03.txt
>
> Ciao!
> --
> Jaime Jiménez
>
> On Sun, May 9, 2021, at 10:51 PM, Carsten Bormann wrote:
>> 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 <noreply@xxxxxxxx> wrote:
>>>
>>> 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
