**Session Date/Time:** 28 Apr 2026 15:00

# [DIEM](../wg/diem.html)

**Interim Meeting Minutes**  
**Date:** 2026-02-xx (Interim 2026-02)  
**Chairs:** Sarah Jennings, Rohan Mahy  
**AD:** Charles Eckel  
**Notes:** Felix Linker  

## Summary
The DIEM working group met to resolve outstanding issues and pull requests (PRs) for [draft-ietf-diem-requirements](https://datatracker.ietf.org/doc/draft-ietf-diem-requirements/). The primary goal is to reach consensus on the use cases and requirements to establish a stable foundation for the upcoming architecture and protocol design work. The chairs noted that the current plan is to conduct a Working Group Last Call (WGLC) for the requirements document but not necessarily proceed to IETF Last Call/RFC publication immediately, allowing it to serve as a living reference.

## Key Discussion Points

### IHL Use Cases (PR 31 and PR 35)
*   **Discussion:** The group discussed splitting International Humanitarian Law (IHL) use cases into two categories: "Protective Emblems" (e.g., Red Cross, Red Crescent, Blue Shield, Civil Defense, and Dangerous Forces) and "Other IHL Use Cases" (e.g., humanitarian infrastructure using recognizable insignia).
*   **Attributes:** **Rahel Fainchtein** noted the exclusion of Civil Defense in the slide summary, which was corrected. **Bill Woodcock** cautioned against embedding specific business processes or legal definitions (like "protection") into the protocol itself, arguing that the protocol should remain general and data-agnostic.
*   **Outcome:** The split is intended to clarify requirements arising from different legal bases and stakeholder needs. **Rohan Mahy** encouraged participants to review PR 35 for any inappropriate specificities.

### Emblem Independence and Future-Proofing (PR 34)
*   **Discussion:** This PR clarifies that individual emblem types are independent and that requirements for one do not constrain others. It also notes that current limitations (e.g., DNS discovery) reflect current use cases but are not intended to limit future work.
*   **Terminology:** **Bill Woodcock** objected to the term "valid issuer," stating that IETF protocols should not define who is allowed to use them. **Sarah Jennings** and **Tommy Jensen** discussed whether "emblem types" should be referred to as "profiles" or "schemas." 
*   **Outcome:** There was a general agreement on the principle of independence, but the specific language regarding "valid issuers" will be refined on the mailing list. **Sarah Jennings** suggested changing "narrow scope of valid issuers" to "defined set of valid issuers" to accommodate different use cases.

### Forensic Tracing and Proof of Presence (Issue 26, PR 25, PR 33)
*   **Presentation:** [Proof of Presence & DE Consistency - intended nuances and motivations](https://datatracker.ietf.org/meeting/interim-2026-diem-02/materials/slides-interim-2026-diem-02-sessa-proof-of-presence-de-consistency-intended-nuances-and-motivations-00) by **Rahel Fainchtein**.
*   **Technical Content:** The requirement aims to prevent "plausible deniability" by proving an emblem was present and reachable at a specific time. This involves "assured response" (every query gets a response) and "consistency of content."
*   **Discussion:** **Jim Reid** requested more concrete "worked examples" to understand the technical implications. **Allison Mankin** cited the Whiteflag protocol's use of a ledger as an example of proving historical presence. **Bill Woodcock** suggested that if existing protocols (like DNSSEC or Whiteflag) already solve these requirements, DIEM may only need to provide pointers rather than new mechanisms.
*   **Outcome:** Consensus that these are valid requirements for the architecture to enable, even if fulfilled by external mechanisms.

### Other Discovery Mechanisms (Issue 36)
*   **Discussion:** The group reviewed suggestions by Mallory (not present) regarding non-DNS discovery and ephemeral session identifiers.
*   **Attributes:** **Bill Woodcock** and **Felix Linker** expressed skepticism regarding the feasibility or necessity of binding emblems to "data in flight" (ephemeral sessions) without a clear use case. **Tommy Jensen** reminded the group that the working group had previously reached a sense of the room to stay within the current charter scope.
*   **Outcome:** The group agreed not to add specific text to [draft-ietf-diem-requirements](https://datatracker.ietf.org/doc/draft-ietf-diem-requirements/) regarding non-DNS discovery at this time, deferring such considerations to the architecture phase or future rechartering.

## Decisions and Action Items
*   **Decision:** Split IHL use cases (PR 31/35) to distinguish between specific protective emblems and general humanitarian assets.
*   **Decision:** Move discussion on "valid issuer" terminology and emblem "profiles" (PR 34) to the mailing list for refinement.
*   **Action Item:** Participants to review Rahel Fainchtein's text in PR 25 and PR 33 regarding assured responses and forensic tracing.
*   **Action Item:** Chairs to merge uncontroversial PRs and publish a new version (-02) of [draft-ietf-diem-requirements](https://datatracker.ietf.org/doc/draft-ietf-diem-requirements/).

## Next Steps
1.  Finalize the security requirements section, which is currently a gap.
2.  Aim for a Working Group Last Call (WGLC) on the requirements draft following the next revision.
3.  Schedule an interim meeting before IETF 126 (Vienna) to begin focused work on the architecture document.
4.  Encourage interested contributors to start drafting architecture proposals based on the stabilized requirements.