CELLAR

Summary

The CELLAR Working Group held an interim meeting to discuss the status of its active documents, address outstanding IESG DISCUSS positions on draft-ietf-cellar-codec, and outline steps to improve the visibility of working group consensus on the mailing list. The group also discussed technical concerns regarding interoperability with defunct or non-public specifications, registry policies, and future interim meeting planning.

Key Discussion Points

Document Status and Minutes Approval

The minutes of the previous meeting were reviewed and approved by Steve Lhomme and Jérôme Martinez.
draft-ietf-cellar-tags remains in the RFC Editor queue.
draft-ietf-cellar-codec is currently under IESG evaluation.

Addressing IESG DISCUSS Positions on draft-ietf-cellar-codec

The working group discussed the two active DISCUSS positions from Eric Rescorla and Roman Danyliw:

Eric's DISCUSS: Steve Lhomme reported that he added a reference to the relevant RFC, which resolved this concern.
Roman's DISCUSS:
- Steve Lhomme noted that Pull Request (PR) 1128 was created to address this and is ready to merge.
- Roman raised a procedural concern regarding the lack of visible working group participation and consensus-building on the mailing list, as much of the activity has occurred within GitHub.
- Roman also raised a technical concern regarding how interoperability is achieved when IANA registry code points reference non-public or defunct specifications (e.g., the DVD Forum specification).

Technical Discussion on Interoperability and Non-Public Specs

Use Case and Archival Context: Robert Sparks noted that for CELLAR, interoperability often means ensuring that an archivist can read back a self-contained record they created. Dave Rice added that the original motivation of the working group was to make media files highly self-descriptive (e.g., explicitly defining aspect ratio, interlacement, and color space) to prevent media players from relying on guesswork.
Legacy and Paywalled References: Steve Lhomme pointed out that archives typically transcode to preferred formats (e.g., FFV1, FLAC) rather than maintaining original container contexts. Matroska's design aims to support all formats that were popular at any given time. Referencing defunct or paywalled standards (such as ISO standards) is a common industry reality; even if a specification body disbands, the documents often remain available within existing implementations and organizations.
Review Mechanisms: Charles Eckel noted that the IETF can send a Liaison Statement (LS) to request temporary access to proprietary specifications for the purpose of review.
Registry Policies & Designated Expert Guidance: Charles Eckel suggested that for media formats with no written specification (where only an open-source implementation or hardware exists), it is still beneficial to have an IANA code point. In such cases, the registry cannot strictly require a specification, and the decision must rely on the judgment of the Designated Expert (DE). The group agreed to add explicit guidance text in the document for DEs dealing with these scenarios.

Working Group Consensus and Mailing List Artifacts

Robert Sparks emphasized the need to bring discussion and consensus back to the mailing list to create a permanent archive, which is especially important now that the document is under IESG review.
Rather than holding up updates, the group agreed that Steve Lhomme should publish draft-ietf-cellar-codec-21 containing the current fixes.
Following publication, Spencer Dawkins will post a summary of the changes to the mailing list to solicit explicit feedback and confirm consensus.
Special attention will be paid to PR 1111 in the mailing list summary. Steve Lhomme explained that PR 1111 represents a solution agreed upon with Google to support new metadata (T_cert5).

Other Business

Charter Update: Spencer Dawkins will migrate the proposed charter text from Google Docs to GitHub. Steve Lhomme has already submitted the individual drafts containing the necessary file name updates.
Broken GitHub Mailer: Steve Lhomme noted that the automated weekly GitHub activity emails to the CELLAR mailing list have been broken since August 9, showing only commit numbers and authors without titles or links. Robert Sparks volunteered to investigate the mailer tool installation.
IETF 125 Planning: Charles Eckel asked about meeting plans for IETF 125 in San Francisco. Spencer Dawkins and Steve Lhomme confirmed that the working group will not hold an in-person meeting and will continue to meet via virtual interims.

Decisions and Action Items

Decision: Publish draft-ietf-cellar-codec-21 containing the current PR fixes, rather than waiting for mailing list approval of individual PRs.
Decision: Add guidance text for Designated Experts in the codec draft to address registrations where specifications are not fully public or available.
Decision: The working group will not request an in-person session at IETF 125.
Action Item (Steve Lhomme): Draft and propose the guidance text for Designated Experts regarding unavailable specifications.
Action Item (Spencer Dawkins): Post a comprehensive summary of changes (specifically highlighting PR 1111) to the mailing list once version -21 is published to solicit explicit participant consensus.
Action Item (Spencer Dawkins): Migrate the proposed new charter text from the Google Doc to GitHub.
Action Item (Robert Sparks): Investigate and fix the broken automated weekly GitHub activity email tool on the mailing list.

Next Steps

Working group participants are requested to review and reply to the upcoming mailing list summary of draft-ietf-cellar-codec-21 to establish a clear record of consensus.
Participants are encouraged to reply to Sam’s recent email regarding his application on the mailing list.

Automatic IETF Minutes