Individual Submission D. King Internet-Draft Lancaster University Intended status: Informational K. Yao Expires: 14 March 2027 China Mobile K. Adler Indeed R. Ramdhany BBC 10 September 2026 Use Cases and Applicability for Discovery of Agents With Names draft-kay-dawn-use-cases-01 Abstract This document describes use cases and applicability for Discovery of Agents With Names (DAWN). It illustrates how clients discover AI resources and obtain the minimum information needed for subsequent interaction within a local network, within an organisation, or between cooperating organisations with trust relationships. This document does not define a discovery protocol, a registration procedure, a selection algorithm, or an agent-to-agent communication protocol. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kay-dawn-use-cases/. Discussion of this document takes place on the Individual Submission Individual mailing list (mailto:dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn/. Subscribe at https://www.ietf.org/mailman/listinfo/dawn/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. King, et al. Expires 14 March 2027 [Page 1] Internet-Draft DAWN Use Cases September 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Limitations of this Document . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Discovery Characteristics . . . . . . . . . . . . . . . . . . 7 6. Discovery Pattern . . . . . . . . . . . . . . . . . . . . . . 8 7. Categories of Discovery . . . . . . . . . . . . . . . . . . . 9 7.1. Capability-Oriented Discovery . . . . . . . . . . . . . . 9 7.1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 9 7.1.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 9 7.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Resource-Oriented Discovery . . . . . . . . . . . . . . . 9 7.2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 10 7.2.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 10 7.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Administrative Scope Extensions . . . . . . . . . . . . . 11 7.3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 11 7.3.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 11 7.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Operational Discovery . . . . . . . . . . . . . . . . . . 12 7.4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 12 7.4.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 12 7.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 12 8. Classes of Use Case . . . . . . . . . . . . . . . . . . . . . 13 8.1. AI Agent . . . . . . . . . . . . . . . . . . . . . . . . 13 King, et al. Expires 14 March 2027 [Page 2] Internet-Draft DAWN Use Cases September 2026 8.2. Software Service . . . . . . . . . . . . . . . . . . . . 13 8.3. Compute Workload . . . . . . . . . . . . . . . . . . . . 13 8.4. Network Function . . . . . . . . . . . . . . . . . . . . 13 8.5. Application Endpoint . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 11. Operational Considerations . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Cross-Organisation Appointment Coordination . . . . 16 A.1. Actors and Assumptions . . . . . . . . . . . . . . . . . 16 A.2. Initial Discovery at a Known Organisation . . . . . . . . 17 A.3. Supporting Resource Discovery and Restaurant Reservation . . . . . . . . . . . . . . . . . . . . . . . 17 A.4. Reconnection and Rediscovery . . . . . . . . . . . . . . 19 A.5. Discovery Information Needed in This Scenario . . . . . . 20 A.6. Security, Privacy, and Operational Considerations . . . . 21 A.7. Links to the DAWN Requirements . . . . . . . . . . . . . 21 Appendix B. Provisioning Edge Compute for Personalised Live Media . . . . . . . . . . . . . . . . . . . . . . . . . . 22 B.1. Actors and Assumptions . . . . . . . . . . . . . . . . . 23 B.2. Discovery and Provisioning . . . . . . . . . . . . . . . 23 B.3. Changes During the Broadcast . . . . . . . . . . . . . . 24 B.4. Security and Privacy . . . . . . . . . . . . . . . . . . 24 B.5. Links to the DAWN Requirements . . . . . . . . . . . . . 24 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Artificial Intelligence (AI) systems may depend on resources whose capabilities, locations, or communication methods are not configured in advance. Discovery allows a client to locate a resource and obtain the minimum information needed to attempt a subsequent interaction. Discovery of Agents With Names (DAWN) initially focuses on AI agents and their capabilities, including discovery of other resources used in AI systems. This document uses "entity" for a discoverable component in that context. Such entities may include agents, tools, services, tasks, data sources, models, inference services, workloads, brokers, and application endpoints. Skills may be discoverable attributes of those entities. Reuse in other discovery contexts is desirable, but does not extend the initial scope to general resource discovery. King, et al. Expires 14 March 2027 [Page 3] Internet-Draft DAWN Use Cases September 2026 The DAWN problem statement [I-D.akhavain-moussa-dawn-problem-statement] and the DAWN requirements document [I-D.king-dawn-requirements] provide background for this work. These use cases inform the Discovery Architecture, which will define the requirements and minimum discovery information. This document defines the following categories of entity discovery: 1. Capability-Oriented Discovery, where an entity needs to discover another entity that can provide a function or capability. 2. Resource-Oriented Discovery, where discovery identifies resources used in AI systems. 3. Administrative Scope Extensions, where discovery crosses organisational, delegation, or tenancy boundaries within the applicable trust relationships. 4. Operational Discovery, where discovery supports operation, audit, troubleshooting, compliance, or automation. The first two categories are base cases. The others describe common extensions or deployments of those base cases. Other Internet-Drafts describe agentic AI discovery use cases and communication protocol requirements, including [I-D.mozley-aidiscovery], [I-D.agentic-ai-usecases-requirements], and [I-D.scrm-aiproto-usecases]. 2. Limitations of this Document This document describes discovery within a local network, within an organisation, or between cooperating organisations with trust relationships over the public Internet. It does not describe the full lifecycle of an entity or establish those trust relationships. The following are in scope: * discovery of a specific named AI resource; * discovery of candidate AI resources by capability or other discovery properties within the applicable deployment; * discovery of tasks as resources in an AI system; * discovery initiated by an agent, workload, service, application, or human operator; King, et al. Expires 14 March 2027 [Page 4] Internet-Draft DAWN Use Cases September 2026 * discovery of supporting resources used by AI agents and applications; * exchange of the minimum discovery information, directly or by indirection, before selection, invocation, or communication can take place. The following are out of scope: * registration of entities for discovery; * authentication or attestation of registrations; * design, definition, or governance of naming systems; * identity management of AI agents, tools, and skills; * trust management and trust evaluation beyond protecting content exchanged between discovery participants; * selection among candidate entities returned by discovery; * exchange of capability information beyond the minimum discovery information defined by the Architecture work; * capability negotiation after discovery; * all application communication beyond the discovery process; * task orchestration; * standalone certificate or key lookup services; and * AI resource indexing across the wider Internet, general search, ranking, or marketplace discovery. Clients may query an organisation's catalogue or a cooperating discovery service within these boundaries. They may follow references to obtain minimum discovery information. Fetching a richer capability description is a subsequent application exchange, even when discovery supplies its reference. 3. Terminology Terminology for DAWN is defined in [I-D.farrel-dawn-terminology]. Attention is drawn to the following specific terms defined in [I-D.farrel-dawn-terminology] that are key to this document: King, et al. Expires 14 March 2027 [Page 5] Internet-Draft DAWN Use Cases September 2026 * discovering entity * discovered entity * discoverable object * discovery information * minimum discoverable information The client initiating discovery is the discovering entity. In this document, "minimum discovery information" refers to the minimum discoverable information whose content is to be defined by the Architecture requirements. The appendix also uses the following implementation term: Agent harness Software that supports an AI agent's execution, such as interaction with models, invocation of tools, management of context and state, and application of execution controls. It may support discovery on behalf of the agent. This document does not specify its internal operation. Opensource examples of an agent harness include: OpenClaw and Hermes. 4. Applicability The categories in Section 7 apply in three settings: King, et al. Expires 14 March 2027 [Page 6] Internet-Draft DAWN Use Cases September 2026 +===============+=======================+===========================+ | Deployment | Illustrative | Applicability condition | | | discovery need | | +===============+=======================+===========================+ | Local network | An assistant finds a | Discovery visibility is | | | nearby inference | local; using the service | | | service advertised on | remains subject to | | | its local network. | application permissions. | +---------------+-----------------------+---------------------------+ | Within an | An enterprise | Publication and access | | organisation | assistant finds an | follow the | | | internal data source | organisation's existing | | | or tool. | administrative and trust | | | | arrangements. | +---------------+-----------------------+---------------------------+ | Between | An assistant finds a | The organisations have a | | cooperating | partner's calendar- | trust relationship; | | organisations | coordination agent. | discovery finds | | | | resources within that | | | | relationship. | +---------------+-----------------------+---------------------------+ Table 1 Organisations publish independently and may use delegation or federation under existing trust arrangements. Knowing an organisation's name does not establish trust. Conversely, a partner's agents and endpoints may be unknown even when the organisational relationship is established. DNS and mDNS are possible discovery mechanisms; others may also be suitable. Protocol work should reuse existing IETF mechanisms where possible. 5. Discovery Characteristics The use cases share a common question: what must a client discover before it can attempt interaction with an entity? * Discovery may be initiated by autonomous software or by a human operator. * The discovered target may be a specific named entity or a set of entities determined by properties or classification. * Capability is often an important discovery input, but it is not the only one. Organisation, jurisdiction, locality, protocol, policy, and responsible party also appear in several use cases. King, et al. Expires 14 March 2027 [Page 7] Internet-Draft DAWN Use Cases September 2026 * The minimum discovery information may change over time. Freshness and caching therefore matter even when detailed runtime properties are obtained later through application interaction. * Discovery may need to account for entities that are dynamic, mobile, or available only in a particular context. * Trust in discovery information is different from trust in the discovered entity. A discovery mechanism can help protect discovery metadata, but it does not decide whether the discovered entity should be used. * Brokers and aggregators may serve an organisation or cooperating group. Discovery supports independent publication rather than requiring a single central registry or an index of resources across the wider Internet. 6. Discovery Pattern The use cases in this document follow a common pattern. 1. A discovering entity has a task, intent, policy requirement, or operational need. 2. The discovering entity needs to find an entity, or class of entities, that can satisfy that need. 3. The discovering entity forms a discovery request using information such as a name, organisation, entity type, capability, location, jurisdiction, communication protocol, or policy constraint. 4. The discovery mechanism returns information about one or more candidate entities. 5. The discovering entity uses that information to decide whether selection, authorisation, capability exchange, or communication should be attempted. The last step is outside the scope of discovery. However, discovery has to return enough information for this step to be possible. The Architecture determines which query properties belong in minimum discovery information. Other constraints are evaluated by the application. King, et al. Expires 14 March 2027 [Page 8] Internet-Draft DAWN Use Cases September 2026 Discovery may take several steps. A client may follow a reference, refresh a cached result, or repeat a query when the information is no longer sufficient. 7. Categories of Discovery Each category includes assumptions, discovery impacts, and examples within the settings in Section 4. 7.1. Capability-Oriented Discovery A client needs to find an entity that provides a particular function or capability, such as an agent, tool, task, service, or model- serving endpoint. 7.1.1. Assumptions The client can express the required function using the discovery properties supported by the architecture. A service type or capability identifier may be sufficient. The result identifies the function and how to reach the entity, and may include a reference to a capability card. 7.1.2. Discovery Impacts Capability-oriented discovery suggests support for discovery by function, capability, skill, entity type, and protocol. The returned discovery information needs to include enough information to allow later selection, authorisation, capability exchange, or communication to be attempted. 7.1.3. Examples A scheduling assistant needs to find a calendar-coordination agent at a partner organisation and learn how to contact it. The appendix develops this example in Appendix A. An agentic workflow decomposes a user request into several subtasks. The workflow needs to discover agents, tools, services, or tasks that can participate in the work. Discovery provides candidate entities and their published properties; the workflow then performs selection and orchestration outside DAWN. 7.2. Resource-Oriented Discovery A client needs to discover resources supporting an AI system, such as data sources, knowledge bases, models, inference services, or compute services. King, et al. Expires 14 March 2027 [Page 9] Internet-Draft DAWN Use Cases September 2026 7.2.1. Assumptions This discovery category assumes that the discovered resource may have properties that are partly static and partly dynamic. For example, a dataset description may be relatively stable, while freshness or access policy may change. A compute resource may have stable hardware properties but rapidly changing availability, load, price, or locality. It also assumes that some discovery information may be sensitive. Data classification, model provenance, jurisdiction, permitted use, and operational capacity may need visibility controls. 7.2.2. Discovery Impacts Discovery returns the minimum information needed to locate and contact the resource. It may return a pointer to an application service for current state, detailed policy, or authorisation. Accessing an already known data source to read its contents is an application query, not resource discovery. Properties such as jurisdiction, format, freshness, and access method may motivate discovery requirements. The Architecture work determines which belong in the minimum discovery information. Richer descriptions, live availability, and detailed policy information are obtained outside the discovery process. 7.2.3. Examples An enterprise agent needs to find a data source for retrieval- augmented generation. Discovery identifies a relevant internal source and how to contact it. The application subsequently checks detailed freshness, format, and access conditions and retrieves data through the source's native interface. A scheduler for an AI workload needs to find a compute service within its organisation or a cooperating provider. Discovery identifies the service and its contact information. Checking accelerator availability, jurisdictional constraints, and allocation policy can require subsequent application queries. An AI application needs to find an inference service for a particular modality. Discovery supplies the relevant service type and communication information. Detailed model provenance, safety classification, and permitted use are assessed outside discovery where they exceed the minimum information. King, et al. Expires 14 March 2027 [Page 10] Internet-Draft DAWN Use Cases September 2026 A user or agent needs to discover a model-serving resource for inference. Discovery supplies its function and access method; subsequent interaction obtains richer model information when needed. 7.3. Administrative Scope Extensions Discovery crosses organisational, administrative, or tenancy boundaries. A client may need to find a partner's resource, or a provider may expose different discovery views to its tenants, customers, or departments. 7.3.1. Assumptions Organisations control what they publish and who can see it. Cooperation and authority to act for a user rely on existing arrangements. Discovery information may identify the publishing domain or responsible party to support later checks. 7.3.2. Discovery Impacts DAWN discovery needs to support discovery across administrative domains without requiring a single central registry. It also needs to support scoped discovery where the information returned depends on tenant, customer, department, network, or policy context. Publication scope helps the client interpret a result. Discovery must also avoid exposing sensitive tenant or organisational structure to unauthorised parties. 7.3.3. Examples An enterprise agent acting for an employee needs to discover an agent at a cooperating supplier. The discovery result indicates how to contact the supplier's agent and provides information needed by later authorisation and policy checks. A software-as-a-service provider hosts agents or tools for multiple customers. Each customer needs discovery information scoped to its own tenancy. The same provider may also need different discovery views for internal operators and cooperating customers. A research consortium operates AI services across several cooperating institutions with established trust relationships. Each institution publishes information about its own agents, data services, and tools. Collaborators need to discover entities by capability while respecting institutional boundaries and trust models. King, et al. Expires 14 March 2027 [Page 11] Internet-Draft DAWN Use Cases September 2026 7.4. Operational Discovery A human operator, management system, or AI operations agent needs to locate AI resources and supporting tools for troubleshooting, audit, incident response, or compliance review. 7.4.1. Assumptions This discovery category assumes that discovery is useful for both autonomous systems and human-operated tools. It also assumes that operational environments may be multi-vendor, multi-domain, and partly private. Operational discovery needs to identify relevant resources and how to contact them. An operational client may subsequently obtain detailed runtime state, observability data, or compliance information. Those exchanges are outside discovery and may require separate permissions. 7.4.2. Discovery Impacts DAWN discovery may need to support tooling and operational inspection, not only agent-to-agent workflows. Discovery metadata may need to be logged, auditable, and understandable by operators. Management and diagnostics for the discovery system itself may also be needed so that operators can understand discovery behaviour and failures. Brokers, directory services, and operational tools may themselves be discovery targets when they support an AI system. Observability of the discovery process is a separate operational consideration. Recording a discovery result or logging a later action does not itself constitute discovery of an operational resource. 7.4.3. Examples A human operator needs to locate the AI agents maintained by a team within an organisation. Discovery provides their service types and communication information. Inspection of their runtime behaviour occurs subsequently. King, et al. Expires 14 March 2027 [Page 12] Internet-Draft DAWN Use Cases September 2026 An AI-assisted network operations system needs to discover telemetry sources, topology systems, control points, and remediation tools within an organisation or cooperating group. DAWN can help identify these supporting AI resources and their communication methods. Diagnosis, correlation, action recommendation, and remediation remain outside discovery. An edge deployment includes lightweight agents that need fast and cacheable discovery because local connectivity is constrained. Discovery provides enough stable information for connection bootstrapping while avoiding reliance on rapidly changing operational state. 8. Classes of Use Case The taxonomy in [I-D.akhavain-moussa-dawn-problem-statement] provides background for classifying AI resources and their supporting entities. 8.1. AI Agent TBD 8.2. Software Service TBD 8.3. Compute Workload TBD 8.4. Network Function TBD 8.5. Application Endpoint TBD 9. Security Considerations The use cases in this document involve discovery information that may affect which entity is contacted, what protocol is used, and what trust indicators are presented. Incorrect or malicious discovery information could cause a discovering entity to contact the wrong entity, disclose information to an attacker, or use an unsuitable service. King, et al. Expires 14 March 2027 [Page 13] Internet-Draft DAWN Use Cases September 2026 Outside a local network, all discovery information exchanged between DAWN participants requires integrity protection. Local deployments may also provide such protection. Where it is absent, the deployment needs to account for the risks of unprotected discovery information; locality alone does not establish trust. Discovery mechanisms also need to address authenticity, freshness, and access controls using established security mechanisms and trust arrangements. A cached digest or version comparison detects change but does not independently authenticate discovery content. This document does not select a protection mechanism or define new trust- evaluation methods. Security of discovery metadata is distinct from trust in the discovered entity. Authentication, authorisation, attestation, and policy checks for later interaction are outside discovery. Identity management and establishing trust relationships are also outside DAWN's initial scope; an authentic publication does not establish authority to act for a particular person. 10. Privacy Considerations Discovery queries may reveal information about the intent, capability needs, or operational state of the discovering entity. Published discovery information may also reveal information about deployed services, agents, data sources, models, or organisational relationships. This suggests that a DAWN discovery mechanism will need to consider what information is public, what information is restricted, and what information should not be exposed through discovery. Privacy-sensitive information can include proprietary capabilities, deployment location, capacity, runtime state, model or dataset metadata, requester identity, search history, and query intent. 11. Operational Considerations Enterprise, cloud, and edge deployments have different needs for publication, caching, freshness, authorisation, observability, and operational control. King, et al. Expires 14 March 2027 [Page 14] Internet-Draft DAWN Use Cases September 2026 Dynamic information such as current load, availability, price, or status may change too frequently to be carried directly in a general discovery mechanism. Such application state can be obtained outside discovery through a referenced service. The minimum discovery information has its own freshness needs: an endpoint or supported protocol may also change. A client may refresh retained information or repeat discovery when it is no longer sufficient. A changed description need not imply a different entity, and a temporary communication failure need not imply withdrawal. Recovery of application state or transfer of an existing task to a replacement is outside discovery. Across administrative domains, operational considerations include publication authority, caching, freshness, visibility controls, logging, abuse handling, and failure behaviour. 12. IANA Considerations This document has no IANA actions. 13. References 13.1. Normative References [I-D.farrel-dawn-terminology] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-farrel-dawn-terminology-04, 26 July 2026, . 13.2. Informative References [I-D.agentic-ai-usecases-requirements] Reddy.K, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, draft-agentic-ai-usecases-requirements-02, 25 August 2026, . King, et al. Expires 14 March 2027 [Page 15] Internet-Draft DAWN Use Cases September 2026 [I-D.akhavain-moussa-dawn-problem-statement] Akhavain, A., Moussa, H., and D. King, "Problem Statement for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-akhavain- moussa-dawn-problem-statement-05, 19 July 2026, . [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-king-dawn-requirements-01, 28 April 2026, . [I-D.mozley-aidiscovery] Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "AI Agent Discovery (AID) Problem Statement", Work in Progress, Internet-Draft, draft-mozley-aidiscovery-01, 16 April 2026, . [I-D.scrm-aiproto-usecases] Schott, R., Maisonneuve, J., Contreras, L. M., and J. Ros- Giralt, "Taxonomy for Agentic AI Use Cases", Work in Progress, Internet-Draft, draft-scrm-aiproto-usecases-05, 4 July 2026, . Appendix A. Cross-Organisation Appointment Coordination Alice asks her AI assistant, Hermes, to review her schedule and arrange lunch with Bob at another organisation, including a restaurant table for two near the office. Later, she asks to move both the appointment and the reservation to a different day. The example combines capability and resource discovery across an organisational boundary, then shows how Hermes can reuse what it has learned. A.1. Actors and Assumptions Hermes Agent provides the agent harness for Alice's assistant. The running assistant, called Hermes here, is the discovering entity. Alice talks to it through a conversational interface. Her calendar service is already configured; Hermes can read it but cannot change it. King, et al. Expires 14 March 2027 [Page 16] Internet-Draft DAWN Use Cases September 2026 Alice's and Bob's organisations are assumed to cooperate under an established trust relationship. Their calendar agents have not previously interacted. Hermes knows Bob's organisation but not its calendar-agent endpoints. Bob's agent can coordinate appointments and create events, subject to permission. The restaurant-booking service is assumed to be available through a cooperating provider with an established trust relationship. OpenTable is used as an illustrative provider; the example assumes a suitable agent-accessible interface and does not claim that a particular integration or trust arrangement exists. Alice is assumed to supply enough context to distinguish the intended Bob. A.2. Initial Discovery at a Known Organisation Alice asks Hermes to find a time for lunch with Bob on Thursday and book a table for two near the office. Hermes reads her calendar, then needs to find a calendar-coordination agent at Bob's organisation. It knows the organisation and required capability, and may have constraints on the communication protocol. Hermes locates the organisation's discovery entry point and queries its catalogue for calendar-coordination agents. The result identifies candidates and their contact information. DNS could provide the entry point; the example does not depend on a particular bootstrap or catalogue protocol. A candidate may serve the whole organisation or particular users. Hermes needs to determine whether it can handle the request concerning Bob. The application then selects a candidate, obtains any necessary authorisation, and exchanges proposed times. Bob's agent creates the event in his calendar. Hermes still has no permission to write to Alice's calendar; invitation handling is an application matter. A.3. Supporting Resource Discovery and Restaurant Reservation Hermes obtains free/busy information through the calendar services. Alice's calendar was already known, so reading it required no discovery. It discovers any additional data source it needs before querying that source. With a suitable time identified, Hermes proceeds as follows: King, et al. Expires 14 March 2027 [Page 17] Internet-Draft DAWN Use Cases September 2026 1. Discover the restaurant-booking service through the cooperating provider's discovery entry point. The result identifies the booking capability and how to contact it. 2. Query the service for restaurants near the office with a table for two at the proposed time. Availability, price, and booking conditions come from the service's application interface. 3. Present a suitable option to Alice and ask her to confirm the restaurant, time, and any booking conditions. 4. On confirmation, request the reservation through the service and retain its booking reference. Report whether the reservation succeeded. The discovery target is the booking service. Restaurant search, table availability, and reservation are subsequent application activities. The table is reserved through the service, not through DAWN. The following exchanges show the restaurant-booking part of the example. The discovery steps also apply to finding Bob's calendar agent, using his organisation's discovery entry point instead of the booking provider's. Alice Hermes Provider's Booking discovery service | | | | |--Lunch request--> | | | | | | Discovery | |-Booking capability--> | | <-Name, URI, protocol-| | | | | | Application exchange | |----------Time, area, party size-----------> | <--------Options, price, conditions---------| <-Booking option--| | | |-----Confirm-----> | | | |----------Reserve selected table-----------> | <---------Result, booking reference---------| <-Booking result--| | | | | | | King, et al. Expires 14 March 2027 [Page 18] Internet-Draft DAWN Use Cases September 2026 A.4. Reconnection and Rediscovery Alice asks Hermes to move the lunch to Friday. Hermes has cached discovery information for both the calendar agent and the booking service, including their names, endpoints, protocols, and available freshness information. If these remain usable, it can reconnect without repeating the catalogue queries. An expired record or changed endpoint may require a refresh. If the agent cannot be found or no longer offers calendar coordination, Hermes can return to the organisation's discovery entry point. A temporary connection failure alone does not establish that the agent has been withdrawn. The application may also need to retrieve a changed capability card and reassess the agent. Finding a replacement does not establish that it holds the original booking or has permission to change it. Hermes checks Friday's calendar availability and asks the booking service whether the reservation can be moved. It presents the revised arrangements and any changed conditions to Alice for confirmation, then requests both changes through the respective services. If only one succeeds, Hermes reports the outstanding change to Alice. Discovery does not make the two updates a single transaction. The services below are contacted separately. If cached information is still usable, the discovery exchanges are skipped. Availability checks and booking changes use application interfaces. King, et al. Expires 14 March 2027 [Page 19] Internet-Draft DAWN Use Cases September 2026 Alice Hermes Discovery Calendar / entry points booking services | | | | |-Move to Friday--> | | | | | | Reuse cached discovery information if still valid. If refresh or rediscovery is needed: | |-Name or capability--> | | <---Contact details---| | | | | | Application exchanges with each service | |--Friday availability / booking reference--> | <------Options and changed conditions-------| <--Revised plan---| | | |-----Confirm-----> | | | |-----Change appointment / reservation------> | <-----Separate results for each change------| <-----Outcome-----| | | | | | | A.5. Discovery Information Needed in This Scenario The first requests identify an organisation and a capability: calendar coordination or restaurant booking. Reconnection starts with a known agent or service. In either case, useful results include: * the entity's name, type, and a service or capability identifier; * reachability information and supported communication methods; and * references used to obtain that minimum information through indirection. The Architecture defines the minimum field set. A reference may lead to further discovery information or to richer application information. Fetching a capability card beyond that minimum, detailed policy, live calendar data, or table availability is outside discovery. Booking references are application state, separate from cached discovery information. King, et al. Expires 14 March 2027 [Page 20] Internet-Draft DAWN Use Cases September 2026 A.6. Security, Privacy, and Operational Considerations All cross-organisation discovery information is integrity-protected under the assumed trust arrangements, including information obtained through references. Hermes checks its origin and freshness. An authentic publication does not prove that an agent may act for Bob. A version comparison can reveal change, but does not establish authenticity. The discovery query may reveal Alice's interest in Bob's organisation and its scheduling service. Calendar contents and personal details can be restricted to the subsequent authorised exchange. Discovery records may also need access controls. For troubleshooting, operators may need to know which source Hermes used, whether it used cached information, and why it repeated discovery. Logs can record these decisions, subject to privacy and retention controls. A.7. Links to the DAWN Requirements The scenario illustrates several requirements in [I-D.king-dawn-requirements]. King, et al. Expires 14 March 2027 [Page 21] Internet-Draft DAWN Use Cases September 2026 +===============================+===================================+ | Part of the scenario | Related requirements | +===============================+===================================+ | Finding a calendar or booking | REQ-DISC-2: discovery by | | capability, then reconnecting | function or specific | | to a known entity. | instance; REQ-CLASS-2: | | | classification by capability. | +-------------------------------+-----------------------------------+ | Starting at each | REQ-PROTO-4: predictable | | organisation's discovery | entry points; REQ-ARCH-4: | | entry point. | independent publication. | +-------------------------------+-----------------------------------+ | Obtaining the endpoint and | REQ-PROP-2: communication | | protocol needed to contact | protocols and transport | | the service. | parameters, directly or by | | | reference. | +-------------------------------+-----------------------------------+ | Keeping cached discovery | REQ-PROP-4 and REQ-PROP-11: | | information separate from | property change rates and | | live calendar and table | their implications for | | availability. | caching and refresh. | +-------------------------------+-----------------------------------+ | Protecting discovery | REQ-SEC-1: authenticity and | | responses and restricting who | integrity; REQ-SEC-4: | | can see them. | visibility controls. | +-------------------------------+-----------------------------------+ | Recording the discovery | REQ-SEC-7: auditability of | | source and decisions to | discovery operations. | | refresh or repeat a query. | | +-------------------------------+-----------------------------------+ | Using separate application | REQ-DISC-4: discovery's place | | exchanges to select a | in the interaction workflow. | | restaurant, confirm with | | | Alice, and reserve a table. | | +-------------------------------+-----------------------------------+ Table 2 Appendix B. Provisioning Edge Compute for Personalised Live Media A broadcaster offers a personalised live programme [object-based media delivery]. Viewers may chooses different audio, graphics, or accessibility features. Some devices cannot combine these media objects themselves, so nearby edge compute renders part or all of the programme for them. King, et al. Expires 14 March 2027 [Page 22] Internet-Draft DAWN Use Cases September 2026 Before the broadcast, an operator asks a media orchestration agent to arrange enough compute for the expected audience, balancing delay, cost, and energy use. The agent needs to find the services and information sources that can help it do this. B.1. Actors and Assumptions The media orchestration agent coordinates the request. A compute allocation agent arranges resources at suitable sites, using an optimisation tool to compare options. Data services provides audience forecasts and information about compute and network conditions. These entities operate within the broadcaster's organisation or cooperating providers with established trust relationships. The discovery entry points are known, but individual service endpoints may not be. Agentic Resource Discovery (ARD) (https://agenticresourcediscovery.org/) is possible interface to a provider's catalogue in this scenario. It provide a common way to describe and search agents, tools, and services. A provider could expose its compute allocation and telemetry services through ARD, allowing the media agent to find candidates without preconfiguring every service endpoints or loading every service description into its context. Here, queries would be limited to the organisation or cooperating providers. ARD is an illustrative option; protocol choice remains open. Resource allocation and invocation continue through the service's own interfaces. B.2. Discovery and Provisioning 1. The media agent queries the relevant discovery entry points for a compute allocation capability and any required data services. Results identify the entities and how to contact them. 2. The allocation agent discovers suitable site controllers and media-processing services, including GPU rendering where needed. It obtains their names, service identifiers, endpoints, and supported communication methods. 3. Through the services' application interfaces, the agents obtain audience forecasts, current capacity, and cost, energy, and delay estimates. The optimisation tool uses these inputs and the operator's priorities to propose a placement. King, et al. Expires 14 March 2027 [Page 23] Internet-Draft DAWN Use Cases September 2026 4. Subject to the operator's policy and authorisation, the allocation agent requests provisioning through the site controllers. It reports result, or explains why the available resources cannot meet the request. The diagram summarises discovery and the later application exchanges. The agents contact each service separately. Media / allocation Discovery Data services / agents entry points site controllers | | | |--Required capability---->| | |<--Name, URI, protocol----| | | | | |--Forecast / resource information request-------->| |<--Demand, capacity, cost, energy, delay----------| | | | Compare options using the optimisation tool | | | |--Provision selected resources------------------->| |<--Result / resource references-------------------| Discovery provides the information needed to contact an entity. Comparing sites, reserving compute, steering traffic, and delivering media are application activities outside DAWN. B.3. Changes During the Broadcast Audience demand or site availbility may change. The agents can reuse valid discovery information and query current conditions through the data services. Changed or expired discovery records may requires a refresh or a new query. Moving workloads or adding capacity remains an application decision. B.4. Security and Privacy Discovery information is integrity-protected, including across provider boundaries, and its origin and freshness are checked. Finding a controller does not grants permission to provision resources. Viewer details and detailed capacity data are restricted to authorised application exchanges. B.5. Links to the DAWN Requirements The example reuses requirements in [I-D.king-dawn-requirements]: * REQ-DISC-2 and REQ-CLASS-2: finding entities by function or capability. King, et al. Expires 14 March 2027 [Page 24] Internet-Draft DAWN Use Cases September 2026 * REQ-PROP-2: obtaining communication details, directly or by reference. * REQ-PROP-4 and REQ-PROP-11: distinguishing cached discovery information from frequently changing resource data. * REQ-SEC-1 and REQ-SEC-4: protecting discovery information and controlling its visibility. * REQ-??? Acknowledgments The authors thank Adrian Farrel and Jim Mozley for early discussion in the creation of this document, and their ongoing reviews and comments. We also thank the following peopl for their DAWN mailing-list comments: Tommy Jensen (concrete use cases), Mohamed Boucadair (discovery starting points), Sumit Ahuja (capability discovery), Roman Danyliw (security and privacy), Lori Jakab (local network discovery), Matthew Quick (cross-domain applicability), Pete Resnick (agent identity considerations), and Mirja Kuehlewind (discovery steps). Finally, we thank the following for their contribution to the use case practical examples: * Revika Anand, Lancaster University * Edward Revika, Lancaster University Authors' Addresses Daniel King Lancaster University Email: d.king@lancaster.ac.uk Kehan Yao China Mobile Email: yaokehan@chinamobile.com Ken Adler Indeed Email: kadler@indeed.com King, et al. Expires 14 March 2027 [Page 25] Internet-Draft DAWN Use Cases September 2026 Rajiv Ramdhany BBC Email: rajiv.ramdhany@bbc.co.uk King, et al. Expires 14 March 2027 [Page 26]