Federated Agent Metadata Synchronization Protocol (FAMS-P)

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.¶

• 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.¶

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 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.¶

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.¶

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).¶

• 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.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.¶

• 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).¶

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.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.¶

• 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).¶

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.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.¶

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.¶

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.¶

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.¶

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.¶

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.¶

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>.

[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>.

[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>.

[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>.

[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>.