| Internet-Draft | A Framework for Agent Discovery in DAWN | October 2026 |
| Zhang & Yang | Expires 13 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 13 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], AID [I-D.nemethi-aid-agent-identity-discovery]); 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 (ARDP [I-D.pioli-agent-discovery], 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 directory holding FMR registration records; 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 is a concrete binding of the DAWN Minimum Discoverable Information (MDI) [I-D.cui-dawn-mdi-model] for cross-domain transport: it carries the minimum public discovery information (Entity Identifier, Entity Type, reachability/locator, communication protocol, services, status, and time-to-live). It does not carry capability information beyond this minimum. 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 collects agent discovery information from local agents, applies export policy, and participates in cross-domain federation. 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 of its FMRs in the site's zone 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 is the DAWN MDI [I-D.cui-dawn-mdi-model] as scoped by the DAWN charter; the FMR carries exactly this information and nothing more.¶
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 database maintained by each FGW, containing all FMRs received from federation peers plus locally-originated FMRs. Functionally analogous to a distributed Agent Directory [I-D.jimenez-agent-directory].¶
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 zero-configuration or low-configuration agent advertisement and collection. This plane may use mDNS/DNS-SD, local API registration, edge platform discovery, or other site-local mechanisms.¶
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 efficiently handle frequent agent events: startup, graceful shutdown, network disconnection, and capability update. Metadata MUST become invalid promptly after an agent goes offline. Satisfies DAWN requirements for 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 in this architecture may be answered by the FAD (local cache) or forwarded to peer FGWs, rather than requiring a global ACAP query endpoint. 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.¶
ARDP [I-D.pioli-agent-discovery] specifies a lightweight federated protocol for registering and discovering agents, with cryptographic proof-of-control via JWS signatures and support for cross-domain federation through explicit trust relationships.¶
This architecture aligns with ARDP's federation goals but operates at a different granularity. ARDP focuses on agent-level registration and discovery; this architecture focuses on site-level gateway federation. An FGW could use ARDP as its Federation Plane synchronization protocol, aggregating multiple local agents into a single gateway-level ARDP registration, or ARDP could be used directly between FGWs for FMR exchange. The Export Policy Engine in this architecture adds a layer of data sovereignty not explicitly addressed by ARDP.¶
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], DN-ANR [I-D.cui-dns-native-agent-naming-resolution], and AID [I-D.nemethi-aid-agent-identity-discovery] 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.¶
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.¶
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 agent discovery metadata MAY be advertised either by the agent itself after startup via a site‑local discovery mechanism, or registered or advertised on its behalf by an authorized entity such as an agent orchestration, placement, or hosting system, or a local gateway. The primary site‑local mechanism candidate is link‑local multicast mDNS/DNS‑SD (service type such as "_agent._tcp.local"), but alternative mechanisms are permitted: local API registration to an Agent Directory [I-D.jimenez-agent-directory], edge‑platform‑driven discovery (e.g., Kubernetes service discovery), or ACAP [I-D.zahed-acap] registration. This architecture supports both deployment models and does not mandate agent‑originated metadata advertisement, nor does it mandate any single 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 listens to local agent advertisements (via mDNS passive listening, Agent Directory subscription, or ACAP endpoint polling) and maintains a site-local agent table for all agents discovered inside this site.¶
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 only distributes sanitized FMRs to its authenticated federation peers, according to its export policy.¶
When an agent's state changes (online, offline, capability update), the local FGW generates an incremental metadata update and propagates it according to the selected synchronization mode: in Mode A it publishes or refreshes the corresponding resource records in its own authoritative zone; in Mode B it propagates the update using the selected mechanism (incremental update over peering sessions, gossip exchange, or directory registration) (see Appendix A for protocol considerations).¶
Remote receiving FGWs update their local Federated Agent Directory (FAD). Every FGW maintains its local copy of federation agent metadata.¶
When a client in one site needs to discover cross-domain resources, the local FGW queries its local FAD cache; in Mode A it issues a DNS query to the peer site's authoritative zone and validates the response (e.g., with DNSSEC) before caching, while in Mode B it relies on the records obtained through the selected synchronization mechanism. If the returned FMR refers the client to a catalog or another discovery endpoint (referral, delegation, or indirection), the client follows that referral; retrieval of any richer capability information is outside this architecture's scope.¶
Federation membership can be dynamically adjusted: FGWs may join or leave the federation according to trust agreements.¶
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).¶
The FGW in Site B obtains the FMR (by resolving Site A's authoritative zone and validating the record, e.g., with DNSSEC, in Mode A; or by receiving the update through the selected Mode B mechanism), verifies its origin and integrity, and stores it in its local FAD.¶
A client in Site B queries its local FGW for resources matching a requested type or service. The FGW searches its FAD and returns the FMR for the resource in Site A.¶
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): In the preferred DNS realization (Mode A), publishes policy-filtered FMRs as resource records in the site's authoritative zone and validates responses from peer zones (e.g., with DNSSEC).¶
Discovery and Referral Response Service (on FGW): Responds to discovery queries with FMR records from the FAD, and issues referrals to catalogs or other discovery endpoints when the queried resource is not held locally.¶
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): Periodically scans the FAD and purges expired FMR entries based on their TTL values.¶
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.¶
The architecture permits different subsets of an overall federation to adopt different modes or mechanisms. For example, the preferred DNS delegation mode (Mode A) serves as the common, infrastructure-based mechanism for inter-organizational interaction, while a core group of trusted operators additionally uses BGP-like structured peering among themselves for low-latency convergence, a broader set of peripheral participants connects via gossip, and an even broader public set discovers via DNS zone publication or a trusted directory. The FMR metadata format is shared across all 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] and ARDP [I-D.pioli-agent-discovery] 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 FMR resource records, 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.¶
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:¶
FMRs previously learned from now-unreachable peers remain in the local FAD until their TTL 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.¶
When an FGW fails, FMRs originated by that gateway remain in peer FADs until TTL expiry, providing a grace period for recovery.¶
Upon recovery, the FGW rebuilds its site-local agent table via Layer 1 discovery, then re-originates its FMRs: in Mode A it re-publishes them in its authoritative zone, and in Mode B it re-originates them through the selected synchronization mechanism.¶
If an FGW is permanently decommissioned, operators SHOULD gracefully withdraw all its FMRs before shutdown (see Section 9.3).¶
When an FGW is administratively shut down, it SHOULD withdraw all of its locally-originated FMRs: in Mode A, by removing or shortening the TTL of its published resource records; in Mode B, by sending withdrawal messages over its peering sessions (BGP-like peering), through anti-entropy withdrawal (gossip), or through the directory's deregistration interface (directory publication). This allows peers to immediately remove the shutting-down gateway's agents rather than waiting for TTL expiry.¶
Each FMR carries a TTL value. When an FGW inserts or updates an FMR in its FAD, it records an expiry time. A background aging process periodically scans the FAD and removes any FMR whose expiry time has passed. Expired records are NOT announced via withdrawal; they simply disappear from the local FAD. If the origin gateway still has the agent, it refreshes the FMR before TTL expiry by sending a new update.¶
Origin gateways MUST send refresh updates for each active local agent at an interval of no more than half the TTL value, ensuring that transient federation disruptions do not cause valid agents to expire prematurely.¶
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).¶
TTL expiry rate (high expiry rate may indicate origin gateway refresh problems or network instability).¶
Discovery query request rate and authorization failure rate.¶
This informational architecture document does not define any normative protocol. It is intended to serve as a deployment framework within the DAWN working group's overall discovery architecture. The relationship with other documents is as follows:¶
DAWN Core Documents (Informational): The DAWN terminology [I-D.farrel-dawn-terminology], problem statement [I-D.akhavain-moussa-dawn-problem-statement], requirements [I-D.king-dawn-requirements], use cases [I-D.kay-dawn-use-cases], and gap analysis [I-D.moussa-dawn-gap-analysis] provide the foundational context. This architecture is a concrete instantiation of the "Administrative Scope Extensions" use case and addresses several identified gaps.¶
MDI (Informational): [I-D.cui-dawn-mdi-model] defines the abstract information model. This architecture defines FMRs as a concrete binding of MDI for cross-gateway transport.¶
ACAP (Standards Track candidate): [I-D.zahed-acap] may serve as the Description Plane protocol within a site. This architecture does not compete with ACAP; it federates ACAP-described agents across domains.¶
Agent Directory (Standards Track candidate): [I-D.jimenez-agent-directory] may serve as the Local Discovery Plane protocol. This architecture provides a federation model for Agent Directory instances.¶
Federation Protocol Documents: Normative federation synchronization protocols, if any, are expected to be specified in separate documents developed based on the architectural considerations in Appendix A. Any such protocol document MUST share the FMR metadata format described in this architecture as a binding of MDI, and MUST NOT relax the MDI constraints.¶
DNS-Based Protocol Documents: The concrete mapping of FMRs to DNS resource records is left to the DAWN DNS protocol specifications (e.g., DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] and DN-ANR [I-D.cui-dns-native-agent-naming-resolution]). This architecture identifies DNS delegation between authoritative zones (Mode A) as the preferred realization of the Federation Plane for inter-organizational interaction, and treats non-DNS synchronization (Mode B: BGP-like peering, gossip, and trusted directory publication) as alternative realizations; any DNS-based realization MUST preserve the FMR as a binding of MDI.¶
The FMR metadata format is shared across all protocol documents, ensuring that agent metadata records are interoperable regardless of which synchronization mechanism transports them. Protocol documents MAY define additional protocol-specific fields in their message headers, but the FMR payload format — as a binding of MDI — MUST remain consistent.¶
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 invalidation relies on TTL-based aging: the publishing FGW refreshes its records within half the TTL, and stale records disappear from resolver caches and peer FADs when they expire.¶
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], DN-ANR [I-D.cui-dns-native-agent-naming-resolution], AID [I-D.nemethi-aid-agent-identity-discovery]).¶
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).¶
A deployment may combine the modes above. FGWs using different synchronization modes (DNS delegation in Mode A; BGP-like peering, gossip, or directory publication in Mode B) must still exchange FMRs; likewise, a federation that also uses trusted directory publication (Section 7.2.3) must keep directory records consistent with records exchanged in the other modes. This may be achieved by:¶
Deploying protocol translators or bridge FGWs that participate in multiple synchronization modes.¶
Using a shared FMR advertisement format that is opaque to the synchronization mode, so that the same thin MDI binding can be exchanged over DNS zone publication, peering, gossip, or a directory registration interface without conversion.¶
Designating a bridge FGW (or the directory itself) as the boundary between modes: records learned in one mode may be re-published into another, subject to the originating gateway's export policy and signature verification.¶
Using a shared bootstrap mechanism (e.g., DNS-SD or a well-known URI) for neighbor and zone discovery across modes, and optionally for locating a trusted directory.¶
Treating the directory as a common query endpoint: requesters outside the federation discover via the directory, while federation peers may query their FAD directly or resolve peer zones in Mode A, with all paths resolving to the same originating FGW for further interaction under that FGW's policy.¶