Requirements for the Discovery of Agents With Names (DAWN)
draft-king-dawn-requirements-02
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 , Adrian Farrel | ||
| Last updated | 2026-10-19 | ||
| 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-king-dawn-requirements-02
Network Working Group D. King
Internet-Draft A. Farrel
Intended status: Informational Old Dog Consulting
Expires: 22 April 2027 19 October 2026
Requirements for the Discovery of Agents With Names (DAWN)
draft-king-dawn-requirements-02
Abstract
The proliferation of distributed systems, Artificial Intelligence
(AI) agents, and network services has created a need for
interoperable mechanisms to discover entities across administrative
and network boundaries. Entities may include AI agents, software
services, and other named resources that need to be found and
characterised before interaction can begin.
This document defines the requirements for Discovery of Agents With
Names (DAWN) and sets out the objectives that a discovery mechanism
for such entities must satisfy. It describes what information must
be discoverable, what properties a discovery mechanism needs to
support, and what constraints apply to discovery in decentralised
environments.
This document does not specify any particular discovery protocol or
solution.
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/.
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 22 April 2027.
King & Farrel Expires 22 April 2027 [Page 1]
Internet-Draft DAWN Requirements October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope of this Document . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions and Definitions . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 5
3.2. Discovery Information . . . . . . . . . . . . . . . . . . 6
3.3. Trust and Security . . . . . . . . . . . . . . . . . . . 6
3.4. Scalability and Architecture . . . . . . . . . . . . . . 7
3.5. Discovery Protocol . . . . . . . . . . . . . . . . . . . 7
3.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
7. Operational Considerations . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Modern distributed systems increasingly rely on the dynamic
composition of services and agents that may not have pre-configured
relationships. For example, an AI agent may need to find another
agent with specific capabilities, or a service consumer may need to
discover providers that support a required protocol version. Further
use cases and scenarios are described in [I-D.kay-dawn-use-cases].
King & Farrel Expires 22 April 2027 [Page 2]
Internet-Draft DAWN Requirements October 2026
In each case, an entity needs knowledge of remote entities before
interaction can proceed: what they are, what they offer, and whether
they can be trusted. Such knowledge could be obtained through static
configuration, but this approach is impractical at scale and across
organisational boundaries. Automated discovery mechanisms are
therefore needed.
Today, where automated discovery exists, it is typically handled
through proprietary directories or platform-specific mechanisms.
These approaches do not scale across organisational boundaries and
create fragmented ecosystems where entities cannot find entities
managed by other organisations.
An interoperable discovery mechanism is needed that builds on
existing protocols and tools, benefits from an established trust
model, supports proven delegation and federation architectures, and
allows organisations to independently publish discovery information.
This document defines requirements that any Discovery of Agents With
Names (DAWN) mechanism must satisfy. It is informed by
[I-D.akhavain-moussa-dawn-problem-statement] and
[I-D.mozley-aidiscovery], and uses the terminology of
[I-D.farrel-dawn-terminology].
1.1. Scope of this Document
The requirements in this document address what information must be
discoverable about entities, what properties a discovery mechanism
must support, and what architectural constraints apply. The detailed
requirements are set out in Section 3.
Discovery, as used here, is the initial step by which a discovering
entity obtains the public Minimum Discoverable Information (MDI)
about an entity. It applies within a local network, within an
organisation, and between cooperating parties over the public
Internet.
These requirements are intended to be solution-neutral. They do not
require discovery information to be carried in any particular
protocol element or data record. Section 3.2 sets out how
information may be provided by value or by reference.
The following topics are explicitly out of scope of this document:
* Open-ended search, semantic matchmaking, ranking, and selection of
entities;
King & Farrel Expires 22 April 2027 [Page 3]
Internet-Draft DAWN Requirements October 2026
* Capability information beyond the MDI, including catalogues of
capabilities;
* All communication beyond the initial discovery process;
* Indexing and searching of entities across the wider Internet;
* Entity registration processes, including attestation and other
security mechanisms for registration;
* Design, definition, and governance of naming systems for entities;
* Identity management, authentication, and authorisation of entities
themselves (as distinct from the integrity of discovery
information);
* Trust management and trust evaluation beyond the secure exchange
of discovery information;
* Capability exchange and negotiation between entities;
* Task management and orchestration.
2. Terminology
This document uses the following terms defined in
[I-D.farrel-dawn-terminology]:
* Agent
* Capability
* Capability Card
* Capability Exchange
* Discovered Entity
* Discovering Entity
* Discovery
* Discovery Information
* Discovery Mechanism
* Discovery Scope
King & Farrel Expires 22 April 2027 [Page 4]
Internet-Draft DAWN Requirements October 2026
* Entity
* Function
* Minimum Discoverable Information (MDI)
* Named Entity
* Properties
* Selection
* Trust Indicator
2.1. Conventions and Definitions
Although this is an informational requirements document, key words in
upper case are used for clarity of stating the requirements. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
3. Requirements
The requirements are organised into the following categories:
discovery scenarios, discovery information, trust and security,
scalability and architecture, discovery protocol, and extensibility.
3.1. Discovery Scenarios
REQ-DISC-1: A discovery mechanism MUST support the discovery of both
specific entity instances and classes of entities that can perform
a desired function.
REQ-DISC-2: A discovery mechanism MUST be applicable within a local
network, within an organisation, and between cooperating parties
over the public Internet. Different mechanisms MAY be specified
for different deployment contexts.
REQ-DISC-3: A discovery mechanism SHOULD support referral to another
entity, such as a catalogue or directory service, that can further
the discovery process. The information such a service exposes
beyond the MDI is out of scope.
REQ-DISC-4: Discovery is initiated from a name or scope known to the
King & Farrel Expires 22 April 2027 [Page 5]
Internet-Draft DAWN Requirements October 2026
discovering entity. A discovery mechanism MUST allow a
discovering entity to express the discovery scope of a discovery
operation in one or more dimensions, and SHOULD indicate whether
that scope has been fully searched or the results have been
truncated.
3.2. Discovery Information
REQ-PROP-1: A discovery mechanism MUST define the Minimum
Discoverable Information (MDI) that every discoverable entity
provides. The MDI MUST include at least the entity's type, the
services it offers, its reachability information, and the
communication protocols and any security parameters needed to
interact with it. Properties beyond the MDI are optional.
REQ-PROP-2: The MDI MUST be available by value. Information beyond
the MDI MAY be provided by reference. A discovery mechanism MUST
specify the maximum depth of indirection a discovering entity is
expected to follow, and the behaviour when that depth is exceeded.
REQ-PROP-3: A discovery mechanism MUST specify the behaviour of a
discovering entity when a reference cannot be used, distinguishing
at least the cases where the reference does not resolve, where
resolution is prevented by the discovering entity's own retrieval
policy, and where the reference resolves but the referenced
information is absent. A finding of absence MUST be based on a
complete result for the requested lookup; an incomplete result
MUST NOT be reported as absence.
REQ-PROP-4: A discovery mechanism SHOULD allow a reference to a
capability card or equivalent machine-readable description of an
entity's interface and functions. The format, content, and
exchange of such descriptions are out of scope.
REQ-PROP-5: A discovery mechanism MUST indicate whether discovery
information is static or dynamic, together with any validity or
freshness information needed for caching and refresh.
3.3. Trust and Security
REQ-SEC-1: A discovery mechanism MUST provide a means to verify the
origin and integrity of discovery information, for example through
digital signatures, and MUST be resilient to attacks that poison,
corrupt, or replay that information.
REQ-SEC-2: A discovery mechanism SHOULD allow an entity to control
King & Farrel Expires 22 April 2027 [Page 6]
Internet-Draft DAWN Requirements October 2026
the visibility of its properties to different audiences (e.g.,
public versus organisation-internal discovery), and allow an
operator to control which entities are discoverable in a given
context.
REQ-SEC-3: A discovery mechanism MUST be designed to limit its use
as a vector for abuse, including amplification, scraping, denial-
of-service, or unauthorised disclosure of discovery information.
3.4. Scalability and Architecture
REQ-ARCH-1: A discovery mechanism MUST be capable of operating in
decentralised architectures without a single centralised registry,
and MUST scale across a large number of entities and
administrative domains.
REQ-ARCH-2: A discovery mechanism SHOULD allow organisations to
independently publish discovery information without depending on a
third-party directory.
3.5. Discovery Protocol
REQ-PROTO-1: A discovery mechanism SHOULD be built in a modular way
using existing Internet Engineering Task Force (IETF) protocols,
such as DNS and mDNS, where possible, filling gaps only where
existing protocols are insufficient.
REQ-PROTO-2: A discovery mechanism MUST define a predictable entry
point for discovery that is based on ubiquitous and interoperable
mechanisms.
3.6. Extensibility
REQ-EXT-1: A discovery mechanism MUST support the addition of new
entity types and properties, including domain-specific extensions,
through structured, versioned schemas that allow backward-
compatible evolution without changes to the core mechanism.
4. IANA Considerations
This document does not make any requests of IANA.
King & Farrel Expires 22 April 2027 [Page 7]
Internet-Draft DAWN Requirements October 2026
5. Security Considerations
This document defines requirements for entity discovery mechanisms.
It does not define a protocol and therefore does not introduce
specific security vulnerabilities. However, the requirements in
Section 3.3 place security constraints on any solution that satisfies
these requirements.
Implementers of discovery mechanisms that satisfy these requirements
should pay particular attention to the following concerns:
* The integrity and authenticity of discovery information must be
protected to prevent poisoning attacks that could direct entities
to malicious endpoints.
* Integrity protection of discovery information does not, by itself,
authenticate a discovered entity as the live peer in a subsequent
protocol exchange.
* The security properties that can be provided differ by deployment
context. A specification should state which of origin
verification, integrity, and confidentiality it provides in each
context it supports.
* Access control mechanisms should be considered to prevent
unauthorised disclosure of entity properties, particularly in
environments where entity metadata may be sensitive.
* The discovery mechanism itself must not become a vector for
denial-of-service attacks against the infrastructure on which it
is built.
6. Privacy Considerations
Discovery mechanisms inherently involve the publication of
information about entities. Implementers should consider the privacy
implications of exposing entity properties, capabilities, and
organisational associations. In particular:
* Entities should be able to control what information is made
publicly discoverable versus restricted to specific audiences.
* The discovery mechanism should not require the disclosure of
information beyond what is necessary for a discovering entity to
determine whether interaction is appropriate.
King & Farrel Expires 22 April 2027 [Page 8]
Internet-Draft DAWN Requirements October 2026
* A specification of a discovery mechanism should state whether its
design resists enumeration of the entities it makes discoverable.
Unless it does, the set of discoverable entities should be assumed
to be public.
* Where entities represent individuals or process personal data,
compliance with applicable data protection regulations should be
considered.
7. Operational Considerations
Discovery mechanisms that satisfy these requirements will need to be
deployable across public and private networks, across organisational
boundaries, and across heterogeneous operational environments.
Operators should consider publication workflows, update and
withdrawal procedures, caching and refresh behaviour, observability,
operational policy, and the impact of discovery traffic on the
infrastructure used to support the mechanism.
8. Acknowledgements
The authors wish to acknowledge the contributions of participants in
the DAWN discussions that shaped this document, including Jim Mozley,
Balazs Nemethi, Chenguang Du, Francesco Marinoni Moretto, Girish
Konda, Songbo Bu, and Jamal Le Blanc.
9. References
9.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,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-04>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
9.2. Informative References
King & Farrel Expires 22 April 2027 [Page 9]
Internet-Draft DAWN Requirements October 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,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-05>.
[I-D.kay-dawn-use-cases]
King, D., Yao, K., Adler, K., and R. Ramdhany, "Use Cases
and Applicability for Discovery of Agents With Names",
Work in Progress, Internet-Draft, draft-kay-dawn-use-
cases-01, 10 September 2026,
<https://datatracker.ietf.org/doc/html/draft-kay-dawn-use-
cases-01>.
[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>.
Authors' Addresses
Daniel King
Old Dog Consulting
United Kingdom
Email: daniel@olddog.co.uk
Adrian Farrel
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
King & Farrel Expires 22 April 2027 [Page 10]