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/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
