Skip to main content

Last Call Review of draft-ietf-cellar-matroska-15
review-ietf-cellar-matroska-15-genart-lc-davies-2023-03-02-00

Request Review of draft-ietf-cellar-matroska
Requested revision No specific revision (document currently at 21)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2023-02-28
Requested 2023-02-14
Authors Steve Lhomme, Moritz Bunkus, Dave Rice
I-D last updated 2023-03-02
Completed reviews Genart Last Call review of -15 by Elwyn B. Davies (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-cellar-matroska by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/l2gsKdSbRBtCBNMrVZBmmRiu1IM
Reviewed revision 15 (document currently at 21)
Result Almost ready
Completed 2023-03-02
review-ietf-cellar-matroska-15-genart-lc-davies-2023-03-02-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-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/