]> Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

DAWN discovery agents AI agents AI resources named entities information model metadata The charter of the Discovery of Agents With Names (DAWN) working group asks it to specify the minimum public discovery information that a client obtains when it discovers an AI resource. An individual draft on DAWN terminology defines Minimum Discoverable Information (MDI) as the minimum amount of information an entity needs to provide to become discoverable, distinguishes it from the Minimum Viable Dataset (MVD) that a discovery mechanism needs as input, and gives only examples of the content of either. Individual drafts on the DAWN problem statement and requirements call for a standardized minimum structure and list what it must at least contain; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document addresses the minimum public discovery information as a client obtains it and as a publisher provides it, and its relation to the input of discovery; registration mechanisms are outside its scope. Using the distinction RFC 3444 draws between information models and data models, it describes the information involved in publication, lookup, and response; proposes a procedure that derives what is minimal for each deployment context from the scope of the charter; applies the procedure to the charter's three deployment contexts: a local network, an organization, and the domain of a cooperating party; and proposes a set of elements with the minimal constraints that hold among them. Information can be supplied by the discovery response, by context the client already has, or by binding rules. This document is input to the DAWN architecture and protocol work; normative definitions that affect interoperability belong to the corresponding Standards Track documents. It is a mapping target for richer descriptors. Discussion Venues Discussion of this document takes place on the Discovery of Agents, Workloads, and Named entities Working Group mailing list (dawn@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Clients often need to discover information about AI resources, such as AI agents, before interacting with them , and often have no pre-configured relationship with them. Before any interaction can begin, a client needs a small amount of information about the AI resource: what it is, what it does, how to reach it, and what assurances, if any, accompany those claims. defines Minimum Discoverable Information (MDI) as the minimum amount of information an entity needs to provide to become discoverable, and does not define its content; requires each discovery mechanism to define the MDI, including 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, and to indicate whether discovery information is static or dynamic; calls directly for a standardized structure carrying the minimum information a discovery response returns; and sketches a provisional baseline without normalizing it. Mechanism-specific drafts define such fields for their carriers (, ); none defines MDI content independently of a carrier. The DAWN charter places this information at the center of the working group's scope: discovery is limited to a client requesting and obtaining the minimum public discovery information for an AI resource (for example, its type, reachability information, communication protocol, and services) within a local network, within an organization, or between cooperating parties with trust relationships over the public Internet. The charter assigns this information to two deliverables: the Discovery Architecture captures the requirements behind it, and the Protocol specifications, possibly one per deployment context, define it. This document uses "MDI" as shorthand for the information the charter calls minimum public discovery information; where the two might differ, the charter's wording governs. Meanwhile, the gap is being filled independently and incompatibly by adjacent ecosystems: DNS-based bootstrap (), well-known JSON manifests, agent cards, and signed capability documents each carry a slightly different minimal field set with slightly different semantics, each bound to its own substrate. A descriptor that is minimal and sufficient in one system is unreadable in another. distinguishes the input of discovery, the Minimum Viable Dataset (MVD), from MDI, which it defines by what an entity provides to become discoverable and describes as what a lookup returns. This document considers MDI at both points, publication and response, and relates it to the input. Following the distinction draws between information models and data models, it describes the information involved in discovery (), proposes how to decide what is minimal (), applies that procedure to the charter's three deployment contexts (), and describes the elements of the common discovery header and the minimal constraints that hold among them (), leaving encodings to bindings. lists the points on which input is sought.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terms defined in , including AI Resource, Entity, Discovered Entity, Discovering Entity, Discovery, Discovery Information, Discovery Scope, Discoverable Object, Capability Card, Trust Indicator, and, centrally, Minimum Discoverable Information (MDI); readers are assumed to be familiar with that document. The elements defined here are the normalized slots through which a minimal subset of an entity's Properties is conveyed as Discovery Information. The entity that MDI describes is a Discovered Entity, which in DAWN is an AI system or AI resource ; the charter's AI resource "may be an individual named agent or a service such as a catalog that will further the discovery process" . In this document, "resource" is short for AI resource. The client, as the charter calls it, is the Discovering Entity; this document also calls it the discovering party. In addition:

Discovery response:

What a discovery mechanism returns to a client; it may carry element values for one or more entities.

Known context:

Information the client already has when it interprets a discovery response, such as the Discovery Scope it searched, the name it started from, or the network it is attached to. Some of it is part of the MVD ().

Minimum Viable Dataset (MVD):

As defined in , "the data that must be provided to the discovery mechanism to enable it to return indications of Discovered Entities" ().

MDI instance:

The collection of element values for one entity, as a publisher provides it or as a consumer obtains it (). A consumer's instance takes each value from the discovery response, known context, or a binding rule.

Consumer:

The party that interprets an MDI instance, typically the client that performed discovery.

Scope and Non-Goals This document defines the abstract content of the MDI common header, and proposes how it is derived (), within the initial discovery that the DAWN charter scopes . It does NOT define:

