Markdown Version | Transcript | Session Recording | Session Materials

DAWN

Summary

The DAWN (Discovery of Agents, Workloads, and Named Entities) BOF was held at IETF 126 to discuss the creation of a working group focused on standardizing discovery architectures for AI agents, workloads, and other named entities across different administrative domains.

The session highlighted significant interest, with participants discussing 24 candidate drafts already submitted in this space. While proponents advocated for utilizing existing internet directory infrastructures like the DNS as a bootstrap mechanism, several participants expressed concerns regarding the scalability of global "Internet-wide" discovery, the complexity of semantic query capabilities, and the critical need for integrating robust trust, identity, and security architectures from day one.

Key Discussion Points

1. Chairs' Introduction and BOF Scoping

Presented by Adrian Farrel and Wes Hardaker (Chairs' Introduction).

• The Chairs outlined the constraints of a working group-forming BOF, highlighting the need for a well-scoped problem, a clear set of initial priorities, and a high probability of success.
• The community was cautioned against deep-diving into specific solutions or candidate drafts during the session, and was encouraged instead to focus on the problem space and the draft charter.

2. DAWN Problem Statement and Terminology

Presented by Rashmit Ananthanarayanan (DAWN problem statement and terminology).

• Core Concepts Defined:
  • Entity: A participant in the ecosystem (AI agents, tools, workloads, compute nodes, data sources).
  • Discovery: The process of locating entities exhibiting desired capabilities or properties.
  • Capability: A description of what an entity can perform (e.g., translation, image generation).
  • Minimum Discoverable Information (MDI): The baseline data an entity exposes to facilitate discovery.
  • Discovery Substrate: The underlying infrastructure (like DNS, local registries, or databases) used to publish and retrieve MDI.
• Out of Scope: AI model behaviors, subsequent post-discovery communication/interaction, entity selection algorithms, authentication, authorization, and orchestration.
• Discussion:
  • Daniel Kahn Gillmor (DKG) asked for clarification on terms like "MDI" versus "MDR" (Minimum Discoverable Record). Rashmit clarified that MDI represents the baseline metadata. DKG and Eric Rescorla (Ekr) expressed skepticism about how an internet-scale capability search (e.g., finding translation services) could scale efficiently.
  • Linda Dunbar questioned how DAWN avoids overlapping with cloud orchestration frameworks (e.g., AWS or Google Cloud compute registries). Rashmit clarified that DAWN aims to enable interoperability across distinct cloud and administrative domains.
  • Ramesh Raskar asked whether "discovery" would bleed into semantic search and intent-parsing, which would require a significantly larger scope.

3. DAWN Use Cases

Presented by Kihong and Frank Brockners (DAWN-use-cases).

• Four Primary Use-Case Categories:
  1. Capability-oriented: An agent discovering tools (such as chart generators) to help design a slide deck.
  2. Resource-oriented: Finding specific compute/GPU nodes with dynamic attributes (such as current load and availability).
  3. Cross-domain/Organizational: A personal assistant in Company A scheduling a meeting with an assistant in Company B.
  4. Natural operations: Human or system agents locating network fault analysis tools.
• Discussion:
  • Eric Rescorla (Ekr) questioned whether global, Internet-wide capability queries (e.g., "who on the Internet can translate French to English?") are a realistic requirement or if the focus should be restricted to trusted partners or local namespaces.
  • Frank Brockners highlighted local, highly constrained environments (e.g., a hospital nursing agent or a warehouse forklift agent) as practical, semi-trusted starting points that do not require global internet scaling.
  • Rashid and Usama raised questions regarding how trust is established during discovery, arguing that the authenticity of the discovered MDI is crucial. Kihong clarified that while the working group would focus on the integrity of the discoverable information, verifying the overall trustworthiness of the entity itself is considered out of scope.

4. DAWN Solution Requirements

Presented by Daniel King (DAWN Solution Requirements).

• The draft requirements aim to classify requirements into entity classification, discovery protocol properties, scaling, resilience, trust, and security.
• Discussion:
  • Stephen Farrell clarified that the core protocol scope of DAWN is conceptually the transaction between the discovering entity and the directory/substrate endpoint.
  • Peter asked if trust anchors (such as root CAs or ID tokens) should be considered within the scope of discovery. Daniel King responded that while DAWN must identify when trust/attestation is required by an endpoint, the mechanisms to evaluate those trust chains should be handled by external specifications or working groups.
  • Usama argued that keeping trust entirely out of scope is highly problematic, as discovering malicious agents poses significant security risks.

5. What the Community Needs to Decide & Charter Discussion

Led by the Chairs (What the Community Needs to Decide and DAWN Charter Discussion).

The Chairs presented recommendations to narrow the charter: focusing initially on AI agents and tools, avoiding full-scale orchestration, defining distinct organizational/domain boundaries, and evaluating DNS as a bootstrap option without forcing it as the sole long-term protocol.

• Open Mic and Chat Log Debate:
  • Trust & Identity Boundaries: Several participants (including Rashid, Usama, and Stephen Farrell) argued that trust and identity are the "elephants in the room" and must be defined alongside discovery. Linda Dunbar and Rashmit discussed leveraging the Workload Identity in Multi-System Environments (WIMSE) working group's outputs for identity semantics. Naved requested that DAWN explicitly define the identity and accountability properties it depends on before protocol work begins.
  • Scoping & Network Diameter: Colin Jakes, Jonathan Rosenberg, and Danny strongly advocated for restricting the scope to single administrative domains or trusted federations rather than global "Internet-scale" discovery, citing unsolvable trust, payment, and namespace issues on the open internet.
  • The Role of DNS: Stephen Farrell expressed doubt that complex capability matching (like finding an MRI reader) could map cleanly to DNS queries. Conversely, John Zinke noted that DNS could be used to retrieve pointer records (like SVCB/TXT) that lead to structured agent cards or negotiation endpoints. Ramesh Raskar suggested a hybrid DNS/non-DNS approach where DNS functions purely as an anchor.
  • Prior Art: Leslie Daigle advised the proponents to thoroughly review RFC 3404 and the Dynamic Delegation Discovery System (DDDS) framework, noting that past IETF efforts faced identical architectural challenges when mapping discovery to the DNS.
  • Alternative Venues & Research: Arnaud Taddei proposed coordinating with ITU-T SG17 and the newly formed TIDA focus group to avoid duplication. Usama suggested that because the engineering space is highly immature, a research group within the IRTF might be a more appropriate starting venue than an IETF working group.
  • Consolidation: Roberta suggested that DAWN could act as a single coordinating venue for AI-related discovery, preventing "AI scope creep" from fragmenting other established IETF working groups.

Decisions and Action Items

• No formal consensus calls or binding procedural decisions were taken during the session (as consensus is determined on the mailing list).
• AD Feedback (Eric Vyncke): Eric Vyncke noted he was optimistic about the engagement in the room. He clarified that the mention of "DNS" in the draft charter was intended as a starting focal point to prevent the discussion from drifting, rather than a rigid constraint. He encouraged the proponents to continue refining the charter on the mailing list.

Next Steps

1. Refine the Draft Charter: Proponents must update the charter draft based on the session's feedback. Key areas of focus include:
   • Clearly defining "collaborating organizations" and the administrative boundaries of discovery.
   • Focusing explicitly on AI agents and tools (such as Model Context Protocol (MCP) servers) as the primary initial discovery targets.
   • Clarifying the dependency on external identity and trust architectures (e.g., WIMSE).
2. Review Prior Art: Proponents will review the Dynamic Delegation Discovery System (DDDS) specifications (including RFC 3404) to extract lessons learned.
3. Mailing List Discussion: Continued discussion on the DAWN mailing list to consolidate the core use cases and prepare for subsequent IESG charter review.