Skip to main content

Use Cases for the Discovery of Agents, Workloads, and Named Entities
draft-kay-dawn-use-cases-00

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]