Federated Agent Metadata Synchronization Protocol (FAMS-P)
draft-zhang-dawn-bgp-style-federated-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Bin Zhang | ||
| Last updated | 2026-10-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-dawn-bgp-style-federated-discovery-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[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, <https://www.rfc-editor.org/rfc/rfc6973>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015,
<https://www.rfc-editor.org/rfc/rfc7515>.
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, <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase and Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stepanov,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, July 2014,
<https://www.rfc-editor.org/rfc/rfc7301>.
14.2. Informative References
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013, <https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[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,
<https://www.rfc-editor.org/rfc/rfc9176>.
[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,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-05>.
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, <https://datatracker.ietf.org/doc/html/draft-zhang-
dawn-agent-discovery-framework-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-cui-dawn-mdi-
model-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-cui-dns-
native-agent-naming-resolution-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-02>.
[I-D.jimenez-agent-directory]
Jimenez, J., "Agent Directory", Work in Progress,
Internet-Draft, draft-jimenez-agent-directory-01, May
2026, <https://datatracker.ietf.org/doc/html/draft-
jimenez-agent-directory-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-jimenez-dawn-
discovery-landscape-00>.
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, <https://datatracker.ietf.org/doc/html/draft-
kay-dawn-use-cases-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-
king-dawn-requirements-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-
auth-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-liu-agent-
metadata-sync-protocol-01>.
[I-D.mp-agntcy-ads]
AGNTCY, "Agent Directory Service", Work in Progress,
Internet-Draft, draft-mp-agntcy-ads, 2025,
<https://spec.dir.agntcy.org>.
[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, <https://datatracker.ietf.org/doc/html/draft-moussa-
dawn-gap-analysis-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
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,
<https://datatracker.ietf.org/doc/html/draft-nemethi-aid-
agent-identity-discovery-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-pioli-agent-
discovery-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-yao-dawn-
agent-discovery-architect-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-zahed-acap-
00>.
Author's Address
Bin Zhang (editor)
Pengcheng Laboratory
Sibilong Street
Shenzhen
China
Email: zhangb@pcl.ac.cn
Zhang Expires 17 April 2027 [Page 26]