Matroska Media Container Codec Specifications
draft-ietf-cellar-codec-19

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cellar-codec-18. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions that we must complete.

First, a new registry called the Matroska Codec IDs registry is to be created. The new registry will be located in the Matroska registry group located at:

https://www.iana.org/assignments/matroska/

The new registry will be managed via Expert Review as defined by [ RFC8126 ]. There are initial registrations in the new registry as documented in section 9.1 of the current draft. Each initial registration will have a Change Controller of IETF.

Second, a new registry will be created called the Matroska BlockAdditional Type IDs registry. The new registry will be located in the Matroska registry group located at:

https://www.iana.org/assignments/matroska/

The new registry will be managed via Expert Review as defined by [ RFC8126 ]. There are initial registrations in the new registry as documented in section 9.2 of the current draft. Each initial registration will have a Change Controller of IETF.

IANA Question -> The initial registrations in the new Matroska BlockAdditional Type IDs registry are expressed as decimals for some registrations and hexadecimals for other registrations. Is this intended, and if so, should we list both the decimal and hexadecimal representation for each registration (similar to the Ethertypes registry, for example, at: https://www.iana.org/assignments/ieee-802-numbers/) or should we display values as all decimal or all hexadecimal, similar to other Matroska registries?

We understand that these are the only actions required to be completed upon approval of [RFC-to-be].

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-05-29):

From: The IESG
To: IETF-Announce
CC: cellar-chairs@ietf.org, cellar@ietf.org, draft-ietf-cellar-codec@ietf.org, eckelcu@cisco.com, spencerdawkins.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Matroska Media Container Codec Specifications) to Proposed Standard


