Session Date/Time: 01 Oct 2025 17:00

DIEM

Summary

The DIEM interim meeting primarily focused on a detailed walkthrough and discussion of draft-ietf-diem-use-cases-and-requirements-00. The co-editors, Rahel and Felix, presented the document's structure and content, emphasizing its "requirements-first" approach. Key discussions revolved around bearer identification (FQDN vs. IP addresses), the scope of the document, and the process for its adoption as a Working Group document. A strong sense of those present indicated support for moving forward with a call for adoption.

Key Discussion Points

Introduction of draft-ietf-diem-use-cases-and-requirements-00: Co-editors Rahel and Felix presented the document, explaining its structure to prioritize requirements, followed by extensions and use cases.
- The "requirements-first" approach aims to clearly define the initial scope of the DIEM architecture, provide a framework for future work, and facilitate stakeholder input.
Bearer Identification (Requirement 3.1.1):
- The document currently specifies Fully Qualified Domain Names (FQDNs) for bearer identification, aligning with the WG charter.
- Michael Richardson raised concerns about the sole reliance on FQDNs, suggesting that IP addresses should also be explicitly identified, citing operational challenges with reverse maps and the potential for collateral damage when sharing IP infrastructure.
- Rahel clarified that while FQDNs are charter-aligned, the document could allow for co-identification with IP addresses and includes concepts for bridging mechanisms to other identifiers.
- Ori Steele inquired about feedback from cyber operators on the suitability of FQDNs as a conveyance mechanism for their assets. Felix noted that while ICRC research (Samit, not present) indicated support for domain names, the current draft hasn't been widely circulated to external stakeholders. The intent is to adopt the draft first, then gather broader stakeholder feedback with a stable WG document.
- Bill asserted that IP addresses are already encompassed by FQDNs via .arpa zones, thus requiring no special action or rechartering. Martin countered that operational difficulties in updating reverse maps make this a non-trivial issue, suggesting a more direct update mechanism for bearers might be needed.
- Jim emphasized the need to avoid diving into deep operational details at this stage and advocated for circulating the document broadly to gather use case feedback, cautioning against scope creep by attempting to encompass all potential identifiers (e.g., UPCs, RFID tags) immediately.
- Tommy noted that while general URLs were considered, the decision was to stick with the charter's FQDN focus for now to build consensus. Rowan added that the document's phrasing requiring an FQDN identifier does not preclude other identifiers, providing sufficient flexibility.
Review of Other Requirements:
- Emblem Semantics (3.1.2): Use cases must specify the semantics of the emblem and bearer, and how discovery/validation informs validators.
- Discovery Requirements (3.2):
  - Presence Check (3.2.1): Digital emblems must specify how validators check for presence.
  - Removability (3.2.2): Emblems must be "removable" (can be turned off/on).
  - Undetectable Validation (3.2.3): Validation processes for protection-oriented use cases must be undetectable to the bearers, issuers, and authorizers, to avoid alarming targets (especially those without emblems). This addresses prior IESG feedback.
- Validation Requirements (3.3):
  - Validation (3.3.1): Validation should be possible.
  - Authorization (3.3.2): Authorization may be required by some use cases.
- Extensibility (3.4.1): The architecture design must account for future extensions, avoiding overly specific constraints that could create "shadow requirements."
Extensions and Use Cases Sections (4.x and 5.x):
- The Extensions section sketches how past ideas (e.g., new data formats, confidentiality, bearer discovery for non-FQDN assets like "ponds") could be addressed.
- The Use Cases section (alphabetical list of 13 cases) needs further refinement, potentially grouping related cases and detailing how they fit the defined architecture, to make feedback more meaningful.
Document Adoption Discussion:
- A sense of those present was taken, and no objections were raised against adopting draft-ietf-diem-use-cases-and-requirements-00 as a Working Group document.
- Ori Steele (AD) confirmed no objections from the IESG perspective to initiating a call for adoption, advising chairs to check IETF 124 critical dates.
- Felix questioned whether the Use Cases section needed more fleshing out before adoption, especially for non-IETF audiences. Ori and Martin clarified that adoption signifies WG ownership of a good starting point, not a final state, and further revisions are expected before a Working Group Last Call (WGLC).

Decisions and Action Items

Decision: The working group will issue a call for adoption on the mailing list for draft-ietf-diem-use-cases-and-requirements-00.
- Status: Action completed by the chair during the meeting. The call for adoption was issued, for a two-week period ending October 15th. The submitted -00 version was used for the call, as no substantive changes were present in the live copy compared to the officially submitted draft.
Action Item: Participants are encouraged to provide feedback, raise issues, and submit pull requests on the document via the GitHub repository during the adoption call period.

Next Steps

Mailing list discussion and feedback collection regarding the adoption of draft-ietf-diem-use-cases-and-requirements-00.
Following adoption, further refinement of the use cases section in the document, focusing on grouping and explicitly linking them to the defined requirements.
Preparation for IETF 124 in Montreal. The specific meeting day for DIEM is yet to be determined.