• a discovery, query, resolution, or transport protocol, and it does not bind MDI to DNS or to any other carrier;
• a wire format, serialization, or schema; representations are illustrative ();
• a new capability card, or a replacement for any existing descriptor;
• identity verification, authentication, authorization, policy evaluation, or attestation procedures;
• capability exchange, negotiation, selection, registration, or invocation semantics;
• open-ended search, semantic matchmaking, ranking, indexing or searching across the wider Internet, or trust management and trust evaluation beyond the secure exchange of discovery information, all of which the charter places out of scope.

Design Principles

Encoding-neutral model:

Per , one information model can be carried by many concrete data models -- a JSON object, a CBOR map, a set of DNS records. Those are carriers; MDI is the shared meaning they carry.

Information, not fields:

Information that initial discovery needs can be carried in a discovery response, supplied by known context (such as the scope searched or the name the client started from), or fixed by a binding. Necessary information therefore need not be repeated in every record.

Thin core, rich references:

MDI is a header. Rich or sensitive structures -- capability cards, proofs, certificates, policy documents -- are referenced, not embedded, and fetched only when needed.

Discovery-time only:

MDI carries what lets a discovering party identify an entity, decide whether follow-up is worthwhile, and dereference the next object safely.

Freshness and rate of change matter -- elements are marked static, mainly-static, or dynamic, and validity information is first-class -- but detailed cache behavior belongs to bindings ().

Information in the Discovery Flow Discovery moves information through four stages, and each stage holds different information:

Publication:

A publisher makes information about an entity available to a discovery system. The publisher can be the entity or a system that maintains information on its behalf, such as an orchestration system . Published information contains the published MDI instance and can include more, such as administrative or policy data that is never returned to clients.

Serving:

A system that answers lookups, such as an authoritative DNS server, a registry, a catalog, or a responder on the local link, holds the published information. It can generate or transform parts of the output, for example when an mDNS responder renames an instance after a name conflict or a Discovery Proxy answers unicast queries with the results of mDNS queries , and it can add information of its own or hold different views for different audiences. A serving system outside the publisher's administrative domain, such as a gateway or a third-party catalog, is an intermediary.

Lookup input:

The MVD: the data the discovery mechanism needs to return results. The client supplies some of it in its query, such as a name, a protocol, or a scope; other mechanisms can supply the rest, such as context derived from the client's network attachment.

Response:

The MDI instances returned for the entities found, interpreted together with known context and binding rules.

Information in the discovery flow | | +-----------+ | serving system | | | +-----------+ lookup input (MVD) | can generate, | | client |-------------------------->| transform, or | | |<--------------------------| add | +-----------+ response (MDI) | information | | +-----------------+ | follow-up at an Endpoint: description retrieval, v interaction, or further discovery ]]>

This document proposes that MDI be considered at publication as well as in the response. The individual terminology draft defines MDI by what an entity needs to provide to become discoverable and describes a lookup that returns it, and the individual requirements draft asks each mechanism to define the MDI "that every discoverable entity provides"; the charter defines discovery by what a client obtains. The model of describes MDI instances at both points: published MDI instances, which publishers provide, and the instances consumers obtain. The correspondence need not be one to one. One published MDI instance can yield several obtained instances, as when a Discovery Proxy relays an advertisement (), and an entity can have several published MDI instances, per protocol or per publisher; a binding states how they correspond. A published and an obtained instance have the same elements and can differ in which values they carry and in the values themselves: a serving system can generate or transform values, as in the examples above; a binding can fix a value, such as an Endpoint purpose; and known context can supply one, such as a protocol named in the query. Every other value comes from a publisher. Considered at publication, the analysis of also indicates what a publisher has to provide, which each binding states (). Origin and attribution are assessed per value. A value can be verified to the name that a validated key is authorized for, the zone for DNSSEC or the origin for TLS, whoever operates the server. Protection applied at publication, such as a signature by a key that the binding ties to the publisher's name through an authenticated property of the carrier, covers only values that serving systems pass on unchanged. A value that a serving system generates or transforms, as a catalog or a Discovery Proxy does, can be verified at most to that serving system, and only where that system is authenticated; applies this to the deployment contexts. A consumer generally obtains only its own instance, so a binding states which values a serving system can generate or transform, and those values are attributable to the serving system unless protection applied at publication covers them. How published information reaches a serving system, for example by zone provisioning, DNS Update, SRP registration, or a registry interface, is a registration mechanism. lists registration as a function separate from the discovery lookup and places it out of scope for DAWN, while noting that "the information that can be discovered and the trust with which that information is treated are key to any complete system". This document defines no registration mechanism (). The MVD and MDI can share attributes, such as a protocol that a client asks for and a response reports, and each has items the other lacks, such as a search scope in the input and endpoints in MDI. The sources of the input, how it is conveyed, and how it corresponds to published information are stated for each deployment context and binding. The individual use-cases draft leaves to the DAWN architecture which query properties belong in the minimum ().

