Network Working Group A. Hecker Internet-Draft Huawei Technologies Duesseldorf GmbH Intended status: Informational 28 October 2026 Expires: 1 May 2027 The Intent-to-Capability Knowledge Gap in Discovery of Agents With Names draft-hecker-dawn-intent-capability-gap-00 Abstract DAWN defines discovery as an initial step that returns minimum discoverable information (MDI) about entities. Clients, however, usually start from an intent, not from a name or a capability, and the capabilities needed to satisfy an intent depend on what is available. A client therefore has to know what is on offer to decide what to look for, and has to decide what to look for to learn what is on offer. This document describes that circular dependency, locates it in the current DAWN documents, compares five strategies for handling it, and lists questions for the Architecture work. The main question is what the MDI must contain for a client to act without a pre-agreed capability vocabulary. This document proposes no protocol. Editorial Note (to be removed before publication) Reviewed for this version: the DAWN charter (charter-ietf-dawn-01), [I-D.king-dawn-requirements] -02, [I-D.farrel-dawn-terminology] -05, [I-D.kay-dawn-use-cases] -01, [I-D.akhavain-moussa-dawn-problem- statement] -05, [I-D.mozley-aidiscovery] -01 (expired), and [I-D.iannone-dawn-privacy-considerations] -00 (mostly placeholders). The agentic AI use-case drafts were seen only in excerpts and are not analysed. REQ identifiers refer to requirements -02, which renumbered those of -01 that the use cases draft cites. 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/. 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 1 May 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. Table of Contents 1. Introduction 2. Terminology 3. The Knowledge Gap 3.1. The Circular Dependency 3.2. What This Is Not 3.3. Where the Gap Sits in the DAWN Documents 4. Strategies 5. Scalability of the Strategies 6. Questions for the DAWN Architecture 7. Security Considerations 8. Privacy Considerations 9. IANA Considerations 10. Informative References Appendix A. Worked Example Author's Address 1. Introduction The DAWN charter says clients need to learn how to reach AI resources and what those resources offer. It limits the work to the initial discovery of minimum public discovery information within a local network, an organisation, or between cooperating parties, and it excludes open-ended search, semantic matchmaking, ranking, and selection based on capabilities or user intent. The DAWN documents describe discovery as starting from a task or intent that is turned into a discovery request [I-D.kay-dawn-use- cases]. The step from intent to request is assumed, not described. This document examines it. An intent can usually be satisfied in several ways, each needing different capabilities, and the best way depends on what is available. What is available is learned by discovery, and discovery requests are formed from the chosen capabilities. The aim is to make the gap explicit so that the Architecture work can treat it deliberately and not define the MDI on the silent assumption that clients already know what to ask for. 2. Terminology The following terms are used as defined in [I-D.farrel-dawn- terminology]: Capability, Capability Card, Discovered Entity, Discovering Entity, Discovery, Discovery Information, Discovery Mechanism, Discovery Scope, Entity, Function, Minimum Discoverable Information (MDI), Properties, and Selection. This document adds four terms. Intent: A goal held by a discovering entity or by a user on whose behalf it acts, not necessarily expressed in terms of any published capability. Decomposition: A mapping from an intent to one or more plans, each a set of capabilities whose combined fulfilment would satisfy the intent. Capability Identifier: A token or description in which a discovery request or MDI expresses a Function or Capability. Scope Enumeration: A discovery request that asks for the MDI of all entities visible within a Discovery Scope, without filtering by capability. 3. The Knowledge Gap 3.1. The Circular Dependency 1. To form a discovery request, a client needs a decomposition of its intent, or at least candidate capabilities to ask about. 2. The best decomposition depends on which capabilities are available, and valid decompositions are usually numerous. 3. Which capabilities are available can be learned only by discovery. Take the intent "get to place X as fast as possible". If X is within walking distance in a dense city, a bicycle service may be best. If X is 30 km away, a taxi may be best. If X is 1000 km away, a train to an airport and a flight may be best. The client does not initially know its distance to X or what is around it, and learning those things is itself a matter of finding and querying resources. A client that cannot form a request cannot discover. A client that forms requests blindly either asks about many capabilities, which is costly and revealing, or about too few, and may miss a better plan. Sending the whole intent as the request is unlikely to match any published capability exactly, and it discloses the intent. 3.2. What This Is Not Bootstrapping: How a client learns which domain, network, or entry point to query is a known problem with known solutions, such as provisioning, configuration, or a first multicast query. This document assumes the client has an entry point for the Discovery Scope it cares about. Vocabulary definition: Agreeing that a printer is called a printer is a vocabulary problem. The gap persists even with a perfect dictionary. The client would know which names might exist, but not which are offered in this Discovery Scope, nor which combinations satisfy its intent. It could probe the dictionary entry by entry, but probing makes the gap a scalability and privacy problem: the number of probes grows with the dictionary, and the pattern of probes reveals the intent. The classic model, a query for a printer that handles a given page description language, assumes the client already holds the Capability Identifier. The gap concerns a client that holds only an intent. 3.3. Where the Gap Sits in the DAWN Documents Charter and terminology. The terminology draft defines Discovery as locating entities able to perform a desired function. It also breaks the discovery ecosystem into functions, one of which is search based on a "formalised encoding of search criteria", and places only the discovery lookup in scope. The gap sits between the two: lookup needs criteria, and producing criteria from an intent is not part of the work. Requirements. [I-D.king-dawn-requirements] requires discovery of both specific entities and classes of entities that can perform a function (REQ-DISC-1). It also says discovery starts from "a name or scope known to the discovering entity" (REQ-DISC-4). Together these describe discovery by function within a Discovery Scope. Nothing says how the function is chosen. The MDI is to include the type and "services it offers" (REQ-PROP-1), but the documents do not say whether that is an identifier or a description. A reference to a capability card is allowed, with its content out of scope (REQ-PROP-4). The requirements do help Scope Enumeration: results should say whether a Discovery Scope was fully searched or truncated (REQ-DISC-4), and absence may be reported only from a complete result (REQ-PROP-3). Use cases. The pattern in [I-D.kay-dawn-use-cases] runs from intent to request to candidates, and its examples begin at the request, with the organisation and capability already known. The problem statement lists chained, interactive, and reversed discovery among topics for the use cases document, and names blind or exploratory search among things current approaches do not handle [I-D.akhavain-moussa-dawn-problem-statement]. The current use cases draft has none of these as a category. Chained discovery, in which later queries depend on earlier results, is the circular dependency of Section 3.1 in iterative form. The problem statement also names semantic matching as a possible discovery mechanism, which sits uneasily with the charter exclusion. Discovery Scope. The terminology allows a Discovery Scope to be defined by administrative identifiers, trust domains, distance, geographic or jurisdictional boundaries, and time. A location- bounded scope can answer "what is near me", but a client has to reveal its location to use it. 4. Strategies Five ways of handling the gap are described. They differ in where matching happens and what they cost. They are not exclusive. A. Identifier probing. The client holds a vocabulary and queries for identifiers from candidate plans. It needs the vocabulary in advance, and a series of probes can reveal the intent. It scales poorly with open-ended intents. B. Intent forwarding. The client sends the intent, or a close paraphrase, to a catalog that matches it. This removes the circularity and needs no vocabulary, but it discloses the intent and is semantic matchmaking, which the charter excludes. C. Scope Enumeration with client-side matching. The client asks for all MDI in a Discovery Scope and evaluates it against its own plans. The intent never leaves the client. It works only where the Discovery Scope is small enough to enumerate and where the MDI is descriptive enough to interpret without a pre-agreed vocabulary. The charter example "discover all agents in this shop" is of this kind. D. Brokered discovery. The client discovers a planning or coordinating entity, such as a journey planner, by a coarse Capability Identifier, then gives it the intent in the application exchange. This keeps the intent out of discovery and semantic matching out of DAWN, but it still needs a coarse vocabulary and puts trust and privacy exposure on the broker. The requirements already ask for discovery of brokers (REQ-DISC-3). E. Reversed discovery. The client publishes its need as a discoverable object and providers find it, as the problem statement describes for tasks. This needs no vocabulary on the client side, but it publishes the intent to everyone who can see the Discovery Scope. +----------+------------+--------------+-------------+-------------+ | Strategy | Vocabulary | Intent seen | Fits | Main limit | | | in advance | by others | charter | | +==========+============+==============+=============+=============+ | A Probe | Full | Inferable | Yes | Probe count | +----------+------------+--------------+-------------+-------------+ | B Forward| None | Yes | No | Privacy | +----------+------------+--------------+-------------+-------------+ | C Enumer-| Depends on | No | Yes, if MDI | Scope size | | ate | MDI content| | stays small | | +----------+------------+--------------+-------------+-------------+ | D Broker | Coarse | Broker only | Yes | Broker trust| +----------+------------+--------------+-------------+-------------+ | E Reverse| None | Yes, public | Unclear | Privacy | +----------+------------+--------------+-------------+-------------+ Table 1 Within the charter as written, A, C, and D are available. A depends on a full vocabulary and D on a coarse one. C depends on what the MDI contains, which is the first question below. 5. Scalability of the Strategies The strategies differ mostly in who bears the scaling cost, not in whether there is one. This section is qualitative and assumes that no central registry is available (REQ-ARCH-1). +----------+------------------+-----------------+-----------------+ | Strategy | Main bottleneck | Who pays | Cacheable | +==========+==================+=================+=================+ | A Probe | Plans times | Client; the | Yes, exact | | | vocabulary size | vocabulary | match | +----------+------------------+-----------------+-----------------+ | B Forward| Matching over | The matching | No, intents | | | all offers | service | are unique | +----------+------------------+-----------------+-----------------+ | C Enumer-| Size of the | Client; and | Yes, same | | ate | scope and of MDI | publishers | for all clients | +----------+------------------+-----------------+-----------------+ | D Broker | Knowledge held | Brokers | Yes, for | | | by the broker | | finding one | +----------+------------------+-----------------+-----------------+ | E Reverse| Needs times | Providers and | No, needs are | | | watching parties | notification | short-lived | +----------+------------------+-----------------+-----------------+ Table 2 A: The server side scales like DNS-SD: exact match, cacheable, and delegable. The cost moves to the client, which probes more as intents become open-ended, and to the vocabulary. Privacy mitigations add cost; the privacy draft itself notes that private information retrieval may not cope with DAWN's scale. B: The worst fit. Matching free-form intents needs an aggregated index across domains, which conflicts with REQ-ARCH-1 and with independent publication (REQ-ARCH-2). C: Richer MDI reduces the need for a shared vocabulary but enlarges every enumeration. For a language-model client the limit is not bandwidth but context budget and interpretation cost, so C trades the vocabulary problem for a compute and trust problem. Dynamic properties defeat caching and are better carried by reference. C scales by hierarchy (a shop, a mall, a city), which makes the granularity of Discovery Scopes a real design question. D: Finding a broker is cheap, because broker types are few, coarse, and stable. The broker must know the offers, so the market tends toward a few large brokers, and brokers that discover brokers can cascade without bound. E: Write load follows the number of clients, and every provider must scan every need. It needs expiry and rate limiting. Intents that span several Discovery Scopes multiply the cost, because chained discovery needs sequential rounds. A and D handle this through delegation; C needs the client to know the scopes. The combination that scales best on paper is hierarchical: a coarse probe (A) finds the scope or broker, enumeration (C) runs inside a small scope, and a broker (D) handles cross-scope intents. What remains open is how a client finds the right scopes. 6. Questions for the DAWN Architecture MDI content. If Strategy C is to work without a shared vocabulary, the MDI must be interpretable on its own, which suggests descriptive content and not only an identifier. What keeps such content minimal, how is it language-tagged, and where does it end and a capability card begin? The terminology describes the MDI as a common header of a data structure, and "services offered" in REQ-PROP-1 does not settle this. Enumeration and abuse limits. Strategy C needs enumeration to be possible. The requirements ask the mechanism to limit abuse including scraping (REQ-SEC-3), and ask a specification to say whether it resists enumeration, failing which the set of discoverable entities is to be treated as public. The Architecture will have to say which Discovery Scopes allow enumeration, to whom, and at what cost. Truncation. REQ-DISC-4 asks for an indication of truncated results. What should a client do with a partial enumeration: page through it, narrow the Discovery Scope, or refine the request? Chained and multi-scope intents. An intent such as the long- distance case in Appendix A needs offers from several Discovery Scopes that the client does not know in advance. Finding them is an indexing problem, which the charter excludes. Is referral (REQ-DISC-3) expected to carry this, and should chained and interactive discovery be added to the use cases? Vocabulary ownership. Extensible schemas are required (REQ-EXT-1), but nobody is assigned to define Function identifiers, and the naming of entities is out of scope. Service types in existing service discovery come from a registry [RFC6763]. Can a registry keep pace with agent capabilities, and what would DAWN carry if none exists? 7. Security Considerations Integrity protection shows that discovery information was not altered in transit. It does not show that the information is accurate or safe to interpret. Strategy C asks clients to read descriptive MDI, often with a language model, so that content is untrusted input. A publisher can write descriptions to match as many intents as possible or to steer a client's behaviour; the AID draft already lists inputs from an index that modify agent reasoning as an adversarial use [I-D.mozley-aidiscovery]. Enumerations also let an attacker add or remove entries to shape a client's plan, and large results can exhaust a client's processing budget. 8. Privacy Considerations Discovery queries can reveal intent; the privacy draft gives a medical-dataset example [I-D.iannone-dawn-privacy-considerations]. The strategies differ in exposure. * Granularity: fine-grained queries are selective but reveal more; coarse queries reveal less and return more. A destination or a medical need should not appear in a discovery query. * Series: repeated probing (A) can reveal an intent when each query is coarse, and repeated queries to one service can be correlated. Private information retrieval, named in the privacy draft, may help but its scaling is unproven. * Enumeration (C): reveals the chosen Discovery Scope but not the intent. A location-bounded scope reveals location. * Brokers (D) learn the full intent, and reversed discovery (E) publishes it. * Multicast queries are visible to every node on the link. A sound default is to keep the intent out of the discovery exchange and to carry it only in an authenticated application exchange with an entity the client has chosen. 9. IANA Considerations This document has no IANA actions. 10. Informative References [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, 19 July 2026. [I-D.farrel-dawn-terminology] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet-Draft, draft-farrel-dawn-terminology-05, 19 October 2026. [I-D.iannone-dawn-privacy-considerations] Iannone, L. and A. Fressancourt, "Privacy Considerations for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-iannone-dawn-privacy-considerations-00, 22 May 2026. [I-D.kay-dawn-use-cases] King, D., Yao, K., Adler, K., and R. Ramdhany, "Use Cases and Applicability for Discovery of Agents With Names", Work in Progress, Internet-Draft, draft-kay-dawn-use-cases-01, 10 September 2026. [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet-Draft, draft-king-dawn-requirements-02, 19 October 2026. [I-D.mozley-aidiscovery] Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "AI Agent Discovery (AID) Problem Statement", Work in Progress, Internet-Draft, draft-mozley-aidiscovery-01, 16 April 2026. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. Appendix A. Worked Example A user's agent holds the intent "get to place X as fast as possible". The three situations of Section 3.1 need different capabilities: bicycle rental, a taxi, or local transit plus rail plus an airline. A (probing): The agent probes for bicycle, taxi, rail, and airline capabilities. It needs the identifiers beforehand, and the probes show that the user is travelling and roughly how. B (forwarding): The agent sends "get to X fast" to a catalog. It needs no identifiers, but the destination is disclosed. C (enumeration): The agent enumerates a Discovery Scope it knows, such as the local network or the city transport organisation, and matches locally. This covers the first two situations if the scope contains them. It does not cover the third unless the agent can find the rail and airline scopes (Section 6). D (broker): The agent discovers a journey planner by a coarse capability, then sends the destination to it in an application exchange. Discovery reveals only that a planner was sought. The user must trust the planner with the destination. E (reversed): The agent publishes "need a fast route to X". Any provider in the Discovery Scope can respond, and everyone there learns the destination. Author's Address Artur Hecker Huawei Technologies Duesseldorf GmbH Germany Email: [EMAIL TBD]