**Session Date/Time:** 24 Feb 2026 20:00

# [CELLAR](../wg/cellar.html)

## Summary

The CELLAR Working Group reviewed the status of its current documents, including CELLAR Tags and CELLAR Codec. A significant discussion focused on clarifying the role of IANA Considerations sections and resolving normative text within them. The group also discussed the future of Matroska, moving away from a "V5" versioning scheme towards an extension-based model, and addressed a proposal for "OTGE Stems" in the context of Matroska profiles and extensions.

## Key Discussion Points

*   **CELLAR Tags Document Status (draft-ietf-cellar-tags-22)**
    *   The -22 draft has been submitted.
    *   Steve has outstanding Pull Requests (PRs) to submit, and one discuss requires follow-up.
    *   An Area Director (AD) evaluation from Mike Bishop is pending.
*   **IANA Normative Text in CELLAR Tags**
    *   A DISCUSS comment from Mohamed Boucadair highlighted the presence of normative text (MUST/MUST NOT) in the IANA Considerations section.
    *   **Discussion:** The IANA Considerations section is primarily for defining IANA's registration procedures and instructions, not for imposing requirements on protocol implementers or registrants. Requirements like a tag name "must only be found once in the IANA registry" should reside in the core protocol text, with IANA's role being to manage the registry according to those protocol rules. The IESG, Designated Experts, and the IETF community (during review) are responsible for enforcing policy, not IANA directly.
    *   **Clarification:** If a sentence duplicates requirements already stated outside the IANA section, it should be removed. If it adds unique requirements, those requirements should be moved out of the IANA section into the main document body.
*   **CELLAR Codec Document Status**
    *   AD evaluation comments on DASH 16 (related to codecs document) have been addressed.
    *   The group aims to request IETF Last Call for this document.
*   **Chapter Codecs and FFV1 v4**
    *   No new updates were reported for either document since the last meeting.
    *   Testing for FFV1 v4 is still in progress.
*   **OTGE Stems Discussion**
    *   A mailing list question about "OTGE stems" and its relevance to CELLAR's scope was discussed.
    *   **Discussion:** The proposal appears to involve a version of Matroska with specific limitations, akin to WebM.
    *   **Suggestion:** This could potentially be handled as a Matroska "profile" rather than requiring fundamental changes to the core specification.
    *   **Scope:** If the work involves only using Matroska without needing new extensions to the Matroska format itself, it is less obvious for CELLAR's scope. If it requires standardization of new Matroska elements or extensions, then it could be in scope. Further discussion is needed to define the actual standardization requirements.
*   **Matroska V5 / Future Extensions**
    *   **Versioning:** The concept of a distinct "Matroska V5" protocol identifier is problematic for the IETF community, especially if there isn't a clear breaking change. The current approach of adding new elements without incrementing a major version number (like Matroska V4) has worked.
    *   **Extension Model:** The preferred model is to treat new features as extensions published in separate RFCs. These RFC numbers could then collectively define a "profile" or supported feature set (e.g., "I support foo: RFC X, Y, Z"). This aligns well with how the IETF typically handles document evolution.
    *   **Backward Compatibility (Timestamps):** A potential breaking change involving rational number timestamps was discussed (from an old PR, [https://github.com/ietf-wg-cellar/matroska-specification/pull/22](https://github.com/ietf-wg-cellar/matroska-specification/pull/22)). It needs to be determined if this can be implemented in a backward-compatible manner (e.g., old and new systems coexisting). If not, it becomes a more significant issue.
    *   **Naming for New Documents:** For accumulated features (currently grouped under a conceptual "V5" by the community), it was suggested to use a general name like "Matroska Additions" for the initial large set of accumulated changes. In the future, individual new elements or groups of related features could be documented in separate RFCs (e.g., "Matroska Codec Extensions", "Matroska Streaming Features"). This addresses a "one-time problem" of many accumulated ideas.
    *   **Publication:** There is user pressure for some new features (e.g., video skipping in streaming services) to be published as RFCs.

## Decisions and Action Items

*   **ACTION: Steve** to create a PR to move normative text out of the IANA Considerations section in `draft-ietf-cellar-tags`. (Due before IETF 125 ID Cutoff)
*   **ACTION: Chair (Robert)** to follow up with Area Director Ori regarding the `draft-ietf-cellar-codec` document to request IETF Last Call, specifically aiming to finalize this before IETF 125.
*   **ACTION: Chair (Robert)** to socialize the Matroska versioning and extension approach (moving away from a "V5" protocol identifier, towards an extension-based model with separate RFCs) with the IESG and broader IETF community to gather guidance.
*   **ACTION: Steve** to investigate the backward compatibility of the rational number timestamp proposal (from Matroska GitHub PR #22).
*   **ACTION: Chair** to follow up with Mike Bishop regarding his outstanding DISCUSS on `draft-ietf-cellar-tags`.

## Next Steps

*   Proceed with document updates and AD follow-ups to progress `draft-ietf-cellar-tags` and `draft-ietf-cellar-codec` towards IETF Last Call/publication.
*   Further discussions and technical work on Matroska extensions, focusing on the extension model and resolving backward compatibility for potential breaking changes like timestamps.
*   Engage with the IESG and other IETF groups on best practices for versioning and extensions for complex document sets like Matroska.