Determining What Is Minimal The charter gives examples of the minimum public discovery information (type, reachability information, communication protocol, and services) but no list . This document uses one question to decide what belongs: what does a client need to know to use a discovery result? Using a result means the subsequent interactions that the charter names, "such as selection, invocation, or communication": choosing one result, then fetching its description, talking to it, or asking a catalog for more results. An example shows how the question works. A client on a shop's network looks for agents and receives three results. To choose one and talk to it, the client has to tell the three apart, so each result needs a name. It has to know where to connect, such as a host and port or a URL, and which agent protocol to speak there, such as A2A or MCP. It has to know what it will find there: the agent itself, or a description of the agent, such as an agent card. And it has to know whether the result is still current. Other information helps only in some situations: a short description when a person, not software, makes the choice; an authentication scheme when the client talks to the agent directly without reading a description first; and a stable identifier when the client wants to recognize the same agent later or in another result. The rest, such as the full list of what the agent can do, can be read from its description after the choice is made, and is not part of the minimum. Not everything a client needs has to be in every result. A client that asked for A2A agents already knows the protocol, and a discovery mechanism can fix defaults, such as where an agent card is found. For each piece of information, this document therefore records two things: whether a client needs it, and where the client gets it, which is from the result, from its own query, from the rules of the discovery mechanism, or later from a description. The analysis has four steps:

1. List the candidates: the charter's examples and the information that existing discovery mechanisms carry ().
2. For each candidate and each deployment context of the charter, ask: if this were missing, could the client still use the result? If not, the client needs it in that context.
3. For each candidate the client needs, ask whether the client can know it without the result telling it. If not, results have to carry it, and the publisher provides it unless a serving system generates it ().
4. Where a candidate is needed only in some situations, state the situation.

What existing mechanisms carry is evidence for step 1: information that all of them carry can be required at little cost, and information that only some of them carry still has to pass step 2. The charter also requires integrity of all discovery information exchanged; protecting it, and the origin of the information where marks this, is an obligation on the binding in every context ().

Applying the Procedure This section applies to the three deployment contexts of the charter.

Local network:

The charter's example is "discover all agents in this shop". The client knows only its network attachment and possibly the agent protocol it wants; it has no name, registry, or prior relationship. DNS-SD over multicast DNS, as the individual draft profiles it for agents, is a representative mechanism. The next step is to tell the candidates apart, choose one, and retrieve its description or interact with it.

Within an organization:

The charter's example is "discover all agents available to employees within their employer's infrastructure". In the case tested here, the client is attached to the organization's network, possibly through a VPN, and can learn from that attachment where to look: DNS-SD domain enumeration queries names derived from a domain name received through DHCP and from the client's address prefixes (). Representative mechanisms extend those of the other two contexts: DNS-SD beyond the link, through Discovery Proxies or registration with the Service Registration Protocol (SRP) , as describes for enterprise campus and branch networks, and DNS records in internal zones, which the individual draft provides for. The next step is to choose an agent and retrieve its description or interact with it, or to continue discovery at a catalog.

Known domain of a cooperating party:

The charter's example is "discover all agents of example.org, for all its customers/members", between cooperating parties with trust relationships over the public Internet. The client knows the party's domain name and possibly the protocol, and has an organizational trust relationship; knowing the name does not show that information came from that party, and "for all its customers/members" names an audience for the results. DNS records under the party's domain, as proposed in the individual drafts and , are representative. To find all of a domain's agents, these drafts locate an organizational index at a well-known name such as _index._agents.<domain>, so the next step is further discovery at that index; a client that already knows an agent's name queries its records directly, then reaches the agent or retrieves its description.

Derivation for the three deployment contexts

Information	If missing	Other source	Result
Name of each result	Results cannot be told apart	The query, when it names one entity	Needed in every context
Endpoint location	Client cannot connect	Partly: owner name, default path	Needed in every context
Agent protocol	Client cannot talk to the endpoint	The query, when the binding ties the protocol to it	Needed in every context
Endpoint purpose	Next step unknown	Protocol or well-known name, via the binding	Needed in every context
Freshness	Stale data not recognized	Record lifetime	Needed in every context
Entity type	Mostly covered by the purpose	Partly	Left to the WG
Display name	Only a person choosing is affected	DNS-SD instance name	When a person chooses
Authentication hint	Next step can fail	Description or protocol handshake	When neither supplies the scheme first
Stable identifier	Results cannot be correlated	None	When results are correlated
Services	Covered by Endpoint protocols and Entity Type	Description	Left to the WG
Origin	Publisher unknown	DNSSEC or TLS, to the zone or origin; none for mDNS or SRP advertisers	Protection goal
Coarse capability labels	Nothing; the client chooses by protocol and type	Description	Beyond the minimum
Trust material, publisher name	Nothing beyond what origin provides	Binding and carrier	Beyond the minimum
Scope or audience hint	Nothing; the audience applies to the lookup	Query and deployment	Beyond the minimum
Availability	The connection fails and the client tries another result	Follow-up connection	Beyond the minimum

