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

Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 05 January 2026 08:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: cellar@ietf.org
Delivered-To: cellar@mail2.ietf.org
Received: from [10.244.9.115] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 91537A2C4AAE; Mon, 5 Jan 2026 00:46:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.55.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176760281350.3304339.9509637392974117767@dt-datatracker-5656579b89-p6k4r>
Date: Mon, 05 Jan 2026 00:46:53 -0800
Message-ID-Hash: OPLNL3DDFXGNNGCH7RXA63O6AEBMALKN
X-Message-ID-Hash: OPLNL3DDFXGNNGCH7RXA63O6AEBMALKN
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cellar.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: cellar-chairs@ietf.org, cellar@ietf.org, draft-ietf-cellar-tags@ietf.org, spencerdawkins.ietf@gmail.com
X-Mailman-Version: 3.3.9rc6
Reply-To: Éric Vyncke <evyncke@cisco.com>
Subject: [Cellar] Éric Vyncke's Discuss on draft-ietf-cellar-tags-20: (with DISCUSS and COMMENT)
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/i_XFK6cmmz6BOogMKDWkauPDzX4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Owner: <mailto:cellar-owner@ietf.org>
List-Post: <mailto:cellar@ietf.org>
List-Subscribe: <mailto:cellar-join@ietf.org>
List-Unsubscribe: <mailto:cellar-leave@ietf.org>

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


# Éric Vyncke INT AD comments for draft-ietf-cellar-tags-20
CC @evyncke

Thank you for the work put into this document even if I find a little weird to
have tag definitions of a container done in a codec WG, but it fits the CELLAR
WG charter, so all is good.

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.

### Section 3.2.1

Happy to be corrected as I am not a UTF-8 expert, but what is the exact
definition of `any space`? again thinking about UTF-8 and
https://en.wikipedia.org/wiki/Whitespace_character

### Section 4.11

`Library of Congress Control Number` but from which country? This definition is
ambiguous.


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

### Section 1

Please expand `EBML` at first use.

### Use of personal pronouns

Let's avoid the use of personal pronouns such as `if you wanted to store`
(section 3) or `We also need an official list` (section 3.1) or even `Our
recommendations are in between` and `put any tag in your file` (section 3.1
albeit not pronouns ;-) ). I.e., who is the "we" ? The authors ? The WG ? The
IETF ?

### Use of 'official'

As noted in other ballots, please refrain using `official`, the IETF issues
standards and not laws; so, s/official/standard/ would be much better.

### Section 3.2.1

`UTF-8 capital letters`, I am not a UTF-8 or internationalisation expert, but
do all alphabets have "capital letters" (and should it be "character" rather
than `letter`)

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

### Section 3.2.2.2

A long discussion about the decimal '.' vs. ',', but nothing is written in
which base the "UTF-8 number" is represented. I guess base 10, but let's be
specific. I also wonder why not using a IEEE binary format was not used
(possibly for backward compatibility).

### Section 3.3.1

Should there be a definition or reference for `TagChapterUID`? (also for other
*UID terms).