**Session Date/Time:** 23 Jul 2026 12:00 # [DIEM](../wg/diem.html) ## Summary The DIEM (Digital Emblems) working group met at IETF 126. The session covered administration and logistics, an update on the ITU-T Study Group 17 liaison, a status update on the Working Group Last Call (WGLC) for the use cases and requirements document, and an extensive discussion on architectural directions and protocol-level dimensions for digital emblems. --- ## Key Discussion Points ### 1. Liaison Statement from ITU-T Study Group 17 Sarah Jennings provided an update on the liaison with ITU-T Study Group 17 regarding two new work items (`xstr.dm-assets` and `xstr.dm`) initiated in December 2025. The working group replied in April 2026, outlining IETF activities and inviting ITU-T members to participate. Jim Reid noted that the next Study Group 17 meeting is scheduled for early September, which will likely produce subsequent activities relevant to IETF 127. ### 2. Changes in Use Cases and Requirements Document Felix Linke presented [Changes in Use Cases and Requirements Document](https://datatracker.ietf.org/meeting/126/materials/slides-126-diem-changes-in-use-cases-and-requirements-document-01) for [draft-ietf-diem-requirements](https://datatracker.ietf.org/draft-ietf-diem-requirements/). Key updates in versions -02 and -03 include: * Clarifying that use cases should not restrict one another. * Introducing greater flexibility to digital emblem formats and validation requirements. * Adding concepts such as assured or selective response, and consistent or selective content. * Refining the text on the "removability" requirement and removing some restrictive normative language. * Elaborating on details for diplomatic pouches and International Humanitarian Law (IHL) emblems. Rohan Mahy reminded the group that the WGLC for [draft-ietf-diem-requirements](https://datatracker.ietf.org/draft-ietf-diem-requirements/) ends on July 30, and urged participants to send reviews to the mailing list. ### 3. Sequencing of Architecture and Protocol Work The chairs asked the working group how to proceed with the sequencing of the architecture and protocol deliverables. * Felix Linke, Orie Steele, and Allison Mankin advocated for working on the architecture and protocol documents in parallel to ensure the architecture remains practical and grounded. * Charles Eckel (AD) supported this approach, noting that parallel work on the protocol must not delay the progress of the core architecture. * A formal poll was taken, showing strong support for parallel development (see Decisions). ### 4. Architecture Prompt and Technical Dimensions Rohan Mahy presented the [Chair's architecture prompt slides](https://datatracker.ietf.org/meeting/126/materials/slides-126-diem-chairs-architecture-prompt-slides-00) and [Arch dimensions](https://datatracker.ietf.org/meeting/126/materials/slides-126-diem-arch-dimensions-00) to trigger discussion on several architectural design dimensions: * **Information Categorization**: Organizing data into fields for the issuer, asset identification, asset handling (e.g., CITES), emblem type, and emblem instance. * **DNS Delivery Mechanisms**: Options discussed included using TXT records, creating a new Resource Record (RR) type, splitting data across multiple RR types, or using an SVCB/HTTPS URI pointer. * James Mozley, Tommy Jensen, and Jim Reid strongly argued against TXT records due to issues with size and clutter at the zone apex (citing `mit.edu` as a real-world example of overloaded TXT records). * Tommy Jensen relayed a remote comment from Peter Koch emphasizing that "versioned" RR types are historically unsuccessful and violate transparency principles outlined in RFC 3597. * Jim Reid and Tommy Jensen favored using a new RR type or using SVCB records for indirection to web-based services. * **Validation & Verification**: Incorporating DNSSEC, DANE certificates, JSON/CBOR Web Tokens, or Web PKI. * Allison Mankin highlighted DNSSEC's value in providing both source authentication and authenticated proof of non-existence (NSEC/NSEC3). * Felix Linke and Daniel Gillmor raised concerns that DNSSEC alone does not address application-layer authorization (e.g., verifying whether an entity has the legal authority to display a Red Cross emblem). Rahel Fainchtein argued that DNSSEC could still be extended or utilized to build these authorization mechanisms. * Dan York shared data from the Internet Society's Pulse platform showing that only about 39% of global DNS queries currently undergo validation. * Alex Rosenberg argued that standard validation statistics are less critical because validation will be executed by dedicated emblem-validation clients rather than random DNS resolvers. * **Rooting of DNS Records**: Storing records under a dedicated domain (`dm.arpa`), the issuer's domain, or the asset's domain. * Jim Reid argued against `dm.arpa` due to the complexity of getting international bodies (like ICAO or UNESCO) to coordinate delegations at their operational speed. * James Mozley suggested placing records under a designated label like `_dm` under the issuer or asset domain to avoid apex resolution issues. * Laura Scalone inquired about the discovery of DIEM names and whether a global registry would be necessary. Tommy Jensen and Allison Mankin clarified the distinction between discovering asset identifiers and discovering an asset's emblem once the name is known. * **Asset Types**: The charter explicitly focuses on assets identified by a Fully Qualified Domain Name (FQDN). Tommy Jensen and Orie Steele advised sticking closely to FQDN-based assets to avoid over-engineering. Rohan Mahy noted the architecture should still maintain flexibility for future non-FQDN extensions (e.g., IPs, ASNs, data at rest/flight) without fully defining them now. * **Other Operational Dimensions**: Discussion touched on offline support, undetectable validation, logging/traceability, and selective disclosure. Nic Williams suggested considering a "disaster recovery" or delegation scenario where an organization loses access to its primary DNS infrastructure but needs to authorize emergency personnel to display emblems. --- ## Decisions and Action Items ### Decisions * The Working Group agreed to develop the architecture and protocol documents in parallel, provided it does not delay the primary architectural deliverable. ### Session Polls * **Poll 1**: *Is the WG happy to work on the architecture and protocol documents in parallel?* * **Yes**: 11 * **No**: 0 * **No Opinion**: 2 * **Total Responses**: 30 ### Action Items * **Rohan Mahy** to send detailed DNSSEC deployment and validation statistics to the mailing list. * **Jim Reid** to post a technical explanation to the list outlining why TXT records are discouraged for this type of application. * **Tommy Jensen** to coordinate with chairs and relevant DNS experts regarding the scope and applicability of using SVCB/DDDS records for emblem indirection. * **All WG Participants** to review and submit feedback for [draft-ietf-diem-requirements](https://datatracker.ietf.org/draft-ietf-diem-requirements/) before the WGLC closes on July 30. --- ## Next Steps * Conclude the Working Group Last Call on [draft-ietf-diem-requirements](https://datatracker.ietf.org/draft-ietf-diem-requirements/) on July 30. * Begin drafting early architectural and protocol proposals as separate, parallel efforts. * Plan a virtual interim meeting between IETF 126 and IETF 127 to review architectural drafts.