[Cellar] Re: Mohamed Boucadair's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Steve, 

Thank you for the follow-up.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Steve Lhomme <[e-mail]>
> Envoyé : dimanche 11 janvier 2026 09:49
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-cellar-tags-
> 20: (with DISCUSS and COMMENT)
> 
> 
> Hi Mohamed,
> 
> Sorry for the delay to respond to this. My replies are found
> inline.
> 
> > On 18 Dec 2025, at 15:46, Mohamed Boucadair via Datatracker
> <[e-mail]> wrote:
> >
> > Mohamed Boucadair has entered the following ballot position for
> > draft-ietf-cellar-tags-20: Discuss
> >
> > When responding, please keep the subject line intact and reply
> to all
> > email addresses included in the To and CC lines. (Feel free to
> cut
> > this introductory paragraph, however.)
> >
> >
> > ----------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------
> >
> > Hi Steve, Moritz, and Dave,
> >
> > Thank you for the effort put into this document.
> >
> > I have few process-related DISCUSS points:
> >
> > # Neutral examples
> >
> > The document includes several examples, that I suspect echo
> authors favorites.
> > However, per the IESG statement on "IESG Statement on Assignable
> > Codepoints for Examples in IETF Specifications" [1], "patterns
> such as
> > including product information, political matters, or names of
> > identifiable individuals should be avoided."
> >
> > Please consider updating the examples to use more neutral ones.
> 
> The idea is that they are real world example that people can
> double check if the explanation is not clear enough.
> 
> There are 2 items:
> - Daft Punk "Da Funk" a single with 2 tracks. This is a simple
> enough example that even fake values would probably still make
> sense. However the name of the record is also the name of the main
> track (as often). This is to demonstrate that the same tag NAME
> can be used to describe different things.
> 
> - "The Orb's Adventures Beyond The Ultraworld" this a 2-CD set
> which describes just a track of the second CD
> 
> I think generic values should be clear enough too. Especially
> since the XML representation has some extra comments describing
> each value.
> 
> Here is the version with generic names
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> github.com%2Fietf-wg-cellar%2Fmatroska-
> specification%2Fpull%2F1045&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7Cbcd99e83b67f4aadc2ce08de50ee5b7b%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C639037181847741619%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ywb1COqvXfqpjFLmKZkf6
> %2BL6wu%2FujHXBvYhP%2FO8m0fI%3D&reserved=0
> 

[Med] Thank you.


> > # Normative language in an IANA Section
> >
> > Per the IESG statement on "IESG Statement on Clarifying the Use
> of BCP
> > 14 Key Words", use of normative language in inappropriate in the
> IANA
> > Considerations section. Please update accordingly.
> >
> > CURRENT:
> >   The Name corresponds to the value stored in the TagName
> element.  The
> >   Name SHOULD always be written in all capital letters and
> contain no
> >   space as defined in Section 3.2,
> 
> Good catch! The rules in the tags description were made stricter,
> but this was not changed in the process.
> Fixed by
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> github.com%2Fietf-wg-cellar%2Fmatroska-
> specification%2Fpull%2F1046&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7Cbcd99e83b67f4aadc2ce08de50ee5b7b%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C639037181847751034%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y3nW1elf4C2k3%2BR2QPM
> %2Bth7r85cgEImcT58k4Hcw8jY%3D&reserved=0
> 

[Med] You may simply s/MUST/is. 

> > # How to ensure that distinct attributes are not covering the
> same
> > piece of information, especially for the FCFS ones?
> >
> > CURRENT:
> >   Matroska Tag Names for UTF-8 data are to be allocated
> according to
> >   the "First Come First Served" policy [RFC8126].
> >
> > Maybe I misinterpreted the intended use of "Reference", but it
> would
> > be more convenient for the IANA registry to include a
> description of the attribute.
> 
> I followed what we did in RFC8794 and RFC9559. The Reference being
> a link to a document explaining what the tag does.
> The "Reference" is currently marked as optional. I think this is
> OK for people who want to register a private tag name so that it
> doesn't collide with others in the future.
> 
> So it is technically OK to register a tag name with a type but no
> reference. Only those who know what this is supposed to mean
> should use it. For third party apps it's still useful to validate
> the name and the content matches the type.

[Med] ACK. I think that the possibility that a ref can be omitted, even exacerbates my initial point: how to prevent overlapping/redundant attributes are being added to the registry?

> 
> > # Are there provisions for tagging specific attributes as
> deprecated
> > in the future? Should that be reflected in the registry (e.g.,
> Status)?
> 
> I don't think tag names can be deprecated. Once a file has been
> created with this tag name, it should be possible to interpret it
> forever.
> 

[Med] Can this expectation about deprecation be added to the spec?

> For Matroska we have quite a bit of deprecated element IDs in the
> registry [1]. The "Reference" fields marks them as Reclaimed with
> a link to the document explaining what it was doing. I think the
> same should be done for tag names in the future if we ever want to
> replace an element by another.
> 
> > # Specification required policy
> >
> > As a reminder, RFC8126 says:
> >
> >   For the Specification Required policy, review and approval by
> a
> >   designated expert (see Section 5) is required, and the values
> and
> >   their meanings must be documented in a permanent and readily
> >   available public specification, in sufficient detail so that
> >   interoperability between independent implementations is
> possible.
> >   This policy is the same as Expert Review, with the additional
> >   requirement of a formal public specification.
> 
> Yes, for "binary" and "nested tags" we want proper documentation
> available to everyone. If people want to create a binary tag but
> not publish the documentation it's fine. It will just not be an
> "official" tag.
> 
> > ## DE Guidelines should be provided as well.
> 
> What are DE Guidelines ?

[Med] These are guidelines to be followed by designated experts to perform their review. An example of DE guidelines can found here: https://datatracker.ietf.org/doc/html/rfc9445#name-guidelines-for-the-designat.

> 
> > ## Do you expect allowing registrations based on individual I-
> Ds, for example?
> 
> I don't understand the question.

[Med] Given that Specification Required Policy you picked here requires "permanent and readily" spec, some may consider I-Ds not falling under that criteria while others adopts a less strict approach. This is an example of a consideration that you can include in the DE guidance for this specific registry.

> 
> > ----------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------
> >
> > # Official tags
> >
> > I would introduce what is meant by "official" tag early in the
> > document. At least, I didn't find such concept in two RFCs cited
> in the terminology section.
> 
> I added a link to the IANA registry in the Why Official Tags
> Matter section:
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> github.com%2Fietf-wg-cellar%2Fmatroska-
> specification%2Fpull%2F1047&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7Cbcd99e83b67f4aadc2ce08de50ee5b7b%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C639037181847760305%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Vx3XO%2Bd%2BssAL58tn2
> RIAJlMGmp8qLW8XxO5JfsvLhmk%3D&reserved=0

[Med] Thank you.

> 
> > Cheers,
> > Med
> 
> Thanks for your review.
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.