In the Result column, "Protection goal" marks an obligation on the binding (), "Left to the WG" marks a question in , and "Beyond the minimum" marks information a client does not need for its next step, which is therefore not part of MDI (). The results are the same in all three contexts; what differs is where the client gets each item. On a local network, each result carries the name, the endpoint location, and the protocol. A query for a known name, as under a cooperating party's domain, supplies the name, and a query for one protocol supplies the protocol. The binding supplies defaults, such as the protocol's default path, and usually the endpoint purpose, which follows from the protocol or from a well-known name such as an index label. Freshness comes from the lifetime of the records a result is built from. The conditional items depend on the next step. A display name matters when a person chooses among results. An authentication hint matters when the client interacts directly and neither a description nor the agent protocol's own handshake supplies the scheme first. A Stable Identifier matters when results are correlated, as when a client within an organization sees the same agent both through multicast DNS on its link and through a Discovery Proxy (). Entity type is largely covered by the endpoint purpose, and services by Endpoint protocols and Entity Type; both are asked in . Information beyond the minimum can help but is not needed: the client chooses by protocol and type, learns the details from the description, and learns availability at the follow-up connection. Where the results are meant for an audience, as "available to employees" and "for all its customers/members" suggest, the restriction applies to the lookup, for example through split-view DNS or a VPN, and the result carries nothing that enforces it; where this requester context belongs is asked in . Origin is where the contexts differ most. Under a party's domain, DNSSEC-validated records and TLS-authenticated origins tie the information to the party. A catalog or a Discovery Proxy that relays information can be authenticated only as itself, and on a local link multicast DNS does not authenticate advertisements, so the agent is authenticated only at the follow-up connection . How the charter's integrity requirement is met for such advertisements is asked in . Compared with REQ-PROP-1 of the individual requirements draft , reachability and protocol are needed in every context, security parameters (an authentication hint) under a condition, and type and services are questions for the working group.

MDI Information Model An MDI instance is the common header published or obtained for one entity. Its elements follow the results of ():

• Information needed in every context becomes the mandatory Name and Endpoint (location, agent protocol, and purpose) and the Freshness element. Freshness is SHOULD because its meaning is obtainable from the carrier lifetime; a binding whose carrier provides no lifetime MUST carry it.
• Entity type, left to the working group, is the mandatory Entity Type until the question in is decided. Services are covered by Endpoint protocols and Entity Type ().
• Information needed only under a condition becomes an element with Status MAY: Display Name, Authentication Hint, and Stable Identifier. A publisher cannot always know whether the condition holds for a given consumer; a binding or profile for deployments where it holds can make the element MUST.
• Origin is a protection goal, met by the binding (), and is not an element.
• Information beyond the minimum is not an element of MDI. A binding can still carry it as an Extension, and names the kinds that existing formats and individual drafts carry, so that bindings agree on their meaning.

Mandatory elements keep the record very small; in constrained carriers, a binding can derive their values from the carrier or from known context (). All Status values are provisional. Status key words in this document place obligations on the publishers and bindings that claim to carry MDI, and key words addressed to consumers apply to implementations of a binding. Status says how strongly the meaning of an element has to be obtainable by the consumer, from the response, from known context, or from binding rules; whether each response carries a value explicitly is a binding decision. Status applies to the instance a consumer obtains; a publisher provides every value that the binding neither derives nor fixes and that no serving system generates (). Cardinality governs how many values of an element may be carried. Obligations specific to binding documents are collected in .

Structure shows the elements and their shapes. Composite members marked "?" are optional, and freshness, whose members are all optional, is present only when at least one member is present; all other structure is given by the cardinalities.

Elements of the MDI model Entity +--------------+ |- name (1) |- endpoint { locator-type, locator, | protocols (1..n), purpose?, | digest? } (1..n) |- freshness { version?, valid-from?, | valid-until?, refresh-hint? } (0..1) |- entity-type (1) |- display-name (0..n) |- authentication-hint { scheme, metadata? } (0..n) |- stable-identifier (0..1) |- extension { name, value } (0..n) Reference = { ref-type, locator, digest? } ]]>

A Reference is a typed pointer, used by the Authentication Hint and by information beyond the minimum: the ref-type says how to interpret the locator, and the optional digest is an integrity digest over the object the locator identifies ().

Elements

Element	Status	Class	Result in Table 1
Name	MUST	varies	Needed in every context
Endpoint	MUST	mainly-static	Needed in every context (location, protocol, purpose)
Freshness	SHOULD	dynamic	Needed in every context; carrier lifetime
Entity Type	MUST	static	Left to the WG
Display Name	MAY	static	When a person chooses
Authentication Hint	MAY	mainly-static	When neither description nor handshake supplies it
Stable Identifier	MAY	static	When results are correlated
Extension	MAY	varies	Mechanism for information beyond the minimum

A static value is not expected to change while the resource keeps its identity. A mainly-static value changes only through deliberate administrative or deployment action. A dynamic value can change in normal operation and is evaluated together with Freshness. The stability of a Name varies with the carrier and is stated by the binding. The following elements are needed in every context.

Name:

The name under which a result is found, such as a DNS-SD service instance name or a DNS owner name, which lets a client tell results apart and refer back to them. It is often implicit in the carrier and is interpreted within its naming scope (). One resource can be found under several Names, for example one per protocol, and a Name can change, as when multicast DNS renames an instance after a conflict. A Name that the binding states to be stable also serves as the Stable Identifier; such a name is the stable name by which identifies a Named Entity.

Endpoint:

