Network Working Group L. Dunbar Internet Draft Futurewei Intended status: Informational Expires: April 13, 2027 October 13, 2026 Infrastructure-Assisted Discovery for AI Agents draft-dunbar-dawn-infra-assisted-discovery-00 Abstract This document describes an infrastructure-assisted approach to AI-agent discovery. An orchestration, placement, or hosting system can publish current deployment and reachability information for available AI-agent services or instances. Separately, network infrastructure can derive an abstract Attachment Scope representing the network context applicable to a requester. A discovery mechanism combines requester intent, currently published AI-agent resources, and the requester's Attachment Scope to identify applicable agent instances. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt xxx, et al. Expires April 13, 2027 [Page 1] Internet-Draft Infrastructure Assisted Discovery The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 13, 2026 . 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction..............................................3 2. Conventions used in this document.........................5 3. Problem Statement.........................................6 4. Gap Analysis: DNS-SD and AI-Agent Discovery...............8 4.1. Service Type Limitations.............................9 4.2. External Deployment State...........................10 4.3. Discovery Domain vs. Network Scope..................11 4.4. Hidden Network Context..............................12 4.5. Discovery vs. Selection.............................12 5. Infrastructure-Assisted Discovery Model..................13 5.1. Requester Criteria..................................14 5.2. Published Resource State............................14 5.3. Requester Scope.....................................15 5.4. Discovery Processing................................15 5.5. Metadata and Deployment State.......................16 5.6. Applicability Versus Selection......................17 5.7. Relationship to Specific Discovery Mechanisms.......17 6. Resource Publication and Update..........................18 6.1. Logical Service vs. Instance Publication............18 6.2. Cloud Deployment Example............................19 Dunbar, et al. Expires Dec 13, 2027 [Page 2] Internet-Draft Infrastructure Assisted Discovery 6.3. 5G Edge Deployment Example..........................19 6.4. Publication Lifecycle...............................20 7. Attachment Scope Determination and Update................20 7.1. Policy-Based Mapping................................21 7.2. Requester Attachment Scope..........................21 7.3. Scope Policy........................................22 7.4. Mobility and Reassociation..........................23 8. Applying the Model to DNS-SD.............................23 8.1. DNS-SD Mapping......................................24 8.2. DNS-SD Publication..................................25 8.3. Applying Attachment Scope...........................26 8.3.1. Scope to Domain Mapping........................26 8.3.2. Filtering Resources After Enumeration..........27 8.4. Agent Metadata in DNS-SD............................28 8.5. Discovery Result....................................29 8.6. Caching and Freshness...............................30 8.7. No Match............................................31 9. Second-Stage Agent Metadata Retrieval....................32 10. Relationship to Resource Selection......................33 11. Alternative methods.....................................33 12. Security Considerations.................................34 13. IANA Considerations.....................................35 14. References..............................................35 14.1. Normative References...............................35 14.2. Informative References.............................35 15. Acknowledgments.........................................36 Appendix A:.................................................36 1. Introduction AI-agent discovery is being explored in several DAWN documents. The DAWN use-case work describes scenarios in which clients need to discover AI resources and obtain information required for subsequent interaction. Other DAWN contributions examine gaps in existing discovery protocols, identify information that may need to be discoverable, describe local discovery using mDNS/DNS-SD, and propose broader discovery architectures and frameworks. This document complements those efforts by focusing on managed enterprise, cloud, edge-computing, and communication- network deployments in which infrastructure already maintains information that can assist AI-agent discovery. In such environments, orchestration, placement, hosting, gateway, or management systems can provide current Dunbar, et al. Expires Dec 13, 2027 [Page 3] Internet-Draft Infrastructure Assisted Discovery information about which AI-agent services or instances are available and how they can be reached. Separately, network infrastructure can provide an abstract "Attachment Scope" representing the requester's current network applicability context. This document defines two infrastructure integration points: o a "Resource Publication Hook", through which authorized deployment infrastructure makes current AI-agent service or instance information available to the discovery mechanism; and o an "Attachment Context Hook", through which trusted network infrastructure provides the requester's current Attachment Scope. The discovery mechanism combines these infrastructure- provided inputs with requester-supplied discovery criteria and relevant agent metadata to identify AI-agent resources applicable to the request. The proposed hooks are intended to assist existing discovery mechanisms rather than replace them. For example, the local discovery approach described in [DAWN-MDNS] reuses mDNS and DNS-SD for AI-agent discovery. The infrastructure-assisted model described here follows the same principle of reusing existing discovery mechanisms, while adding support for managed deployments in which agent deployment state and requester network context are maintained by infrastructure. Similarly, the Resource Publication Hook and Attachment Context Hook can provide infrastructure-facing inputs to broader DAWN discovery architectures, such as those described in [DAWN-FRAMEWORK], without requiring those architectures to depend on a particular access, cloud, or mobile-network technology. The infrastructure assistance described in this document uses authorized control-plane or management information. It does not require infrastructure to inspect, intercept, or participate in agent-to-agent communications. Dunbar, et al. Expires Dec 13, 2027 [Page 4] Internet-Draft Infrastructure Assisted Discovery This document does not define a new wire protocol. The model can be applied to DNS-SD, registries, directories, federated discovery systems, or other AI-agent discovery mechanisms. 2. Conventions used in this document 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following acronyms and terms are used in this document: AI Agent: A software entity that uses artificial intelligence techniques to interpret context, make decisions, and take actions toward achieving one or more goals, possibly by interacting with users and by invoking other agents, tools, or services. Attachment Context Hook: An infrastructure integration point through which trusted network infrastructure provides the requester's current Attachment Scope to the discovery mechanism. Attachment Scope: An abstract network-derived context representing an attachment or reachability domain applicable to a requester or discoverable resource. Discovery Mechanism: A mechanism that receives discovery intent and returns one or more applicable AI- agent resources. The mechanism may use DNS-SD, a registry, a directory, a federated discovery system, or another technique. Logical AI-Agent Service: An AI-agent service whose functional identity can remain stable while the number, location, or endpoints of its runtime instances change. Dunbar, et al. Expires Dec 13, 2027 [Page 5] Internet-Draft Infrastructure Assisted Discovery Requester: An entity initiating an AI-agent discovery operation. The requester may itself be an AI agent or another application acting on behalf of one. Resource Publication Hook: An infrastructure integration point through which an authorized orchestration, placement, hosting, gateway, or management system makes current AI-agent service or instance information available to the discovery mechanism. 3. Problem Statement AI agents are increasingly deployed as software services in enterprise networks, cloud environments, edge-computing platforms, and communication networks. An AI agent may provide functions such as reasoning, information retrieval, translation, content generation, task execution, or interaction with external tools and services. Although AI agents may use conventional cloud-native deployment techniques, their interaction model can be more heterogeneous than that of many traditional software services. A conventional service is often accessed through a known API or interface contract once its endpoint is located. Different AI agents, however, may support different communication protocols, invocation methods, request or response schemas, authentication procedures, supported modalities, tools, task formats, or agent-specific parameters. A2A provides one example. An A2A Agent Card can describe an agent's identity, supported interfaces, capabilities, skills, security information, and other properties required for interaction. Therefore, locating an AI-agent endpoint and understanding how to interact with that agent can be separate operations. This creates an opportunity to use a lightweight discovery stage to identify an applicable AI-agent service or instance and then retrieve richer agent metadata through a subsequent agent-specific mechanism. Dunbar, et al. Expires Dec 13, 2027 [Page 6] Internet-Draft Infrastructure Assisted Discovery In managed deployments, information relevant to the lightweight discovery stage may be distributed among several infrastructure systems. For example, an orchestration, placement, or hosting system may know: - which AI-agent services or instances currently exist; - where an instance is deployed; - which externally reachable endpoint corresponds to that instance; - whether multiple instances share a common service endpoint; - when an instance is moved or replaced; and - when an instance is withdrawn. The AI-agent application itself need not maintain complete knowledge of this deployment state, particularly when it operates behind a load balancer, service mesh, reverse proxy, gateway, or other hosting infrastructure. Network infrastructure may separately possess information useful for determining which AI-agent resources are applicable to a requester. Such information can include: - access-network attachment; - enterprise or tenant context; - VPN or routing context; - DNN; - network slice; - serving UPF or UPF group; - edge-computing domain; or - another reachability-related network context. Requiring the requester to understand and explicitly include such network information can couple application-layer Dunbar, et al. Expires Dec 13, 2027 [Page 7] Internet-Draft Infrastructure Assisted Discovery discovery to network-specific technologies. Conversely, exposing detailed network topology or low-level identifiers directly through an AI-agent discovery mechanism can create unnecessary complexity and information exposure. Deployment information and rich agent metadata may also change at different rates. For example, an image-analysis agent may move from one edge location to another while retaining the same skills, interfaces, authentication model, and Agent Card. Changes to deployment location or endpoint do not necessarily require changes to the agent's functional metadata, such as its capabilities, skills, supported interfaces, or Agent Card. There is therefore value in separating: - information describing what an AI agent is and how it can be used; - information describing where currently deployed instances can be reached; and - information describing the requester's current attachment or reachability context. There is therefore a need to combine requester-provided discovery criteria and relevant agent metadata with current deployment information and network-derived Attachment Scope, without requiring the requester to understand network specific attachment details. The infrastructure-assisted discovery model described in this document addresses this problem by allowing deployment and network infrastructure to contribute this information to the discovery process. 4. Gap Analysis: DNS-SD and AI-Agent Discovery DNS-Based Service Discovery [RFC6763] provides a well- established mechanism for discovering instances of a particular service type within a discovery domain. A client identifies a service type and domain and obtains service instances. SRV records identify where an instance can Dunbar, et al. Expires Dec 13, 2027 [Page 8] Internet-Draft Infrastructure Assisted Discovery be reached, while TXT records may provide a small amount of additional service-specific information. This model provides a useful foundation for AI-agent discovery. draft-jakab-dawn-agent-discovery-mdns applies this approach to local AI-agent discovery and describes a two-stage model in which DNS-SD performs lightweight enumeration and the agent's native protocol subsequently provides the complete agent description. This document adopts that two-stage principle. However, DNS- SD by itself does not address several deployment conditions relevant to managed AI-agent environments. 4.1. Service Type Limitations For many conventional services, knowing the service type, host, port, and protocol can be sufficient to initiate application-level communication. AI-agent interaction may require additional information before meaningful interaction can begin. For example, an A2A requester may need to obtain an Agent Card describing: o supported interfaces; o skills; o capabilities; o security requirements; o interaction characteristics; and o other agent-specific information. Trying to represent all such information in DNS-SD TXT records would duplicate metadata that is already available through the agent's native description mechanism and could make the discovery layer unnecessarily complex. A more practical approach in some deployments is to use lightweight discovery to identify an applicable agent instance or endpoint, and then retrieve richer agent-native metadata only when needed before interaction: Dunbar, et al. Expires Dec 13, 2027 [Page 9] Internet-Draft Infrastructure Assisted Discovery Lightweight discovery | v Agent instance / endpoint | v Retrieve agent-native metadata | v Interaction 4.2. External Deployment State Traditional DNS-SD commonly assumes that a service or the system hosting it registers the appropriate service-discovery information. Managed AI-agent environments may involve additional deployment abstraction. For example, an orchestration system can create several runtime instances of the same logical A2A service: Vision Agent Service | +-----------+-----------+ | | | v v v Instance-A Instance-B Instance-C The instances may share the same Agent Card and capabilities while having different endpoints or attachment contexts. Alternatively, the three instances may sit behind one stable service endpoint: Vision Agent Service | Common Endpoint | +--------+--------+ | | | A B C Dunbar, et al. Expires Dec 13, 2027 [Page 10] Internet-Draft Infrastructure Assisted Discovery In this case, changes to the backend instances need not change agent metadata or the externally published discovery endpoint. A discovery architecture therefore benefits from distinguishing the logical AI-agent service from currently deployed instances. 4.3. Discovery Domain vs. Network Scope DNS-SD uses a discovery domain to determine where service enumeration occurs. In a managed communication network, however, the set of agent instances applicable to a requester may depend on a network context that is different from a DNS administrative domain. For example, two requesters using the same DNS namespace may be associated with: o different enterprise VPNs; o different DNNs; o different network slices; o different UPFs; o different edge domains; or o different tenant contexts. Those requesters may therefore have access to different edge- resident AI-agent instances even though they query the same general service category. Conversely, several underlying network states may belong to the same discovery applicability domain. For example: UPF-A + DNN-X + Slice-1 ----+ | UPF-B + DNN-X + Slice-1 ----+--> Attachment Scope X | VPN-X + Enterprise-A -------+ DNS-SD does not itself define such a mapping between requester-side network state and discovery applicability. Dunbar, et al. Expires Dec 13, 2027 [Page 11] Internet-Draft Infrastructure Assisted Discovery 4.4. Hidden Network Context A requester can reasonably know what type of AI-agent service it seeks. For example: Service-Category: Vision-Inference It should not necessarily need to know: Serving-UPF DNN S-NSSAI VRF BNG Access Circuit Edge Domain Those properties belong to the infrastructure. Requiring an AI-agent application to understand them creates unnecessary coupling between application discovery and network architecture. 4.5. Discovery vs. Selection Existing service-discovery and service-routing systems often use region, zone, or locality information to steer a request toward a preferred instance. The Attachment Scope described in this document serves a different initial purpose. It identifies the network context within which an AI-agent resource is applicable to a requester. For example: Requester Intent: Vision-Inference Attachment Scope: AScope-A Published Instances: Agent-A -> AScope-A Dunbar, et al. Expires Dec 13, 2027 [Page 12] Internet-Draft Infrastructure Assisted Discovery Agent-B -> AScope-B Agent-C -> Shared-Cloud The discovery mechanism may determine that Agent-A and Agent- C are applicable. A later selection mechanism can choose between them based on latency, load, cost, GPU availability, or another dynamic factor. Thus: Discovery: Which resources are applicable? Selection: Which applicable resource should be used? The two functions are intentionally separated. 5. Infrastructure-Assisted Discovery Model The infrastructure-assisted discovery model combines information from the requester, deployment infrastructure, network infrastructure, and the discovery mechanism. The purpose of the model is to allow infrastructure that already maintains deployment and network state to contribute that information to AI-agent discovery, without requiring the requesting AI agent to understand the underlying deployment or network-specific details. The model uses three primary categories of information: Requester Discovery Criteria + Published AI-Agent Resource State + Requester Attachment Scope | v Discovery Mechanism | v Applicable AI-Agent Resources Dunbar, et al. Expires Dec 13, 2027 [Page 13] Internet-Draft Infrastructure Assisted Discovery 5.1. Requester Criteria The requester provides information describing what it wants to discover. The request may identify: - a specific AI-agent resource; - an AI-agent service category; - a subtype; - a supported interaction protocol; - a capability or skill; - or other agent-related discovery criteria supported by the discovery mechanism. The requester is not required to provide network-specific information such as a serving UPF, DNN, network slice, VPN, access point, or edge domain. 5.2. Published Resource State Deployment infrastructure provides information describing the AI-agent resources currently available for discovery. This information can include: o logical service identifier; o instance identifier; o reachable endpoint; o communication protocol; o current deployment state; o Attachment Scope associated with the resource, when applicable; and o a reference to additional agent metadata. The Resource Publication Hook described in Section 6 provides this information to the discovery mechanism. The published resource may represent either: o a logical AI-agent service exposed through a stable endpoint; or Dunbar, et al. Expires Dec 13, 2027 [Page 14] Internet-Draft Infrastructure Assisted Discovery o an individually reachable runtime instance. The choice depends on how the AI-agent service is deployed and exposed. Deployment infrastructure is responsible for keeping this information consistent with the actual deployment state. 5.3. Requester Scope Trusted network infrastructure determines the requester's current Attachment Scope from network attachment or reachability state. The Attachment Scope abstracts network-specific information such as: o access attachment; o VPN or routing context; o DNN; o network slice; o serving UPF; o tenant context; or o edge domain. The Attachment Context Hook described in Section 7 provides the resulting Attachment Scope to the discovery mechanism. The Attachment Scope is infrastructure-provided context. It is not required to be supplied by the requester and does not need to be exposed to the requester. 5.4. Discovery Processing The discovery mechanism combines requester discovery criteria with current published resource state and the requester's Attachment Scope. Dunbar, et al. Expires Dec 13, 2027 [Page 15] Internet-Draft Infrastructure Assisted Discovery The mechanism can also use agent metadata that it maintains, indexes, or references. Conceptually: Agent Metadata | v Requester Intent --> Candidate Identification | v Candidate Resources | +------------------+ | | v | Attachment Scope | | | +--------+---------+ | v Applicability Processing | v Applicable Resources Agent-related criteria determine which resources can satisfy the requester's functional intent. Attachment Scope determines which of those candidate resources are applicable from the requester's current network context. These two functions are complementary. 5.5. Metadata and Deployment State Agent metadata and deployment state describe different properties and can change independently. For example, an A2A Agent Card can describe an agent's capabilities, skills, supported interfaces, and security requirements. The same logical agent service can be deployed at several locations or moved between locations without changing those properties. Dunbar, et al. Expires Dec 13, 2027 [Page 16] Internet-Draft Infrastructure Assisted Discovery Conversely, deployment infrastructure can update an endpoint, instance identifier, or associated Attachment Scope without requiring the underlying functional description of the agent to change. The discovery mechanism may maintain or reference both kinds of information, but they need not be represented or updated in the same way. 5.6. Applicability Versus Selection The result of infrastructure-assisted discovery is a set of AI-agent resources that are applicable to the requester. The discovery mechanism does not necessarily select the optimal resource from that set. For example, discovery may determine that two AI-agent instances are both applicable: Agent-A Agent-B A subsequent selection function can choose between them based on factors such as latency, network condition, compute load, accelerator availability, cost, or application policy. The distinction between discovery applicability and resource selection is described further in Section 10. 5.7. Relationship to Specific Discovery Mechanisms The infrastructure-assisted model is independent of a particular discovery protocol. The Resource Publication Hook and Attachment Context Hook provide inputs to the discovery process, while the underlying discovery mechanism can use DNS-SD, a registry, a directory, a federated discovery system, or another mechanism. Section 8 describes how the model can be realized using DNS- SD as an example. Dunbar, et al. Expires Dec 13, 2027 [Page 17] Internet-Draft Infrastructure Assisted Discovery The model does not require changes to agent-to-agent communication protocols and does not require infrastructure to inspect the contents of agent communications. 6. Resource Publication and Update The Resource Publication Hook allows deployment infrastructure to maintain information about AI-agent resources currently available for discovery. The procedure can be illustrated using an A2A deployment. An A2A Agent Card describes the agent's interaction-related characteristics. The Resource Publication Hook instead describes current deployment and reachability state. For example: Logical-Service-Identifier: Vision-Inference Instance-Identifier: Vision-Agent-A Service-Category: Vision-Inference Endpoint: https://vision-a.edge.example Attachment-Scope: AScope-A Protocol: A2A Agent-Card-Reference: https://vision-a.edge.example/.well-known/agent-card.json 6.1. Logical Service vs. Instance Publication Where multiple runtime instances share a stable service endpoint: Document-Analysis-Agent | v Stable Service Endpoint | +----+----+----+ | | | | A B C D the discovery mechanism may publish only: Logical-Service-Identifier: Document-Analysis-Agent Endpoint: https://document-agent.example Dunbar, et al. Expires Dec 13, 2027 [Page 18] Internet-Draft Infrastructure Assisted Discovery Protocol: A2A Agent-Card-Reference: https://document-agent.example/.well-known/agent- card.json Scaling from four instances to eight need not modify the discovery publication. If the instances are independently reachable or have different Attachment Scopes, they may instead be published individually. 6.2. Cloud Deployment Example An A2A agent hosted on a Kubernetes-based cloud platform may be exposed through a Kubernetes Service, ingress gateway, or externally assigned endpoint. When the common endpoint remains stable, backend Pod creation or removal need not affect discovery. If the externally visible endpoint changes because the service is moved to another cluster: Before: Endpoint: cluster-a.example/agent After: Endpoint: cluster-b.example/agent the orchestration infrastructure can update the publication while the Agent Card remains unchanged. 6.3. 5G Edge Deployment Example Consider two runtime instances of the same logical AI-agent service: Edge Orchestrator / \ v v Edge-A Edge-B Agent-A Agent-B Dunbar, et al. Expires Dec 13, 2027 [Page 19] Internet-Draft Infrastructure Assisted Discovery | | UPF-A UPF-B The publications may be: Agent-A Logical-Service: Vision-Inference Endpoint: vision-a.edge.example Attachment-Scope: AScope-A and: Agent-B Logical-Service: Vision-Inference Endpoint: vision-b.edge.example Attachment-Scope: AScope-B If Agent-A moves to another edge environment, the infrastructure can change its endpoint and scope or withdraw the old instance and publish a new one. 6.4. Publication Lifecycle Publication events can include: - initial deployment; - new instance creation; - endpoint assignment; - scale-out or scale-in; - migration; - gateway change; - Attachment Scope change; - failure or unavailability; and - withdrawal. The publication mechanism may be event-driven, controller- driven, registry-based, DNS-based, or implemented through another infrastructure interface. 7. Attachment Scope Determination and Update Attachment Scope abstracts network state that is relevant to discovery applicability. Dunbar, et al. Expires Dec 13, 2027 [Page 20] Internet-Draft Infrastructure Assisted Discovery The network may derive Attachment Scope from one or more constructs, including: - access network; - cell or tracking area; - serving UPF or UPF group; - DNN; - network slice; - VPN or VRF; - enterprise or tenant context; - edge domain; or - other network reachability state. For example: UPF: UPF-A DNN: enterprise-ai Slice: Slice-1 Enterprise: Enterprise-A | v Attachment-Scope: AScope-A The discovery mechanism does not need to understand how AScope-A was derived. 7.1. Policy-Based Mapping The mapping can be many-to-one: UPF-A + DNN-X ----+ | UPF-B + DNN-X ----+--> AScope-X | VPN-X ------------+ This enables a deployment to define discovery applicability independently of a particular network technology. 7.2. Requester Attachment Scope A requester may issue a discovery request such as: Dunbar, et al. Expires Dec 13, 2027 [Page 21] Internet-Draft Infrastructure Assisted Discovery Service-Category: Vision-Inference Separately, network infrastructure determines the requester's current Attachment Scope based on network attachment state and provides it to the discovery mechanism: Attachment-Scope: AScope-A The discovery mechanism combines the requester's discovery criteria with the network-provided Attachment Scope when determining applicable AI-agent resources. The requester therefore does not need to know or supply network-specific information such as its serving UPF, network slice, DNN, VPN, or edge-domain association. 7.3. Scope Policy Attachment Scope matching does not necessarily require the requester and resource to have identical scope values. A deployment may define relationships among scopes so that a requester associated with one scope can discover resources associated with the same scope or with other permitted scopes. For example, a requester associated with AScope-Edge-A may be allowed to discover resources published for AScope-Edge-A, a broader metropolitan scope, or a shared cloud scope:For example: Requester Attachment Scope: AScope-Edge-A Applicable Resource Scopes: AScope-Edge-A AScope-Metro AScope-Shared-Cloud A deployment may define policy that determines which resource Attachment Scopes are applicable to a requester's Attachment Scope. For example, a requester associated with AScope-Edge-A Dunbar, et al. Expires Dec 13, 2027 [Page 22] Internet-Draft Infrastructure Assisted Discovery may be permitted to discover resources published for AScope- Edge-A and AScope-Shared-Cloud. 7.4. Mobility and Reassociation Attachment Scope can change when the requester: - moves between access areas; - changes serving UPF; - changes DNN; - changes slice; - moves between VPN or tenant contexts; - moves between Wi-Fi and cellular access; or - enters another edge domain. For example: Before: UPF-A -> AScope-A After reassociation: UPF-B -> AScope-B Subsequent discovery can therefore return resources applicable to the requester's new network context. Attachment Scope may be updated through events, queried at discovery time, or cached with an appropriate validity period. 8. Applying the Model to DNS-SD This section describes how the infrastructure-assisted discovery model in Section 5 can be realized using DNS-SD [RFC6763]. The general roles of requester criteria, published resource state, Attachment Scope, and discovery processing are defined in Section 5 and are not repeated here. In the DNS-SD realization, the Resource Publication Hook maps current AI-agent resource state into DNS-SD service information, while the Attachment Context Hook provides Dunbar, et al. Expires Dec 13, 2027 [Page 23] Internet-Draft Infrastructure Assisted Discovery network-derived context used to determine which DNS-SD discovery domains or service instances are applicable to the requester. No change to the DNS-SD query or response protocol is required by this document. 8.1. DNS-SD Mapping DNS-SD [RFC6763] represents service discovery using service types, instance enumeration, and endpoint resolution. The infrastructure-assisted model maps onto those mechanisms as follows: Published AI-Agent Resource State | v DNS-SD Representation PTR -> discoverable service instances SRV -> reachable target and port TXT -> selected discovery attributes or references to agent metadata For example, an AI-agent instance may be represented as: Vision-Agent-A._example-agent._tcp.example.com. with an SRV record identifying: vision-a.edge.example.com.:443 and TXT information such as: protocol=A2A metadata= https://vision-a.edge.example.com/.well-known/agent- card.json The service type, instance naming convention, and TXT attributes shown above are illustrative. This document does not define a new DNS-SD service type or new TXT keys. Dunbar, et al. Expires Dec 13, 2027 [Page 24] Internet-Draft Infrastructure Assisted Discovery 8.2. DNS-SD Publication When DNS-SD is used, the Resource Publication Hook described in Section 6 can populate and update the DNS-SD representation of currently available AI-agent resources. The deployment or orchestration system provides the information needed to create, update, or withdraw the corresponding DNS-SD records as the published AI-agent resource state changes. Conceptually: AI-Agent Deployment State | v Resource Publication Hook | +--> PTR: service-instance enumeration | +--> SRV: reachable target and port | +--> TXT: selected discovery attributes or metadata reference A published resource may represent either a logical AI-agent service or an individually reachable instance, as described in Section 6.1. When a published endpoint changes, the corresponding SRV information can be updated without requiring unrelated agent metadata to change. When a published resource is no longer available, its corresponding DNS-SD information can be withdrawn. An authorized controller may populate and maintain these records on behalf of the AI-agent service. Where Dynamic DNS is used, DNS UPDATE [RFC2136] can be used to add, modify, or remove DNS resource records. Other deployments may use authoritative DNS management interfaces, orchestration APIs, or controller-specific mechanisms. Dunbar, et al. Expires Dec 13, 2027 [Page 25] Internet-Draft Infrastructure Assisted Discovery The interface between the Resource Publication Hook and DNS infrastructure is outside the scope of this document. 8.3. Applying Attachment Scope The requester's Attachment Scope is provided to the discovery function through the Attachment Context Hook described in Section 7. It is not required to be carried in the DNS-SD request itself. When DNS-SD is used, Attachment Scope can be applied in at least two ways: o by mapping the requester's Attachment Scope to one or more DNS-SD discovery domains; or o by filtering enumerated resources according to the requester's Attachment Scope and deployment policy. 8.3.1. Scope to Domain Mapping A deployment can associate an Attachment Scope with one or more DNS-SD discovery domains. For example: Attachment-Scope: AScope-Edge-A | +--> edge-a.agent.example | +--> shared.agent.example A requester may issue only its application-level discovery intent, such as: Service-Category: Vision-Inference The discovery function combines this request with the network-provided Attachment Scope and determines which DNS-SD domains are applicable. For example: Dunbar, et al. Expires Dec 13, 2027 [Page 26] Internet-Draft Infrastructure Assisted Discovery Requester Intent: Vision-Inference Attachment Scope: AScope-Edge-A Applicable Discovery Domains: edge-a.agent.example shared.agent.example DNS-SD enumeration can then be performed within those domains using the procedures defined in [RFC6763]. This approach allows the DNS-SD discovery domain to reflect network applicability without requiring the requester to know which domain corresponds to its current network attachment. The mapping from Attachment Scope to discovery domains is deployment policy. 8.3.2. Filtering Resources After Enumeration Another deployment can use a common DNS-SD discovery domain that contains AI-agent resources associated with multiple Attachment Scopes. For example: Vision-Agent-A Attachment-Scope: AScope-A Vision-Agent-B Attachment-Scope: AScope-B Vision-Agent-C Attachment-Scope: AScope-Shared The discovery function can first identify resources matching the requester's service-related criteria and then apply policy based on the requester's Attachment Scope. Dunbar, et al. Expires Dec 13, 2027 [Page 27] Internet-Draft Infrastructure Assisted Discovery For a requester associated with: Attachment-Scope: AScope-A the applicable resource scopes might be: AScope-A AScope-Shared The resulting resources could therefore be: Vision-Agent-A Vision-Agent-C The Attachment Scope associated with a resource does not need to be exposed to the requester or encoded in a generally visible DNS-SD TXT record. It can instead be maintained by a trusted discovery component or associated infrastructure database. This approach is useful when resources associated with multiple network contexts share a common DNS-SD namespace, or when Attachment Scope information should remain internal to the infrastructure. In both approaches, DNS-SD continues to provide service- instance enumeration and endpoint resolution. The infrastructure-provided Attachment Scope determines which DNS-SD discovery domains or enumerated service instances are applicable to the requester's current network context. 8.4. Agent Metadata in DNS-SD Agent metadata used for discovery matching may be represented directly in DNS-SD, maintained separately by the discovery system, or obtained through a reference to an agent-native metadata mechanism. A deployment may place selected discovery attributes in DNS- SD TXT records, such as a supported protocol or a reference to richer metadata. For example: Dunbar, et al. Expires Dec 13, 2027 [Page 28] Internet-Draft Infrastructure Assisted Discovery protocol=A2A metadata= https://vision-a.edge.example/.well-known/agent- card.json Other attributes, such as skills, capabilities, supported modalities, or authentication characteristics, may be indexed by the discovery system without being encoded directly in DNS-SD. For an A2A deployment, some or all of this information may originate from an Agent Card. The complete Agent Card does not need to be duplicated in DNS-SD TXT records. The choice of which attributes are represented directly in DNS-SD and which are maintained or retrieved separately is deployment-specific. 8.5. Discovery Result The DNS-SD realization returns the service instances that remain applicable after the processing described in Section 8.3 and, where applicable, the metadata matching described in Section 8.4. For an applicable resource, DNS-SD provides the information needed to identify and resolve the published service instance. For example, the resulting information may correspond to: Resource-Identifier: Vision-Agent-A Endpoint: https://vision-a.edge.example Protocol: A2A Metadata-Reference: https://vision-a.edge.example/.well-known/agent- card.json For DNS-SD, the target host and port are resolved using the normal SRV and address-resolution procedures defined by [RFC6763] and [RFC2782]. Dunbar, et al. Expires Dec 13, 2027 [Page 29] Internet-Draft Infrastructure Assisted Discovery The Attachment Scope used to determine applicability does not need to be returned to the requester. It is infrastructure context used during discovery rather than information required for subsequent agent communication. A DNS-SD result may contain multiple applicable service instances. Where SRV records are used, the Priority and Weight procedures defined by [RFC2782] continue to apply. These procedures do not replace a separate resource-selection function when additional criteria such as network condition, compute load, accelerator availability, cost, or application policy are required. Additional agent-specific metadata, such as an A2A Agent Card, may be provided by reference or retrieved subsequently as described in Section 9. This document does not change the DNS-SD response format. 8.6. Caching and Freshness AI-agent deployment state can change after discovery information has been published. For example: o an instance can be withdrawn; o an endpoint can change; o an agent can move to another edge site; o an Attachment Scope associated with a resource can change; or o a requester can move to a different Attachment Scope. The Resource Publication Hook is responsible for reflecting changes to resource deployment state in the discovery system. When DNS is used, normal DNS TTL semantics apply. [RFC1035] specifies the interval for which a resource record can be cached before the source of the information should be consulted again. Dunbar, et al. Expires Dec 13, 2027 [Page 30] Internet-Draft Infrastructure Assisted Discovery Deployments in which agent endpoints or placement change frequently can therefore use TTL values appropriate to the expected lifetime of the published information. Very dynamic deployment information should not be treated as indefinitely valid merely because it was previously returned by discovery. Attachment Scope can have a lifetime that is independent of the lifetime of DNS resource records. For example, a requester may change from: AScope-A to AScope-B. while previously discovered DNS information remains present in a cache. A new discovery operation should therefore use the requester's current Attachment Scope rather than assuming that a previously determined Attachment Scope remains valid. Implementations should avoid treating cached resource information and cached Attachment Scope as having the same validity period unless deployment policy explicitly defines them that way. 8.7. No Match A discovery request can identify no resource that satisfies both the agent-related discovery criteria and the applicable Attachment Scope policy. For example: Requested: Vision-Inference Candidate: Agent-B -> AScope-B Requester: AScope-A Dunbar, et al. Expires Dec 13, 2027 [Page 31] Internet-Draft Infrastructure Assisted Discovery If policy does not permit AScope-A to use resources in AScope-B, the discovery result contains no applicable resource. The discovery mechanism may return an empty result or use mechanisms provided by the underlying discovery system to indicate that no applicable resource was found. A deployment can also define fallback policy. For example, when no edge-local resource is applicable, the discovery mechanism may consider an AI-agent resource published for a shared cloud Attachment Scope. Such fallback behavior is deployment policy and is not mandated by this document. 9. Second-Stage Agent Metadata Retrieval The lightweight discovery mechanism is intentionally not a complete AI-agent description system. Once an applicable resource has been identified, the requester can retrieve richer information using the agent's native mechanism. For A2A: Discovery Response | v Agent Card Reference | v Retrieve Agent Card | v Identity, Capabilities, Skills, Interfaces, Security, Interaction Requirements Other AI-agent protocols may use different descriptors. Dunbar, et al. Expires Dec 13, 2027 [Page 32] Internet-Draft Infrastructure Assisted Discovery This model avoids requiring one general discovery mechanism to reproduce all protocol-specific agent metadata. 10. Relationship to Resource Selection Attachment Scope determines applicability rather than optimization. For example: Discovery Result: Agent-A Agent-B means that both agents are usable within the applicable discovery context. A separate mechanism may select one based on: - latency; - network congestion; - compute load; - GPU availability; - service cost; - application policy; or - another dynamic metric. Mechanisms such as CATS may be applicable to such subsequent network-aware selection. 11. Alternative methods The infrastructure-assisted model does not depend on a particular discovery protocol. The discovery mechanism may use: - DNS-SD; - a centralized registry; - a distributed directory; - a federated discovery mechanism; or - another service-discovery system. The Resource Publication Hook may be implemented by: Dunbar, et al. Expires Dec 13, 2027 [Page 33] Internet-Draft Infrastructure Assisted Discovery - Kubernetes or cloud orchestration; - serverless hosting infrastructure; - MEC orchestration; - an application gateway; - a service mesh; - an enterprise AI platform; or - another deployment controller. Attachment Scope may be derived from: - 5G network state; - enterprise VPN/VRF state; - Wi-Fi infrastructure; - cloud networking; - SD-WAN state; - edge-controller state; or - combinations of these. Resource and Attachment Scope state may be updated through events, queried dynamically, periodically refreshed, or cached. Agent-native metadata may be represented using an A2A Agent Card, MCP metadata, another protocol-specific descriptor, or a deployment-specific format. 12. Security Considerations Attachment Scope may be derived from sensitive network information. The discovery mechanism should receive only the abstraction needed for discovery and should not require unnecessary exposure of: - subscriber identity; - physical access port; - precise geographic location; - internal topology; - routing identifiers; or - detailed network configuration. Infrastructure providing Attachment Scope needs to be trusted by the discovery mechanism. Dunbar, et al. Expires Dec 13, 2027 [Page 34] Internet-Draft Infrastructure Assisted Discovery A requester should not be able to obtain unauthorized resources merely by asserting an Attachment Scope in an untrusted request. Likewise, Resource Publication Hooks need authentication and authorization so that unauthorized systems cannot publish, alter, or withdraw AI-agent resource information. Discovery information can reveal the existence and reachability of AI resources. Deployments should therefore apply appropriate visibility and access policies. 13. IANA Considerations TBD 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. 14.2. Informative References [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery," RFC 6763, February 2013. [A2A] Agent2Agent Protocol, "Agent2Agent Protocol Documentation", https://a2a-protocol.org/. [AGENT-ATTACHMENT] Dunbar, L., et al., "Agent Attachment Protocol," Work in Progress. [DAWN-MDNS] Jakab, L. and Brockners, F., "Zero-Configuration Agent Discovery," draft-jakab-dawn-agent-discovery- mdns, Work in Progress. Dunbar, et al. Expires Dec 13, 2027 [Page 35] Internet-Draft Infrastructure Assisted Discovery [DAWN-USE-CASES] King, D., et al., "Use Cases and Applicability for Discovery of Agents With Names," Work in Progress. [DAWN-MDI] Cui, et al., "Minimum Discoverable Information for DAWN," Work in Progress. [MCP] Model Context Protocol, "Model Context Protocol Specification", https://modelcontextprotocol.io/specification/ 15. Acknowledgments Acknowledgements to xxx for their extensive review and suggestions. This document was prepared using 2-Word-v2.0.template.dot. Appendix A: Authors' Addresses Linda Dunbar Futurewei Email: ldunbar@futurewei.com Contributors' Addresses Dunbar, et al. Expires Dec 13, 2027 [Page 36]