Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-cellar-matroska-15

[Lars Eggert <[e-mail]>]

Elwyn, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On Mar 3, 2023, at 02:14, Elwyn Davies via Datatracker <[e-mail]> 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-cellar-matroska-15
> Reviewer: Elwyn Davies
> Review Date: 2023-03-02
> IETF LC End Date: 2023-02-28
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:  Almost ready.  Thre is a good deal of discussion of earlir versions
> of the structure and associated parsers together dicussion of future proofing
> and potential future versions of the structure and associated parsers.  I am
> concerned that it is not possible to automatically know which components are
> associated with a given version.  At the least, this would assist implementers
> to ensure that their parsers are working on the right ietms and ignoring
> irrelevant items.
> 
> Major issues:
> 
> Versions of Matroska:  According to Section 2, this document covers versions 1,
> 2, 3 and 4 of Matroska. The implication is that not all elements were defined
> in lower numbered versions but that older parsers should potentially be able to
> handle later versions of the format.  I am unclear about this but I have a
> suspiscion that implementers and extenders of the format need to know which
> elements existed in which versions and may need to understand whether they can
> modify these elements in future versions.  At present there is no indication
> which elements are defined in earlier versions and are therefore potentially
> not updateable.
> 
> Minor issues:
> 
> General: I am concerned about the long term stability of the web site
> referenced for the Matroska Container Format, reference [MCF].  Among other
> issues it is not accessed via https and it claims that it is the one true
> specification which is rather confusing when it is being written into a
> standards track RFC.
> 
> s1: What is meant by the term 'old parsers'?  Is this just claiming that
> parsers for possible future formats will be always capable of parsing old
> versions of the format?
> 
> Nits and Editorial Comments
> 
> Abstract and s1: I wonder if 'Matroska audiovisual data container structure'
> might be a clearer reflection of what is being described?
> 
> s1: It might be more helpful if the MCF reference pointed to the descriptive
> introductory page of the web site (http://mukoli.free.fr/mcf/).
> 
> s1, para 1: s/differentiates from it/diverges from it/
> 
> s1, para 1: s/enables/provides/
> 
> s1, 2nd bullet: s/for which/in which/
> 
> s1, para after 2nd bullet: s/features like/features such as/
> 
> s4.3: I suspect that the use and format of Hexadecimal Floating-Point Constants
> is not sufficiently generally understood to not require explanation in an RFC.
> I suggest duplicating the reference to [ISO9899] used in Section 11.1.18 of RFC
> 8794 would be desirable.
> 
> s5: A reference to Section 11 of [RFC8794] referring to the structure of
> element definitions would be useful.
> 
> s5.1: The details of the elements in this section are outside my competence and
> I haven't looked at them with any exactitude.  Nothing jumped out at me.
> 
> s6.1, para 2: I was unable to parse the second sentence: "In that case the
> Segment containing in these Chapters do no required a Track Element or
> a Cluster Element."
> 
> s20.5.2: s/contain/contains/
> 
> s23.3.3, para 1: s/want to seek/wants to seek/; s/to have these/to access these/
> 
> s27.1: Should an Element ID registry entry contain the Matroska version at
> which it was introduced?
> 
> s28, para 2: s/if there is no more/if there are no more/
> 
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art