Where follow-up can proceed, for what purpose, and in which agent protocol; the locator is the charter's "reachability information", and the protocols member its "communication protocol". In this document, "agent protocol" means the application protocol that an AI resource speaks at the endpoint, such as A2A or MCP, whether or not the resource is an agent. The locator-type and locator members say where to go; a binding can carry the locator as one value, such as a URI, or assemble it from several fields, such as a target host and port plus a path. The protocols member names the agent protocols reached there, such as A2A or MCP; the protocol negotiated on the underlying TLS or QUIC connection, such as an HTTP version identified by ALPN , is different information unless the agent protocol runs directly over TLS or QUIC. The purpose member says what the follow-up is: retrieving a description of the resource (for example, an agent card), interacting with the resource, or continuing discovery at another discovery service, such as a catalog. When the purpose is not carried, the binding states how it follows from the protocol. An Endpoint for description retrieval is how MDI points to a fuller capability description, such as a Capability Card; its protocols member names the agent protocol of the described resource, the description is fetched as the locator implies (for an https URI, with an HTTP GET), and the Endpoint can carry a digest of the description. An entity can have Endpoints with different protocols and purposes.

Freshness:

Version, validity window, and refresh hint for the instance.

The following element is left to the working group.

Entity Type:

The kind of AI resource: for example an individual named agent or a service such as a catalog that furthers discovery, the two kinds the charter names , or another AI resource such as an AI inference service . It lets a client triage before fetching anything. The value space is left to DAWN, bindings, or profiles to define.

The following elements are needed under the conditions that states.

Display Name:

A short human-readable name or description for a person choosing among results, with no machine semantics. In DNS-SD the Name often serves; under unicast owner names, a binding carries one, as the title parameter of does, or takes it from the description. Language handling, if any, is a binding matter.

Authentication Hint:

The authentication scheme(s) a discovering party would need for follow-up, optionally with a Reference to authentication metadata. Never credentials, never authorization logic.

Stable Identifier:

A name for the resource itself that stays the same across results, protocols, and time within its naming scope, so that a client can correlate results and recognize the resource later. Like a Name, it is a name, not a verified identity, key, or proof.

Extension:

An extension named by a binding, profile, or future registry, carrying type-specific or ecosystem-specific information, including the information beyond the minimum of . An Extension does not alter core element semantics and does not reintroduce a non-goal of .

Information Beyond the Minimum finds that a client does not need the following information for its next step, so it is not part of MDI; REQ-PROP-1 of the individual requirements draft likewise states that "Properties beyond the MDI are optional". Existing formats and individual drafts carry it (). A binding that carries it does so as an Extension, with the following meanings:

Capability Summary:

Coarse, machine-readable capability tags for discovery-time filtering and triage; they are not sufficient for selection, negotiation, authorization, or invocation. The value space is not yet defined ().

Trust Reference:

A Reference to a trust indicator, such as a signature, certificate, attestation, trust manifest, or key set.

Provenance:

Who published this discovery information and, optionally, the party responsible for the entity -- information-layer provenance, not verified identity.

Scope Hint:

An opaque hint about discovery scope, audience, jurisdiction, or visibility. It is not access control ().

Operational Hint:

A coarse availability or health class, or a Reference to richer operational state, or both.

Services The charter lists "services" among its examples , and REQ-PROP-1 of requires the MDI to include "the services it offers"; neither says what a service is. This document covers services with existing elements, so there is no separate Services element:

• The agent protocols a resource offers, such as A2A or MCP, are the protocols of its Endpoints. The per-protocol DNS-SD subtypes proposed for agents, such as "_a2a._sub._agents._tcp", name these protocols .
• A resource that is itself a service, such as a catalog that furthers discovery, as the charter's scope notes, is identified by its Entity Type and by an Endpoint whose purpose is continuing discovery.

Coarse labels for what a resource does are the Capability Summary, which is beyond the minimum (). The individual draft makes such labels mandatory, while leaves capabilities out of DNS records and notes that coarse categories, if ever needed, could use DNS-SD subtypes. A shared vocabulary for the labels does not yet exist, and labels used for more than triage would be capability information beyond the minimum, which the charter places out of scope. Whether this reading of "services" is right is asked in .

Minimal Constraints The following rules are part of the model. A binding MAY tighten them but MUST NOT relax them.

1. An MDI instance describes exactly one entity. A discovery response may carry information for several entities; aggregation is a carrier matter.
2. Each Name and Stable Identifier is interpreted within a naming scope, which by default is the publisher scope. A binding states the naming scope and stability period of each Name and Stable Identifier it carries and how values are compared, with exact match as carried as the default. A Name distinguishes results only within its naming scope and stability period, and one resource may be found under several Names. The host name at which an endpoint is reached (such as an SVCB TargetName) belongs to the Endpoint locator and names a host, even where the same string is also a Name. Correlating results to one resource without a Stable Identifier is heuristic. Within one naming scope, equal Stable Identifiers denote the same resource; unequal ones do not by themselves denote distinct resources, and across naming scopes this model makes no sameness claim. Where a consumer holds several instances with the same Stable Identifier, it reconciles them by Freshness only among instances whose integrity and origin in that naming scope have been verified as the binding defines, using only Freshness values that the same verification covers; an instance that has not passed those checks does not displace one that has, and other cases are left to the binding.
3. Protocols attach to endpoints, not to the instance as a whole. A protocols value names an agent protocol, not the protocol negotiated on the underlying connection, such as an HTTP version, except where the two coincide (). An instance-level protocol list, where a binding offers one, is derived information (the union over all endpoints) and cannot diverge from them. The model attaches no meaning to the order of Endpoints; preference and selection are binding or carrier matters.
4. A digest, when present, is a member of the Reference or of the description-retrieval Endpoint it protects and covers exactly the object located there. Integrity is not trust: a matching digest shows that the bytes are intact, provided the digest itself was obtained with integrity, and it does not show that the publisher or the entity should be believed. A consumer MUST NOT use an object whose digest does not match. How a digest value identifies its algorithm is defined by the binding.
5. A consumer MUST ignore unrecognized Extensions; their presence is not an error. As an exception, a binding MAY mark an Extension as mandatory, as SVCB does with its "mandatory" key (); unless the binding says otherwise, a consumer that does not understand a mandatory Extension does not use the Endpoint or result that carries it, as an SVCB client skips a record that lists a mandatory key it does not support.

