]> Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

Network Working Group discovery agents workloads named entities information model metadata The Discovery of Agents, Workloads, and Named Entities (DAWN) terminology document defines Minimum Discoverable Information (MDI) as the minimum information an entity must provide to be discoverable, but does not define its field-level content. The DAWN requirements and problem-statement documents identify the need for a standardized minimum structure; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document proposes a small, encoding-neutral information model, in the sense of RFC 3444, for MDI: three mandatory elements, a short set of recommended and optional elements, and the minimal constraints that hold among them. It is a minimum common subset and a mapping target for richer descriptors -- not a new card format and not a discovery protocol.

Introduction Distributed systems increasingly compose agents, workloads, and services that have no pre-configured relationship with one another. Before any interaction can begin, a discovering party needs a small amount of information about a remote entity: what it is, what it does, how to reach it, and what assurances, if any, accompany those claims. names this common header Minimum Discoverable Information (MDI) but intentionally does not define its fields; requires that discovery mechanisms convey base properties, communication parameters, capability descriptions, and trust-related information, distinguishing mandatory from optional and static from dynamic; calls directly for a standardized structure carrying the minimum information a discovery response returns; and sketches a provisional baseline without normalizing it. No DAWN document instantiates MDI as a field-level model. Meanwhile, the gap is being filled independently and incompatibly by adjacent ecosystems: DNS-based bootstrap (), well-known JSON manifests, agent cards, and signed capability documents each carry a slightly different minimal field set with slightly different semantics, each bound to its own substrate. A descriptor that is minimal and sufficient in one system is unreadable in another. This document proposes an information model in the sense of -- abstract, protocol- and encoding-neutral, derivable into many concrete data models -- for MDI: the elements of the common discovery header and the minimal constraints that hold among them. The intended division of labor is a three-part stack: terminology says what MDI is, this document proposes what MDI contains, and specific discovery mechanisms say how those contents are carried.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terms defined in , including Entity, Discovery, Discovery Information, Discoverable Object, Capability Card, Trust Indicator, and, centrally, Minimum Discoverable Information (MDI); readers are assumed to be familiar with that document. The elements defined here are the normalized slots through which a minimal subset of an entity's Properties is conveyed as Discovery Information. An MDI instance -- the collection of element values published or returned for one entity -- is itself Discovery Information and, where it is retrievable as a unit, can be regarded as a Discoverable Object. A Capability Card is a richer Discoverable Object that MDI points to; it is not part of MDI.

Scope and Non-Goals This document defines the abstract content of the MDI common header, and nothing else. It does NOT define:

• a discovery, query, resolution, or transport protocol, and it does not bind MDI to DNS or to any other carrier;
• a wire format, serialization, or schema; representations are illustrative ();
• a new capability card, or a replacement for any existing descriptor;
• identity verification, authentication, authorization, policy evaluation, or attestation procedures;
• capability exchange, negotiation, selection, registration, or invocation semantics.

MDI is advertised information, positioned strictly below entity verification: by itself it asserts nothing a discovering party should treat as verified. Trust-related elements carry references and hints only.

Design Principles

Encoding-neutral model:

Per , one information model can be carried by many concrete data models -- a JSON object, a CBOR map, a set of DNS records. Those are carriers; MDI is the shared meaning they carry.

Thin core, rich references:

MDI is a header. Rich or sensitive structures -- capability cards, proofs, certificates, policy documents -- are referenced, not embedded, and fetched only when needed.

Discovery-time only:

MDI carries what lets a discovering party identify an entity, decide whether follow-up is worthwhile, and dereference the next object safely -- not negotiation state, selection criteria, or invocation contracts.

Freshness and rate of change matter -- elements are marked static, mainly-static, or dynamic, and validity information is first-class -- but detailed cache behavior belongs to bindings ().

MDI Information Model An MDI instance is the common header published or returned for one entity. Only three elements are mandatory -- Entity Identifier, Entity Type, and Endpoint -- so that an entity can be discoverable with a very small record; in constrained carriers, a binding may derive mandatory values from the carrier itself (). Everything else is recommended or optional. The element set instantiates the conveyance requirements of , including the mandatory/optional and static/dynamic distinctions. Status key words in this document place obligations on the publishers and bindings that claim to carry MDI; an abstract model has nothing that could conform on its own. Status governs whether an element is conveyed at all; cardinality governs how many values of it may be carried. Obligations specific to binding documents are collected in .

Structure shows the elements and their shapes. Composite members marked "?" are optional, and an element whose members are all optional (freshness, operational-hint) is present only when at least one member is present; all other structure is given by the cardinalities.

