I support Ketan's DISCUSS on the need for instructions for the DEs.

I support Kentan's discuss on IANA registry guidance.

Thanks for this work.

I support Ketan's DISCUSS on IANA registries to need stronger rules.

a small, but relevant, typo is that WAVEFORMATEX integer signed/unsigned is wrong.

Section 3.4.25 says:
"A WORD corresponds to a signed 2 octets integer, DWORD corresponds to a signed 4 octets integer."

Microsoft defines WORD as an unsigned 16-bit integer and DWORD as an unsigned 32-bit integer. Please change both to unsigned. See https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types.

Thanks to the authors and the WG for their work on this document.

I missed one detail on the GitHub PR, and I apologize for not catching it sooner. This concerns the inappropriate use of BCP14 keywords in IANA considerations (see https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/). This can be fixed simply by changing them to lower case.

Expecting the authors to make this change before the document approval is approved by the responsible AD (Charles).

Section 3.3.25, V_THEORA CodecPrivate layout:

767 >   *  Bytes 2..n: lengths of the first #p packets, coded in Xiph-style
768 >      lacing.  The length of the last packet is the length of the
769 >      CodecPrivate block minus the lengths coded in these bytes minus
770 >      one.

The same text appears verbatim in Section 3.4.41 (A_VORBIS), lines
1405-1408. On Éric's DISCUSS: I checked, and RFC 9559 already defines this
exact mechanism under its own name.

 >    Xiph Lacing: This approach uses a series of size values to delimit
 >    frames. The final frame's size is calculated by subtracting the sum
 >    of preceding frame sizes from the total remaining data, eliminating
 >    the need to explicitly store the last frame's dimensions.

That's Section 10.3 of RFC 9559, "Block Lacing." So the fix really is
trivial: add "; see Section 10.3 of [RFC9559]" (or similar) at both of the
two places above, and RFC9559 moves from an informative to a normative
reference.

---

Section 8.1, Table 4, "Matroska Codec IDs" registry:

3212 >      |           S_SSA |   17  | SubStation Alpha   | Reclaimed,     |
3213 >      |                 |       | Format             | Section 3.5.7  |

This points readers to Section 3.5.7, which is S_TEXT/ASS. But the
Codec ID S_SSA is actually discussed in Section 3.5.9 (S_TEXT/SSA):

1571 >    The codec MAY also be found with the Codec ID S_SSA, but using that
1572 >    value is NOT RECOMMENDED.

s/Section 3.5.7/Section 3.5.9/

---

Section 3.2, recommendations for new Codec Mappings:

384 >    These recommendations are based on Section 3 of [RFC6648].

RFC 6648 Section 3 actually says SHOULD NOT for the "X-" prefix, not MUST
NOT. Elevating it to MUST NOT here is a reasonable editorial choice for a
registry-governed identifier space, but the text presents it as directly
"based on" RFC 6648 without noting that it's strengthening the
recommendation. A short note to that effect would avoid a reader assuming
RFC 6648 itself mandates this.

---------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 9.1, [ITU-T.H.262] normative reference:

3427 >    [ITU-T.H.262]
3428 >               ITU-T, "Procedure for the allocation of ITU-T defined
3429 >               codes for non-standard facilities", ITU-T
3430 >               Recommendation H.262, July 1995,
3431 >               <https://www.itu.int/rec/T-REC-H.262/en>.

That title is word-for-word the title given later in the document for
[ITU-T.35] (Informative References) — it's the wrong title. The actual
title of ITU-T Recommendation H.262 is "Information technology - Generic
coding of moving pictures and associated audio information: Video" (the
joint ISO/IEC 13818-2 MPEG-2 video spec, which is what Section 3.3.12
actually needs).

s/Procedure for the allocation of ITU-T defined codes for non-standard facilities/Information technology - Generic coding of moving pictures and associated audio information: Video/

---

Section 9.1, [ISO.11172-3] normative reference:

3403 >    [ISO.11172-3]
3404 >               International Organization for Standardization,
3405 >               "Information technology - Coding of moving pictures and
3406 >               associated audio for digital storage median at up to about
3407 >               1,5 Mbit/s - Part 3: Audio", ISO 11172-2:1993, August
3408 >               1993.

The title says "Part 3: Audio" but the document number given is
11172-2, which is Part 2 (Video) — already cited two entries above for
[ISO.11172-2]. The correct number for the audio part is ISO/IEC
11172-3:1993.

s/ISO 11172-2:1993/ISO\/IEC 11172-3:1993/

---

Section 3.4.11, A_AC3 description:

995 >    Section 4.4.2.1 of [ETSI.TS102-366] is 10 or below.  Channel number
996 >    have to be read from the corresponding audio element

s/Channel number have to be read from the corresponding audio element/The channel number has to be read from the corresponding audio element./

---

Section 3.3.9, V_MPEGH/ISO/HEVC field layout:

526 >    Codec Name: HEVC/H.265
527 >    Description: Individual pictures (which could be a frame, a field, or

Every other codec entry has a blank line between fields (Codec ID / Codec
Name / Description / Initialization). This one runs Codec Name straight
into Description with no blank line. The same thing happens in Section
3.3.13 (V_MPEG4/ISO/AVC), 3.3.28 (V_VP8), and 3.5.3 (S_HDMV/PGS). Cosmetic,
but easy to fix in one pass.

I support Roman's DISCUSS and would like to understand how consensus was achieved/declared.

To assist the reader, please correct these references between sections: Section 3.5.3 defines presentation graphics subtitles and should therefore refer to Section 5.5 (instead of 5.6), and Section 3.5.4 defines text subtitles and should therefore refer to Section 5.6 on text subtitles (instead of 5.5).