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

["Eric Vyncke (evyncke)" <[e-mail]>]

Steve,

The text in the PR 1083 would be perfect, I will trust you to merge it and submit a revised I-D.

Clearing my DISCUSS in a couple of minutes

-éric


From: Steve Lhomme <[e-mail]>
Date: Tuesday, 24 February 2026 at 09:32
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)

Hi Éric,

As Spencer mentioned all the suggested Pull Requests have been merged and are now integrated in draft-ietf-cellar-tags-22.

Comments on the remaining discussions below.

On 22 Feb 2026, at 18:08, Eric Vyncke (evyncke) <[e-mail]> wrote:

Hello Steve,

Thanks for your 2 messages (and your patience).

Replying to the first one (to be simple). See inline for EV>

In short, please merge the PRs and submit a revised I-D, then I am clearing my DISCUSS.

Regards,

-éric


From: Steve Lhomme <[e-mail]>
Date: Sunday, 11 January 2026 at 11:45
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)

Hi Eric and thanks for your review,

My comments are inline below.

On 5 Jan 2026, at 09:46, Éric Vyncke via Datatracker <[e-mail]> wrote:

Éric Vyncke 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:
----------------------------------------------------------------------


Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to Spencer Dawkins for the shepherd's detailed write-up
including the WG consensus (albeit a small WG it seems) and the justification
of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Missing version

The CELLAR charter includes `Standards Track specification for Matroska
container format version 4` but this I-D, while proposed standard, does not
mention at all the version 4. So, it is really unclear.

Note: RFC 9559 section 7 is about versioning, but this I-D should really
mention version 4.

The tags document define the values set in Matroska elements \Segment\Tags\Tag\+SimpleTag\TagName, \Segment\Tags\Tag\+SimpleTag\TagString and \Segment\Tags\Tag\+SimpleTag\TagBinary.
The elements don’t have a “minver” attribute, which means they are usable since Matroska v1. That’s why there is no versioning mentioned.
All the tags, even the ones that don’t exist yet and even “unofficial” ones, can be used in files compatible with Matroska v1. For apps that interpret tags, they only need to handle the names they care about and ignore the (infinite) rest.

EV> ah ah... it there any chance to add some text like the above in the introduction ?

I created this Pull Request to add some text in the introduction: https://github.com/ietf-wg-cellar/matroska-specification/pull/1073

“Matroska Tags consist of a Name and a value.
Unlike EBML or Matroska elements, they are not dependent on the version of the file.
All tags defined in this document and even others can be used in all versions of Matroska."

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Support for others DISCUSS points

I second (hence won't repeat) the following DISCUSS points by Med:
- use of BCP14 in IANA considerations
- other issues mentioned in the IANA considerations

I note though that IANA tagged (punt intended) this I-D as "IANA OK"

### Abstract

Abstracts need to be concise but also useful and descriptive. I.e., at least
mention the version (per my DISCUSS point) and be more descriptive.

The title should also include "version 4".

No, these tags are usable in all Matroska versions. There is no versioning of tag names and values.

EV> see above

### Section 3.2.2

Why not a MUST in `Multiple items SHOULD NOT`? See also
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

This used to be that way but turned back in https://github.com/ietf-wg-cellar/matroska-specification/pull/1030
After the AD review from Orie https://mailarchive.ietf.org/arch/msg/cellar/4ebLFttRb_I8SFu5yMQSIDPuk2E/

EV> the guidance for the SHOULD should still be there though…

I think it’s covered by the next paragraphs that deal with the same thing:

“Preexisting files may have used multiple values in the same TagString but given there are no defined delimiters they cannot be easily split into multiple elements. INSTRUMENTS (Section 4.4) and KEYWORDS (Section 4.6) tags allow using a comma as a separator. However, it is RECOMMENDED to use separate SimpleTags with each containing a single instrument or keyword value, respectively.

Due to the varied nature of tag sources it may also not always possible to know programmatically whether a value is a list that must be split or not.”

Thanks,
Steve