Elements of the MDI model Entity +--------------+ |- entity-identifier (1) |- entity-type (1) |- entity-summary (0..n) |- Endpoint { locator-type, locator, | protocols (1..n) } (1..n) |- capability-summary (0..n) |- capability-reference : Reference (0..n) |- trust-reference : Reference (0..n) |- authentication-hint { scheme, metadata? } (0..n) |- freshness { version?, valid-from?, | valid-until?, refresh-hint? } (0..1) |- provenance { publisher, | responsible-party? } (0..1) |- scope-hint (0..n) |- operational-hint { status?, detail? } (0..1) |- extension { name, value } (0..n) Reference = { ref-type, locator, digest? } ]]>

A Reference is a typed pointer: the ref-type says how to interpret the locator, and the optional digest is an integrity digest over the object the locator identifies ().

Elements

Element	Status	Class	Purpose
Entity Identifier	MUST	static	Stable handle within a publisher scope
Entity Type	MUST	static	Coarse type of the entity
Endpoint	MUST	mainly-static	Where and by which protocols follow-up proceeds
Entity Summary	SHOULD	static	Short human-readable description
Capability Summary	SHOULD	mainly-static	Discovery-time triage tags
Capability Reference	SHOULD	mainly-static	Pointer to richer capability information
Authentication Hint	SHOULD	mainly-static	Hint for follow-up access
Trust Reference	SHOULD	mainly-static	Pointer to assurance material
Freshness	SHOULD	dynamic	Version or validity information
Provenance	SHOULD	static	Publisher or responsible party
Scope Hint	MAY	mainly-static	Opaque discovery-scope hint
Operational Hint	MAY	dynamic	Coarse availability hint
Extension	MAY	varies	Type-specific extension

A static value does not change for the lifetime of the Entity Identifier. A mainly-static value changes only through deliberate administrative or deployment action. A dynamic value can change in normal operation and is evaluated together with Freshness.

Entity Identifier:

An opaque, stable handle for the entity within a publisher scope (). It is a name -- not a verified identity, key, or proof -- and it anchors caching and deduplication.

Entity Type:

The kind of entity (for example agent, workload, or service); it lets a discovering party triage before fetching anything. The value space is left to DAWN, bindings, or profiles to define.

Entity Summary:

A short human-readable description with no machine semantics; language handling, if any, is a binding matter.

Endpoint:

A composite of locator-type, locator, and one or more protocols spoken at that endpoint: where follow-up can proceed and in which protocol families, not how to speak. An entity whose endpoints speak different protocols is expressible without loss.

Capability Summary:

Coarse, machine-readable capability tags for discovery-time filtering and triage; they are not sufficient for selection, negotiation, authorization, or invocation. Full capability detail lives behind a Capability Reference.

Capability Reference:

A Reference to a fuller capability description, such as a Capability Card, retrieved on demand.

Authentication Hint:

The authentication scheme(s) a discovering party would need for follow-up, optionally with a Reference to authentication metadata. Never credentials, never authorization logic.

Trust Reference:

A Reference to a trust indicator -- a signature, certificate, attestation, trust manifest, or key set. A pointer, not a procedure.

Freshness:

Version, validity window, and refresh hint for the instance.

Provenance:

Who published this discovery information and, optionally, the party responsible for the entity -- information-layer provenance, not verified identity.

Scope Hint:

An opaque hint about discovery scope, audience, jurisdiction, or visibility -- deliberately no more than an extension point, so as not to pre-empt scope and policy work under way elsewhere.

Operational Hint:

A coarse availability or health class, or a Reference to richer operational state, or both.

Extension:

An extension named by a binding, profile, or future registry, carrying type-specific or ecosystem-specific information. An Extension does not alter core element semantics and does not reintroduce a non-goal of .

Minimal Constraints The following rules are part of the model. A binding MAY tighten them but MUST NOT relax them.

1. An MDI instance describes exactly one entity. A discovery response may carry multiple instances; aggregation is a carrier matter.
2. An Entity Identifier is scoped by a publisher scope. How that scope is determined and how identifier and token values are compared are defined by the binding, with exact match as published as the default. Within one publisher scope, equal identifiers denote the same entity; inequality does not by itself imply distinct entities, and across publisher scopes this model makes no sameness claim. Where a consumer holds multiple instances for the same identifier, reconciliation is guided by Freshness and otherwise left to the binding.
3. Protocols attach to endpoints, not to the instance as a whole. An instance-level protocol list, where a binding offers one, is derived information -- the union over all endpoints -- and cannot diverge from them. The model attaches no meaning to the order of Endpoints; preference and selection are binding or carrier matters.
4. A digest, when present, is a member of the Reference it protects and covers exactly the object that Reference locates. Integrity is not trust: a matching digest shows that the bytes are intact, not that the publisher or the entity should be believed. How a digest value identifies its algorithm is defined by the binding.
5. A consumer MUST ignore unrecognized Extensions and Scope Hints; their presence is never an error.