Binding Expectations MDI reaches the wire through bindings: documents that map this model onto a concrete encoding or discovery mechanism. Existing discovery formats already approximate bindings (); normative bindings are expected in separate documents. A binding that carries MDI MUST specify:

Encoding:

How each element is encoded and which value space it uses, defined by the binding, a profile, or a future registry. Which values are implicit and how they are derived from the carrier or from known context, for example a Name taken from a DNS-SD service instance name; an implicit value counts exactly as an explicit one. How unrecognized Extensions are carried and skipped at the encoding level, and which Extensions, if any, are mandatory.

Names and Endpoints:

The naming scope and stability period of each Name and Stable Identifier it carries, and whether it carries a Stable Identifier at all. For each Endpoint, how the locator is assembled, how the purpose is determined when it is not carried, and, where connection-level protocols are also carried, how they are kept apart from the protocols member. For an Endpoint for description retrieval, which object a digest covers. For Endpoints whose purpose is continuing discovery, the maximum referral depth, how loops are detected, and the naming scope of the results obtained there.

Integrity and origin:

How the integrity and origin of the MDI it conveys are protected, including how carried values are bound to the carrier fields and known context they are interpreted with, for example that a response answers the name or scope the client asked about, and where verification material comes from. How the publisher scope is determined from an authenticated property of the carrier, such as a DNSSEC-validated owner name or a TLS-authenticated web origin, never from values the instance asserts about itself, such as Provenance, and what publisher scope, if any, applies where a serving system generates the content from unauthenticated sources, as a Discovery Proxy does. Whether information relayed by a catalog or other intermediary is verified to the original publisher or only to the intermediary. How a consumer treats failed verification, removed elements, and expired information, and what successful verification establishes and what it does not.

Sources and lifetimes of values:

Which values the publisher provides and which a serving system generates or transforms, how a consumer tells them apart, how what an intermediary adds or changes is attributed to it, and which publisher an obtained instance derives from when several provide information for one entity. How carrier lifetimes, such as a DNS TTL or an HTTP cache lifetime, combine with Freshness, including which record lifetimes apply when a result is assembled from several records, with the earliest applicable expiry prevailing, and how stale or replayed information is detected.

A binding MUST protect the integrity of all MDI it conveys, as the charter requires ; what meets this requirement where the carrier does not authenticate advertisements is asked in . A binding MAY tighten Status, cardinality, or constraints, including per entity type, but MUST NOT relax a MUST element or a rule of .

Security Considerations MDI is advertised information; a consumer MUST treat it as unverified until corroborated by mechanisms outside this document.

• Values prove nothing by themselves. Any value can be forged by whoever publishes or serves it: a Name or Stable Identifier is not proof of identity, and an Endpoint does not prove that the reachable party is the intended entity. A matching digest shows only that a referenced object is the one the digest was computed over, and only if the digest was obtained with integrity; it does not show that the publisher or the entity can be trusted. A Display Name or other text chosen by the publisher can imitate another entity, including through visually confusable characters, or carry text aimed at automated consumers; a client presents such text as unverified, does not use it to identify or authorize, and does not treat it as instructions. An Authentication Hint, and any metadata at its locator, is unverified; it does not lead a client to weaken its authentication requirements or to send credentials to a party named only by unverified MDI. A Trust Reference locates assurance material but confers none until that material is verified by procedures defined elsewhere.
• Protection comes from the binding and the carrier, value by value. Integrity and origin, including protection against the removal of optional elements, are properties of the binding and carrier (for example DNSSEC, TLS); each binding states how it provides them and to whom origin is verified (). A serving system can generate, transform, withhold, or replay values, and protection applied at publication covers only the values it protects. A value derived from the carrier is as trustworthy as that carrier, and a value taken from known context is no more trustworthy than that context. A consumer SHOULD NOT draw conclusions from the absence of an element. A referral to another discovery service does not extend the referring publisher's naming scope or protection to the results obtained there.
• Every locator in MDI, whether of an Endpoint, a Reference, or authentication metadata, is supplied by an unverified party, and following it carries the usual risks of contacting an untrusted party. The usual dereferencing protections apply, such as limits on redirects and response sizes. Which addresses a client connects to is a matter of deployment policy, applied to the addresses a locator resolves to at connection time, including after redirects. Link-local and internal addresses are expected results of local and organizational discovery; unless deployment policy permits otherwise, a client does not connect to them when they appear in information obtained from outside that context.

