| Internet-Draft | A Framework for Agent Discovery in DAWN | October 2026 |
| Zhang, et al. | Expires 18 April 2027 | [Page] |
The IETF DAWN (Discovery of Agents With Names) working group is chartered to enable a client to discover the minimum public discovery information about AI resources (e.g., AI agents) before interacting with them, within the local network, within an organization, and between cooperating parties over the public Internet. Existing DAWN contributions include terminology, use cases, requirements, gap analysis, a discovery mechanism survey, and an information model for Minimum Discoverable Information (MDI).¶
This document, the DAWN Discovery Architecture deliverable, describes a two-layer federated reference architecture for this initial discovery. The first layer, the Local Discovery Plane, performs zero-configuration advertisement and collection of the minimum public discovery information inside each local site, without mandating a specific link-local protocol. The second layer, the Federation Plane, builds a federation among site gateways to exchange lightweight Federation Metadata Records (FMRs) — a concrete binding of the minimum public discovery information — across independent administrative domains, and provides integrity for all exchanged discovery information.¶
The architecture emphasizes data sovereignty through an Export Policy Engine, supports iterative discovery via referrals, delegation, and indirection, and allows organizations to publish their discovery information independently. The Federation Plane is preferably realized over DNS (Mode A, DNS Delegation Model), in which each site publishes its FMRs as resource records in its own authoritative zone and other sites' validating resolvers obtain and verify them with DNSSEC, with delegation and referral between authoritative zones providing the primary means of inter-organizational interaction. Alternatively, the Federation Plane MAY be realized over non-DNS synchronization modes (Mode B), selected according to the number and scale of participating organizations and the deployment scenario from BGP-like structured peering, gossip-based epidemic dissemination, and trusted directory publication; the modes may be combined. The architecture supports multiple federation synchronization strategies and builds on existing IETF protocols such as DNS and mDNS. This document is informational: it does not define normative protocol formats, nor does it compete with existing DAWN proposals such as ACAP, Agent Directory, or ARDP; rather, it provides a deployment framework showing how these mechanisms may be composed at administrative boundaries. Consistent with the DAWN charter, open-ended search, semantic matchmaking, ranking, selection based on capabilities, capability catalogs, and communication beyond the initial discovery process are out of scope.¶
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 18 April 2027.¶
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.¶
The IETF DAWN working group [I-D.akhavain-moussa-dawn-problem-statement] is chartered to enable a client to discover the minimum public discovery information about AI resources before interacting with them, covering the local network, an organization, and cooperating parties with trust relationships over the public Internet. Its problem statement identifies that no single existing mechanism satisfies all discovery scenarios, particularly when crossing trust and administrative boundaries [I-D.moussa-dawn-gap-analysis]. DAWN requirements [I-D.king-dawn-requirements] and use cases [I-D.kay-dawn-use-cases] scope discovery to obtaining the minimum public discovery information needed to reach and communicate with a resource: type, reachability information, communication protocol, and services.¶
A growing number of individual submissions propose concrete mechanisms within this space: DNS-based naming extensions (DNS-AID [I-D.mozleywilliams-dnsop-dnsaid], DN-ANR [I-D.cui-dns-native-agent-naming-resolution]); DNS-like hierarchical architectures (Agent Root, Agent Registry, Agent Resolver [I-D.yao-dawn-agent-discovery-architect]); mDNS/DNS-SD-based two-phase discovery [I-D.jakab-dawn-agent-discovery-mdns]; host-level self-description (A2A Agent Cards, ACAP [I-D.zahed-acap], ANP agent-descriptions, api-catalog [RFC9727]); and registry protocols (Agent Directory [I-D.jimenez-agent-directory], AGNTCY ADS [I-D.mp-agntcy-ads]). A survey by Jimenez et al. [I-D.jimenez-dawn-discovery-landscape] compares these mechanisms and identifies gaps, including the lack of interoperable federation across administrative boundaries.¶
Cui [I-D.cui-dawn-mdi-model] proposes an encoding-neutral information model for Minimum Discoverable Information (MDI) — a common header that any discovery response may carry, independent of transport or format. MDI defines three mandatory elements (Entity Identifier, Entity Type, Endpoint) and a short set of recommended elements (Capability Summary, Authentication Hint, Trust Reference, Freshness).¶
At the IETF 126 BoF, the discussion converged on a minimal set of building blocks for a workable solution: establishing initial context with a known and trusted party, a directory server holding registration records, and a data format for those records. This architecture maps directly onto these three elements: the Federation Gateway (FGW) realizes the initial context and trust boundary with a remote party; the Federated Agent Directory (FAD) is the local store for accepted discovery records, serving as an on-demand cache for remote DNS results in Mode A; and the FMR is the data format, itself a concrete binding of MDI [I-D.cui-dawn-mdi-model].¶
This document complements the above work by defining a reference architecture for the initial discovery of the minimum public discovery information across the DAWN deployment contexts. It addresses the "Administrative Scope Extensions" use case [I-D.kay-dawn-use-cases], where discovery must cross organizational boundaries while preserving data sovereignty. The architecture introduces a Federation Gateway (FGW) as the boundary component between a local site and external domains, and an Export Policy Engine that controls which agent metadata may leave the site. It binds the minimum public discovery information into a lightweight Federation Metadata Record (FMR) for inter-gateway exchange. Discovery may be iterative: a returned record may refer the client to a catalog or to another discovery endpoint via referral, delegation, or indirection, rather than returning a complete answer in a single step.¶
This document does not define a new discovery protocol competing with ACAP, Agent Directory, or ARDP. Instead, it shows how a site may deploy a gateway that federates with peer gateways, using existing or future DAWN protocols as the synchronization substrate. The FGW concept fills a gap not yet addressed by existing proposals: the explicit modeling of the administrative boundary and per-peer export policy. Consistent with the DAWN charter's orientation toward DNS and mDNS as mechanisms, the Federation Plane is preferably realized over DNS (Mode A, DNS Delegation Model): each site publishes its FMRs as resource records in its own authoritative zone, and other sites' validating resolvers obtain and verify them (e.g., with DNSSEC), with delegation and referral between authoritative zones providing the primary means of inter-organizational interaction. Non-DNS synchronization modes (Mode B) — BGP-like structured peering, gossip-based epidemic dissemination, and trusted directory publication — remain alternatives selected according to federation scale and scenario, and the modes may be combined.¶
This document defines a reference architecture for the initial discovery of the minimum public discovery information about AI resources within the DAWN deployment contexts: the local network, an organization, and cooperating parties with trust relationships over the public Internet. It specifies logical layers, functional components, data flow, an integrity model, and deployment considerations for this discovery.¶
The following items are explicitly out of scope for this informational document, consistent with the DAWN charter:¶
Normative protocol message formats, encodings, or state machines. These are addressed in separate protocol specifications that may be developed based on this architecture.¶
Mandatory cryptographic algorithms or cipher suites. The architecture requires transport security and metadata integrity, but specific algorithm selection is deferred to protocol documents.¶
A global root trust authority or certificate hierarchy. The architecture supports federation-local trust models, consistent with DAWN's initial scope [CSA-DAWN-Note].¶
Exchange of capability information beyond the minimum public discovery information; in particular, catalogs of capabilities are out of scope. The FMR carries only the minimum public discovery information (type, reachability, communication protocol, services).¶
All communication beyond the initial discovery process, including any interaction, invocation, or selection that follows discovery.¶
Open-ended search, semantic matchmaking, ranking, or the selection of an AI resource based on capabilities or user intent.¶
Identity management of AI agents, tools, and skills.¶
Trust management and trust evaluation methods beyond secure content exchange between DAWN parties. The architecture provides integrity for exchanged discovery information but does not define a general trust framework.¶
Agent runtime execution, task scheduling, or inter-agent communication protocols beyond discovery.¶
Business-level service level agreements or commercial federation governance rules.¶
Open-Internet-scale agent indexing — the "AI resource indexing across the wider Internet" case excluded by the DAWN charter — is out of scope. Trusted directory publication (Section 7.2.3) is limited to publication to trusted or semi-public directories under explicit operator policy, and does not constitute open-Internet indexing.¶
Section 2 defines terminology, aligned with DAWN [I-D.farrel-dawn-terminology]. Section 3 states architectural requirements and maps them to DAWN requirements. Section 4 positions this architecture relative to existing DAWN family protocols. Section 5 provides a state-of-the-art review and gap analysis. Section 6 defines the two-layer reference architecture and functional components. Section 7 describes the inter-organizational interaction modes: Mode A (DNS delegation, preferred) and Mode B (non-DNS alternatives selected according to federation scale and scenario). Section 8 presents the layered security model. Section 9 covers resilience and operational considerations. Section 10 describes the relationship between this architecture and normative protocol documents. Section 11 is IANA considerations. Appendix A provides detailed considerations for the federation synchronization modes: Appendix A.1 describes the preferred DNS delegation model (Mode A); Appendix A.2 introduces the non-DNS alternatives (Mode B), with Appendix A.3, Appendix A.4, and Appendix A.5 describing BGP-like structured peering, gossip-based epidemic dissemination, and trusted directory publication respectively.¶
This document uses terms defined in [I-D.farrel-dawn-terminology], including Entity, Discovery, Discovery Information, Discoverable Object, Minimum Discoverable Information (MDI), Capability Card, and Trust Indicator. The following additional terms are defined for the purpose of this architecture:¶
Agent: An autonomous network-resident entity that can execute tasks, expose service interfaces, and advertise capability metadata. Aligns with the DAWN definition of Entity when the entity type is "agent".¶
Administrative Domain: A network or set of networks under a single organizational authority, with its own security and operational policies. Equivalent to the DAWN scope concept.¶
Federation Metadata Record (FMR): A lightweight, sanitized descriptive record of an AI resource, exchanged among Federation Gateways in the Federation Plane. An FMR carries the minimum public discovery information for cross-domain transport, including Entity Identifier, Entity Type, reachability/locator, communication protocol, services, status, and time-to-live. This information MAY be represented using the DAWN Minimum Discoverable Information (MDI) model [I-D.cui-dawn-mdi-model] or derived from resource information supplied through the Resource Publication Hook [I-D.dunbar-dawn-infra-assisted-discovery]. An FMR does not carry capability information beyond the minimum public discovery information. The concrete TLV encoding of an FMR is left to the synchronization protocol specifications that may be developed based on this architecture.¶
Capability Card: A fuller description of an agent's capabilities. Exchange of capability information beyond the minimum public discovery information is out of scope for DAWN's initial phase (see Section 1.2); this architecture does not distribute or retrieve Capability Cards as part of discovery. ACAP's Agent Capability Document (ACD) [I-D.zahed-acap] and A2A Agent Cards are examples of such fuller descriptions.¶
Site / Local Domain: An independent administrative area, typically one local-area network or a single tenant namespace, where agents run.¶
Federation Gateway (FGW): A network component deployed at the boundary of a local site. It obtains agent discovery information collected through LAN-based discovery, infrastructure-assisted discovery, or both, applies export policy, constructs FMRs, and participates in cross-domain federation. A local infrastructure gateway MAY be implemented separately from, or integrated with, the FGW. The FGW realizes the boundary function between DAWN's local discovery and cross-domain registry planes. In the preferred DNS realization (Mode A), the FGW acts as an authoritative publisher in the site's zone -- publishing its FMRs as resource records or, in the pointer-only form, bootstrap records advertising the FGW discovery directory endpoint -- and as a validating resolver that queries and verifies peer zones (e.g., with DNSSEC); in the non-DNS realization (Mode B), it instead participates in the selected synchronization mechanism (e.g., BGP-like peering, gossip, or directory publication).¶
Federation: A trust group formed by multiple federation gateways from different administrative domains, for exchanging agent discovery metadata.¶
Federation Peer: A remote FGW with which a local FGW has established an authenticated control relationship.¶
DNS Delegation Mode (Mode A): The preferred realization of the Federation Plane for inter-organizational interaction. Each site publishes its FMRs as resource records in its own authoritative zone, and other sites' validating resolvers query those zones directly; delegation and referral between authoritative zones provide the discovery path without requiring persistent gateway-to-gateway sessions. Detailed considerations are provided in Appendix A.1.¶
Non-DNS Synchronization Mode (Mode B): The alternative realization of the Federation Plane when the DNS delegation model (Mode A) does not meet operational requirements. Mode B offers three synchronization mechanisms, selected according to the number and scale of participating organizations and the deployment scenario: BGP-like structured peering (Appendix A.2.1), gossip-based epidemic dissemination (Appendix A.2.2), and trusted directory publication (Appendix A.2.3).¶
Minimum Public Discovery Information: The set of public properties a client needs before interacting with an AI resource: its type, reachability information, communication protocol, and services. This information MAY be represented using the DAWN MDI model [I-D.cui-dawn-mdi-model] and MAY be obtained through agent advertisement or the Resource Publication Hook [I-D.dunbar-dawn-infra-assisted-discovery]. An FMR carries this information together with the identifier, status, and time-to-live described in its definition; capability information beyond this minimum remains out of scope.¶
Iterative Discovery / Referral: A discovery process in which a returned record refers the client to a catalog or to another discovery endpoint (referral, delegation, or indirection), continuing until the client obtains the minimum public discovery information it needs.¶
Federated Agent Directory (FAD): The local discovery-information store maintained by an FGW. In Mode A, remote agent discovery information is not pre-populated or synchronized into the FAD by default. A cross-domain discovery request triggers DNS retrieval when no valid matching cached record exists; validated results are then cached in the FAD for their remaining permitted lifetime. In Mode B, the FAD also holds accepted records obtained through the selected synchronization or directory mechanism. Locally originated FMRs MAY be maintained separately or within the same store.¶
Export Policy Engine: A functional module on the FGW that filters, redacts, and controls which agent metadata may be shared with which federation peers. This is the core mechanism for data sovereignty.¶
Local Discovery Plane: The first architectural layer, operating within a single site, responsible for collecting and maintaining lightweight agent discovery information. It supports two complementary modes: LAN-Based Discovery and Infrastructure-Assisted Discovery (IAD). The modes MAY coexist within the same administrative domain, and the architecture does not mandate a specific local discovery protocol.¶
LAN-Based Discovery: A local discovery mode in which an agent or an authorized entity advertises lightweight agent discovery information through a site-local mechanism, such as link-local multicast mDNS/DNS-SD. Local peers and discovery components obtain the advertised information through that mechanism.¶
Infrastructure-Assisted Discovery (IAD): A local discovery mode primarily intended for organization-level agent discovery in managed environments. Authorized deployment infrastructure collects and maintains agent discovery information using its knowledge of current deployments. When the local infrastructure gateway is separate from the FGW, it advertises the collected information and subsequent updates or withdrawals to the FGW. When integrated, the FGW primarily obtains this information from registration records maintained within the managed infrastructure. This mode uses the Resource Publication Hook described in [I-D.dunbar-dawn-infra-assisted-discovery].¶
Local Infrastructure Gateway: An authorized orchestration, placement, hosting, or management system that collects and maintains discovery information on behalf of agents deployed within a managed organizational environment. It MAY be implemented separately from, or integrated with, the FGW. When implemented separately, it advertises the collected agent discovery information to the FGW and provides updates as deployment state changes. When integrated, the FGW primarily obtains agent discovery information from registration records maintained within the managed infrastructure. Its local discovery role does not itself imply participation in cross-domain federation.¶
Resource Publication Hook: The infrastructure-assisted mechanism described in [I-D.dunbar-dawn-infra-assisted-discovery] through which deployment infrastructure supplies resource discovery information for local registration and maintenance. In this architecture, the FGW MAY use the supplied information to construct FMRs after applying export policy.¶
Attachment Context Hook: An infrastructure integration point through which trusted network infrastructure provides the requester's current Attachment Scope to the discovery mechanism, as described in [I-D.dunbar-dawn-infra-assisted-discovery]. This context complements published resource information when identifying applicable discovery domains and reachable agent endpoints. Its detailed realization is outside the scope of this document.¶
Attachment Scope: An abstract network-derived context representing the attachment or reachability domain applicable to a requester or discoverable resource. It may reflect a tenant, VPN, access network, or edge domain. Attachment Scope indicates network applicability; it does not itself provide agent load measurements or runtime endpoint addresses.¶
Federation Plane: The second architectural layer, operating across administrative domains, responsible for FMR exchange among FGWs.¶
This section defines high-level architectural requirements for the two-layer agent-discovery architecture. These requirements are derived from the DAWN working group's problem statement [I-D.akhavain-moussa-dawn-problem-statement], requirements [I-D.king-dawn-requirements], and use cases [I-D.kay-dawn-use-cases]. They are non-normative for this informational document.¶
F-1: Cross-Domain Discovery -- The architecture MUST enable discovery of the minimum public discovery information about resources that reside in administrative domains different from the requester's domain, i.e., between cooperating parties with trust relationships over the public Internet. Satisfies DAWN use case "Administrative Scope Extensions" [I-D.kay-dawn-use-cases].¶
F-2: Zero-Configuration Local Discovery -- Agents MUST be capable of advertising themselves on the local network without pre-provisioned discovery server addresses. Satisfies DAWN requirements for local-context discovery [I-D.king-dawn-requirements].¶
F-3: Data Sovereignty -- Each site administrator MUST retain full control over which agent metadata records can be shared outside its local domain, including per-record filtering, field redaction, and per-peer access policy. Addresses the gap identified in [I-D.moussa-dawn-gap-analysis] regarding lack of interoperable federation with per-domain policy control.¶
F-4: Decentralized Federation -- The architecture MUST NOT require a mandatory global centralized directory. Federation participants MUST be able to operate without submitting data to a third-party central authority. Aligns with DAWN's emphasis on avoiding single points of failure [I-D.king-dawn-requirements].¶
F-5: Minimum Public Discovery Information Only -- The architecture MUST exchange only the minimum public discovery information (type, reachability, communication protocol, services) in the federation plane, and MUST NOT distribute or retrieve capability information beyond this minimum. This instantiates the DAWN MDI principle of a thin, encoding-neutral record [I-D.cui-dawn-mdi-model].¶
F-6: Dynamic Agent Lifecycle -- The architecture MUST support changes in agent availability, deployment state, reachable endpoints, and export permission. After detecting a relevant change, the responsible publisher MUST promptly update or withdraw the affected authoritative publication or federation advertisement. In Mode A, authoritative updates do not immediately invalidate previously cached copies; resolver caches and remote FAD entries remain subject to their established validity limits. In Mode B, updates, withdrawals, and expiration follow the selected mechanism. These procedures support dynamic updates and freshness [I-D.king-dawn-requirements].¶
F-7: Multi-Protocol Support -- The architecture MUST permit multiple alternative synchronization modes for the federation plane, with DNS delegation between authoritative zones (Mode A) as the preferred realization, and non-DNS modes (Mode B: BGP-like structured peering, gossip-based epidemic dissemination, or trusted directory publication) selected according to deployment scale and scenario. Aligns with DAWN's requirement to support multiple discovery models [I-D.king-dawn-requirements].¶
F-8: Iterative Discovery and Referral -- The architecture MUST support iterative discovery in which a returned record may refer the client to a catalog or to another discovery endpoint (referral, delegation, or indirection). The AI resource to be discovered may itself be a catalog or service that furthers the discovery process.¶
F-9: Integrity of Discovery Information -- The architecture MUST provide integrity for all discovery information exchanged between DAWN parties, allowing a recipient to detect alteration of, or unauthorized injection into, the exchanged records.¶
NF-1: Security Against Forged Advertisements -- The architecture MUST provide a mechanism to verify the origin and integrity of FMRs, preventing malicious federation participants from injecting forged agent advertisements.¶
NF-2: Fault Tolerance -- The architecture MUST tolerate individual gateway failures, network partitions, and transient connectivity loss without catastrophic loss of discovery capability.¶
NF-3: Interoperability -- The architecture MUST support interoperability among different federation synchronization protocols, so that gateways using different protocols can coexist within the same overall architecture. Supports DAWN's goal of cross-domain interoperability [I-D.king-dawn-requirements].¶
NF-4: Privacy Protection -- The architecture MUST prevent leakage of internal network topology, private IP addresses, and sensitive agent details to unauthorized external parties. Satisfies DAWN privacy considerations [I-D.king-dawn-requirements].¶
NF-5: Scalability -- The architecture MUST scale from small federations of a few sites to large federations of hundreds or thousands of sites, without requiring per-site full-mesh manual configuration.¶
NF-6: Operational Simplicity -- The architecture MUST minimize operational overhead for site administrators, particularly for local-site deployment where zero-configuration is a primary goal.¶
This architecture is designed to complement, not replace, existing protocols being discussed in the DAWN community and adjacent efforts. The following positioning statements clarify the relationship.¶
ACAP [I-D.zahed-acap] defines a well-known URI scheme, a rich Agent Capability Document (ACD) format, and HTTP/3 operations (GET, PUT, POST) for retrieval, registration, and search within a site. ACAP operates primarily at the Description Plane: it specifies how a host publishes its capabilities and how a domain-level query endpoint answers discovery queries.¶
This architecture treats ACAP as a valid implementation of the Description Plane within a site. An FGW may collect ACDs via ACAP PUT/GET from local agents, extract the minimum public discovery information (type, reachability, communication protocol, services) into an FMR, and distribute the FMR in the Federation Plane; the richer capability content of the ACD is not carried in the FMR, consistent with the charter. Cross-domain discovery queries may be answered from valid FAD entries. In Mode A, a cache miss triggers a DNS query for the remote domain, followed by validation and caching of the result; Mode B uses its selected exchange or directory mechanism. A global ACAP query endpoint is not required. Thus, ACAP and this architecture are composable: ACAP handles intra-domain description, while this architecture handles inter-domain federation and export policy.¶
The Agent Directory [I-D.jimenez-agent-directory] adapts the CoRE Resource Directory [RFC9176] to software agents, providing an HTTP/JSON service for registration and lookup with soft-state lifetimes. It defines a well-known URI (/.well-known/ad) and supports capability filtering.¶
This architecture is complementary: the Agent Directory may serve as the Local Discovery Plane mechanism within a site, collecting agent registrations and answering local queries. The FGW may subscribe to the local Agent Directory, extract MDI-compliant records, apply export policy, and generate FMRs for federation. The FAD maintained by the FGW is conceptually a distributed extension of the Agent Directory across administrative boundaries. Federation across multiple Agent Directory instances is acknowledged but not specified in [I-D.jimenez-agent-directory]; this architecture provides one possible federation model.¶
AGNTCY ADS [I-D.mp-agntcy-ads] is a distributed directory using libp2p Kad-DHT for content routing and a hierarchical skill taxonomy. It supports open, Internet-scale discovery, which is outside DAWN's initial scope.¶
This architecture differs in approach: ADS is a global or wide-area distributed hash table, while this architecture is a federated gateway model with explicit per-peer trust and policy control. ADS targets open, Internet-scale discovery, which is excluded by the DAWN charter; this architecture targets closed or semi-closed federations where data sovereignty and per-peer export policy are paramount. A hybrid deployment is possible: an FGW may publish a subset of its FMRs to a trusted directory such as AGNTCY ADS for broader discoverability, while retaining sensitive records for private federation peers only (see trusted directory publication, Section 7.2.3).¶
DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] and DN-ANR [I-D.cui-dns-native-agent-naming-resolution] propose DNS-based mechanisms for agent naming and location resolution. These operate at the DAWN Naming Plane, providing decentralized name-to-location mapping.¶
This architecture treats DNS-based discovery as one valid mechanism for the Local Discovery Plane (e.g., resolving a known partner's domain to locate its FGW or agents). The FGW may itself be advertised via DNS records, and FMRs may contain DNS-based locators. The two approaches are orthogonal and composable.¶
The MDI information model [I-D.cui-dawn-mdi-model] defines an abstract, encoding-neutral common header for discovery responses. This architecture directly adopts MDI as the basis for FMRs: an FMR is a concrete, protocol-specific binding of MDI elements (Entity Identifier, Entity Type, Endpoint, Capability Summary, Freshness, Provenance) for the purpose of cross-gateway exchange. By grounding FMRs in MDI, this architecture ensures that federated metadata can be translated to and from other DAWN discovery formats (ACAP ACDs, Agent Directory records, A2A Agent Cards) without loss of the minimal necessary information.¶
The FMR is a thin, cacheable index by design: Entity Summary and Operational Hint stay with the Capability Card and the Record-Flag/TTL mechanism respectively, and Extension is realized by reserved and unknown TLV types, which recipients MUST ignore. Two FMR fields (Origin-GW-ID, Record-Flag) are binding-level mechanism fields and are not MDI elements. The FMR binding does not relax any MDI constraint: one FMR describes exactly one entity; Entity Identifiers are compared within the publisher scope established by Origin-GW-ID; protocols attach to the Endpoint; and recipients MUST ignore unrecognized extensions. The concrete TLV encoding of the FMR is left to the synchronization protocol specifications that may be developed based on this architecture.¶
This section reviews existing approaches to cross-domain service and agent discovery, and identifies gaps that motivate the proposed two-layer architecture. It extends the gap analysis in [I-D.moussa-dawn-gap-analysis] and [I-D.jimenez-dawn-discovery-landscape].¶
One approach is to deploy a hierarchical, DNS-like or WebFinger-like global registration system. Sites register their agent metadata with regional or global directory servers; requesters query the directory to discover agents.¶
Strengths: Familiar operational model; query latency is controllable; well-understood caching and delegation mechanisms.¶
Gaps: (1) Data sovereignty — sites must submit agent metadata to a third-party directory, which many organizations resist for industrial and enterprise deployments. (2) Trust and governance — operating a global root directory requires a governance body that all participants accept. (3) Single-point-of-failure and scaling concerns at the root level. (4) Granular per-peer access control is difficult in a public query model. These gaps are noted in [I-D.moussa-dawn-gap-analysis] as "no interoperable federation" across administrative boundaries.¶
mDNS/DNS-SD [RFC6762] [RFC6763] provides excellent zero-configuration discovery within a single broadcast domain.¶
Strengths: Zero configuration; widely deployed; no infrastructure required; excellent for local-area networks.¶
Gaps: (1) Link-local multicast does not cross IP routers, so discovery is confined to a single LAN. (2) No built-in mechanism for cross-domain metadata exchange. (3) Large LANs can experience multicast storm issues without a proxy or gateway. This satisfies only the "local context" use case [I-D.kay-dawn-use-cases].¶
In this approach, every gateway establishes direct peering sessions with every other gateway in the federation, exchanging metadata via incremental updates (similar to BGP [RFC4271]).¶
Strengths: Fast convergence; fine-grained per-peer policy control; clear data sovereignty; well-understood operational model from routing protocols.¶
Gaps: (1) Full-mesh configuration becomes operationally expensive at large scale (N-squared peering). (2) Every site must manually configure and maintain peer relationships. (3) Not ideal for loosely-managed, open federations with high member churn.¶
Gossip-based protocols propagate metadata probabilistically among a small set of neighbors, achieving eventual consistency across the federation.¶
Strengths: Excellent horizontal scalability; robust against partial failures; low per-node connection count; self-organizing topology.¶
Gaps: (1) Eventual consistency means convergence delay is unavoidable. (2) Precise per-record distribution policies are difficult to enforce. (3) Malicious participants can rapidly spread forged metadata across the overlay. (4) Security and trust management are more complex than in static peering models.¶
No single existing approach satisfies all requirements simultaneously:¶
Centralized directories fail F-3 (data sovereignty) and F-4 (decentralized federation).¶
Link-local multicast fails F-1 (cross-domain discovery).¶
Full-mesh peering fails NF-5 (scalability) at large federation sizes.¶
Gossip dissemination fails NF-1 (security against forged advertisements) and F-6 (prompt lifecycle invalidation) due to convergence delay.¶
The two-layer federated architecture addresses these gaps by: (1) keeping local discovery zero-configuration and decentralized, without mandating a specific local protocol; (2) introducing a federation gateway layer that enforces data sovereignty via export policy; (3) supporting two top-level federation modes — with DNS delegation between authoritative zones (Mode A) as the preferred realization for inter-organizational interaction, and non-DNS synchronization (Mode B: BGP-like peering, gossip-based dissemination, and trusted directory publication) as alternatives selected according to scale and scenario — so that deployments can select the mode matching their scale and trust model; and (4) exchanging only the minimum public discovery information in FMRs to reduce cross-domain data exposure.¶
As inllustrated in the following figure, the overall architecture consists of two logically separated layers: the Local Discovery Plane (Layer 1) and the Federation Plane (Layer 2). Traffic and control logic between the two layers are decoupled. The Federation Gateway (FGW) is the only component that spans both layers.¶
Domain A Domain B
+----------------------+ +----------------------+
| Agents / AI resources| | Agents / AI resources|
+----------------------+ +----------------------+
| | | |
v v v v
+---------+ +----------+ +---------+ +----------+
|LAN-based| |Infra- | |LAN-based| |Infra- |
|discovery| |assisted | |discovery| |assisted |
| | |discovery | | | |discovery |
+---------+ +----------+ +---------+ +----------+
| | | |
+-----+-----+ +-----+-----+
| |
v v
+----------------------+ +----------------------+
| Federation Gateway A | | Federation Gateway B |
| | | |
| Export Policy Engine | | Export Policy Engine |
| | | | | |
| v | | v |
| Construct local FMRs | | Construct local FMRs |
| | | |
| FAD | | FAD |
| A: DNS cache | | A: DNS cache |
| B: remote FMRs | | B: remote FMRs |
+----------------------+ +----------------------+
| |
| Layer 1: Local Discovery Plane |
-----------|--------------------------------|------------
| Layer 2: Federation Plane |
v v
+--------------------------------------------------------+
| Mode A: authoritative DNS publication |
| Request -> cache miss -> DNS query -> validate -> cache|
| |
| Mode B: peering / gossip / directory |
| Obtain FMRs -> validate -> store accepted records |
+--------------------------------------------------------+
Local discovery modes may coexist.
DNS services may be separate from FGWs.
Agent data traffic uses the discovered endpoints.
FGWs need not forward agent data traffic.
The first layer runs inside each independent local site (LAN, tenant namespace, or edge cluster). Its responsibilities are agent advertisement, local metadata collection, and export policy enforcement.¶
When an agent becomes available, its lightweight discovery information MAY be collected and maintained through two complementary modes within the Local Discovery Plane:¶
LAN-Based Discovery: In a local network, an agent MAY advertise its lightweight discovery information after startup through a site-local discovery mechanism, such as link-local multicast mDNS/DNS-SD (e.g., service type "_agent._tcp.local"). An authorized entity, such as an agent orchestration system or local gateway, MAY advertise this information on the agent's behalf. Other agents and local discovery components can obtain the advertised information through the same mechanism without requiring a preconfigured discovery server. Alternative mechanisms MAY also be used, including local API registration with an Agent Directory [I-D.jimenez-agent-directory], edge‑platform‑driven discovery (e.g., Kubernetes service discovery), or registration through ACAP [I-D.zahed-acap]. The architecture supports advertisement by either the agent or an authorized entity and does not mandate a specific local discovery protocol.¶
Infrastructure-Assisted Discovery: This mode is primarily intended for organization-level agent discovery within managed enterprise, cloud, or edge environments. Authorized deployment infrastructure, such as an orchestration, placement, hosting, or management system, MAY act as a local infrastructure gateway. It collects and maintains agent discovery information based on its knowledge of current deployments, including available agent services or instances, their reachable endpoints, and communication protocols. When the infrastructure gateway is implemented separately from the FGW, it advertises the collected information to the FGW and provides updates or withdrawals as deployment state changes. When integrated with the FGW, the FGW primarily obtains this information from registration records maintained within the managed infrastructure. This infrastructure-driven publication uses the Resource Publication Hook described in [I-D.dunbar-dawn-infra-assisted-discovery] and does not require agents to advertise themselves through multicast.¶
Both modes provide lightweight discovery information to the Local Discovery Plane and MAY coexist within the same administrative domain. An infrastructure gateway performs local collection and registration functions and MAY be implemented separately from, or integrated with, the Federation Gateway (FGW). When implemented separately, the local infrastructure gateway advertises the collected agent discovery information to the FGW through a discovery mechanism and provides updates as deployment state changes. When integrated, the FGW obtains this information internally. In either deployment, the FGW obtains the locally collected discovery information and applies export policies before making it available through the Federation Plane. The architecture does not mandate either mode or a specific local discovery protocol.¶
Advertised records carry the minimum public discovery information (Entity Identifier, Entity Type, reachability/locator, communication protocol, services). No capability information beyond this minimum is transmitted via multicast or local broadcast packets.¶
Local peers (other agents) may discover and communicate directly within the site. The FGW is NOT required to forward agent data traffic; it only collects discovery metadata.¶
The FGW collects agent discovery information through LAN-based discovery, infrastructure-assisted discovery, or both. In LAN-based discovery, the FGW MAY listen to local mDNS/DNS-SD advertisements, subscribe to an Agent Directory, or retrieve information through ACAP. In infrastructure-assisted discovery, primarily used for organization-level agent discovery, the FGW receives agent discovery information advertised by a separate local infrastructure gateway or, when integrated with that gateway, primarily obtains the information from registration records maintained within the managed infrastructure. Advertisements and registration records are updated or withdrawn as deployment state changes.¶
The Export Policy Engine on the FGW applies local sharing policy: it filters which agents may be advertised externally, redacts sensitive fields, and generates federation-ready FMRs before exporting them to remote federation peers. Different peers may receive different subsets of FMRs.¶
Federation Gateways from separate administrative domains compose a federation control plane. Agent business data plane traffic does NOT flow through federation gateways by default. The Federation Plane is preferably realized over DNS (Mode A, DNS Delegation Model): each FGW publishes FMRs as resource records in its own authoritative zone, and validating resolvers query and verify peer zones, with delegation and referral between authoritative zones providing the primary inter-organizational interaction. Alternatively, the Federation Plane MAY be realized over non-DNS synchronization modes (Mode B) — BGP-like structured peering, gossip-based epidemic dissemination, or trusted directory publication — selected according to federation scale and scenario, or a combination of both.¶
Each FGW publishes or exchanges only sanitized FMRs permitted by its export policy. In Mode A, publication makes records available in the originating domain's authoritative DNS zone; it does not push those records into remote FADs. Access-controlled Mode B exchanges apply the export view authorized for each recipient.¶
When an agent's discovery information changes, its FGW updates or removes the corresponding authoritative DNS records in Mode A. Remote FADs are not proactively synchronized with these changes; subsequent request-driven DNS retrieval obtains the current information after cached data expires. In Mode B, changes propagate through the selected synchronization or directory mechanism (see Appendix A).¶
In Mode A, an FGW does not maintain a complete local copy of remote agent metadata by default. Its FAD contains remote records previously retrieved in response to discovery requests and retained within their permitted cache lifetimes. In Mode B, the FAD contains the accepted subset delivered or retrieved through the selected mechanism.¶
When a client requests cross-domain agent information, the local FGW first checks for a valid matching FAD cache entry. In Mode A, if no such entry exists, the FGW uses a validating resolver to query the authoritative DNS service for the remote FGW's domain, using a discovery name supplied by the request or obtained through a defined naming or referral mechanism. It validates the response, applies import policy, caches accepted discovery information in the FAD, and returns the result to the client. Later requests MAY reuse that entry until it expires. In Mode B, the FGW uses records obtained through the selected mechanism. Returned referrals MAY continue discovery at another catalog or endpoint.¶
Federation membership can be dynamically adjusted: FGWs may join or leave the federation according to trust agreements.¶
Federation connects independently administered discovery domains while each domain controls the information it publishes. The originating FGW applies export policy and makes permitted FMRs available; the requesting FGW retrieves or receives eligible records according to the selected mode and applies validation and import policy. Publication in one domain does not by itself create a record in another domain's FAD.¶
In Mode A, the originating domain's authoritative DNS service holds the published agent discovery information. Remote records are not synchronized into other FGWs' FADs by default. The FAD serves as a request-driven cache rather than a replica of remote DNS zones.¶
In Mode B, remote records may instead enter the FAD through structured peering, gossip, or directory retrieval and subscriptions. Each FAD contains the records available and acceptable to its local domain; no mode requires identical FAD contents throughout the federation. Once discovery supplies a reachable endpoint, agent communication proceeds independently of the discovery metadata path.¶
The originating domain is responsible for the discovery information describing its local agents. Its FGW obtains that information through LAN-based or infrastructure-assisted discovery and applies export policy before constructing FMRs for external publication. The federation process operates on these FMRs independently of the local collection mechanism.¶
The receiving domain decides which external sources and records it accepts. Its FGW validates obtained FMRs and applies local import policy before making them available through its FAD. A federation relationship therefore combines the originating domain's permission to disclose information with the receiving domain's permission to accept and use that information.¶
Participating domains establish the identities, trust anchors, authorization rules, and disclosure scope applicable to their chosen federation mechanism. Discovering a remote FGW endpoint does not itself grant federation membership or permission to retrieve restricted metadata. Similarly, accepting an FMR does not authorize access to the agent it describes; agent access remains subject to the resource owner's policy.¶
The common federation workflow consists of the following steps:¶
Establish discovery and trust context: Participating domains configure or discover the authoritative discovery zones, FGW endpoints, or directory services applicable to the selected federation mechanism and establish the required trust and authorization policies. In Mode A, this establishes how to locate and validate remote DNS records; it does not require retrieving those records or populating the FAD in advance.¶
Construct an export view: The originating FGW applies its Export Policy Engine to local discovery information, selects the resources and fields permitted for disclosure, and constructs sanitized FMRs. Different peers or publication audiences MAY receive different subsets of records. Information published through public DNS is limited to the subset approved for public disclosure.¶
Publish or exchange FMRs: In Mode A, the originating FGW publishes the selected discovery records in its domain's authoritative DNS zone. Publication makes the information available for subsequent queries but does not push it into remote FADs. In Mode B, FMRs are distributed or made available through structured peering, gossip-based dissemination, or trusted directory publication.¶
Receive a discovery request and check the FAD: When a user requests cross-domain agent discovery information, the local FGW checks its FAD for a valid matching record. If such a record exists and satisfies local policy, the FGW MAY answer from that record. In Mode A, a cache miss or an expired entry triggers retrieval from the remote domain's authoritative DNS service, using a discovery name supplied by the request or obtained through a defined naming or referral mechanism.¶
Retrieve, validate, and cache remote information: On a Mode A cache miss, the requesting FGW uses a validating resolver to query the authoritative DNS service for the remote FGW's domain. It validates the response using DNSSEC, applies local import policy, and caches accepted discovery information in its FAD with its provenance and expiration information. The cache lifetime does not exceed the remaining DNS TTL or any shorter applicable validity limit. In Mode B, the receiving FGW validates records obtained through the selected mechanism before accepting them into its FAD. When records are relayed through an intermediary, validation also considers the authority of the original publisher.¶
Return the discovery result: The FGW returns the validated discovery information to the requester. A result provides the minimum public information needed to reach an agent or continue discovery through another endpoint. Subsequent requests MAY reuse a valid matching FAD entry without repeating the remote DNS query. Cache hits do not restart the entry's validity period.¶
Maintain record lifecycle: Changes in agent availability, reachable endpoints, or export policy cause the originating FGW to update or remove its published records. In Mode A, these changes do not proactively synchronize remote FADs or immediately invalidate existing cached copies. Cached entries cease to be usable when their permitted lifetime expires, and a subsequent request triggers fresh DNS retrieval. In Mode B, updates and withdrawals are processed according to the selected mechanism. Cached or relayed copies do not extend the applicable validity period.¶
In the preferred DNS Delegation Model (Mode A), each administrative domain publishes its permitted agent discovery information in its own authoritative DNS zone. Publication makes the records available for remote queries but does not automatically populate other FGWs' FADs. Remote discovery information is retrieved on demand when a cross-domain discovery request cannot be answered from a valid matching FAD cache entry. This model does not require persistent FGW-to-FGW sessions or continuous replication of records between domains.¶
For example, Domain A's FGW constructs an FMR for a local agent and publishes the corresponding discovery records in Domain A's authoritative zone. When a user in Domain B requests information about that agent, Domain B's FGW first checks its FAD for a valid matching cached entry. If one exists and satisfies local policy, the FGW MAY return it directly. Otherwise, the FGW uses a validating resolver to query Domain A's authoritative DNS service, validates the response using DNSSEC [RFC4035], applies local import policy, caches the accepted discovery information in its FAD, and returns the result to the requester. The authoritative DNS service MAY be operated separately from Domain A's FGW.¶
The requesting FGW uses a discovery name supplied by the request or obtained through a defined bootstrap, naming, or referral mechanism. DNS delegation locates the authoritative source for that name; it does not itself enumerate all agents or perform arbitrary searches over agent properties. Where detailed discovery information requires access control, DNS MAY publish only a bootstrap pointer to an FGW discovery endpoint. The requesting FGW then retrieves FMRs from that endpoint under the applicable authentication and authorization policies; validating the DNS pointer alone does not validate the subsequently retrieved FMRs.¶
For discovery information retrieved directly through DNS, the FAD cache lifetime does not exceed the remaining DNS TTL or any shorter applicable validity limit. Subsequent requests MAY reuse a valid matching entry, but cache hits do not restart its lifetime. Once the entry expires, it is no longer used to answer discovery requests, and a subsequent request triggers fresh DNS retrieval.¶
When Domain A changes or removes its published records, it updates its authoritative DNS zone. These changes do not proactively synchronize Domain B's FAD or immediately invalidate previously cached information. Domain B obtains the current published state through subsequent DNS retrieval after its cached information expires. DNSSEC protects the origin and integrity of DNS data; federation authorization and access to the discovered agent remain separate policy decisions. Further considerations are provided in Appendix A.1.¶
In Mode A, the originating FGW or an authorized infrastructure controller maintains the authoritative DNS records representing its exported agent discovery information. Publication updates are triggered by changes in agent availability, reachable endpoints, communication protocols, or export policy. These updates modify the authoritative publication state; they do not proactively synchronize remote FADs.¶
For infrastructure-assisted discovery, changes are obtained from infrastructure registration records when the infrastructure gateway is integrated with the FGW, or communicated to the FGW by a separate infrastructure gateway. The FGW applies export policy before adding, replacing, or removing the corresponding DNS records.¶
Authoritative records MAY be maintained through authenticated DNS UPDATE [RFC2136] or an authorized DNS management interface. The FGW need not operate the authoritative DNS server itself. The selected mechanism authenticates the updating component and restricts its authority to the records it is permitted to manage. Concrete update interfaces and authentication procedures are outside the scope of this document.¶
When an agent becomes unavailable or is no longer permitted to be exported, the responsible publisher removes or updates its authoritative records. Related records and references are reconciled to avoid leaving obsolete discovery paths. An authorized controller SHOULD also reconcile published information with current deployment state after failures or missed events.¶
Updating or removing authoritative records does not immediately invalidate information already cached by recursive resolvers or remote FADs. Those copies remain subject to their previously established expiration times. On a subsequent discovery request without a valid matching cache entry, the requesting FGW performs DNS resolution, validates the response, and caches the accepted result. An intermediate resolver may still return an earlier cached response within its remaining TTL.¶
DNS TTL controls cache lifetime rather than authoritative record lifetime. An authoritative record remains published until it is changed or removed, unless the deployment provides a separate publication-expiration mechanism. Periodic publication reconciliation therefore serves a different purpose from TTL-based aging in remote FADs.¶
In the Non-DNS Synchronization Modes (Mode B), FGWs distribute FMRs through an exchange or publication mechanism selected for the federation's operational requirements. These mechanisms support different dissemination patterns while retaining the same resource ownership, export-policy, import-policy, and record-validation principles.¶
Structured peering: Authorized FGWs establish authenticated sessions. Each sender supplies an initial set of records permitted for the receiving peer, followed by incremental additions, updates, and withdrawals. The receiving FGW validates the records and maintains the accepted subset in its FAD. This mechanism supports direct per-peer disclosure control.¶
Gossip-based dissemination: Authorized neighboring FGWs compare record summaries and exchange missing or newer records. Repeated exchanges and reconciliation spread permitted information across the federation. FADs converge over time within the applicable disclosure scope; they need not contain identical records or converge immediately.¶
Trusted directory publication: An originating FGW registers a policy-filtered subset of FMRs with an authorized directory and maintains those registrations as local state changes. Remote FGWs query or subscribe to the directory, validate the returned information, and import eligible records into their FADs.¶
For example, Domain A's FGW exports an agent's FMR through the selected mechanism. Domain B's FGW receives or retrieves the record, validates its provenance and validity, and stores it in its FAD. Subsequent discovery requests in Domain B can use that record without repeating the original local discovery process in Domain A. Updates and withdrawals propagate through the same mechanism, subject to its delivery and consistency properties. Detailed considerations are provided in Appendix A.2.¶
Each FAD represents the discovery information currently available and acceptable to its local domain, rather than a complete replica of all agent information in the federation. Its contents depend on local storage choices, export and import policies, the selected federation mechanisms, previous discovery requests, and record validity.¶
In Mode A, remote agent discovery information is not pre-populated in the FAD by default. The FAD serves as an on-demand cache: when a cross-domain request has no valid matching cached entry, the FGW retrieves the relevant information from the remote domain's authoritative DNS service, validates it, and caches the accepted result. Later requests MAY reuse that entry within its permitted lifetime. Expired entries are no longer eligible for discovery responses, and cache hits do not extend their validity.¶
In Mode B, the FAD MAY contain accepted remote FMRs obtained through proactive synchronization, directory retrieval, or subscriptions, according to the selected mechanism. Locally originated FMRs MAY be maintained within the FAD or in a separate local store. A deployment MAY combine Mode A and Mode B while retaining the provenance and validity information needed to manage records obtained through each mechanism.¶
Once discovery provides a suitable agent endpoint, the requester communicates with that agent using the indicated communication protocol and the agent's access-control requirements. The FGWs support discovery and metadata federation; they are not required to forward agent business data traffic.¶
The architecture MAY use the Attachment Context Hook described in [I-D.dunbar-dawn-infra-assisted-discovery] to obtain the requester's current Attachment Scope from trusted network infrastructure. This scope represents the network attachment or reachability context applicable to the requester and complements the agent deployment and endpoint information supplied through the Resource Publication Hook.¶
The FGW or an associated discovery service MAY use this context to identify applicable discovery domains or reachable agent endpoints. Published information may identify a stable logical service endpoint or an individually reachable agent instance. Where further resolution is needed, attachment context and current deployment information can support resolution to an agent endpoint reachable from the requester's network context, subject to deployment policy.¶
The resulting endpoint information MAY support a subsequent load-balancing or instance-selection function. Attachment context provides network applicability information; load measurements and other selection inputs, where required, are supplied by separate infrastructure mechanisms. This framework does not define load-balancing algorithms, instance-ranking policies, backend address mapping, or the detailed procedures for resolving a logical service endpoint to a runtime instance.¶
In Mode A, context-dependent discovery results cached in the FAD are reused only for requests to which the same applicability conditions apply and within their permitted validity period. A change in the requester's attachment context may require a new discovery lookup even when an earlier cached record has not expired. The representation, acquisition, exchange, and cache partitioning of attachment context are outside the scope of this document.¶
The complete discovery data flow proceeds as follows:¶
An agent starts up in Site A and advertises itself via a site-local mechanism (e.g., mDNS on the local LAN, or registration with a local Agent Directory).¶
The FGW in Site A collects the advertisement, validates it, and passes it to the Export Policy Engine.¶
The Export Policy Engine determines that this agent may be shared with federation peers, redacts any sensitive fields, and produces an FMR binding the agent's MDI elements.¶
The FGW in Site A publishes the FMR as a resource record in Site A's authoritative zone (Mode A) or propagates it to its federation peers, including the FGW in Site B, using the selected Mode B mechanism (e.g., BGP-like peering sessions, gossip exchange, or directory registration).¶
A client in Site B requests discovery information for an agent in Site A. Site B's FGW checks its FAD for a valid matching record. In Mode A, Site A's publication alone has not populated Site B's FAD; a cache miss triggers DNS retrieval. In Mode B, a suitable record may already have arrived through the selected mechanism.¶
On a Mode A cache miss, Site B's FGW queries Site A's authoritative DNS service through its validating resolver, validates the returned discovery records using DNSSEC and local import policy, and caches the accepted information in its FAD for no longer than the remaining DNS TTL or any shorter applicable validity limit. The FGW returns the information to the client. If a valid cache entry already exists, it MAY answer directly from that entry.¶
Discovery concludes once the client obtains the minimum public discovery information in the FMR. If the FMR contains a referral (e.g., to a catalog or another discovery endpoint), the client may follow it to continue discovery; any communication beyond this initial discovery process is outside the scope of this architecture.¶
When multiple candidate records are returned, this architecture exposes them but keeps ranking and selection logic outside its scope, consistent with the DAWN charter's exclusion of ranking and selection based on capabilities or user intent. The final choice among candidates is made by the consuming application or end-user.¶
Local Agent Discovery Module (on FGW): Captures local agent advertisements via passive mDNS listening, Agent Directory subscription, or other local mechanisms; maintains the site-local agent table.¶
Export Policy Engine (on FGW): Executes data filtering, privacy redaction, and per-peer export access policy. This is the core data sovereignty mechanism.¶
Federation Control Module (on FGW): Implements the selected Mode B synchronization mechanism (managing BGP-like peering sessions, gossip exchanges, or directory registration), transmits incremental metadata updates, receives records from federation peers, and maintains the FAD.¶
DNS Publication and Validation Service (on FGW): Publishes policy-filtered local FMRs in the site's authoritative DNS zone. For Mode A cross-domain requests without a valid matching FAD entry, retrieves records from the remote domain's authoritative DNS service through a validating resolver, validates them with DNSSEC, and caches accepted results in the FAD. The authoritative service MAY be operated separately from the FGW.¶
Discovery and Referral Response Service (on FGW): Checks the FAD for valid matching records and answers discovery requests. In Mode A, a cache miss or expired entry triggers request-driven DNS retrieval and validation before caching and returning the result. The service also handles referrals to catalogs or other discovery endpoints.¶
Metadata Integrity Module (on FGW): Signs outgoing FMRs and verifies signatures on incoming FMRs, providing origin authentication and integrity protection.¶
FAD Aging Module (on FGW): Expires records according to their applicable validity rules. For Mode A DNS-derived entries, the cache lifetime does not exceed the remaining DNS TTL or any shorter applicable validity limit. Cache hits do not restart that lifetime; an expired entry requires fresh retrieval on a subsequent request.¶
The two-layer architecture supports two top-level modes for inter-organizational interaction. Mode A (DNS Delegation Model) is the preferred realization for the cooperating-parties context: each site publishes its FMRs as resource records in its own authoritative zone, and peer sites' validating resolvers query those zones directly. When Mode A does not meet operational requirements, Mode B provides non-DNS alternatives whose selection depends on the number and scale of participating organizations and on the deployment scenario: BGP-like structured peering for closed trusted federations, gossip-based epidemic dissemination for large-scale loose federations, and trusted directory publication when discoverability beyond the immediate federation is required. Detailed protocol considerations for all modes are provided in Appendix A.¶
Mode A is the preferred mode for inter-organizational information interaction. It applies across the cooperating-parties context: each site publishes its policy-filtered FMRs as resource records in its own authoritative zone, and other sites' validating resolvers query those zones directly, with delegation and referral between authoritative zones providing the discovery path. Participants remain independent: membership changes do not require reconfiguration of peering sessions, because discovery follows the DNS hierarchy rather than a pre-established session graph.¶
Recommended synchronization: DNS delegation between authoritative zones. Each site publishes its FMRs as resource records in its own authoritative zone, and the other sites' validating resolvers query those zones directly, with delegation and referral between authoritative zones providing the inter-organizational interaction for the cooperating-parties context. This mode reuses existing DNS infrastructure, requires no persistent gateway-to-gateway sessions, and obtains origin authentication and integrity for the published records from DNSSEC. See Appendix A.1.¶
Rationale: Mode A builds on mature, standardized DNS infrastructure and DNSSEC integrity, scales without per-site peering configuration, and lets each site publish its discovery information independently while retaining full export-policy control. It composes with the DAWN DNS-based naming proposals and is the natural default for inter-organizational interaction.¶
Scale range: Suitable from small federations of a few sites to large federations, scaling naturally through the DNS hierarchy.¶
Mode B is the alternative to Mode A when the DNS delegation model does not meet operational requirements, for example when sites require push-based, near-real-time propagation, per-peer export policy that cannot be expressed through zone publication, operation in networks without a usable DNS hierarchy, or discoverability beyond the immediate federation. Mode B offers three synchronization mechanisms; the appropriate choice depends on the number and scale of participating organizations and on the deployment scenario.¶
BGP-like structured peering is suited to medium-scale, tightly-managed federations such as industrial compute consortiums, multi-site enterprise AI deployments, and operator-managed edge-agent networks. Participants are known and pre-authenticated; membership changes infrequently.¶
Recommended synchronization: Structured peer-to-peer incremental unicast synchronization (full-mesh or partial-mesh peering), with delegation or referral between discovery domains where needed. See Appendix A.3.¶
Rationale: Persistent, low-latency peering with fine-grained per-peer sharing policy and fast convergence; the mesh operational overhead is acceptable for medium-scale federations.¶
Scale range: Approximately 2 to 200 sites.¶
Gossip-based epidemic dissemination applies to large, loosely-managed federations with high member churn, such as open edge-computing networks or cross-industry AI agent marketplaces. Participants may join and leave frequently; mesh manual configuration is impractical.¶
Recommended synchronization: Gossip-based epidemic dissemination, with a bounded neighbor set and periodic anti-entropy synchronization. See Appendix A.4.¶
Rationale: Excellent horizontal scalability, robust against partial failures, and self-organizing topology that minimizes per-node configuration. Convergence delay is acceptable for use cases that do not require instant global consistency.¶
Scale range: Hundreds to thousands of sites.¶
Note: Due to the security challenges of gossip dissemination, this mechanism is RECOMMENDED for experimental or controlled deployments rather than as a mandatory standards-track protocol.¶
Trusted directory publication applies to deployments where agents must be discoverable by parties outside the immediate peer federation, within the limits set by operator policy and the DAWN charter (which excludes AI resource indexing across the wider Internet). Pure peer federation may not provide sufficient discoverability for requesters outside the federation.¶
Recommended approach: Hybrid deployment. The FGW participates in a peer federation for trusted partners, AND optionally publishes a subset of sanitized FMRs to a trusted or semi-public directory service (e.g., AGNTCY ADS [I-D.mp-agntcy-ads]) or to a DNS-based registration/aggregation system, operated under explicit trust relationships. In the preferred DNS realization (Mode A), the FGW publishes the subset in its own authoritative zone, or registers it with a trusted aggregator that mirrors the records.¶
Rationale: Combines the data sovereignty and trust benefits of peer federation with the broad discoverability of public directories. The Export Policy Engine controls which records are published to the public directory versus retained for federation peers only.¶
Note: The architecture does not mandate a specific public directory protocol. Existing or future registration protocols may be used. A DNS-based directory is a natural realization: the FGW publishes sanitized FMRs in its own zone or registers them with a trusted aggregator, and DNSSEC provides integrity for the published records. Publishing to a directory is a dissemination endpoint, not a trust anchor: it does not relax federation admission control, and directory publication remains governed by the Export Policy Engine.¶
Mixed-mode federation combines the bootstrap and integrity properties of Mode A with the data-exchange characteristics of Mode B. A common and recommended pattern is a two-phase deployment:¶
Phase 1 -- Bootstrap and endpoint discovery (DNS as a pointer): DNS is used solely as a bootstrap pointer to advertise the location of each site's federation gateway discovery directory endpoint. Detailed agent discovery records are not published in the public DNS; instead, each site's zone carries only pointer records (e.g., SRV or NAPTR-style records) that let a peer site's validating resolver locate the target FGW or directory endpoint, verified with DNSSEC. This phase reuses the Mode A infrastructure in its restricted, pointer-only form (see Section 8.3 for the access-control rationale).¶
Phase 2 -- Metadata exchange (Mode B by scale): Once each federation gateway has learned the directory endpoints of its peers, the federation exchanges FMRs using the selected Mode B mechanism, chosen according to the number and scale of participating organizations: BGP-like structured peering (Section 7.2.1) for closed trusted federations, gossip-based epidemic dissemination (Section 7.2.2) for large-scale loose federations, or trusted directory publication (Section 7.2.3) when discoverability beyond the immediate federation is required. Peer gateways retrieve agent metadata from the discovery directory endpoint behind the local gateway, where authorization and identity validation are enforced according to pre-established trust policies (Section 8.3).¶
This two-phase pattern keeps detailed discovery records under the originating site's access control while still using DNS for the initial context that DAWN requires. Deployments that prefer maximum interoperability and public discoverability may instead use Mode A in its full form, publishing FMRs directly as resource records (Appendix A.1); the choice between the two is an operator decision driven by the required level of access control and data sovereignty.¶
The architecture also permits different subsets of an overall federation to adopt different mechanisms concurrently - for example, a core group of trusted operators using BGP-like structured peering among themselves while peripheral participants use gossip. In all cases the FMR metadata format is shared across modes, ensuring that records are interoperable regardless of how they are transported.¶
Security is a primary concern in cross-domain agent discovery. A malicious or compromised federation gateway could inject forged agent advertisements, causing requesters to connect to rogue agents. This section defines a layered security model for the architecture. It aligns with the DAWN security considerations and the authentication framework in [I-D.klrc-aiagent-auth].¶
All federation control traffic between FGWs MUST be protected by authenticated encrypted transport. TLS 1.3 [RFC8446] with mutual X.509 certificate authentication [RFC5280] is the RECOMMENDED mechanism. Plaintext metadata exchange over public networks MUST NOT be used.¶
Mutual authentication ensures that each FGW can verify the identity of its federation peers. A federation may use its own certificate authority (CA) or a web-of-trust model; the architecture does not mandate a global root CA. This aligns with DAWN's position that no global root trust authority is required [CSA-DAWN-Note].¶
Transport security alone protects messages in transit but does not prevent a compromised peer from forging FMRs that claim to originate from another gateway. The architecture therefore requires that each FMR carry an origin authentication and integrity mechanism.¶
Each outgoing FMR MUST be signed by the originating FGW using its private key. The signature covers the FMR content (Entity Identifier, Origin-GW-ID, timestamp, type/services, TTL, and other mandatory fields).¶
Each receiving FGW MUST verify the FMR signature against the originating gateway's public key before accepting the record into its FAD.¶
FMRs that fail signature verification MUST be discarded and MUST NOT be propagated further.¶
The specific signature algorithm and key management mechanism are deferred to normative protocol documents. The architecture requires the capability but does not mandate a particular algorithm. JWS [RFC7515] as used in ACAP [I-D.zahed-acap] is a candidate mechanism.¶
This mechanism ensures that even if a malicious gateway joins the federation, it cannot forge FMRs on behalf of other gateways. It can still forge its own local agent records, which is an inherent trust-boundary issue addressed by federation admission control (see Section 8.4).¶
In the preferred DNS realization (Mode A), DNSSEC [RFC4035] provides origin authentication and integrity for the published resource records (FMR records or, in the pointer-only form, bootstrap records advertising the FGW or discovery directory endpoint), and DANE [RFC6698] MAY be used to authenticate the endpoints that a record references. In the Mode B realizations (BGP-like peering, gossip, or directory publication), FMR signing provides the same protection over the corresponding interfaces. FMR signing and DNSSEC may be combined for defense in depth; either mechanism alone satisfies the integrity requirement (F-9) for the records it covers.¶
Because FMRs may carry information that an organization does not wish to expose uniformly, the architecture requires that the export and serving of discovery information be access-controlled. This is realized primarily by the Export Policy Engine at the source FGW and by per-peer policy at each federation boundary.¶
The Export Policy Engine controls which minimum public discovery information leaves the site and to which peers, preserving data sovereignty (F-3).¶
Referrals in FMRs point back to the originating FGW rather than directly to a resource's internal address, preserving internal topology privacy.¶
Discovery responses at an FGW MUST be served only to authenticated federation peers; the FGW MAY apply per-peer policies, serving different subsets of records to different parties, or rejecting requests from unauthorized parties entirely.¶
To control which federation gateways can obtain discovery information, the deployment choice depends on whether the operator can enforce a DNS access-control mechanism:¶
Without a DNS access-control mechanism: DNS MAY be used solely as a bootstrap pointer to advertise the location of the federation gateway or its discovery directory endpoint. Detailed agent discovery records (FMRs) SHALL NOT be published directly in the public DNS; instead, peer federation gateways retrieve agent metadata from the discovery directory endpoint behind the local gateway, where authorization and identity validation are enforced according to pre-established trust policies between administrative domains. This confines the exposure of detailed records to authenticated peers while still providing a standard, cacheable, and DNSSEC-verifiable bootstrap path.¶
With a DNS access-control mechanism: Detailed agent discovery records MAY be published directly in DNS, which is also a realization of Mode A, provided that access control is enforced at the authoritative servers. A deployment option suitable for enterprise or closed federations is split-horizon DNS or private subdomain zones to restrict the visibility of discovery records: authoritative DNS servers return valid records only to queries originating from pre-registered trusted resolvers or gateway prefixes, while returning NXDOMAIN or REFUSED responses for other requesters. This option is typically easier to operate for smaller enterprises and closed groups, but it has scaling limitations and relies primarily on source-IP-based access control unless augmented by DNS over TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC8484] with mutual client certificate authentication.¶
The architecture's trust boundary is the federation membership. A gateway that is admitted to the federation is trusted to accurately report its local agents (though FMR signing prevents it from forging other gateways' records).¶
Federation admission is governed by out-of-band administrative policy, not by the protocol itself.¶
Operators SHOULD carefully vet new gateway participants before admitting them to a federation, particularly in closed trusted federations using BGP-like structured peering (Section 7.2.1).¶
In gossip-based federations (Section 7.2.2), the larger and more open the participant set, the higher the risk of malicious participants. Operators SHOULD consider additional reputation or rate-limiting mechanisms.¶
Rate limiting MUST be applied to incoming federation control messages per peer. An FGW SHOULD implement a maximum message rate and disconnect peers that exceed it.¶
The FAD database size MUST be bounded. An FGW SHOULD implement a maximum number of FMRs per origin gateway and reject excess entries.¶
TLS handshake rate limiting protects against connection-flood attacks.¶
The hold timer and keepalive mechanism (in peering protocols) or neighbor timeout (in gossip protocols) detect dead peers and free resources.¶
When a network partition occurs, FGWs on each side lose connectivity to peers on the other side. The architecture handles this as follows:¶
Previously accepted remote FMRs, including Mode A records cached after a discovery request, remain eligible in the local FAD only until their permitted validity expires. This prevents transient partitions from causing mass agent disappearance.¶
When connectivity is restored, a full resynchronization (in peering protocols) or anti-entropy exchange (in gossip protocols) reconciles the two sides.¶
Operators SHOULD set TTL values that balance prompt stale-record removal against tolerance for transient partitions. A TTL of 300 seconds (5 minutes) is RECOMMENDED as a default.¶
An agent or FGW may stop unexpectedly without completing graceful withdrawal. The architecture distinguishes resource failure, discovery-component failure, and temporary loss of connectivity; none of these conditions is inferred solely from a failed federation session or an unexpired discovery record.¶
Unexpected agent failure: Authorized deployment or management infrastructure detects the change and updates or withdraws the agent's registration and corresponding published information. In Mode A, previously cached DNS results may remain usable until expiration even after authoritative records are removed. A requester may therefore encounter an unreachable endpoint during this interval. Endpoint retry, failover, and load-balancing behavior are outside the scope of this document.¶
FGW failure with independent DNS service: Published DNS records may remain retrievable while the originating FGW is unavailable. Remote FGWs can continue request-driven DNS retrieval if the authoritative service remains reachable and the records remain valid. An authorized controller or replacement FGW is needed to maintain publication accuracy as agent state changes; DNS availability alone does not establish that the published agent information is current.¶
Failure of the authoritative DNS service: A requesting FGW MAY answer from a valid matching FAD entry within its permitted lifetime. When no such entry exists, it cannot complete discovery through that DNS source and reports a temporary discovery failure or uses another authorized discovery path. Failure to retrieve a record does not by itself prove that the agent has stopped.¶
Failure of a separate local infrastructure gateway: The FGW may stop receiving deployment updates while previously collected information remains present. An authorized monitoring or reconciliation mechanism determines whether that information can still be treated as current and updates or withdraws publications when necessary. Detailed health-check and registration-lease mechanisms are deployment-specific.¶
Mode B session failure: Loss of a peer session or directory connection does not by itself mean that every represented agent is unavailable. Previously accepted records remain subject to their validity and the selected protocol's failure-handling rules. Expiration, explicit withdrawal, and reconnection reconciliation determine subsequent FAD state.¶
Recovery: A recovered or replacement FGW reconciles local discovery and infrastructure registration state with actual deployments before restoring publication. In Mode A, it repairs authoritative DNS records without requiring unsolicited population of remote FADs; remote FGWs obtain the current records through subsequent request-driven lookups. In Mode B, it reconciles records and withdrawal state through the selected synchronization mechanism while preserving origin authority and replay protection.¶
Attachment context and current resource information MAY assist identification of alternative applicable endpoints after a failure. Detailed failure detection, backend address resolution, instance selection, traffic failover, and load-balancing algorithms are outside the scope of this framework.¶
Planned shutdown distinguishes withdrawal of an agent from shutdown of an FGW. Agent withdrawal changes the availability of a discoverable resource. FGW shutdown affects discovery publication or federation functions but does not necessarily make the agents represented by that FGW unavailable.¶
Before an agent is shut down, the responsible agent management or deployment infrastructure SHOULD notify the local discovery component and withdraw or update the agent's registration. A separate local infrastructure gateway communicates the corresponding change to the FGW; an integrated FGW obtains it from the infrastructure's registration records. The FGW then updates the affected FMRs and their publication state.¶
In Mode A, the FGW or an authorized publication controller removes or updates the affected authoritative DNS records. This action prevents subsequent authoritative queries from returning the withdrawn information, but it does not immediately invalidate copies already held by recursive resolvers or remote FADs. Those copies remain subject to their previously established expiration times. Lowering the authoritative TTL at shutdown does not shorten the lifetime of copies already cached.¶
For a planned agent shutdown, an operator MAY lower the TTL sufficiently far in advance, allow the previous larger cache lifetimes to elapse, withdraw the affected records, and allow the remaining cache lifetimes to expire before stopping the agent. Where supported, the service MAY drain existing interactions separately from discovery withdrawal. The detailed shutdown and draining procedures are deployment-specific.¶
Before an FGW is shut down, its publication and federation responsibilities SHOULD be transferred to a replacement component or explicitly discontinued. If agents remain available and their authoritative DNS records remain accurate and are maintained by another authorized component, those records need not be withdrawn solely because the FGW stops. Records advertising an FGW-hosted discovery endpoint that will become unavailable SHOULD be updated or removed.¶
In Mode B, affected FMRs are withdrawn, updated, or transferred according to the selected mechanism. Structured peering may send explicit withdrawals, gossip may disseminate withdrawal state, and directory publication may remove registrations. A receiving FGW that accepts an authorized withdrawal removes the affected record from usable FAD results without waiting for its previous validity period to expire. Records describing agents that remain available MAY continue under an authorized continuity arrangement.¶
The FAD maintains expiration information for accepted remote records according to the mechanism through which they were obtained. Expiration limits the use of cached or synchronized information; it does not by itself establish whether an agent is currently reachable.¶
In Mode A, remote discovery information is not pre-populated in the FAD by default. When a cross-domain request has no valid matching cache entry, the FGW retrieves the relevant DNS records, validates them, and caches the accepted information. Its expiration time is bounded by the remaining TTL supplied by the DNS resolution process and any shorter applicable record or validation lifetime. A response obtained from an intermediate resolver does not receive a new full authoritative TTL merely because it is copied into the FAD.¶
A cache hit does not restart the entry's lifetime. Once an entry expires, it is no longer eligible to answer discovery requests. A subsequent request triggers fresh DNS retrieval and validation. The FGW does not extend an expired entry merely because the authoritative service is temporarily unreachable. Background cleanup MAY remove expired entries later, provided that request processing excludes them immediately upon expiration.¶
A fresh validated DNS response MAY establish a new cache lifetime according to its remaining TTL and applicable validity limits. Mode A does not require the originating FGW to push periodic refreshes to remote FADs, and an unchanged DNS record does not require a new FMR version solely to be cached again after a later query.¶
DNS TTL bounds the lifetime of a cached copy, not the lifetime of a record in the authoritative zone. If an obsolete record remains published, subsequent queries can retrieve and cache it again. Deployments therefore need an authorized mechanism to reconcile published DNS records with current agent state and to remove obsolete publications independently of cache aging.¶
In Mode B, accepted FMRs expire according to the originating record's validity and the selected synchronization or directory mechanism. Duplicate reception, relay activity, and local cache access do not extend origin-defined validity. The applicable protocol defines authenticated refreshes, version ordering, replay protection, and withdrawal-state retention. These rules are distinct from ordinary DNS cache refresh in Mode A.¶
Where discovery results depend on Attachment Scope, cached information is reused only for requests satisfying the same applicability conditions. A change in attachment context may require a new lookup before the record's TTL expires. Detailed context acquisition and cache partitioning procedures are outside the scope of this document.¶
The FMR format uses self-describing TLV (Type-Length-Value) encoding, allowing new optional fields to be added without breaking backward compatibility. Recipients MUST ignore unknown TLV types.¶
The architecture supports multiple protocol versions simultaneously. FGWs SHOULD negotiate protocol capabilities during session establishment (for BGP-like peering protocols), hello exchange (for gossip protocols), through record-format versioning and TTL-based rollover (for the DNS delegation mode), or through the directory's registration interface (for directory publication).¶
Major architectural changes that break compatibility require a new version of this framework document and SHOULD be discussed in the DAWN working group before deployment.¶
Operators of federation gateways SHOULD monitor the following metrics:¶
Number of active federation peers and peer session uptime.¶
FAD size and growth rate, per origin gateway.¶
FMR update rate and withdrawal rate.¶
Signature verification failure rate (indicator of potential attacks or misconfiguration).¶
Mode A FAD cache-hit and cache-miss rates, entry expiration and eviction rates, and DNS lookup latency. Cache expiration is normal and does not by itself indicate publication failure.¶
Mode A DNS resolution failures, DNSSEC validation failures, authoritative publication update failures, and discrepancies detected during publication reconciliation.¶
Mode B record expiration rates, missed refreshes where applicable, withdrawal propagation delay, and synchronization or reconciliation failures.¶
Discovery query request rate and authorization failure rate.¶
This informational document does not request any new IANA registrations. The architecture itself does not define protocol numbers, ports, or message types.¶
Future normative protocol specifications derived from this architecture MAY request IANA allocations, including but not limited to: well-known TCP/UDP ports for federation control protocols, message type registries, and FMR TLV type registries. DNS-based realizations may additionally request allocation of DNS service names/types (e.g., under the DNS-SD service-type registry) or of new DNS resource record types for agent discovery. Such requests are the responsibility of the respective protocol documents.¶
A shared FMR TLV type registry MAY be established to ensure interoperability across different federation protocols. If established, it SHOULD be managed under the "Specification Required" policy [RFC8126].¶
The author thanks the DAWN working group participants for their foundational work on agent discovery terminology, requirements, and gap analysis. This architecture builds directly on the DAWN problem statement, requirements, use cases, and the discovery mechanism survey by Jimenez et al.¶
This appendix provides detailed considerations for the federation synchronization modes that may be standardized separately based on this architecture. These details are informational and are provided to guide future protocol design. The modes described here may be instantiated by separately-published, normative protocol specifications. Appendix A.1 describes the preferred DNS delegation model (Mode A) for inter-organizational interaction; Appendix A.2 introduces the non-DNS alternatives (Mode B), with Appendix A.3, Appendix A.4, and Appendix A.5 describing BGP-like structured peering, gossip-based epidemic dissemination, and trusted directory publication respectively.¶
For inter-organizational interaction in the cooperating-parties context, the preferred realization of the Federation Plane is DNS delegation between authoritative zones (Mode A). Each site publishes its policy-filtered FMRs as resource records in its own authoritative zone, and other sites' validating resolvers query those zones directly; delegation and referral between authoritative zones provide the discovery path without requiring persistent gateway-to-gateway sessions.¶
Each FGW acts as an authoritative publisher for the site: it publishes FMRs as resource records (e.g., TXT records or dedicated record types carrying the thin MDI binding) in the site's zone, and refreshes them on local agent state changes.¶
Inter-organizational discovery uses ordinary DNS resolution: a querying site's validating resolver resolves the target organization's discovery name, follows DNS delegation to the target's authoritative zone, and obtains the FMR records directly from that zone.¶
Delegation and referral between discovery domains provide the iterative path: a returned record may refer the client to a catalog or to another discovery endpoint (referral, delegation, or indirection), consistent with the iterative discovery model of this architecture (Section 1 and Section 6.3).¶
DNSSEC [RFC4035] provides origin authentication and integrity for the published records; validating resolvers MUST verify the DNSSEC chain of trust and MUST NOT accept unauthenticated FMR records when the zone is signed.¶
DANE [RFC6698] MAY be used to authenticate the endpoints that a record references.¶
Lifecycle management distinguishes authoritative publication updates from cache aging. The publishing FGW or an authorized infrastructure controller updates or removes authoritative DNS records as agent availability, deployment state, or export policy changes. Previously cached copies in resolvers and remote FADs remain subject to their established expiration times and are not immediately invalidated by authoritative updates. A subsequent discovery request without a valid matching FAD entry triggers DNS resolution and validation before the result is cached again. The publisher SHOULD reconcile authoritative records with current deployment state, since cache expiration alone does not remove obsolete records from the authoritative zone.¶
Export policy remains in force at publication time: the Export Policy Engine determines which FMRs are published in the zone, and records that are not published are not reachable via DNS.¶
Mode A is preferred because it reuses mature DNS infrastructure, requires no persistent peering sessions or per-peer manual configuration, scales naturally through the DNS hierarchy, and composes with the DAWN DNS-based naming proposals (DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] and DN-ANR [I-D.cui-dns-native-agent-naming-resolution]).¶
Mode A may also be used in a restricted, pointer-only form in which the zone carries only bootstrap records advertising the FGW discovery directory endpoint, and detailed FMRs are retrieved from that endpoint under access control rather than published in DNS. This form supports the two-phase mixed-mode deployment described in Section 7.3 and is motivated by the access-control considerations of Section 8.3.¶
Mode B is the alternative to Mode A when the DNS delegation model does not meet operational requirements, for example when sites require push-based, near-real-time propagation, per-peer export policy that cannot be expressed through zone publication, operation in networks without a usable DNS hierarchy, or discoverability beyond the immediate federation. The selection among the three Mode B mechanisms depends on the number and scale of participating organizations and on the deployment scenario (Section 7.2):¶
BGP-like structured peering (Appendix A.3) is suited to medium-scale closed trusted federations (Section 7.2.1) that require fast convergence and fine-grained per-peer policy control.¶
Gossip-based epidemic dissemination (Appendix A.4) is suited to large-scale loose federations (Section 7.2.2) with high member churn, where self-organizing topology and horizontal scalability matter more than convergence speed.¶
Trusted directory publication (Appendix A.5) is suited to deployments that must be discoverable by parties outside the immediate federation (Section 7.2.3), within the limits set by operator policy and the DAWN charter.¶
All Mode B mechanisms share the same FMR metadata format and the same integrity requirements as Mode A; the choice of mechanism does not change the thin MDI binding carried in FMRs.¶
BGP-like structured peering is one of the three Mode B mechanisms, suited to closed trusted federations (Section 7.2.1) that require persistent, low-latency peering with fine-grained per-peer policy control. It is the recommended Mode B choice when DNS delegation (Mode A, Appendix A.1) does not meet operational requirements, for example when sites require push-based, near-real-time propagation or per-peer export policy that cannot be expressed through zone publication.¶
Each FGW establishes persistent unicast sessions with configured peer FGWs.¶
Incremental updates are sent when local agent state changes. Full table dumps are exchanged only upon session establishment or after a reset.¶
Per-peer export and import policies control which FMRs are advertised to or accepted from each peer.¶
Keepalive and hold timers detect peer failures.¶
Route reflection or confederation concepts may be applied to reduce full-mesh requirements in large closed federations.¶
It is important to distinguish metadata‑oriented discovery federation from a full network‑routing control plane. This BGP‑style structured peering is only one optional synchronization mechanism for metadata federation and is not mandatory for the architecture. Simpler deployments may rely solely on the DNS delegation mode (Mode A) instead of full peering‑based metadata synchronization, without constructing a routing‑like control‑plane.¶
Gossip-based epidemic dissemination is one of the three Mode B mechanisms, suited to large-scale loose federations (Section 7.2.2) where gossip-based protocols provide horizontal scalability at the cost of eventual consistency.¶
Each FGW maintains a small, bounded set of neighbor FGWs (e.g., log N for N participants).¶
During each gossip cycle, the FGW exchanges a digest of its FAD with a randomly selected neighbor, followed by exchange of missing or updated FMRs.¶
Anti-entropy synchronization reconciles divergent states during periodic full exchanges.¶
Neighbor selection may be random, topology-aware, or latency-optimized.¶
Due to the risk of rapid forged metadata propagation, this model SHOULD be combined with strict FMR signature verification and rate limiting.¶
Trusted directory publication is one of the three Mode B mechanisms, suited to deployments that must be discoverable by parties outside the immediate peer federation (Section 7.2.3). The FGW does not rely solely on peer-to-peer synchronization; instead, it publishes a policy-filtered subset of its FMRs to a trusted or semi-public directory service (e.g., AGNTCY ADS [I-D.mp-agntcy-ads] or a DNS-based registration system) under explicit trust relationships.¶
The directory acts as a registration and query endpoint rather than a peer gateway; publication uses the directory's own registration interface, not a gateway-to-gateway synchronization session.¶
The Export Policy Engine selects which sanitized FMRs are published to the directory, distinct from those shared only with federation peers. Published records are the same thin MDI binding used elsewhere in the federation, so no separate record format is introduced.¶
Publication is one-way by default: the FGW pushes records to the directory and periodically refreshes them; lifecycle invalidation relies on TTL aging or explicit withdrawal through the directory interface.¶
Directory publication is a dissemination endpoint, not a trust anchor: it does not relax federation admission control, and a directory query result points back to the originating FGW, which controls further interaction under its access-control policy.¶
Because the directory may be queried by requesters that are not federation peers, this model trades per-peer export control for broader discoverability, bounded by operator policy and the DAWN charter (which excludes open-Internet-scale indexing).¶
Mixed-mode federation combines Mode A and Mode B in a two-phase deployment: DNS is used first to bootstrap the discovery of peer endpoints, and the selected Mode B mechanism is then used for metadata exchange. The two phases proceed as follows:¶
Phase 1 -- Bootstrap and endpoint discovery (DNS as a pointer): Each site publishes pointer records (e.g., SRV or NAPTR-style records) in its own authoritative zone that advertise the location of its federation gateway's discovery directory endpoint. Detailed agent discovery records (FMRs) are not published in the public DNS. A peer site's validating resolver resolves the target organization's discovery name, follows DNS delegation to the target's authoritative zone, and verifies the pointer records with DNSSEC before caching them. The resolved endpoint -- the target FGW discovery directory endpoint -- establishes the initial context for the subsequent metadata exchange.¶
Phase 2 -- Metadata exchange (Mode B by scale): Once each FGW has learned the endpoints of its peers, the federation exchanges FMRs using the selected Mode B mechanism, chosen according to the number and scale of participating organizations and the deployment scenario (Section 7.2):¶
BGP-like structured peering (Section 7.2.1): For closed trusted federations of approximately 2 to 200 sites, each FGW establishes persistent unicast sessions with its configured peer FGWs, sends incremental FMR updates when local agent state changes (full table dumps only upon session establishment or reset), and applies per-peer export and import policies.¶
Gossip-based epidemic dissemination (Section 7.2.2): For large-scale loose federations of hundreds to thousands of sites, each FGW maintains a small, bounded set of neighbors and periodically exchanges a digest of its FAD with a randomly selected neighbor, followed by exchange of missing or updated FMRs; anti-entropy synchronization reconciles divergent states during periodic full exchanges.¶
Trusted directory publication (Section 7.2.3): When discoverability beyond the immediate federation is required, each FGW publishes a policy-filtered subset of sanitized FMRs to a trusted or semi-public directory service and refreshes them periodically; lifecycle invalidation relies on TTL aging or explicit withdrawal through the directory interface.¶
In all cases, peer gateways obtain FMRs only from endpoints learned in Phase 1 (or from the selected directory), where authorization and identity validation are enforced according to pre-established trust policies (Section 8.3); the origin and integrity of each FMR are verified before the record is accepted into the local FAD.¶
Federations that do not require per-endpoint access control may instead use Mode A in its full form, publishing FMRs directly as resource records (Appendix A.1); the choice is an operator decision driven by the required level of access control and data sovereignty.¶