Binding Expectations MDI reaches the wire through bindings: documents that map this model onto a concrete encoding or discovery mechanism. A binding that carries MDI MUST specify:

• how each carried element is encoded;
• how mandatory values are derived from the carrier where they are implicit (for example, an Entity Identifier taken from a DNS owner name); an implicit value participates in comparison and constraints exactly as if it were carried explicitly;
• how the publisher scope is determined (for example, from a web origin);
• how carrier freshness (a DNS TTL, an HTTP cache lifetime) interacts with the Freshness element, with the earlier applicable expiry prevailing;
• how unrecognized Extensions are carried and skipped at the encoding level;
• which value space applies to each element that has one, and whether it is defined by the binding, a profile, or a future registry.

A binding MAY tighten Status, cardinality, or constraints, including per entity type, but MUST NOT relax a MUST element or a rule of . Existing discovery formats already approximate bindings of this model (); normative bindings are expected in separate documents.

Security Considerations MDI is advertised information; a consumer MUST treat it as unverified until corroborated by mechanisms outside this document.

• Any element can be forged by whoever publishes it: an Entity Identifier is not proof of identity, and an Endpoint does not prove that the reachable party is the intended entity. Acting on unverified MDI carries the usual risks of contacting an untrusted endpoint.
• A digest provides integrity for a referenced object, not trust in the publisher or the entity; a Trust Reference locates assurance material but confers none until that material is verified by procedures defined elsewhere.
• Integrity and authenticity of MDI in transit, including protection against the removal of optional elements, are properties of the binding and carrier (for example DNSSEC, TLS), not of this model. A consumer SHOULD NOT draw conclusions from the absence of an element, and a value derived implicitly from a carrier is exactly as trustworthy as the carrier mechanism that produced it.
• A Reference locator is supplied by an unverified party; the usual dereferencing protections apply, such as limits on redirects and response sizes, and the filtering of locators that resolve to internal or link-local addresses.

Privacy Considerations Publishing MDI can reveal entity names, endpoints, organizational structure, capability hints, and scope information. Publishers SHOULD minimize public MDI to what discovery requires and SHOULD place sensitive information -- detailed capabilities, policy, internal topology, operational state -- behind access-controlled references.

IANA Considerations Future revisions or binding documents may request registries for selected MDI value spaces, such as entity types or capability tags; existing registries are to be reused where applicable.

References Normative References Old Dog Consulting China Mobile Deutsche Telekom Infoblox The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. Huawei Technologies Canada Huawei Technologies Canada Old Dog Consulting Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. Huawei Technologies Canada Huawei Technologies Canada This Internet-Draft provides a gap analysis and applicability statement that maps existing Discovery Mechanisms and protocols to the DAWN problem statement and discovery requirements. The analysis evaluates security, privacy, applicability, flexibility, and suitability of existing standardized, non-standardized, and proposed discovery solutions and protocols to the DAWN problem statement and REQ-DISC corpus. It identifies high priority gaps, proposes mitigations and hybrid patterns, and serves as reference for future prototyping and development. The intention is for this draft to evolve as new solutions come to existence. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

Illustrative JSON Example This example is illustrative only; no encoding is normative in this document.

Mapping Notes MDI is a common subset of, and a translation target for, existing discovery formats; it does not replace them. The table sketches where its mandatory elements and two recurring recommended elements surface in SVCB-based DNS discovery records (, ) and in the generic well-known-JSON and agent-card patterns (no single specification is implied). Field names are indicative; full mappings belong to binding documents.

MDI element	DNS-AID (SVCB)	Well-known JSON	Agent Card
Entity Identifier	owner name / target	identity	agent_id
Entity Type	(label/context)	(metadata)	(metadata)
Endpoint locator	TargetName	endpoints	endpoint.url
Endpoint protocols	alpn	(in endpoints)	endpoint.protocol
Capability Reference	cap	descriptor URI	(the card itself)
Freshness	DNS TTL	version	version

Each format keeps the protocol attached to the endpoint that speaks it (alpn per TargetName, endpoint.protocol), an association the Endpoint composite preserves; carrier-specific selection metadata, such as SVCB priorities, remains with the carrier.

Acknowledgements The author thanks Chenguang Du for his valuable contributions to the design and text of this draft. This work builds on the DAWN terminology, requirements, problem statement, and gap-analysis documents.