Network Working Group B. Zhang, Ed. Internet-Draft Pengcheng Laboratory Intended status: Standards Track October 2026 Expires: 17 April 2027 Federated Agent Metadata Synchronization Protocol (FAMS-P) draft-zhang-dawn-bgp-style-federated-discovery-00 Abstract This document specifies the Federated Agent Metadata Synchronization Protocol (FAMS-P), a normative protocol realization of the "BGP-like structured peering" federation mode (Mode B) defined in the two-layer DAWN discovery architecture (draft-zhang-dawn-agent-discovery- framework). FAMS-P is a peer-to-peer unicast protocol for synchronizing agent discovery metadata between Federation Gateways (FGWs) across administrative domains, in deployments where the preferred DNS delegation model does not meet operational requirements, such as closed trusted federations of approximately 2 to 200 sites. FAMS-P runs over mutually-authenticated TLS 1.3 sessions between peering gateways. It supports initial full metadata synchronization and incremental updates for agent online, offline, and change events. Each gateway maintains a local Federated Agent Directory (FAD). The protocol synchronizes only lightweight Federation Metadata Records (FMRs) — a concrete binding of the DAWN Minimum Discoverable Information (MDI) — and thus transfers only the minimum public discovery information permitted by the DAWN charter; richer capability retrieval is out of scope. The protocol defines complete message formats, a session state machine with connection collision resolution, timestamp-and-replay- protected conflict resolution, mandatory FMR origin signatures, time- to-live aging with bounded refresh jitter, and fine-grained per-peer export policy enforcement. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Zhang Expires 17 April 2027 [Page 1] Internet-Draft Federated Agent Metadata Synchronization October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4 1.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Relationship to DAWN Family Protocols . . . . . . . . . . . . 6 3.1. AMSP (Agent Metadata Synchronization Protocol) . . . . . 6 3.2. ACAP (Agent Capability Advertisement Protocol) . . . . . 7 3.3. Agent Directory . . . . . . . . . . . . . . . . . . . . . 7 3.4. ARDP (Agent Registration and Discovery Protocol) . . . . 7 3.5. DNS-Based Naming Proposals and Other Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. MDI (Minimum Discoverable Information) . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Session Establishment and Maintenance . . . . . . . . . . . . 9 5.1. Transport and Identification . . . . . . . . . . . . . . 9 5.2. Common Message Header . . . . . . . . . . . . . . . . . . 9 5.3. FAMS-P Message Types . . . . . . . . . . . . . . . . . . 10 5.4. Hold Timer and Keepalive . . . . . . . . . . . . . . . . 11 5.5. Session State Machine . . . . . . . . . . . . . . . . . . 11 5.6. Simultaneous Session Collision . . . . . . . . . . . . . 12 5.7. NOTIFICATION Error Codes . . . . . . . . . . . . . . . . 12 6. Federation Metadata Record (FMR) Format . . . . . . . . . . . 13 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 13 6.2. FMR TLVs . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. FMR Signature Computation . . . . . . . . . . . . . . . . 15 Zhang Expires 17 April 2027 [Page 2] Internet-Draft Federated Agent Metadata Synchronization October 2026 6.4. Export Policy and Redaction . . . . . . . . . . . . . . . 15 7. Synchronization Procedures . . . . . . . . . . . . . . . . . 15 7.1. Initial Full Synchronization . . . . . . . . . . . . . . 15 7.2. Incremental UPDATE Process . . . . . . . . . . . . . . . 16 7.3. Conflict Resolution . . . . . . . . . . . . . . . . . . . 16 7.4. Replay Protection, Clock Skew, and Tombstones . . . . . . 17 7.5. Stale Entry Aging and Refresh . . . . . . . . . . . . . . 17 7.6. Transitive Re-distribution . . . . . . . . . . . . . . . 18 8. Local Sharing Policy Enforcement . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. Transport Security . . . . . . . . . . . . . . . . . . . 19 9.2. FMR Origin Authentication and Integrity . . . . . . . . . 19 9.3. Access Control on Discovery Information . . . . . . . . . 19 9.4. Federation Admission Control . . . . . . . . . . . . . . 20 9.5. Denial-of-Service Mitigation . . . . . . . . . . . . . . 20 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 11. Operational and Manageability Considerations . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction 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, within the local network, within an organization, and between cooperating parties 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. The DAWN discovery architecture [I-D.zhang-dawn-agent-discovery-framework] defines a two-layer federated reference architecture consisting of a Local Discovery Plane within each site and a Federation Plane across administrative domains, mediated by a Federation Gateway (FGW) and an Export Policy Engine. The architecture identifies DNS delegation between authoritative zones (Mode A) as the preferred realization of the Federation Plane, and defines three non-DNS synchronization Zhang Expires 17 April 2027 [Page 3] Internet-Draft Federated Agent Metadata Synchronization October 2026 alternatives (Mode B): BGP-like structured peering, gossip-based epidemic dissemination, and trusted directory publication, selected according to federation scale and deployment scenario. This document specifies FAMS-P, the normative protocol realization of the BGP-like structured peering mode (Mode B) of that architecture, targeting closed trusted federations of approximately 2 to 200 sites. It does not compete with the DNS-based realization: deployments select the mode that matches their scale, trust model, and access- control requirements, and the modes share the same FMR metadata format. FAMS-P is inspired by BGP peering principles [RFC4271] but is designed specifically for agent discovery metadata rather than IP routing information. FAMS-P synchronizes only Federation Metadata Records (FMRs), each a concrete binding of the DAWN Minimum Discoverable Information (MDI) information model [I-D.cui-dawn-mdi-model]. Because an FMR carries only the minimum public discovery information, FAMS-P's full synchronization procedure transfers only the minimum information needed to establish communication; it does not distribute capability information beyond that minimum, consistent with the DAWN charter and with the architecture's out-of-scope statement. Richer capability descriptions (e.g., ACAP Agent Capability Documents [I-D.zahed-acap], A2A Agent Cards) are neither synchronized by FAMS-P nor retrieved through it; referral to such information, where permitted by export policy, is expressed with the optional Capability-Card-URI TLV, and the retrieval mechanism itself is out of scope of this document. 1.1. Document Scope This document defines a normative protocol: message formats, session state machine, synchronization procedures, error handling, and registries. It realizes one deployment mode of the DAWN discovery architecture [I-D.zhang-dawn-agent-discovery-framework] and is intended for the closed trusted federation scenario (approximately 2 to 200 sites) described there. 1.2. Out of Scope The following items are explicitly out of scope: * Local discovery mechanisms within a site (e.g., mDNS [RFC6762] [RFC6763], Agent Directory [I-D.jimenez-agent-directory], ACAP [I-D.zahed-acap]). FAMS-P assumes local agents are discovered by other means and fed into the FGW. Zhang Expires 17 April 2027 [Page 4] Internet-Draft Federated Agent Metadata Synchronization October 2026 * The DNS-based federation mode (Mode A) of the architecture; FAMS-P is the Mode B peering alternative. Mixed-mode deployments that use DNS solely as a bootstrap pointer are described in the architecture document. * Gossip-based or epidemic dissemination for large-scale loose federations, and trusted directory publication; these are separate modes of the architecture that may be specified elsewhere. * Capability negotiation, matchmaking, ranking, selection, task orchestration, or any communication beyond the initial discovery process. * Retrieval of full Capability Cards or other rich capability descriptions. * A global root trust authority or mandatory certificate hierarchy. FAMS-P supports federation-local trust models. * Business-level service level agreements or commercial federation governance rules. 2. Terminology 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, and terms defined by the DAWN discovery architecture [I-D.zhang-dawn-agent-discovery-framework], including Federation Gateway (FGW), Federation Metadata Record (FMR), Federated Agent Directory (FAD), Export Policy Engine, Federation Plane, Mode A, and Mode B. The following additional terms are defined for FAMS-P: * *Agent*: An autonomous network-resident entity that exposes service interfaces and publishes discovery metadata. Aligns with the DAWN definition of Entity when the entity type is "agent". * *Origin-GW-ID*: The unique, stable identifier of the FGW where the agent described by an FMR is locally discovered. An FMR's record key is the pair (Origin-GW-ID, Entity-Identifier). * *Peering Session*: A mutually-authenticated FAMS-P session between two FGWs over TLS 1.3, used to exchange FULL_SYNC, UPDATE, KEEPALIVE, and NOTIFICATION messages. Zhang Expires 17 April 2027 [Page 5] Internet-Draft Federated Agent Metadata Synchronization October 2026 * *Full-Sync*: Bulk transmission of all current valid FMRs originated or re-distributed by a gateway, sent after session establishment, terminated by an end-of-synchronization indication (Section 5.4). * *Incremental-Update*: A single-FMR announcement or withdrawal sent after initial synchronization completes. * *TTL*: The time-to-live value of an FMR entry, in seconds; stale entries MUST be purged upon expiry. * *Refresh*: An authenticated UPDATE, originated by the Origin-GW of a record, whose strictly newer timestamp starts a new full TTL lifetime for that record. * *Tombstone State*: Per-record state retained by a gateway recording the latest accepted timestamp and any withdrawal, used for replay protection (Section 7.4). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Relationship to DAWN Family Protocols FAMS-P operates as one realization of the Federation Plane defined by the DAWN discovery architecture [I-D.zhang-dawn-agent-discovery-framework]. The positioning statements in the architecture's Section 4 apply to FAMS-P unchanged; this section adds protocol-specific clarifications. 3.1. AMSP (Agent Metadata Synchronization Protocol) AMSP [I-D.liu-agent-metadata-sync-protocol] specifies a gateway-to- gateway metadata synchronization protocol with hierarchical Level-1/ Level-2 gateways and loop-free propagation of Agent Records. FAMS-P differs from AMSP in topology and policy model. AMSP defines a two-level gateway hierarchy in which Level-2 gateways aggregate and re-distribute records between Level-1 domains, with loop-free propagation as a design goal. FAMS-P, following the BGP-like structured peering mode of the architecture, uses flat, administratively configured bilateral peering with no transitive re- distribution by default: a gateway receives only the records that a peer selects for it under per-peer export policy, which provides stronger data sovereignty guarantees at the cost of full-mesh Zhang Expires 17 April 2027 [Page 6] Internet-Draft Federated Agent Metadata Synchronization October 2026 configuration overhead within the supported scale (approximately 2 to 200 sites). AMSP does not currently define a per-record origin signature comparable to the mandatory FMR signature of FAMS-P (Section 9.2), relying instead on session-level security. The two protocols share the goal of gateway-level metadata synchronization, and their record formats could be aligned through the shared MDI binding; operators SHOULD NOT deploy both protocols between the same pair of gateways. Consolidation of the two efforts is encouraged as the working group progresses. 3.2. ACAP (Agent Capability Advertisement Protocol) ACAP [I-D.zahed-acap] defines a well-known URI scheme, a rich Agent Capability Document (ACD) format, and HTTP/3 operations for retrieval, registration, and capability-based search within a domain. An FGW may collect local agent ACDs via ACAP, translate the minimum public discovery information of each ACD into an FMR (binding ACAP fields to MDI elements), and distribute the FMRs to federation peers via FAMS-P. Cross-domain queries are answered by the FAD (local cache built via FAMS-P); richer capability exchange is out of scope per the DAWN charter. 3.3. Agent Directory The Agent Directory [I-D.jimenez-agent-directory] adapts the CoRE Resource Directory [RFC9176] to software agents, providing an HTTP/ JSON service for local registration and lookup with soft-state lifetimes. The Agent Directory may serve as the Local Discovery Plane within a site: the FGW subscribes to the local Agent Directory, extracts MDI-compliant records, applies export policy, and generates FMRs. The FAD is conceptually a distributed extension of the Agent Directory across administrative boundaries, synchronized by FAMS-P. 3.4. ARDP (Agent Registration and Discovery Protocol) ARDP [I-D.pioli-agent-discovery] specifies a lightweight federated protocol for registering and discovering agents, with JWS-signed records and explicit trust relationships. FAMS-P differs from ARDP in granularity: ARDP focuses on agent-level registration and discovery with agent-scoped identifiers, while FAMS-P focuses on gateway-level metadata synchronization between FGWs. Both protocols use JWS for record-level integrity, easing interworking. An operator MAY use ARDP as the local registration protocol within a site, with FAMS-P providing the inter-gateway synchronization layer. Zhang Expires 17 April 2027 [Page 7] Internet-Draft Federated Agent Metadata Synchronization October 2026 3.5. DNS-Based Naming Proposals and Other Discovery Mechanisms 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]) and DNS-like hierarchical architectures [I-D.yao-dawn-agent-discovery-architect] operate at the Naming Plane and are orthogonal to FAMS-P's synchronization role. The architecture's preferred Mode A realizes the Federation Plane over these DNS mechanisms; FAMS-P realizes Mode B and may be combined with DNS bootstrap pointers in mixed-mode deployments. The AGNTCY Agent Directory Service [I-D.mp-agntcy-ads] targets open Internet- scale discovery and may be composed with FAMS-P in hybrid deployments via the architecture's trusted directory publication mode. 3.6. MDI (Minimum Discoverable Information) The MDI information model [I-D.cui-dawn-mdi-model] defines three mandatory elements (Entity Identifier, Entity Type, Endpoint) and recommended elements (Capability Summary, Authentication Hint, Trust Reference, Freshness). The FMR format defined in this document is a concrete, TLV-encoded binding of MDI for cross-gateway transport, and additionally defines binding-level mechanism fields (Origin-GW-ID, Record-Flag, Signature) that are not MDI elements. One FMR describes exactly one entity; recipients MUST ignore unrecognized TLV types, so the format is forward-extensible without breaking interoperability. 4. Protocol Overview FAMS-P operates between federation gateways over TLS 1.3. The protocol stack consists of four logical layers: 1. Transport Layer: TCP with mandatory mutual TLS 1.3 authentication, negotiated with the ALPN protocol identifier "fams" (Section 9.1). 2. Session Layer: Peer session state machine, connection collision resolution, keepalive, hold timer, and error notification. 3. Synchronization Layer: Full-sync segmentation with an explicit end-of-synchronization indication, and incremental metadata update transmission. 4. Application Layer: FMR validation, local FAD maintenance, timestamp-ordered conflict resolution with replay protection, and TTL aging. Zhang Expires 17 April 2027 [Page 8] Internet-Draft Federated Agent Metadata Synchronization October 2026 FAMS-P peering is configured administratively. A gateway establishes separate FAMS-P sessions towards each configured peer gateway. By default, a gateway MUST NOT re-distribute to one peer the FMRs it learned from another peer; transitive sharing, if desired, is an explicit per-peer export-policy decision of the local administrator and MUST preserve the original origin timestamp and signature (Section 7.4). Gossip-style flooding is out of scope. 5. Session Establishment and Maintenance 5.1. Transport and Identification A FAMS-P session MUST be carried over a bidirectional TCP connection protected by TLS 1.3 [RFC8446] with mutual certificate-based authentication [RFC5280]. Anonymous TLS connections MUST NOT be used. The client MUST offer and the server MUST select the ALPN protocol identifier "fams" [RFC7301] during the TLS handshake; if ALPN is negotiated and "fams" is not selected, the connection MUST be closed. If ALPN is not negotiated, the connection MAY be accepted only if local policy explicitly permits it. No well-known TCP port is assigned by this document. Peering configuration includes the transport address (IP address or DNS name) and port of each peer; deployments MAY use DNS SRV records to discover peer endpoints. Each gateway has a unique, stable Gateway-ID, encoded as a lowercase DNS domain name or a URI, used as Origin-GW-ID in locally-originated FMRs and as the peering identity in OPEN. The Gateway-ID is authenticated by the peer's TLS certificate; the certificate MUST carry a subject or subjectAltName identifier consistent with the claimed Gateway-ID. 5.2. Common Message Header All FAMS-P messages share a fixed 8-octet common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Version: 1 octet. The current protocol version is 1. Receipt of any other value triggers a NOTIFICATION with Error Code 1 (Message Header Error), subcode 1 (Unsupported Version). Zhang Expires 17 April 2027 [Page 9] Internet-Draft Federated Agent Metadata Synchronization October 2026 * Type: 1 octet. Defines the message type (Section 5.3). * Flags: 2 octets. Type-specific flags; reserved bits MUST be set to zero on transmission and MUST be ignored on receipt, except where specified. * Message-Length: 4 octets, unsigned. The total message length in octets, including the common header. An implementation MUST be able to receive messages up to 65,535 octets; larger datasets are segmented as described in Section 7.1. 5.3. FAMS-P Message Types Five message types are defined: 1. OPEN (Type=1): Sent after TLS handshake, to negotiate session parameters, hold-time, and gateway identifier. 2. FULL_SYNC (Type=2): Segmented bulk transfer of the complete set of FMR records selected for this peer; terminated by a segment with the end-of-synchronization flag. 3. UPDATE (Type=3): Incremental announcement or withdrawal of a single FMR entry. 4. KEEPALIVE (Type=4): Idle-period heartbeat to maintain session liveness; carries no payload beyond the common header. 5. NOTIFICATION (Type=5): Error report and session-closing signal. OPEN Message (Type=1): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold-Time | GWID-Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gateway-ID (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional-Parameters (variable, TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hold-Time is the proposed hold timer in seconds (Section 5.5). GWID- Len is the length of the Gateway-ID field in octets. Optional- Parameters is a sequence of TLVs (Section 6.1); currently one parameter is defined: FMR-Format-Version (Parameter Type=1, 1 octet, value 1). Unknown parameters MUST be ignored. Zhang Expires 17 April 2027 [Page 10] Internet-Draft Federated Agent Metadata Synchronization October 2026 FULL_SYNC Message (Type=2): the Flags field carries the MORE flag (0x0001). When MORE is set, at least one further FULL_SYNC segment follows; when MORE is clear, this segment is the end of the synchronization (Section 7.1). The payload is a sequence of one or more complete FMRs (Section 6). UPDATE Message (Type=3): the payload is exactly one complete FMR. The Record-Flag TLV (Section 6.2) indicates ANNOUNCE or WITHDRAW. NOTIFICATION Message (Type=5): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | Error-Subcode | Reason-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason (variable, UTF-8, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error codes and subcodes are defined in Section 5.7 and registered in Section 12. 5.4. Hold Timer and Keepalive The OPEN message negotiates a hold-time value, with a minimum of 30 seconds and a recommended default of 300 seconds; the effective hold- time is the smaller of the values proposed by the two peers. KEEPALIVE messages MUST be sent at an interval no greater than one third of the effective hold-time, with a uniform random jitter of up to 10 percent of the interval. If no message is received from the peer within the hold-time interval, the local gateway SHALL terminate the peering session, discard partial synchronization state, and re- enter the Connect state. 5.5. Session State Machine A FAMS-P peering session runs through five states: Idle, Connect, OpenSent, OpenConfirm, Established. * *Idle*: No active connection. Upon peering activation, the gateway enters the Connect state and initiates a TCP-TLS connection. * *Connect*: Waiting for TLS handshake completion. The ConnectRetry timer (default 30 seconds) governs retransmission. After successful TLS setup with ALPN "fams" and certificate validation, an OPEN message is transmitted and the gateway enters OpenSent. Zhang Expires 17 April 2027 [Page 11] Internet-Draft Federated Agent Metadata Synchronization October 2026 * *OpenSent*: OPEN has been sent; waiting for the peer's OPEN. Parameter mismatch (e.g., hold-time below the minimum, FMR-Format- Version not supporting value 1) triggers a NOTIFICATION with Error Code 2 and session reset to Idle. * *OpenConfirm*: Both OPEN messages have been exchanged and validated. The gateway waits for the first KEEPALIVE from the peer. * *Established*: Normal operational state, entered upon receipt of the first KEEPALIVE (or any other message) in OpenConfirm. Full- sync SHALL be triggered immediately after entering Established state. 5.6. Simultaneous Session Collision If both gateways initiate a TCP-TLS connection to each other at the same time, both sessions proceed through OPEN exchange. Connection collision is resolved as follows: each gateway compares its own Gateway-ID with the peer's Gateway-ID; the connection initiated by the gateway with the lexicographically larger Gateway-ID is preserved, and the other gateway closes the connection it initiated. The surviving session continues normally from OpenConfirm. This procedure mirrors BGP connection collision resolution [RFC4271]. 5.7. NOTIFICATION Error Codes Defined error codes (major categories) and subcodes: * 1 - Message Header Error: subcodes 1 (Unsupported Version), 2 (Bad Message Length), 3 (Unknown Message Type). * 2 - OPEN Message Error: subcodes 1 (Unsupported FMR-Format- Version), 2 (Unacceptable Hold-Time), 3 (Gateway-ID / Certificate Mismatch). * 3 - Hold-Time Expired. * 4 - Administrative Shutdown. * 5 - Policy Rejection: subcodes 1 (Import Policy), 2 (Export Policy). * 6 - Synchronization Data Corruption: subcodes 1 (Malformed TLV), 2 (Missing Mandatory TLV), 3 (Signature Verification Failure), 4 (Stale or Replayed Record). Zhang Expires 17 April 2027 [Page 12] Internet-Draft Federated Agent Metadata Synchronization October 2026 Receipt of a NOTIFICATION with codes 1, 2, or 6 MAY be retried after operator intervention; codes 3, 4, and 5 close the session without automatic retry for a locally configured backoff period. 6. Federation Metadata Record (FMR) Format 6.1. TLV Encoding An FMR is encoded as a sequence of type-length-value (TLV) entries: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type is 1 octet, Length is 2 octets (unsigned, length of the Value field only), and Value is Length octets. TLVs appear in any order except that, within the signed content, they are processed as an unordered set for validation purposes (Section 6.3). A gateway receiving a TLV whose Type it does not understand MUST ignore that TLV and MUST NOT treat it as an error, preserving forward compatibility. 6.2. FMR TLVs Mandatory TLV items (an FMR missing any mandatory TLV is malformed; see Error Code 6, subcode 2): * Entity-Identifier (TLV-Type 1): Globally unique identifier string of the agent (UTF-8). Maps to MDI entity-identifier. * Entity-Type (TLV-Type 2): Coarse type of the entity (e.g., "agent", "workload", "service"). Maps to MDI entity-type. * Endpoint (TLV-Type 3): Locator and protocol information for reaching the entity, expressed as a UTF-8 URI (e.g., "https://fgw.example.net/r/agents/a1"). Maps to MDI endpoint. Multiple Endpoint TLVs MAY be present; at least one MUST be present. * Origin-GW-ID (TLV-Type 4): Identifier of the FGW where this agent is locally discovered. Binding-level mechanism field, not an MDI element. * Publication-Timestamp (TLV-Type 5): 8-octet unsigned integer, seconds since the Unix epoch, set by the originating FGW when the record is generated. Maps to MDI freshness. See Section 7.4 for clock-skew limits. Zhang Expires 17 April 2027 [Page 13] Internet-Draft Federated Agent Metadata Synchronization October 2026 * TTL (TLV-Type 6): 4-octet unsigned integer, maximum lifetime in seconds for this record. RECOMMENDED default value 300. Maps to MDI freshness. * Capability-Summary (TLV-Type 7): Array of short UTF-8 text labels describing the entity's functional services, encoded as a sequence of 2-octet-length-prefixed strings. Maps to MDI capability- summary. Labels SHOULD be drawn from a controlled taxonomy when one is available; this document does not define the taxonomy. * Record-Flag (TLV-Type 8): 1 octet: 0 = ANNOUNCE, 1 = WITHDRAW (agent offline or record revoked). Binding-level mechanism field, not an MDI element. * Signature (TLV-Type 9): JWS Compact Serialization [RFC7515] (UTF- 8), computed over the content of all other TLVs of this FMR (Section 6.3). Mandatory; see Section 9.2. Optional TLV items: * Authentication-Hint (TLV-Type 10): Supported authentication scheme identifiers for interacting with the entity. Maps to MDI authentication-hint. * Trust-Reference (TLV-Type 11): URI pointing to assurance material (signature, certificate, attestation) for the entity. Maps to MDI trust-reference. * Provenance (TLV-Type 12): Publisher or responsible party identifier. Maps to MDI provenance. * Capability-Card-URI (TLV-Type 13): HTTPS endpoint at which a fuller capability description (e.g., an ACAP ACD) may be available. Maps to the MDI capability-reference concept. Retrieval of the referenced material is out of scope of this document and of the DAWN initial discovery phase. * Redistribution-Scope (TLV-Type 14): 1 octet declaring the origin's sharing intent: 0 = direct peers only (default behavior; records MUST NOT be further re-distributed), 1 = re-distribution within the federation permitted under each receiving gateway's export policy. This TLV makes the origin's sharing decision travel with the record, complementing the per-hop Export Policy Engine. TLV-Type values 15-223 are unassigned, 224-254 are reserved for experimental use, and 255 is reserved (see the IANA registry in Section 12). Zhang Expires 17 April 2027 [Page 14] Internet-Draft Federated Agent Metadata Synchronization October 2026 6.3. FMR Signature Computation The Signature TLV value is a JWS [RFC7515] whose payload is the exact octet sequence of all other TLVs of the FMR, in their transmitted order, excluding the Signature TLV itself. The signature MUST be produced with the private key of the originating FGW (the gateway named by Origin-GW-ID), and the JWS header MUST identify the signing key (e.g., via a key identifier or the gateway's certificate reference). The signature covers, at minimum, the Entity-Identifier, Origin-GW-ID, Publication-Timestamp, TTL, Record-Flag, and Capability-Summary TLVs; because the payload is the complete TLV set, all transmitted content is covered automatically. A receiving gateway MUST verify the signature against the public key of the gateway identified by Origin-GW-ID before accepting the FMR into its FAD (Section 9.2). Any modification of an FMR — including value-preserving re-encoding — invalidates the signature; relaying gateways MUST forward FMRs as unmodified octet sequences. 6.4. Export Policy and Redaction Gateways MUST redact private LAN IP addresses, internal hostnames, and sensitive internal fields before publishing FMR records to federation peers, per the Export Policy Engine defined in [I-D.zhang-dawn-agent-discovery-framework]. Precise location information (e.g., geographic coordinates) MUST NOT appear in any TLV. Referral URIs (Endpoint, Capability-Card-URI) SHOULD reference the originating FGW's public rendezvous points rather than agent- internal addresses, preserving internal topology privacy. 7. Synchronization Procedures 7.1. Initial Full Synchronization Once a peering session reaches Established state, each gateway sends its complete current valid FMR dataset — the records selected for this peer by local export policy — via one or more FULL_SYNC messages. Each segment except the last carries the MORE flag; the final segment carries MORE=0, marking the end of synchronization. Until the end-of-synchronization indication is received, the receiving gateway holds the incoming dataset in a staging area and MUST NOT merge it into the FAD. Upon receipt of the final segment, the receiving gateway replaces all existing records previously learned from this peer with the staged dataset. This replace-on-EOS rule ensures that a peer's records never reflect a partial view of that peer's dataset. Zhang Expires 17 April 2027 [Page 15] Internet-Draft Federated Agent Metadata Synchronization October 2026 7.2. Incremental UPDATE Process After full synchronization is finished, any local agent state change triggers an incremental UPDATE message. Events include agent startup, configuration update affecting exported fields, graceful shutdown, and network disconnect. When an agent goes offline permanently, the local gateway transmits an UPDATE message with the WITHDRAW flag set for the corresponding (Origin-GW-ID, Entity-Identifier) key, signed by the origin. Receiving gateways SHALL remove that entry from their local FAD immediately upon accepting a WITHDRAW record, and SHALL retain tombstone state for replay protection (Section 7.4). 7.3. Conflict Resolution A gateway identifies a record by the pair (Origin-GW-ID, Entity- Identifier). When an FMR is received for a key for which the FAD (or tombstone state) already holds a version, the receiver applies the following rules, in order: 1. If signature verification fails, the record is discarded and MUST NOT be propagated (Error Code 6, subcode 3 applies to the session if persistent). 2. If the received Publication-Timestamp is strictly newer than the latest accepted timestamp for that key, the record is accepted and replaces the stored version, starting a new full TTL lifetime. 3. If the timestamp equals the latest accepted timestamp and the signed content is identical, the record is a duplicate: it MUST be silently dropped and MUST NOT renew the stored expiry time. 4. If the timestamp equals the latest accepted timestamp but the signed content differs, the record MUST be rejected as a protocol error. 5. If the timestamp is older than the latest accepted timestamp (including timestamps earlier than a retained withdrawal), the record MUST be rejected as stale or replayed. Note that there is no tie-breaker on gateway identifiers: comparisons are made only among versions of the same record key, so all candidates carry the same Origin-GW-ID by construction. Zhang Expires 17 April 2027 [Page 16] Internet-Draft Federated Agent Metadata Synchronization October 2026 7.4. Replay Protection, Clock Skew, and Tombstones A gateway MUST reject any FMR whose Publication-Timestamp is more than FAMS-SKEW seconds in the future relative to the receiver's clock. The default FAMS-SKEW is 300 seconds; operators MAY configure a tighter value. A gateway SHOULD maintain clock synchronization (e.g., NTP) on all FGWs, but correctness of conflict resolution does not depend on synchronized clocks beyond the skew bound. To prevent an old FMR from being reinstated after explicit withdrawal or expiry, a gateway MUST retain, for each known record key, tombstone state recording at least the latest accepted Publication- Timestamp and whether a withdrawal has been processed. Tombstone state MUST be retained for at least the replay-protection period, RECOMMENDED as the maximum TTL observed in the federation. Implementations SHOULD persist tombstone state across restarts; if tombstone state is lost (e.g., catastrophic failure), the gateway MUST re-synchronize via FULL_SYNC with all peers before accepting UPDATEs, as specified in the architecture document. When a gateway re-distributes an FMR learned from another gateway (an explicit export-policy decision, Section 7.5), it MUST forward the FMR as an unmodified octet sequence, preserving the original Publication-Timestamp, TTL, and Signature, and MUST NOT alter the origin-authenticated lifetime. Receipt or relay of an unrefreshed copy of a record MUST NOT reset its expiry time. 7.5. Stale Entry Aging and Refresh Every gateway scans its local FAD periodically. Any FMR whose TTL has expired MUST be purged locally without further propagation to peers; expired records are not announced via WITHDRAW. 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. Each refresh carries a strictly newer Publication- Timestamp and therefore starts a new full TTL lifetime. To avoid synchronized refresh bursts across the federation, each origin SHOULD apply a uniform random jitter of up to 10 percent of the refresh interval to each timer. A refresh is effective only when authenticated as originating from the origin gateway (Section 7.4); relays MUST NOT treat their own forwarding activity as an origin refresh. Zhang Expires 17 April 2027 [Page 17] Internet-Draft Federated Agent Metadata Synchronization October 2026 7.6. Transitive Re-distribution By default, FAMS-P does not relay: records learned from one peer are not offered to another. If the local administrator configures transitive re-distribution for a peering pair, the Export Policy Engine MUST additionally check the Redistribution-Scope TLV of each candidate record: records carrying scope 0 (or no Redistribution- Scope TLV) MUST NOT be re-distributed. Re-distributed records are sent in FULL_SYNC or UPDATE messages with their original Origin-GW- ID, Publication-Timestamp, and Signature unchanged. 8. Local Sharing Policy Enforcement Each FGW maintains local export policy via the Export Policy Engine, as defined in [I-D.zhang-dawn-agent-discovery-framework]. Before publishing an FMR record to federation peers, the gateway SHALL apply filtering rules: 1. Select which local agents are permitted to be advertised into the federation. 2. Remove private fields from metadata; redact sensitive information (Section 6.4). 3. Apply per-peer policy: different peers may receive different subsets of available FMR records. 4. Honor the Redistribution-Scope TLV when re-distributing records learned from other gateways (Section 7.5). Policy configuration is out-of-band, managed by the site administrator, and is not negotiated via FAMS-P protocol messages. 9. Security Considerations Security in cross-domain agent discovery involves transport protection, metadata integrity, and access control. This section aligns with the security reference model of the DAWN discovery architecture [I-D.zhang-dawn-agent-discovery-framework] and the authentication framework in [I-D.klrc-aiagent-auth]. Zhang Expires 17 April 2027 [Page 18] Internet-Draft Federated Agent Metadata Synchronization October 2026 9.1. Transport Security Mutual TLS 1.3 authentication [RFC8446] is REQUIRED for all FAMS-P peering sessions, authenticating the identity of federation gateways via X.509 certificates [RFC5280] and binding the session to the ALPN identifier "fams". Plaintext transport is prohibited. A federation may use its own certificate authority (CA) or a web-of-trust model; FAMS-P does not mandate a global root CA. 9.2. FMR Origin Authentication and Integrity Transport security protects messages in transit but does not prevent a compromised peer from forging FMRs that claim to originate from another gateway. Therefore, as required by the architecture, each outgoing FMR MUST be signed by the originating FGW (Section 6.3), and each receiving FGW MUST verify the FMR signature against the originating gateway's public key before accepting the record into its FAD. Public keys are learned from peer certificates (for first-hand records) or from federation key-distribution configuration; the key- distribution mechanism is out of scope. FMRs that fail signature verification MUST be discarded and MUST NOT be propagated further; persistent failures SHOULD trigger NOTIFICATION Error Code 6, subcode 3. Because every accepted record carries a verifiable origin signature, FAMS-P provides origin authentication and integrity for all exchanged discovery information (architecture requirement F-9) even when records are re-distributed across multiple hops. 9.3. Access Control on Discovery Information FMRs are served only to authenticated federation peers over the mutually-authenticated peering session. The FGW SHOULD apply per- peer policies, serving different subsets of records to different peers (Section 8). The Endpoint and Capability-Card-URI values reference the originating FGW's rendezvous points rather than agent- internal addresses, preserving internal topology privacy. Unlike the DNS delegation mode, FAMS-P does not rely on DNS-level access control; all detailed records remain behind the authenticated peering boundary. Zhang Expires 17 April 2027 [Page 19] Internet-Draft Federated Agent Metadata Synchronization October 2026 9.4. Federation Admission Control The federation trust boundary is the membership list. A gateway admitted to the federation is trusted to accurately report its local agents; FMR signing prevents it from forging other gateways' records. Federation admission is governed by out-of-band administrative policy, and operators SHOULD vet new participants before admitting them, as described in the architecture document. 9.5. Denial-of-Service Mitigation * Rate limiting MUST be applied to incoming FAMS-P 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 with Error Code 5 or 6 as appropriate. * TLS handshake rate limiting protects against connection-flood attacks. * The hold timer and keepalive mechanism detect dead peers and free resources. * Signature verification SHOULD be performed before expensive FAD operations so that forged records consume minimal resources. 10. Privacy Considerations This section follows the guidance of RFC 6973 [RFC6973]. * Data minimization: FAMS-P synchronizes only the minimum public discovery information (the MDI binding). Capability information beyond the minimum, precise location data, and internal identifiers MUST NOT be carried in FMRs (Section 6.4). * Topology confidentiality: Endpoint and referral URIs point to the originating FGW rather than to agents' internal addresses; private IP address ranges (RFC 1918) and link-local addresses MUST be redacted before export. * Purpose limitation and per-peer control: the Export Policy Engine ensures that different peers receive different subsets of records, and the administrator can withdraw an agent's records federation- wide by withdrawing its FMRs (or allowing them to expire). Zhang Expires 17 April 2027 [Page 20] Internet-Draft Federated Agent Metadata Synchronization October 2026 * Storage: the FAD aggregates discovery metadata from all peers and is therefore sensitive; access to the FAD (configuration, backups, query interfaces) SHOULD be restricted to authorized operators, and retained records disappear automatically via TTL expiry. * Observability: per-peer traffic metadata (session times, message rates) is visible to operators of both gateways; no user- identifying information is carried by the protocol. 11. Operational and Manageability Considerations Operators of FAMS-P gateways SHOULD monitor the following metrics, consistent with the architecture's operational guidance: number of active peering sessions and session uptime; FAD size and growth rate per origin gateway; UPDATE and WITHDRAW rates; signature verification failure rate (an indicator of misconfiguration or attack); TTL expiry rate (a high rate may indicate origin refresh problems or network instability); and rate of policy rejections. Graceful shutdown: before administrative shutdown or decommissioning of a gateway or agent, the operator SHOULD withdraw the affected FMRs (UPDATE with Record-Flag=WITHDRAW) so that peers remove them immediately rather than waiting for TTL expiry. For planned shutdowns, the operator MAY lower TTL values in advance (allowing previously cached lifetimes to elapse before withdrawal) to shrink the stale-record window, consistent with the architecture's graceful- shutdown guidance. Network partition: records from unreachable peers remain in the FAD until TTL expiry; upon connectivity restoration, full resynchronization reconciles both sides automatically. Gateway recovery: a recovering gateway rebuilds its local table via the Local Discovery Plane, then re-originates its FMRs; if tombstone state was lost, it MUST first re-synchronize via FULL_SYNC (Section 7.4). 12. IANA Considerations This Standards-Track document requests the following IANA registrations: 1. Registration of the ALPN protocol identifier "fams" in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry. 2. Creation of the "FAMS-P Message Types" registry, with initial values: 1 (OPEN), 2 (FULL_SYNC), 3 (UPDATE), 4 (KEEPALIVE), 5 (NOTIFICATION). Values 6-254 are unassigned; 255 is reserved. Zhang Expires 17 April 2027 [Page 21] Internet-Draft Federated Agent Metadata Synchronization October 2026 3. Creation of the "FAMS-P FMR TLV Types" registry, with initial values: 1 (Entity-Identifier), 2 (Entity-Type), 3 (Endpoint), 4 (Origin-GW-ID), 5 (Publication-Timestamp), 6 (TTL), 7 (Capability-Summary), 8 (Record-Flag), 9 (Signature), 10 (Authentication-Hint), 11 (Trust-Reference), 12 (Provenance), 13 (Capability-Card-URI), 14 (Redistribution-Scope). Values 15-223 are unassigned; 224-254 are reserved for experimental use; 255 is reserved. 4. Creation of the "FAMS-P NOTIFICATION Error Codes" registry, with initial values 1-6 and subcodes as defined in Section 5.7. All registries defined by this document follow the "Specification Required" registration policy [RFC8126]. 13. Acknowledgements The authors thank the DAWN working group participants for their foundational work on agent discovery terminology, requirements, and gap analysis, and the participants in the mailing-list discussion of the DAWN discovery architecture for comments that shaped this protocol specification. FAMS-P builds directly on the two-layer federated reference architecture and the DAWN Minimum Discoverable Information (MDI) model. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . Zhang Expires 17 April 2027 [Page 22] Internet-Draft Federated Agent Metadata Synchronization October 2026 [RFC8126] Cotton, M. and B. Leiba, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase and Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stepanov, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, July 2014, . 14.2. Informative References [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, . [RFC9176] Amsuess, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, April 2022, . [I-D.akhavain-moussa-dawn-problem-statement] Akhavain, A., Moussa, H., and D. King, "Problem Statement for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-akhavain- moussa-dawn-problem-statement-05, July 2026, . Zhang Expires 17 April 2027 [Page 23] Internet-Draft Federated Agent Metadata Synchronization October 2026 [I-D.zhang-dawn-agent-discovery-framework] Zhang, B., Ed. and Y. Yang, Ed., "A Framework for Agent Discovery in DAWN", Work in Progress, Internet-Draft, draft-zhang-dawn-agent-discovery-framework-05, October 2026, . [I-D.cui-dawn-mdi-model] Cui, Y., "An Information Model for Minimum Discoverable Information (MDI)", Work in Progress, Internet-Draft, draft-cui-dawn-mdi-model-00, July 2026, . [I-D.cui-dns-native-agent-naming-resolution] Cui, Y., "DNS-Native AI Agent Naming and Resolution", Work in Progress, Internet-Draft, draft-cui-dns-native-agent- naming-resolution-01, March 2026, . [I-D.farrel-dawn-terminology] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-farrel-dawn-terminology-02, June 2026, . [I-D.jimenez-agent-directory] Jimenez, J., "Agent Directory", Work in Progress, Internet-Draft, draft-jimenez-agent-directory-01, May 2026, . [I-D.jimenez-dawn-discovery-landscape] Jimenez, J., Feng, J., Arkko, J., Kuehlewind, M., and R. Kandoi, "A Survey of AI Agent Discovery Mechanisms", Work in Progress, Internet-Draft, draft-jimenez-dawn-discovery- landscape-00, July 2026, . Zhang Expires 17 April 2027 [Page 24] Internet-Draft Federated Agent Metadata Synchronization October 2026 [I-D.kay-dawn-use-cases] King, D., Yao, K., and K. Adler, "Use Cases for the Discovery of Agents, Workloads, and Named Entities", Work in Progress, Internet-Draft, draft-kay-dawn-use-cases-00, June 2026, . [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-king-dawn-requirements-01, April 2026, . [I-D.klrc-aiagent-auth] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-02, June 2026, . [I-D.liu-agent-metadata-sync-protocol] Liu, B. and M. Han, "Agent Metadata Synchronization Protocol", Work in Progress, Internet-Draft, draft-liu- agent-metadata-sync-protocol-01, July 2026, . [I-D.mp-agntcy-ads] AGNTCY, "Agent Directory Service", Work in Progress, Internet-Draft, draft-mp-agntcy-ads, 2025, . [I-D.moussa-dawn-gap-analysis] Moussa, H. and A. Akhavain, "Gap Analysis and Applicability Statement for Discovery Protocols of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-moussa-dawn-gap-analysis-01, June 2026, . [I-D.mozleywilliams-dnsop-dnsaid] Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, May 2026, . Zhang Expires 17 April 2027 [Page 25] Internet-Draft Federated Agent Metadata Synchronization October 2026 [I-D.nemethi-aid-agent-identity-discovery] Nemethi, B., "Agent Identity and Discovery (AID)", Work in Progress, Internet-Draft, draft-nemethi-aid-agent- identity-discovery-00, March 2026, . [I-D.pioli-agent-discovery] Pioli, R., "Agent Registration and Discovery Protocol (ARDP)", Work in Progress, Internet-Draft, draft-pioli- agent-discovery-01, February 2026, . [I-D.yao-dawn-agent-discovery-architect] Yao, J., Geng, G., Chen, M., and H. Li, "DNS-like Agent Discovery Architecture", Work in Progress, Internet-Draft, draft-yao-dawn-agent-discovery-architect-00, July 2026, . [I-D.zahed-acap] Sarker, Z. and T. Reddy, "Agent Capability Advertisement Protocol (ACAP)", Work in Progress, Internet-Draft, draft- zahed-acap-00, June 2026, . Author's Address Bin Zhang (editor) Pengcheng Laboratory Sibilong Street Shenzhen China Email: zhangb@pcl.ac.cn Zhang Expires 17 April 2027 [Page 26]