DISPATCH

Summary

The DISPATCH Working Group held an interim meeting on June 30, 2026, to evaluate several new proposals related to secure time attestation, digital product lifecycle management, capability-based routing, and AI agent naming and discovery. The goal of the session was to determine the appropriate routing (the "dispatch question") for these proposals within the IETF or external venues.

Of the scheduled agenda items, two presentations—"Artificial Intelligence Internet Protocol" and the "dispatch slides template"—were deferred due to a lack of submitted materials. The remaining proposals were presented, discussed, and dispatched.

Key Discussion Points

1. Chairs' Slides & Agenda Bashing

Presenter: Jim Mozley
Slides: Chairs' Slides
Discussion: Jim Mozley introduced the Note Well guidelines, reviewed intellectual property rights (IPR) policies under RFC 5378, and outlined the operational boundaries of the DISPATCH working group. The agenda was updated to bypass items without slide submissions.

2. TTTPS: Pre-Ingestion Proof of Time

Presenter: 장동호 (Jaime)
Slides: TTTPS: Pre-Ingestion Proof of Time
Draft: draft-jorgan-tttps (Pre-Ingestion Proof of Time for AI Agent)
Technical Overview: The proposal introduces TTTPS (Pre-Ingestion Proof of Time), a temporal origin primitive designed to provide a verifiable proof of when data was sealed before entering a system. It leverages RFC 3161 consensus, Ed25519 cryptography, and TLS exporter session binding (RFC 5705) to cryptographically exclude data backdating.
Discussion:
- Muhammad Usama Sardar asked whether the protocol utilizes early or standard TLS exporters and questioned if the protocol actually requires TLS. He suggested that if the work focuses on attestation, it might be more relevant to the RATS or COSE working groups. 장동호 replied that the TLS exporter is used to bind the content hash and ID to ensure session integrity.
- Eric Rescorla expressed skepticism regarding the security claims and technical value. He noted that because the author is seeking an Experimental RFC and intends to submit the document via the Independent Submissions Editor (ISE) track, no IETF working group action is required.
- Jim Mozley noted that some mailing list participants had suggested establishing a dedicated mailing list for further discussion.
- Clarification on ISE/IESG routing: At the end of the meeting, Eric Rescorla and Roman Danyliw clarified for the record that DISPATCH did not endorse or recommend sending the draft to the IESG or ISE. They emphasized that the ISE and IESG function independently of the DISPATCH working group's jurisdiction, and authors may pursue independent submissions entirely on their own initiative.

3. Secured Digital Lifecycle Protocol (SDLP)

Presenter: M. Norton
Slides: Secured Digital Lifecycle Protocol (SDLP)
Draft: draft-norton-sdlp (Secured Digital Lifecycle Protocol)
Technical Overview: SDLP is a self-contained security protocol operating between the transport and application layers. It attempts to apply physical lifecycle properties to digital objects, tracking copies via child IDs and implementing a "tamper guard" (where a file performs a "bit drop" and effectively self-destructs if exploited or shared beyond allowed limits).
Discussion:
- Ted Hardie recommended a "no action" outcome, stating that the draft lacked sufficient technical detail to evaluate and did not have a clear architectural binding to existing IETF transport or application layer standards.
- Rich Salz questioned how a passive file on physical storage media could execute programmatic actions (such as a "bit drop") without an active execution environment. He noted the architecture strongly resembles digital rights management (DRM). M. Norton clarified that the object itself is designed to enforce these rules natively rather than relying on external legal policies.
- Eric Rescorla supported the "no action" recommendation, noting there was no clear connection to IETF work and no demonstrated demand for an interoperable standard.
- Kathleen Moriarty agreed with "no action" and suggested the presenter explore external decentralized ledger and provenance projects, such as iota.org, Sigstore, and the IETF's SCITT working group.

4. CIRP: A Capability-Oriented Intent Routing Protocol

Presenter: Saurabh Verma
Slides: CIRP: A Capability-Oriented Intent Routing Protocol
Draft: draft-verma-chirp-routing (A Capability-Oriented Intent Routing Protocol)
Technical Overview: CIRP (referred to as CHIRP) addresses capability-oriented discovery and authorization. Rather than routing to a specific host address, it enables endpoints (such as AI agents and automated systems) to locate and invoke services based on what actions they can perform. The framework covers capability advertising, authorization binding, secure session transport, and fulfillment receipts.
Discussion:
- Saurabh Verma asked for clarification on the recommended action items for the protocol, noting that he plans to split the monolithic draft into separate documents covering architecture, discovery, authorization, and receipts.
- Jim Mozley explained that the proposal currently lacks a broader community of independent implementers interested in interoperating. He advised the author to build a development community around the work before bringing it back to the IETF to prevent it from becoming an orphan protocol.
- Jim Mozley also noted that the agent-to-agent (agent2agent) mailing list would be a highly relevant venue for discussing broader AI agent communication and coordination concepts.

5. DNS-Based Agent Naming (DAN)

Presenter: Ramachandra Seethiraju
Slides: DNS-Based Agent Naming (DAN)
Draft: draft-seethiraju-dan-agent-naming (DNS-Based Agent Naming)
Technical Overview: This draft proposes a DNS-based discovery mechanism for AI agents using two new DNS resource records: AI-DISC and AI-INDEX. AI-DISC maps an agent name to essential discovery metadata (protocol, endpoint, coarse capabilities, and certificate bindings), while AI-INDEX allows zone operators to publish lists of discoverable agent names at the zone apex.
Discussion:
- Ted Hardie noted that the draft exhibits substantial technical and conceptual overlap with the charter, requirements, and use cases of the DNS-Based Agent Naming (DAN) Working Group. He asked the presenter if there was any reason the work should not be routed directly to the DAN Working Group.
- Ramachandra Seethiraju agreed that the work fits squarely within the DAN Working Group’s scope.
- Ted Hardie recommended dispatching the work directly to the DAN Working Group. No objections were raised.

Decisions and Action Items

Proposal / Draft	Dispatch Outcome	Action Item
TTTPS: Pre-Ingestion Proof of Time (draft-jorgan-tttps)	No IETF Action	The author may pursue the Independent Submissions Editor (ISE) track on their own. The IETF will take no direct action.
Secured Digital Lifecycle Protocol (draft-norton-sdlp)	No IETF Action	The author was advised to look at external industry efforts (such as Sigstore, SCITT, or iota.org).
CIRP: Capability-Oriented Intent Routing Protocol (draft-verma-chirp-routing)	No IETF Action	The author should work on building a multi-party community of interest and split the architecture into focused drafts.
DNS-Based Agent Naming (DAN) (draft-seethiraju-dan-agent-naming)	Direct to Working Group	Route the proposal to the DAN Working Group for further development.

Next Steps

DAN Draft Integration: Ramachandra Seethiraju to bring draft-seethiraju-dan-agent-naming to the DAN Working Group mailing list for coordination with their active charter.
Community Building for CIRP: Saurabh Verma to engage with participants on the agent-to-agent mailing list to socialise capability-oriented routing requirements and gather feedback on architectural splits.

Automatic IETF Minutes