Privacy Considerations Publishing MDI can reveal entity names, endpoints, organizational structure, capability hints, and scope information. Publishers SHOULD minimize public MDI to what discovery requires and SHOULD place sensitive information -- detailed capabilities, policy, internal topology, operational state -- behind access-controlled references. A Stable Identifier lets any observer correlate an entity across results, protocols, and time. Where an entity acts for an individual, its names, identifiers, and Provenance can be personal data; publishers that do not need correlation can omit a Stable Identifier. A Scope Hint is not access control. Published information, including data never returned to clients, is disclosed to every serving system that holds it, and views for different audiences stay separate only as far as that system keeps them apart. A key used to sign published MDI instances can be tracked like an identifier (): a key unique to an entity correlates that entity as a Stable Identifier does, and a key shared by a publisher links the entities it publishes. Results obtained under an audience restriction carry no marker of it; a cache, intermediary, or consumer that passes them outside that audience discloses internal names, endpoints, and topology. A Discovery Proxy makes advertisements visible to whoever can query it, and the domain a result appears under can reveal where a device, and a person it acts for, is ().

IANA Considerations Future revisions or binding documents may request registries for selected MDI value spaces, such as entity types or protocol identifiers; existing registries are to be reused where applicable.

Open Issues Input from the working group is sought on the following questions:

• Is the procedure of an acceptable basis for deciding what belongs in the minimum public discovery information? Are the results of right, including the conditions under which a display name, an authentication hint, or a Stable Identifier is needed, and is the information that places beyond the minimum correctly left out of MDI? If so, should this document keep naming that information for bindings (), or leave it to bindings and profiles?
• Should MDI be defined only by what a client obtains, or also at publication? This document proposes both points, with Status defined for the instance a consumer obtains and a publisher's obligations derived from it per binding (); an alternative is to set Status separately for published MDI instances.
• Which items of the MVD should DAWN specify for each deployment context? Is requester context, such as the audience that "available to employees" or "for all its customers/members" implies, part of the MVD, and if so who supplies it, or is it access control outside discovery? Is information restricted to such an audience public in the charter's sense?
• How should the charter's examples "type" and "services" be read? Entity Type can remain MUST or follow from the endpoint purpose. This document covers services by the protocols of Endpoints and by Entity Type, and places coarse labels (Capability Summary) beyond the minimum (); is that right?
• Where an agent's advertisement or registration is not authenticated to its operator, as with multicast DNS, a Discovery Proxy relaying it, or SRP, how is the charter's requirement for integrity of the information exchanged met: by authenticating the agent at the follow-up connection, by that together with protection of the hop that delivers the information, such as a Discovery Proxy's DNSSEC signature, or only by protecting the advertisement to its origin, for example with authenticated DNS Update (), which places a requirement on registration ()? See .

