IETF Last Call Review of draft-ietf-cellar-codec-18
review-ietf-cellar-codec-18-genart-lc-knodel-2026-06-01-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-cellar-codec-??
Reviewer: Mallory Knodel
Review Date: 2026-06-01
IETF LC End Date: 2026-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: This document describes how to map codecs into the Matroska container
format. The draft is well written and clear in purpose.

Major issues: None. Thanks for the document. The biggest challenge I faced
while reviewing this was to do my best to check out all of the different
reference documents (there are so many! and from many other standards bodies).
I guess that this is the core function of this work, to bring together many
different codecs into one standard framework. Caveat that this is a general
review and not a technical review.

Minor issues:

 * Decide whether codec is plural and if so delete all "codecs" (love an
 invariable noun).

 * There is confusion for a new reader between "Block Addition" and "Block
 Additional", both a kind of necessary mapping. What seems to be the difference
 is that the latter is about mapping additional /data/, not about adding a
 block of data. That's a nuance. It would be helpful to define this in an
 introductory paragraph. This sort of introductory paragraph can also provide a
 guide to the table of contents-- why there are mappings of codecs and blocks,
 both for audio and video, and how to handle the data within them. That
 high-level architectural explanation is missing from the doc. If it exists
 elsewhere, you could link to that and summarize.

Nits/editorial comments:

 * Also on the plural tack: You could probably say "Codec Mapping" rather than
 the plural form in most cases, just for consistency, and for the title of
 section 3 specifically, but not, say, 3.2. or 3.3..

 * 3.3.1: "doesn't contains"