Ballot for draft-ietf-cellar-tags
Yes
No Objection
Summary: Has enough positions to pass.
## Comments ### Support Of Other DISCUSS Positions I support Éric's DISCUSS on UTF-8 spaces. Should that be whitespace? I support Gory's position on the "Official". IMHO, the doc is describing "registered" values, not "official" values. And like Gory, I support Med's position on the specification required for DEs.
Thanks to Mohit Sethi for their secdir review. General: I agree with Med's discuss on neutral examples. It would be better if these examples pointed to obvious fictitious entities. Abstract: I agree with Gorry that this needs to be a little more descriptive. Section 3.1, etc.: Please define 'official', or change the word to something more obvious - 'defined' or 'common'. Nits: Section 3.1, last sentence: s/wanted/desired Section 3.2.1, last sentence: s/non official/unofficial
Thanks for the work done in this document, and the follow-up on my previous DISCUSS. I am trusting the authors and the responsible AD that the PR 1083 will be merged and a revised I-D submitted (see https://mailarchive.ietf.org/arch/msg/cellar/HZEUYMiPtwhD198vBsfZEBWPUWw/ ). Regards -éric
Thank you for the new revision that addresses my DISCUSS topics, and the comments below. -- I have several comments that I hope may improve this: 1. Please could you make this abstract more descriptive? It's hard to understand what the document might contain from the abstract. There are many sentences in the introduction that would help. For example these text fragments could be helpful;: Matroska is a multimedia container format that can store timestamped multimedia data but also chapters and tags. ... This document defines ... a set of common tag names used in Matroska. These Tag elements add metadata to identify and classify the information found in a Matroska Segment. ... 2. The document contains the names of several example physical entities in the entertainment industry. I am not yet persuaded that this necessary or even helpful to have actual rather than exemplar identities named. 3. There is a section on Official Tags, which says: "The following is a complete list of the supported Matroska Tags." -- Is that the present value? The only permitted value until this RFC-to-be is updated? This is often phrased as /complete/assigned/ or some similar change (see DISCUSS point).
I support the DISCUSS points raised by other reviewers.
Thank you for your changes to address my previous DISCUSS. I have one outstanding comment that I hope you will consider, but it's not blocking. I think Section 3.2.1's scope needs to be clarified. As currently written, it restricts the format of "Assigned TagName values," i.e. those that are going in the registry; hence my earlier suggestion that a completely non-conformant tag might still be considered valid but unregisterable. But your response suggests you expect these restrictions to be enforced even for private-use tags. I would encourage you to clearly distinguish what is a syntactically valid tag (even if it cannot be registered/assigned); that may already exist in other specifications, and a pointer would be sufficient. Is this section intended to preclude registration of non-conformant tags or intended to preclude their presence in a conformant segment?
Hi Steve, Moritz, and Dave, Thank you for the discussion and for taking care of the comments. Much appreciated. The changes made in [1] address most of the points raised in my previous ballot [2]. # Pending issue I still see, however, that we are mixing normative behavior with IANA considerations (Section 6.1), but I will leave that to the responsible AD to work it out with the authors. Cheers, Med [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-cellar-tags-20&url2=draft-ietf-cellar-tags-22&difftype=--html [2] https://mailarchive.ietf.org/arch/msg/cellar/kca-aLZ-XWZpR7X5ZIxFPKm4Qac/
I agree with most DISCUSS points raised by the other ADs. Additionally, I'd like to point out: - It seems the FSFC policy being used while the document talks about "official tags", seems to imply that FCFS is not the best choice. Perhaps Expert Review is the better choice? - The use of "we" should be avoided, as it is unclear which group that refers to (authors, WG, IETF, etc)
Thank you to Ines Robles for the GENART review. I support the DISCUSS position of Mohamed Boucadair, Gorry Fairhurst, and Éric Vyncke. Thank you for addressing my DISCUSS and COMMENT feedback.