References Normative References Old Dog Consulting China Mobile Deutsche Telekom Infoblox The proliferation of distributed Artificial Intelligence (AI) systems and agents has created a need for interoperable mechanisms for components of AI systems to discover each other. This document defines terminology for Discovery of Agents With Names (DAWN), focusing on the terms necessary to describe the discovery of information about AI systems and resources (e.g., AI agents). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IETF Old Dog Consulting Old Dog Consulting 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. Lancaster University China Mobile Indeed BBC 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. Huawei Technologies Canada Huawei Technologies Canada Old Dog Consulting Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. Huawei Technologies Canada Huawei Technologies Canada This Internet-Draft provides a gap analysis and applicability statement that maps existing Discovery Mechanisms and protocols to the DAWN problem statement and discovery requirements. The analysis evaluates security, privacy, applicability, flexibility, and suitability of existing standardized, non-standardized, and proposed discovery solutions and protocols to the DAWN problem statement and REQ-DISC corpus. It identifies high priority gaps, proposes mitigations and hybrid patterns, and serves as reference for future prototyping and development. The intention is for this draft to evolve as new solutions come to existence. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. Cisco Systems Cisco Systems Protocols for communication between autonomous software agents typically discover agents through documents retrieved over HTTPS from a well-known URI. This model requires a discovering party to already know an agent's host name or URL, or to consult a centralized catalog. It provides no zero-configuration mechanism for enumerating agents that are present on a local network. This document describes how existing, widely deployed protocols, Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD), can be used to advertise and discover agents on a local link, with no new protocol machinery. It presents a general, protocol-independent two- stage discovery model in which lightweight enumeration over DNS-SD is followed by obtaining full agent metadata over the agent's native transport, whether by retrieving a description document or by connecting to the agent and performing its native handshake. The DNS-SD records carry a small set of discovery parameters that is shared with agent discovery in unicast DNS. The document gives worked instantiations of that model for the Agent2Agent (A2A) protocol and the Model Context Protocol (MCP). Cisco Cisco Infoblox, Inc. Infoblox This document defines parameters for AI agents that would be used in DNS and mDNS discovery processes. It provides a set of common parameters for different DNS records to facilitate agents communicating over application layer protocols such as A2A or MCP. Pengcheng Laboratory This document specifies the Federated Agent Metadata Synchronization Protocol (FAMS-P), a normative protocol realization of the "BGP-like structured peering" federation mode (Mode B) defined in the two-layer DAWN discovery architecture (draft-zhang-dawn-agent-discovery- framework). FAMS-P is a peer-to-peer unicast protocol for synchronizing agent discovery metadata between Federation Gateways (FGWs) across administrative domains, in deployments where the preferred DNS delegation model does not meet operational requirements, such as closed trusted federations of approximately 2 to 200 sites. FAMS-P runs over mutually-authenticated TLS 1.3 sessions between peering gateways. It supports initial full metadata synchronization and incremental updates for agent online, offline, and change events. Each gateway maintains a local Federated Agent Directory (FAD). The protocol synchronizes only lightweight Federation Metadata Records (FMRs) — a concrete binding of the DAWN Minimum Discoverable Information (MDI) — and thus transfers only the minimum public discovery information permitted by the DAWN charter; richer capability retrieval is out of scope. The protocol defines complete message formats, a session state machine with connection collision resolution, timestamp-and-replay- protected conflict resolution, mandatory FMR origin signatures, time- to-live aging with bounded refresh jitter, and fine-grained per-peer export policy enforcement. Pengcheng Laboratory Futurewei Sun Yat-sen University This document describes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The Local Discovery Plane obtains discovery information within an administrative domain through mDNS/DNS-SD or infrastructure-assisted discovery. For cross-domain discovery, the Federation Plane uses publication of policy-approved information in authoritative DNS zones and on-demand resolution as its baseline; Federation Gateways apply export policy and validate and cache accepted results. The document also identifies optional functions that may complement this baseline where DNS publication and request-driven resolution do not meet deployment needs: recipient-specific sharing, proactive or multi-hop dissemination, and trusted aggregated directory queries. In mixed- mode deployments, DNS may bootstrap an endpoint that provides one of these additional functions. Futurewei Pengcheng Lab This document describes an infrastructure-assisted approach to AI-agent discovery. An orchestration, placement, or hosting system can publish current deployment and reachability information for available AI-agent services or instances. Separately, network infrastructure can derive an abstract Attachment Scope representing the network context applicable to a requester. A discovery mechanism combines requester intent, currently published AI-agent resources, and the requester's Attachment Scope to identify applicable agent instances. There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations.

Illustrative JSON Example

Mapping Notes The table sketches where the mandatory elements of MDI, the Stable Identifier, the description Endpoint, and Freshness surface in the DNS and DNS-SD parameters proposed in for SVCB records () and DNS-SD TXT records, as used by , and in the generic well-known-JSON and agent-card patterns (no single specification is implied). Field names are indicative; full mappings belong to binding documents.

MDI element	DNS and DNS-SD	Well-known JSON	Agent Card
Name	instance or owner name	(document URL)	(card URL)
Stable Identifier	none; shared desc-ref suggests one agent	identity	agent_id
Entity Type	(service type or name)	(metadata)	(metadata)
Endpoint locator	SRV/SVCB target and port, plus path or well-known	endpoints	endpoint.url
Endpoint protocols	proto	(in endpoints)	endpoint.protocol
Endpoint purpose	implied by proto, or by the _index label	(interaction)	(interaction)
Description Endpoint	desc-ref	descriptor URI	(the card itself)
Freshness	DNS TTL; desc-ref-digest as change signal	version	version

In the DNS and DNS-SD column, proto carries the agent protocol; the alpn parameter carries the protocol negotiated on the TLS or QUIC connection and corresponds to no MDI element. carries the agent protocol in alpn or in a separate bap parameter. Each record carries one proto value, so a resource that offers several protocols appears in several records: in DNS-SD each has its own instance name, while unicast SVCB records share one owner name. Each record supplies the Endpoint for its protocol, and a desc-ref supplies an Endpoint for description retrieval, whose description can be hosted elsewhere. and infer from a shared desc-ref that records belong to one agent; states that desc-ref is neither a universal identifier nor authenticated. The desc-ref-digest parameter is defined as a freshness signal, not a security signal, and maps to Freshness; it is not the digest of the description Endpoint (rule 4 of ). The locator is assembled from the SRV or SVCB target and port plus the path or well-known parameter or, absent both, the protocol's default location (for A2A, /.well-known/agent-card.json). Whether the advertised location serves description retrieval or interaction follows from the protocol: for A2A it serves the agent card, from which interaction URLs are taken, while for MCP it is the interaction endpoint . The individual drafts and define a TLV binding of MDI elements for exchange between gateways, including an Entity-Identifier and a Capability-Summary. In , the Entity-Identifier, which together with the Origin-GW-ID keys a record, can serve as the Name and corresponds to the Stable Identifier; the Capability-Card-URI is an Endpoint for description retrieval; and the Capability-Summary, Trust-Reference, and Provenance TLVs correspond to the information of the same names beyond the minimum (). That draft makes the Capability-Summary mandatory, while places coarse capability labels beyond the minimum.

Acknowledgements The author thanks Chenguang Du for his valuable contributions to the design and text of this draft. This work builds on the DAWN terminology, requirements, problem statement, and gap-analysis documents.