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

[Mohamed Boucadair via Datatracker <[e-mail]>]

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.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/



----------------------------------------------------------------------
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.

# 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,

# 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.

# Are there provisions for tagging specific attributes as deprecated in the
future? Should that be reflected in the registry (e.g., Status)?

# 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.

## DE Guidelines should be provided as well.

## Do you expect allowing registrations based on individual I-Ds, for example?


----------------------------------------------------------------------
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.

Cheers,
Med

[1]
https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/

[2]
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/