Use Cases for the Discovery of Agents, Workloads, and Named Entities
draft-kay-dawn-use-cases-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Daniel King , Kehan Yao , Ken Adler | ||
| Last updated | 2026-06-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kay-dawn-use-cases-00
Individual Submission D. King
Internet-Draft Old Dog Consulting
Intended status: Informational K. Yao
Expires: 9 December 2026 China Mobile
K. Adler
Indeed
7 June 2026
Use Cases for the Discovery of Agents, Workloads, and Named Entities
draft-kay-dawn-use-cases-00
Abstract
This document describes broad categories of use cases for the
Discovery of Agents, Workloads, and Named Entities (DAWN). The
purpose of the document is to illustrate situations in which entities
need to discover other entities.
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 9 December 2026 [Page 1]
Internet-Draft DAWN Use Cases June 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 9 December 2026.
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. Discovery Characteristics . . . . . . . . . . . . . . . . . . 5
5. Discovery Pattern . . . . . . . . . . . . . . . . . . . . . . 6
6. Categories of Discovery . . . . . . . . . . . . . . . . . . . 7
6.1. Capability-Oriented Discovery . . . . . . . . . . . . . . 7
6.1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 7
6.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Resource-Oriented Discovery . . . . . . . . . . . . . . . 8
6.2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 8
6.2.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 8
6.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Administrative Scope Extensions . . . . . . . . . . . . . 9
6.3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 9
6.3.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 9
6.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Operational Discovery . . . . . . . . . . . . . . . . . . 10
6.4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 10
6.4.2. Discovery Impacts . . . . . . . . . . . . . . . . . . 10
6.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 11
7. Classes of Use Case . . . . . . . . . . . . . . . . . . . . . 11
7.1. AI Agent . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Software Service . . . . . . . . . . . . . . . . . . . . 11
King, et al. Expires 9 December 2026 [Page 2]
Internet-Draft DAWN Use Cases June 2026
7.3. Compute Workload . . . . . . . . . . . . . . . . . . . . 11
7.4. Network Function . . . . . . . . . . . . . . . . . . . . 12
7.5. Application Endpoint . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
10. Operational Considerations . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Distributed processing environments depend on interaction between
components that are often configured using static capability,
location, or reachability relationships. In order for these systems
to operate efficiently, components need to be capable of discovering
other components that can provide a function, service, resource, or
capability.
For generality, Discovery of Agents, Workloads, and Named Entities
(DAWN) uses the term "entity" for the components that may be
discovered. Entities may include Artificial Intelligence (AI)
agents, workloads, tasks, tools, services, application endpoints,
data sources, models, inference services, brokers, and other named
resources. Skills may also be among the discoverable attributes of
those entities.
The DAWN problem statement
[I-D.akhavain-moussa-dawn-problem-statement] describes the general
discovery problem. The DAWN requirements document
[I-D.king-dawn-requirements] describes solution-neutral requirements
for a discovery mechanism. This document provides use cases that sit
between those documents: they show where discovery is needed and what
information is needed in representative scenarios.
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 by agents, workloads, applications, or users.
3. Administrative Scope Extensions, where discovery crosses
organisational, delegation, or tenancy boundaries.
King, et al. Expires 9 December 2026 [Page 3]
Internet-Draft DAWN Use Cases June 2026
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 categories of discovery and associated use
cases. It does not describe the full lifecycle of an entity.
The following are in scope:
* discovery of a specific named entity;
* discovery of a class of entities that can provide a requested
function;
* discovery of tasks that can be performed by suitable entities;
* discovery initiated by an agent, workload, service, application,
or human operator;
* discovery of agents, workloads, tools, tasks, data sources,
models, services, brokers, and other named entities;
* information that needs to be discovered before selection,
negotiation, 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;
* selection among candidate entities returned by discovery;
* capability negotiation after discovery;
* task orchestration;
King, et al. Expires 9 December 2026 [Page 4]
Internet-Draft DAWN Use Cases June 2026
* certificate or key lookup;
* search, ranking, or marketplace discovery.
The boundary between discovery and adjacent functions is important.
A discovery mechanism may return information that is used by later
functions, but those later functions are not themselves part of
discovery.
Credential, key, certificate, or attestation references may still
appear as optional discovery information, but DAWN does not define
their lookup or validation.
3. Terminology
Terminology for DAWN is defined in [I-D.farrel-dawn-terminology].
This document uses the term "entity" in the same broad sense as the
DAWN terminology document.
Attention is drawn to the following specific terms defined in
[I-D.farrel-dawn-terminology] that are key to this document:
* discovering entity
* discovered entity
* discoverable object
* discovery information
* minimum discoverable information
4. Discovery Characteristics
The categories of discovery and use cases discussed in this document
share a number of characteristics.
The common question is what minimum information about an entity needs
to be discoverable before later selection, negotiation, or
communication can take place.
* 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.
King, et al. Expires 9 December 2026 [Page 5]
Internet-Draft DAWN Use Cases June 2026
* Discovery may happen within one administrative domain or across
several administrative domains.
* 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.
* Discovery information may include static, mainly static, and
dynamic properties. This raises questions about freshness and
caching when properties change frequently.
* 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 be useful in some environments, but
DAWN ought not to require a single central registry.
5. 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.
King, et al. Expires 9 December 2026 [Page 6]
Internet-Draft DAWN Use Cases June 2026
6. Categories of Discovery
Each discovery category includes assumptions, possible discovery
impacts, and illustrative examples.
6.1. Capability-Oriented Discovery
In this discovery category, a discovering entity needs to find
another entity that can provide a specific function or capability.
The discovered entity might be an AI agent, a tool, a task, a
service, an application endpoint, or a model-serving function.
6.1.1. Assumptions
This discovery category assumes that the discovering entity can
describe the required function in a form that can be used for
discovery. It also assumes that discoverable entities can publish,
or point to, enough information about their function and
communication methods to allow a later decision about whether to
interact.
The capability description may be simple, such as a service type, or
more structured, such as a capability card or schema reference. DAWN
does not define the runtime invocation of the discovered capability.
6.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.
Discovery is not a statement that the discovered entity is safe,
competent, or authorised for a particular use. It provides discovery
information and associated trust indicators, while policy and
selection are later functions.
6.1.3. Examples
A scheduling application is asked to arrange a meeting with people in
another organisation. It needs to discover whether that organisation
exposes an entity for calendar coordination, and what information is
needed to contact it. The discovery result might include the
responsible organisation, supported communication methods, and a
reference to the entity's published capabilities.
King, et al. Expires 9 December 2026 [Page 7]
Internet-Draft DAWN Use Cases June 2026
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.
6.2. Resource-Oriented Discovery
In this discovery category, an entity needs to discover resources
that are not simply peer agents or services. These resources may
include data sources, datasets, knowledge bases, compute resources,
accelerator pools, models, inference services, or similar resource-
bound entities.
6.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.
6.2.2. Discovery Impacts
DAWN discovery needs a way to distinguish information that is
appropriate for a general discovery mechanism from information that
should be obtained from a more dynamic or restricted source.
Discovery may return stable metadata and a pointer to another service
for current state, detailed policy, or authorisation.
The discovery result may need to include provenance, jurisdiction,
freshness, format, access method, safety classification, or other
properties relevant to later selection and policy checks.
6.2.3. Examples
An agent needs to find a data source for retrieval-augmented
generation. The discovery input includes the data domain, freshness
requirement, jurisdiction, format, and access policy. The discovery
result includes a description of the data source, access method,
policy information, and provenance references.
King, et al. Expires 9 December 2026 [Page 8]
Internet-Draft DAWN Use Cases June 2026
A workload scheduler needs to find compute with a particular
accelerator type and jurisdictional constraint. Discovery returns
relatively stable compute properties and information about how to
obtain current availability.
An application needs to find an inference service for a particular
modality and safety classification. Discovery provides a service
description, supported protocols, policy constraints, version or
provenance information, and trust indicators.
A user or agent needs to discover a model for inference. Discovery
provides information about the model's function, supported use,
access method, and relevant policy constraints.
6.3. Administrative Scope Extensions
In this discovery category, capability-oriented or resource-oriented
discovery crosses organisational, administrative, or tenancy
boundaries. An entity may need to discover another entity in a
different organisation, or a provider may need to expose different
discovery views for different tenants, customers, departments, or
policy realms.
6.3.1. Assumptions
This discovery category assumes that organisations need to control
what they publish and to whom it is visible. It also assumes that an
entity may act on behalf of a user, enterprise, tenant, department,
or service, but that proof of that authority is separate from
discovery unless explicitly represented as discovery information.
The discovery category also assumes that discovery information may
need to carry administrative-domain, responsible-party, policy, or
trust-boundary information. This information can help later
authorisation, audit, or policy functions, but DAWN does not define
those functions.
6.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.
King, et al. Expires 9 December 2026 [Page 9]
Internet-Draft DAWN Use Cases June 2026
Discovery information may need to include the responsible
organisation, scope of authority, policy constraints, and trust
indicators associated with the published metadata. Care is needed so
that discovery does not expose sensitive tenant or organisational
structure to unauthorised parties.
6.3.3. Examples
An enterprise agent acting for an employee needs to discover an
authorised agent at a 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 a different discovery
view for internal operators, external customers, and public users.
A research consortium spans several institutions. 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.
6.4. Operational Discovery
In this discovery category, discovery supports operation, audit,
troubleshooting, incident response, compliance review, or network and
service automation. The discovering entity may be a human operator,
management system, controller, or AI-assisted operations agent.
6.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 may need to expose information about scope,
owner, responsible party, operational state, observability, or
compliance status. Some of this information may be restricted.
6.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.
King, et al. Expires 9 December 2026 [Page 10]
Internet-Draft DAWN Use Cases June 2026
Management and diagnostics for the discovery system itself may also
be needed so that operators can understand discovery behaviour and
failures.
Intermediaries such as brokers, aggregators, directory services,
telemetry services, topology services, policy systems, or control
functions may also be discoverable entities.
6.4.3. Examples
A human operator needs to find all entities owned by a team that
expose a particular function. Discovery provides inspectable
metadata, a responsible party, communication information, and trust
indicators.
An AI-assisted network operations system needs to discover telemetry
sources, topology systems, control points, and remediation tools
across a heterogeneous network. DAWN can help identify the relevant
entities. 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.
7. Classes of Use Case
[I-D.akhavain-moussa-dawn-problem-statement] introduces a taxonomy of
entity types in its Figure 2. These entity types provide a useful
broad classification of use cases that is expanded upon here.
References are made back to the categories of discovery discussed in
Section 6, and specifically the examples set out in the subsections
of that section.
7.1. AI Agent
TBD
7.2. Software Service
TBD
7.3. Compute Workload
TBD
King, et al. Expires 9 December 2026 [Page 11]
Internet-Draft DAWN Use Cases June 2026
7.4. Network Function
TBD
7.5. Application Endpoint
TBD
8. 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.
We suggest that any DAWN discovery mechanism will need to consider
authenticity, integrity, freshness, and authorisation to access
discovery information.
Security of discovery metadata is distinct from trust in the
discovered entity. Authentication, authorisation, attestation, and
policy checks for later interaction are outside discovery.
9. 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.
10. Operational Considerations
The use cases include public networks, private networks, enterprise
environments, cloud deployments, edge deployments, and cross-domain
interaction. Different environments may have different expectations
for publication, caching, freshness, authorisation, observability,
and operational control.
King, et al. Expires 9 December 2026 [Page 12]
Internet-Draft DAWN Use Cases June 2026
Dynamic information such as current load, availability, price, or
status may change too frequently to be carried directly in a general
discovery mechanism. A DAWN discovery mechanism may need to return
stable information that points to more dynamic sources.
Across administrative domains, operational considerations include
publication authority, caching, freshness, visibility controls,
logging, abuse handling, and failure behaviour.
11. IANA Considerations
This document has no IANA actions.
12. References
12.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-02, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-02>.
12.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-00, 22 May 2026,
<https://datatracker.ietf.org/doc/html/draft-agentic-ai-
usecases-requirements-00>.
[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-03, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-03>.
[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, <https://datatracker.ietf.org/doc/html/
draft-king-dawn-requirements-01>.
King, et al. Expires 9 December 2026 [Page 13]
Internet-Draft DAWN Use Cases June 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, <https://datatracker.ietf.org/doc/html/draft-
mozley-aidiscovery-01>.
[I-D.scrm-aiproto-usecases]
Schott, R., Maisonneuve, J., Contreras, L. M., and J. Ros-
Giralt, "Agentic AI Use Cases", Work in Progress,
Internet-Draft, draft-scrm-aiproto-usecases-02, 2 March
2026, <https://datatracker.ietf.org/doc/html/draft-scrm-
aiproto-usecases-02>.
Acknowledgments
The authors thank Adrian Farrel and Jim Mozley for their review and
comments.
Authors' Addresses
Daniel King
Old Dog Consulting
Email: daniel@olddog.co.uk
Kehan Yao
China Mobile
Email: yaokehan@chinamobile.com
Ken Adler
Indeed
Email: kadler@indeed.com
King, et al. Expires 9 December 2026 [Page 14]