The IESG has received a request from the Codec Encoding for LossLess
Archiving and Realtime transmission WG (cellar) to consider the following
document: - 'Matroska Media Container Codec Specifications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-05-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines the Matroska multimedia container codec
  mappings, including the codec ID, layout of data in a Block element
  and in an optional CodecPrivate element.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9043: FFV1 Video Coding Format Versions 0, 1, and 3 (Informational - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-codec-18 (updated after AD Evaluation of -16)

*This version is dated 4 July 2022.*

## Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The WG is small (6-8 active participants), and the authors are the most active contributors, but the entire active working group was involved in reaching consensus for this document.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No. This working group is quite calm, and work on draft-ietf-cellar-codec was no exception.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

4. For protocol documents, are there existing implementations of the contents of
the document?

Yes. Notable implementations include vlc, ffmpeg, mkvtoolnix, mediainfo.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Pretty much all the relevant people participate in this IETF WG.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not contain any MIB, YANG module, new media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
          the justification for not fixing them at this time? Does the YANG module
          comply with the Network Management Datastore Architecture (NMDA) as specified
          in RFC 8342?

This document does not contain any YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
          final version of the document written in a formal language, such as XML code,
          BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
          document is needed, clearly written, complete, correctly designed, and ready
          to be handed off to the responsible Area Director?

Yes. The document shepherd did a full top-to-bottom review of draft-ietf-cellar-tags-14 which resulted in some significant technical changes, but these changes involved

- tightening BCP 14 language

- providing context for SHOULDs that provide direction for new codec descriptions while not invalidating existing descriptions - Matroska is intended for use in archival media storage, so allowing conformant implementations to process these codec descriptions is critical

- providing explanations for concepts that the working group understands very well, but new implementers might not understand

10.Several IETF Areas have assembled lists of common issues that their
          reviewers encounter. For which areas have such issues been identified
          and addressed? For which does this still need to happen in subsequent
          reviews?

No issues with common issues have been identified for this document - the document content is application-level, and provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, so no additional issues with common issues are expected here.

11. What type of RFC publication is being requested on the IETF stream (Best
          Current Practice, Proposed Standard, Internet Standard,
          Informational, Experimental or Historic)? Why is this the proper type
          of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is appropriate for this document. It provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, which is also published as Proposed Standard. It holds the same position as "Matroska Media Container Tag Specifications", which is under IESG review as of this writing, and is also requesting Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
          property rights (IPR) disclosure obligations described in BCP 79? To
          the best of your knowledge, have all required disclosures been filed? If
          not, explain why. If yes, summarize any relevant discussion, including links
          to publicly-available messages when applicable.

Yes. Document authors have been surveyed. All have confirmed in email that no disclosures have been made, and no disclosures are expected..

13. Has each author, editor, and contributor shown their willingness to be
          listed as such? If the total number of authors and editors on the front page
          is greater than five, please provide a justification.

Yes. Document authors have agreed.

14.Document any remaining I-D nits in this document. Simply running the idnits
          tool is not enough; please review the "Content Guidelines" on
          authors.ietf.org. (Also note that the current idnits tool generates
          some incorrect warnings; a rewrite is underway.)

Beyond the Content Guidelines, idnits 2.17.1 identifies possible downrefs, but please see below. :

Also - idnits 2.17.1 identifies [Events] as a possible missing reference, but it's not - it's a string in Section 6.3, and appears twice.

15. Should any informative references be normative or vice-versa? See the IESG
          Statement on Normative and Informative References.

The Normative references really are normative. The Informative references are really informative. The normative/informative split was discussed with both Orie and Charles.

—------------

16.List any normative references that are not freely available to anyone. Did
          the community have sufficient access to review any such normative
          references?

  -- ref. 'ALAC' is freely available.

  -- ref. 'ARIB.STD-B10' is freely available.

  -- ref. 'ARIB.STD-B24' is freely available.

  -- ref. 'ARIB.TR-B14' is freely available.

  -- ref. 'ATSC.A52' is freely available.

  -- ref. 'AV1' is freely available.

  -- ref. 'AV1-ISOBMFF 'is freely available.

  -- ref. 'BITMAPINFOHEADER' is freely available.

  -- ref. 'Blu-ray.Part3' is freely available.

  -- ref. 'Dirac' is freely available.

  -- ref. 'DolbyVision-ISOBMFF' is freely available.

  -- ref. 'ETSI.EN300-468' is freely available.

  -- ref. 'ETSI.EN300-743' is freely available.

  -- ref. 'ETSI.TS102-114'  is freely available.

  -- ref. 'ETSI.TS102-366'  is freely available.

  -- ref. 'IEEE.1857-10' is available for purchase from IEEE.

  -- ref. 'IEEE.1857-3' is available for purchase from IEEE.

  -- ref. 'IEEE.1857-4' is available for purchase from IEEE.

  -- ref. 'IEEE.754' is available for purchase from IEEE.

  -- ref. 'ISO.11172-3' is available at no charge to reviewers from ISO/IEC JTC 1/SC 29 through the IETF liaison, Stephan Wegner (stewe@stewe.org) on request, and is available to implementers for purchase from ISO.

  -- ref. 'ISO.13818-2' is available at no charge to reviewers from ISO/IEC JTC 1/SC 29 through the IETF liaison, Stephan Wegner (stewe@stewe.org) on request, and is available to implementers for purchase from ISO.

  -- ref. 'ISO.14496-15' is available at no charge to reviewers from ISO/IEC JTC 1/SC 29 through the IETF liaison, Stephan Wegner (stewe@stewe.org) on request, and is available to implementers for purchase from ISO.

  -- ref. 'ISO.14496-2' is available at no charge to reviewers from ISO/IEC JTC 1/SC 29 through the IETF liaison, Stephan Wegner (stewe@stewe.org) on request, and is available to implementers for purchase from ISO.

  -- ref. 'ISO.14496-3' is available at no charge to reviewers from ISO/IEC JTC 1/SC 29 through the IETF liaison, Stephan Wegner (stewe@stewe.org) on request, and is available to implementers for purchase from ISO.

  -- ref. 'ITU-T.H.262'  is freely available. This version of the specification has been superseded, but is sufficient for Matroska implementations containing archival media.

  -- ref. 'JPEG'  is freely available.

  -- ref. 'JPEG2000' is available for purchase from ITU-T. This specification was a normative reference for RFC 9828, published in 2025, so was considered sufficiently available for implementers.

  -- ref. 'OggKate'  is freely available.

  -- ref. 'QTFF'  is freely available.

  -- ref. 'SSA' is freely available.

  -- ref. 'Theora'  is freely available.

  -- ref. 'TRUEHD' is freely available.

  -- ref. 'TTA'  is freely available.

  -- ref. 'USF'  is freely available.

  -- ref. 'VobSub'  is freely available.

  -- ref. 'VORBIS'  is freely available.

  -- ref. 'VP9'  is freely available.

  -- ref. 'WAVEFORMATEX' is freely available.

  -- ref. 'WAVPACK'  is freely available.

  -- ref. 'WebVTT'  is freely available.


17. Are there any normative downward references (see RFC 3967 and BCP
          97) that are not already listed in the DOWNREF registry? If so,
          list them.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ALAC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AV1'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AV1-ISOBMFF'

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'BITMAPINFOHEADER'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Dirac'

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'DolbyVision-ISOBMFF'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-10'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-3'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-4'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG2000'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'OggKate'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'QTFF'

  ** Downref: Normative reference to an Informational RFC: RFC 9043

** IESG: Please include this note in IETF Last Call announcements, and please consider adding this (recent CELLAR) specification to the downref registry. **

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SSA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Theora'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TRUEHD'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TTA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USF'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VobSub'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VORBIS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VP9'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WAVEFORMATEX'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WAVPACK'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WebVTT'

18. Are there normative references to documents that are not ready to be
          submitted to the IESG for publication or are otherwise in an unclear state?
          If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs?

No.

20. Describe the document shepherd's review of the IANA considerations section,
          especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

21. List any new IANA registries that require Designated Expert Review for
          future allocations. Are the instructions to the Designated Expert clear?
          Please include suggestions of designated experts, if appropriate.

This document creates two new registries called "Matroska Codec IDs Registry" and "Matroska BlockAdditional Type IDs Registry".

Both new registries use the "Expert Review" policy [RFC8126].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Orie Steele, ART AD, comments for draft-ietf-cellar-codec-16
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cellar-codec-16.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Discuss

## Reference Classification Analysis

I used AI for this section of my review, none the less, please consider the analysis carefully.

I've reviewed each reference flagged by idnits. Below is a case-by-case analysis of the severity of issues when normative references are not freely available.

### RFC Downrefs (Informational RFCs used normatively)

**RFC 6386 (VP8 Data Format and Decoding Guide) - Informational RFC**
- **Classification**: Currently normative
- **Usage**: Referenced for VP8 codec mapping (line 908)
- **Assessment**: This is a downref (normative reference to Informational RFC). The document MUST reference VP8 to define the codec mapping, so this appears correctly classified as normative from a functional perspective. However, this requires IESG approval per RFC 3967/BCP 97.
- **Severity: Medium** - The working group should make a recommendation to the responsible AD regarding whether this reference shall be added to the downref registry. The reference itself is appropriate.

**RFC 9043 (FFV1 Video Coding Format) - Informational RFC**
- **Classification**: Currently normative 
- **Usage**: Referenced for FFV1 codec mapping (lines 600, 605)
- **Assessment**: Another downref. FFV1 is an important preservation codec, and the document MUST reference it to define the mapping.
- **Severity: Medium** - The working group should make a recommendation to the responsible AD regarding whether this reference shall be added to the downref registry. The reference is functionally correct.

### Non-RFC Normative References - Freely Available

The following are correctly classified as normative and are freely available (no issue):

- **ALAC** - Freely available, used normatively for codec mapping (line 1147)
- **AV1** - Freely available, used normatively for codec mapping (line 518)
- **AV1-ISOBMFF** - Freely available, used for AV1 container binding
- **BITMAPINFOHEADER** - Freely available Microsoft documentation
- **Dirac** - Freely available, used for Dirac codec mapping
- **DolbyVision-ISOBMFF** - Freely available (though requires registration)
- **JPEG** - Freely available via ITU-T/W3C, used normatively (line 625)
- **OggKate** - Freely available
- **QTFF** - Freely available Apple documentation
- **SSA** - Freely available subtitle format spec
- **Theora** - Freely available
- **TRUEHD** - Freely available
- **TTA** - Freely available
- **USF** - Freely available
- **VobSub** - Freely available
- **VORBIS** - Freely available
- **VP9** - Freely available
- **WAVEFORMATEX** - Freely available Microsoft documentation
- **WAVPACK** - Freely available
- **WebVTT** - Freely available W3C spec

**Assessment**: All correctly classified as normative. No issues.

### Non-RFC Normative References - NOT Freely Available

**IEEE Standards (4 references):**

1. **IEEE.1857-10** - "IEEE Standard for Third Generation Video Coding"
  - **Availability**: Available for purchase from IEEE
  - **Usage**: Referenced for AVS3 codec mapping (line 563)
  - **Severity: HIGH** - This is a normative reference required to implement AVS3 support. Implementers cannot comply without purchasing the standard. This significantly impacts implementability and reviewability.

2. **IEEE.1857-3** - "IEEE Standard for a System of Advanced Audio and Video Coding"
  - **Availability**: Available for purchase from IEEE
  - **Usage**: Referenced for AVS2 codec mapping (line 574)
  - **Severity: HIGH** - Same issue as above. Required for AVS2 implementation.

3. **IEEE.1857-4** - "IEEE Standard for Second-Generation IEEE 1857 Video Coding"
  - **Availability**: Available for purchase from IEEE
  - **Usage**: Referenced for CAVS codec mapping (line 552)
  - **Severity: HIGH** - Required for CAVS implementation.

4. **IEEE.754** - "IEEE Standard for Binary Floating-Point Arithmetic"
  - **Availability**: Available for purchase from IEEE
  - **Usage**: Referenced for floating-point data representation (line 1385)
  - **Severity: MEDIUM** - IEEE 754 is widely implemented and understood, but still requires purchase. However, the core concepts are well-documented elsewhere. This could potentially be moved to informative if the document doesn't mandate specific IEEE 754 conformance requirements.

**ISO Standards (6 references):**

1. **ISO.11172-2** - MPEG-1 Video
  - **Availability**: Available for purchase from ISO
  - **Usage**: Referenced for MPEG-1 video codec mapping
  - **Severity: HIGH** - Required for MPEG-1 implementation.

2. **ISO.11172-3** - MPEG-1 Audio
  - **Availability**: Available for purchase from ISO
  - **Usage**: Referenced for MPEG-1 audio codec mapping
  - **Severity: HIGH** - Required for MPEG-1 audio implementation.

3. **ISO.13818-2** - MPEG-2 Video
  - **Availability**: Available for purchase from ISO
  - **Usage**: Referenced for MPEG-2 video codec mapping
  - **Severity: HIGH** - Required for MPEG-2 implementation.

4. **ISO.14496-15** - Carriage of NAL unit structured video in ISO base media file format
  - **Availability**: Available for purchase from ISO
  - **Usage**: Referenced for H.264/AVC and HEVC mappings
  - **Severity: HIGH** - Critical for AVC/HEVC implementation.

5. **ISO.14496-2** - MPEG-4 Visual
  - **Availability**: Available for purchase from ISO
  - **Usage**: Referenced for MPEG-4 video codec mapping
  - **Severity: HIGH** - Required for MPEG-4 implementation.

6. **ISO.14496-3** - MPEG-4 Audio
  - **Availability**: Available for purchase from ISO
  - **Usage**: Referenced for MPEG-4 audio codec mapping
  - **Severity: HIGH** - Required for MPEG-4 audio implementation.

**ITU-T Standards (1 reference):**

1. **JPEG2000** (ITU-T T.800)
  - **Availability**: Available for purchase from ITU-T
  - **Usage**: Referenced for JPEG2000 codec mapping (line 614)
  - **Severity: HIGH** - Required for JPEG2000 implementation.

### Summary and Recommendations

**Critical Issues (HIGH severity):**
- 10 normative references require purchase (4 IEEE, 6 ISO, 1 ITU-T)
- These are essential for implementing the codec mappings defined in this document
- This creates a significant barrier to implementation and review
- The IESG Statement on Normative and Informative References (https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/) states: "Normative references to documents that are not freely available can create serious problems for the community"

**Recommendations:**
1. For each non-freely-available normative reference, the document should explicitly state in the Security Considerations section that implementers must obtain these standards to fully understand security implications.
2. Consider whether any of these could be moved to informative if the document only needs to reference them for context rather than requiring conformance.
3. Document in the Security Considerations section that security analysis is incomplete without access to the referenced standards.
4. For the downrefs (RFC 6386, RFC 9043), the working group should make a recommendation to the responsible AD regarding whether these references shall be added to the downref registry.


### First Come First Served

I wonder if this policy is correct here.
There is no expert review, are there issues with the registry being filled with incorrect information?
Would it not be better to use expert review for these registries, and have the mailing list available to review new entries?


```
2890 8.  Security Considerations
```

You note here that some security issues don't come from Matroska.
I've noticed a lot of normative and informative rerences to specifications which are not necessarily readily avaialble to the reader.

Its probably worth calling that out a bit more directly here.
Its impossible for me to understand the security issues associated with disregarding some of the normative guidance in this document, without reading those referenced specifications.

## Comments

### How unique?

```
242   encoded data in its associated Clusters.  This CodecID is a unique
243   registered identifier that represents the encoding stored within the
```

I assume this is not globally unique, but instead unique in some limited context?


### Non normative may?

```
244   Track.  Certain encodings MAY also require some form of codec
245   initialization to provide its decoder with context and technical
246   metadata.
```

I don't understand how this MAY impacts interoperability here.
How is initialization related to the mapping?
Why does na implementer need to understand this initialization stuff at this point in the document?

Later:

```
330   Each encoding supported for storage in Matroska MUST have a defined
331   Initialization.  The Initialization MUST describe the storage of data
```

Is this the same initialization stuff?
Why is it not capitalized when introduced if that is the case?

### Why so many params for OPUS?

```
1241 3.4.32.  A_OPUS
```

This section has a lot more details than the others.
This raises the question of why the other sections don't have these details, and what normative guidance is missing in those sections, which is present in this one, for example regarding Channels and CodecDelay.


### buton

```
1653   header consisting of the string "butonDVD" followed by the width and
```

I assume this spelling is intentional.


### BlockAddIDValue

```
1691   Block type name: "Use BlockAddIDValue"
```

Is the "Use" here correct?


## Nits

### Shepherd Writeup Discrepancy

This was section was also reported by AI review.

The shepherd writeup (question 21) states:

```
This document creates a new registry called the "Matroska Tag Names" registry.
The new registry uses the "Specification Required" policy [RFC8126].
```

However, the actual document creates two registries, both using "First Come First Served" policy:
1. "Matroska Codec IDs Registry" (Section 9.1, line 2936-2937)
2. "Matroska BlockAdditional Type IDs Registry" (Section 9.2, line 3327-3328)

There is no "Matroska Tag Names" registry in the document. The shepherd writeup appears to describe a different document or an outdated version. This discrepancy should be resolved.

### ID Nits

```
  == Missing Reference: 'Events' is mentioned on line 2254, but not defined
```

I assume this is from:

```
2254   [Events]
2255   Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, \
2256   Effect, Text
```

Not sure how to fix this, I would leave that to the experts.

# Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-codec-16

*This version is dated 4 July 2022.*

## Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The WG is small (6-8 active participants), and the authors are the most active contributors, but the entire active working group was involved in reaching consensus for this document.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No. This working group is quite calm, and work on draft-ietf-cellar-codec was no exception.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

4. For protocol documents, are there existing implementations of the contents of
the document?

Yes. Notable implementations include vlc, ffmpeg, mkvtoolnix, mediainfo.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Pretty much all the relevant people participate in this IETF WG.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not contain any MIB, YANG module, new media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
          the justification for not fixing them at this time? Does the YANG module
          comply with the Network Management Datastore Architecture (NMDA) as specified
          in RFC 8342?

This document does not contain any YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
          final version of the document written in a formal language, such as XML code,
          BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
          document is needed, clearly written, complete, correctly designed, and ready
          to be handed off to the responsible Area Director?

Yes. The document shepherd did a full top-to-bottom review of draft-ietf-cellar-tags-14 which resulted in some significant technical changes, but these changes involved

- tightening BCP 14 language

- providing context for SHOULDs that provide direction for new codec descriptions while not invalidating existing descriptions - Matroska is intended for use in archival media storage, so allowing conformant implementations to process these codec descriptions is critical

- providing explanations for concepts that the working group understands very well, but new implementers might not understand

10.Several IETF Areas have assembled lists of common issues that their
          reviewers encounter. For which areas have such issues been identified
          and addressed? For which does this still need to happen in subsequent
          reviews?

No issues with common issues have been identified for this document - the document content is application-level, and provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, so no additional issues with common issues are expected here.

11. What type of RFC publication is being requested on the IETF stream (Best
          Current Practice, Proposed Standard, Internet Standard,
          Informational, Experimental or Historic)? Why is this the proper type
          of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is appropriate for this document. It provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, which is also published as Proposed Standard. It holds the same position as "Matroska Media Container Tag Specifications", which is under IESG review as of this writing, and is also requesting Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
          property rights (IPR) disclosure obligations described in BCP 79? To
          the best of your knowledge, have all required disclosures been filed? If
          not, explain why. If yes, summarize any relevant discussion, including links
          to publicly-available messages when applicable.

Yes. Document authors have been surveyed. All have confirmed in email that no disclosures have been made, and no disclosures are expected..

13. Has each author, editor, and contributor shown their willingness to be
          listed as such? If the total number of authors and editors on the front page
          is greater than five, please provide a justification.

Yes. Document authors have agreed.

14.Document any remaining I-D nits in this document. Simply running the idnits
          tool is not enough; please review the "Content Guidelines" on
          authors.ietf.org. (Also note that the current idnits tool generates
          some incorrect warnings; a rewrite is underway.)

Beyond the Content Guidelines, idnits 2.17.1 identifies possible downrefs, but please see below. :

Also - idnits 2.17.1 identifies [Events] as a possible missing reference, but it's not - it's a string in Section 6.3, and appears twice.

15. Should any informative references be normative or vice-versa? See the IESG
          Statement on Normative and Informative References.

The Normative references really are normative. The Informative references are really informative.

—------------

16.List any normative references that are not freely available to anyone. Did
          the community have sufficient access to review any such normative
          references?

  -- ref. 'ALAC' is freely available.

  -- ref. 'ARIB.STD-B10' is freely available.

  -- ref. 'ARIB.STD-B24' is freely available.

  -- ref. 'ARIB.TR-B14' is freely available.

  -- ref. 'ATSC.A52' is freely available.

  -- ref. 'AV1' is freely available.

  -- ref. 'AV1-ISOBMFF 'is freely available.

  -- ref. 'BITMAPINFOHEADER' is freely available.

  -- ref. 'Blu-ray.Part3' is freely available.

  -- ref. 'Dirac' is freely available.

  -- ref. 'DolbyVision-ISOBMFF' is freely available.

  -- ref. 'ETSI.EN300-468' is freely available.

  -- ref. 'ETSI.EN300-743' is freely available.

  -- ref. 'ETSI.TS102-114'  is freely available.

  -- ref. 'ETSI.TS102-366'  is freely available.

  -- ref. 'IEEE.1857-10' is available for purchase from IEEE.

  -- ref. 'IEEE.1857-3' is available for purchase from IEEE.

  -- ref. 'IEEE.1857-4' is available for purchase from IEEE.

  -- ref. 'IEEE.754' is available for purchase from IEEE.

  -- ref. 'ISO.11172-2' is available for purchase from ISO.

  -- ref. 'ISO.11172-3' is available for purchase from ISO.

  -- ref. 'ISO.13818-2' is available for purchase from ISO.

  -- ref. 'ISO.14496-15' is available for purchase from ISO.

  -- ref. 'ISO.14496-2' is available for purchase from ISO.

  -- ref. 'ISO.14496-3' is available for purchase from ISO.

  -- ref. 'JPEG'  is freely available.

  -- ref. 'JPEG2000' is available for purchase from ITU-T.

  -- ref. 'OggKate'  is freely available.

  -- ref. 'QTFF'  is freely available.

  -- ref. 'SSA' is freely available.

  -- ref. 'Theora'  is freely available.

  -- ref. 'TRUEHD' is freely available.

  -- ref. 'TTA'  is freely available.

  -- ref. 'USF'  is freely available.

  -- ref. 'VobSub'  is freely available.

  -- ref. 'VORBIS'  is freely available.

  -- ref. 'VP9'  is freely available.

  -- ref. 'WAVEFORMATEX' is freely available.

  -- ref. 'WAVPACK'  is freely available.

  -- ref. 'WebVTT'  is freely available.


17. Are there any normative downward references (see RFC 3967 and BCP
          97) that are not already listed in the DOWNREF registry? If so,
          list them.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ALAC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AV1'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AV1-ISOBMFF'

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'BITMAPINFOHEADER'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Dirac'

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'DolbyVision-ISOBMFF'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-10'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-3'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-4'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG2000'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'OggKate'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'QTFF'

  ** Downref: Normative reference to an Informational RFC: RFC 6386

  ** Downref: Normative reference to an Informational RFC: RFC 9043

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SSA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Theora'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TRUEHD'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TTA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USF'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VobSub'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VORBIS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VP9'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WAVEFORMATEX'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WAVPACK'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WebVTT'

18. Are there normative references to documents that are not ready to be
          submitted to the IESG for publication or are otherwise in an unclear state?
          If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs?

No.

20. Describe the document shepherd's review of the IANA considerations section,
          especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

21. List any new IANA registries that require Designated Expert Review for
          future allocations. Are the instructions to the Designated Expert clear?
          Please include suggestions of designated experts, if appropriate.

This document creates a new registry called the "Matroska Tag Names" registry.

The new registry uses the "Specification Required" policy [RFC8126].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents: draft-ietf-cellar-codec-16

*This version is dated 4 July 2022.*

## Document History
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The WG is small (6-8 active participants), and the authors are the most active contributors, but the entire active working group was involved in reaching consensus for this document.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No. This working group is quite calm, and work on draft-ietf-cellar-codec was no exception.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

4. For protocol documents, are there existing implementations of the contents of
the document?

Yes. Notable implementations include vlc, ffmpeg, mkvtoolnix, mediainfo.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Pretty much all the relevant people participate in this IETF WG.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not contain any MIB, YANG module, new media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
          the justification for not fixing them at this time? Does the YANG module
          comply with the Network Management Datastore Architecture (NMDA) as specified
          in RFC 8342?

This document does not contain any YANG modules.

8. Describe reviews and automated checks performed to validate sections of the
          final version of the document written in a formal language, such as XML code,
          BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
          document is needed, clearly written, complete, correctly designed, and ready
          to be handed off to the responsible Area Director?

Yes. The document shepherd did a full top-to-bottom review of draft-ietf-cellar-tags-14 which resulted in some significant technical changes, but these changes involved

- tightening BCP 14 language

- providing context for SHOULDs that provide direction for new codec descriptions while not invalidating existing descriptions - Matroska is intended for use in archival media storage, so allowing conformant implementations to process these codec descriptions is critical

- providing explanations for concepts that the working group understands very well, but new implementers might not understand

10.Several IETF Areas have assembled lists of common issues that their
          reviewers encounter. For which areas have such issues been identified
          and addressed? For which does this still need to happen in subsequent
          reviews?

No issues with common issues have been identified for this document - the document content is application-level, and provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, so no additional issues with common issues are expected here.

11. What type of RFC publication is being requested on the IETF stream (Best
          Current Practice, Proposed Standard, Internet Standard,
          Informational, Experimental or Historic)? Why is this the proper type
          of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is appropriate for this document. It provides additional capabilities for "Matroska Media Container Format Specification", RFC 9559, which is also published as Proposed Standard. It holds the same position as "Matroska Media Container Tag Specifications", which is under IESG review as of this writing, and is also requesting Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
          property rights (IPR) disclosure obligations described in BCP 79? To
          the best of your knowledge, have all required disclosures been filed? If
          not, explain why. If yes, summarize any relevant discussion, including links
          to publicly-available messages when applicable.

Yes. Document authors have been surveyed. All have confirmed in email that no disclosures have been made, and no disclosures are expected..

13. Has each author, editor, and contributor shown their willingness to be
          listed as such? If the total number of authors and editors on the front page
          is greater than five, please provide a justification.

Yes. Document authors have agreed.

14.Document any remaining I-D nits in this document. Simply running the idnits
          tool is not enough; please review the "Content Guidelines" on
          authors.ietf.org. (Also note that the current idnits tool generates
          some incorrect warnings; a rewrite is underway.)

Beyond the Content Guidelines, idnits 2.17.1 identifies possible downrefs, but please see below. :

Also - idnits 2.17.1 identifies [Events] as a possible missing reference, but it's not - it's a string in Section 6.3, and appears twice.

15. Should any informative references be normative or vice-versa? See the IESG
          Statement on Normative and Informative References.

The Normative references really are normative. The Informative references are really informative.

—------------

16.List any normative references that are not freely available to anyone. Did
          the community have sufficient access to review any such normative
          references?

  -- ref. 'ALAC' is freely available.

  -- ref. 'ARIB.STD-B10' is freely available.

  -- ref. 'ARIB.STD-B24' is freely available.

  -- ref. 'ARIB.TR-B14' is freely available.

  -- ref. 'ATSC.A52' is freely available.

  -- ref. 'AV1' is freely available.

  -- ref. 'AV1-ISOBMFF 'is freely available.

  -- ref. 'BITMAPINFOHEADER' is freely available.

  -- ref. 'Blu-ray.Part3' is freely available.

  -- ref. 'Dirac' is freely available.

  -- ref. 'DolbyVision-ISOBMFF' is freely available.

  -- ref. 'ETSI.EN300-468' is freely available.

  -- ref. 'ETSI.EN300-743' is freely available.

  -- ref. 'ETSI.TS102-114'  is freely available.

  -- ref. 'ETSI.TS102-366'  is freely available.

  -- ref. 'IEEE.1857-10' is available for purchase from IEEE.

  -- ref. 'IEEE.1857-3' is available for purchase from IEEE.

  -- ref. 'IEEE.1857-4' is available for purchase from IEEE.

  -- ref. 'IEEE.754' is available for purchase from IEEE.

  -- ref. 'ISO.11172-2' is available for purchase from ISO.

  -- ref. 'ISO.11172-3' is available for purchase from ISO.

  -- ref. 'ISO.13818-2' is available for purchase from ISO.

  -- ref. 'ISO.14496-15' is available for purchase from ISO.

  -- ref. 'ISO.14496-2' is available for purchase from ISO.

  -- ref. 'ISO.14496-3' is available for purchase from ISO.

  -- ref. 'JPEG'  is freely available.

  -- ref. 'JPEG2000' is available for purchase from ITU-T.

  -- ref. 'OggKate'  is freely available.

  -- ref. 'QTFF'  is freely available.

  -- ref. 'SSA' is freely available.

  -- ref. 'Theora'  is freely available.

  -- ref. 'TRUEHD' is freely available.

  -- ref. 'TTA'  is freely available.

  -- ref. 'USF'  is freely available.

  -- ref. 'VobSub'  is freely available.

  -- ref. 'VORBIS'  is freely available.

  -- ref. 'VP9'  is freely available.

  -- ref. 'WAVEFORMATEX' is freely available.

  -- ref. 'WAVPACK'  is freely available.

  -- ref. 'WebVTT'  is freely available.


17. Are there any normative downward references (see RFC 3967 and BCP
          97) that are not already listed in the DOWNREF registry? If so,
          list them.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ALAC'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AV1'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'AV1-ISOBMFF'

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'BITMAPINFOHEADER'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Dirac'

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'DolbyVision-ISOBMFF'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-10'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-3'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1857-4'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG2000'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'OggKate'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'QTFF'

  ** Downref: Normative reference to an Informational RFC: RFC 6386

  ** Downref: Normative reference to an Informational RFC: RFC 9043

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SSA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Theora'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TRUEHD'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TTA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USF'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VobSub'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VORBIS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VP9'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WAVEFORMATEX'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WAVPACK'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WebVTT'

18. Are there normative references to documents that are not ready to be
          submitted to the IESG for publication or are otherwise in an unclear state?
          If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs?

No.

20. Describe the document shepherd's review of the IANA considerations section,
          especially with regard to its consistency with the body of the document.

The shepherd read it, and then suggested revisions which were incorporated.

21. List any new IANA registries that require Designated Expert Review for
          future allocations. Are the instructions to the Designated Expert clear?
          Please include suggestions of designated experts, if appropriate.

This document creates a new registry called the "Matroska Tag Names" registry.

The new registry uses the "Specification Required" policy [RFC8126].

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/