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 <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-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 > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
