Agentic Interface to In-Network Computing Functions for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems

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 12 December 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

In-network computing has recently gained significant attention and has been extensively explored as a promising research area. This growing interest stems from the increasing accessibility of data plane programmability, which has opened new opportunities for both application developers and network operators to optimize network operations and application performance. Over the years, rigorous research and numerous trials have validated the effectiveness of certain in-network computing capabilities, collectively referred to as In-Network Computing Functions (ICFs). These functions have proven to be highly beneficial in various domains, such as machine learning, real-time data processing, and large-scale distributed systems. For instance, in-network aggregation techniques have been shown to accelerate collective communication operations like Allreduce and Broadcast, which are critical in training machine learning models. These advancements have led to the gradual commercialization of many in-network computing capabilities. Several other works, such as [I-D.jeong-nmrg-i2icf-problem-statement][I-D.yao-tsvwg-cco-problem-statement-and-usecases][I-D.irtf-coinrg-use-cases]also provide additional use cases and scenarios for in-network computing applications.¶

Despite these promising developments, a critical challenge remains: the absence of a unified framework and standardized interfaces to effectively register, configure, manage, and monitor ICFs. The framework for Interface to Network Security Functions (I2NSF) defined in [RFC8329] provides a solid foundation for managing and orchestrating Network Security Functions (NSFs). However, these frameworks fall short when it comes to supporting the unique requirements of ICFs. Unlike NSFs, ICFs often require seamless coordination between endpoint computing capabilities and in-network nodes, such as Programmable Network Devices (PNDs), to accelerate application performance collaboratively. This highlights the need for a new framework that can integrate endpoint and in-network functionalities while leveraging and adapting existing frameworks, such as I2NSF, to define interfaces for ICFs effectively.¶

This document rigorously examines the applicability of ICFs within constrained environments, particularly in data center networks, and introduces a structured framework for their registration, configuration, management, and monitoring. Additionally, it evaluates extended use cases, including Vehicle-to-Everything (V2X) communication, wherein ICFs facilitate the efficient orchestration of vehicle-to-vehicle (V2V) networks, seamless integration with Cooperative Intelligent Transport Systems (C-ITS), and interoperability with Mobile Network Operators (MNOs). By leveraging ICFs, these architectures can achieve enhanced communication efficiency, improved traffic control, and secure data exchange. Furthermore, this document underscores the pivotal role of ICFs in strengthening cybersecurity measures for both private and public data within such interconnected ecosystems, addressing the increasing demand for resilient security mechanisms in contemporary networked infrastructures.¶

A distinguishing focus of this document is the Software-Defined Vehicle (SDV) as the primary endpoint of the I2ICF framework. In an SDV, traditionally hardware-bound vehicular functions (perception, planning, control, infotainment, diagnostics) are realized as software components running on a consolidated, zonal compute platform and are continuously updated over the air. This software-defined nature aligns naturally with the agentic AI model: each SDV can host one or more AI agents that expose vehicle capabilities (compute, sensing, connectivity, safety classes) as A2A skills, negotiate ICF placement with peer SDV, RSU, MNO, and Center agents, and dynamically adapt to changing road, network, and mission contexts. Conversely, the surrounding C-ITS and MNO infrastructure must evolve from static, message-based V2X delivery toward an intent-driven, agent-mediated control plane that can match the update cadence and behavioral diversity of fleets of SDVs. The I2ICF framework defined here treats SDVs as first-class agentic participants rather than passive V2X clients.¶

In C-ITS, distributed agents across vehicles, Road-Side Units (RSUs), and traffic management backends increasingly need to collaborate directly in an Agent-to-Agent (A2A) manner for capability advertisement, peer discovery, task delegation, and state exchange. Emerging IETF work on Artificial Intelligence (AI) agent protocols formalizes such A2A interactions (e.g., messaging, capability schemas, and discovery) [I-D.rosenberg-ai-protocols], while the IRTF NMRG explores applicability of A2A to multi-domain network management and automation [I-D.yang-nmrg-a2a-nm]. This approach provides a standards-based application/control-plane overlay for ICFs: vehicle, infrastructure, and cloud agents can discover and configure ICFs on programmable network devices, coordinate V2V/V2I compute placement, and exchange low-latency signals for admission control, safety services, and analytics, thereby reducing end-to-end delay and network overhead while improving interoperability and manageability in C-ITS deployments.¶

The A2A paradigm itself has been actively discussed across recent IRTF NMRG meetings (e.g., IETF 124 and IETF 125), where a body of work on agentic AI, Large Language Model (LLM)-assisted operations, and agent-mediated control planes for networks has emerged. Representative directions include problem statements and motivations for agentic AI in network management [I-D.hong-nmrg-agenticai-ps], agentic AI architectural principles for autonomous networks [I-D.jadoon-nmrg-agentic-ai-autonomous-networks], agentic network architectures supporting agent interconnection and multi-level inference [I-D.chuyi-nmrg-agentic-network-inference], agent-driven Network Digital Twin (NDT) architectures [I-D.wmz-nmrg-agent-ndt-arch], agentic sensing and network optimization [I-D.bernardos-nmrg-agentic-network-optimization], and the applicability of model and tool-access protocols such as the Model Context Protocol (MCP) to network management [I-D.yang-nmrg-mcp-nm]. In parallel, industry initiatives (e.g., Google's A2A protocol) have contributed reference patterns for agent identity, capability cards (Agent Cards), task lifecycles, and secure peer-to-peer messaging that can be adopted as the application-layer substrate of an A2A overlay for C-ITS.¶

Building on these trends, this document positions A2A as the primary coordination layer of the I2ICF framework for SDV-centric C-ITS. Specifically, each major entity in the architecture (Center Cloud agents, C-ITS Infra agent, MNO agent, RSU agent, SDV agents, and VRU agent) hosts an AI agent that exposes standardized capability descriptions and exchanges intent-based requests over A2A. SDV agents in particular act as the bridge between in-vehicle software stacks (zonal controllers, AI/ADAS workloads, IVN buses) and the external A2A overlay, so that vehicle-side software updates and capability changes are immediately reflected in the agent's advertised Agent Card. The I2ICF interfaces (I1 to I10) defined in this document are realized as A2A interactions between these agents, while the underlying transport, security, and policy enforcement continue to rely on existing C-ITS, V2X, and mobile network mechanisms. This split keeps the agentic control plane aligned with the NMRG agentic-AI direction while preserving compatibility with deployed C-ITS, SDV, and MNO infrastructures.¶

4. Security Considerations

The I2ICF framework for C-ITS and MNO Networking offers numerous advantages for various applications. However, due to the framework's extensive connectivity between diverse vehicles, devices, centers, clouds, and VRUs, a vast amount of information and functionalities are exposed during network configuration, leading to potential security risks. To ensure the overall security of the entire system, the following measures are recommended: First, the application development system should be controlled by the same service providers (e.g., cloud service providers or network operators) that own the network and computing infrastructure. Second, devices within the cloud center should be pre-configured with security zones to isolate traffic, preventing it from affecting other network traffic. Third, encryption keys for each device should be centrally managed by the cloud center. In the event of key exposure, the system should support Over-The-Air (OTA) updates to promptly replace compromised keys. Fourth, if a security breach occurs within the centralized management system, exposing encryption keys, the entire system should undergo a reset to perform a security initialization. This process will generate and distribute new encryption keys to ensure the continued protection of sensitive data.¶

Introducing an A2A overlay on top of I2ICF adds further security-sensitive surfaces that need to be addressed. Each agent MUST have a verifiable identity and a signed Agent Card whose contents (e.g., advertised ICFs, supported intents, authorization scopes) are authenticated by the Cyber Security System. A2A messages between agents MUST be mutually authenticated, integrity-protected, and confidentiality-protected, and SHOULD carry replay protection suitable for vehicular environments. Agents SHOULD operate under a least-privilege capability model: an SDV Agent cannot reconfigure RSU or MNO ICFs unless explicitly authorized, and a compromised agent's credentials MUST be revocable through the same OTA mechanism used for cryptographic key rotation. Finally, because A2A may carry LLM-generated or LLM-influenced content, deployments SHOULD apply input validation, prompt-injection mitigation, and human-in-the-loop oversight for safety-critical decisions, consistent with the agentic-AI principles discussed in [I-D.jadoon-nmrg-agentic-ai-autonomous-networks] and [I-D.hong-nmrg-agenticai-ps].¶

5. A2A Use Cases for SDV-Centric C-ITS Integration

In emerging SDV ecosystems, seamless coordination among vehicle agents, C-ITS infrastructure agents, and MNO agents becomes essential for achieving real-time awareness and adaptive network optimization. The A2A communication paradigm enables direct interaction among these heterogeneous entities without relying solely on centralized control mechanisms. For instance, SDV agents can dynamically negotiate data offloading, perform network slicing, or compute resource scheduling with MNO agents in response to vehicular mobility and network conditions, while roadside infrastructure agents exchange situational context such as congestion level, edge compute availability, or safety alerts with SDV agents to support cooperative perception and hazard prediction. These A2A interactions facilitate distributed decision-making across application and network layers, forming the basis for intelligent coordination and resilient service continuity in connected mobility.¶

When integrated with the proposed I2ICF framework, such A2A-based orchestration allows SDVs, RSUs, and MNO backends to jointly manage ICFs, thereby ensuring low-latency, secure, and reliable service delivery across multi-domain C-ITS environments. This approach follows recognized architectures and standards used in C-ITS and V2X systems, including frameworks for security management and network data analytics. Leveraging these industry standards, A2A coordination can extend beyond individual domains to enable intent-driven, cross-layer management of communication, computation, and data analytics among SDV, C-ITS, and MNO ecosystems.¶

The following use cases illustrate concrete A2A interaction patterns on top of the I2ICF framework. They are intentionally aligned with the agentic-AI direction discussed in the IRTF NMRG at IETF 124 and IETF 125, and with the broader industry A2A reference patterns (e.g., Agent Cards, task lifecycles, and secure peer-to-peer messaging) so that C-ITS deployments can interoperate with general-purpose AI agent ecosystems.¶

* Capability Advertisement and Discovery (I2, I4, I5, I7): C-ITS Infra Agent, MNO Agent, RSU Agents, and SDV Agents publish Agent Cards describing the ICFs they host (e.g., perception offload, message aggregation, slice selection, OTA key rotation). Center Cloud agents index these cards via I2/I3 and use them to plan ICF placement. Discovery is intent-driven: an SDV Agent requesting "low-latency cooperative perception within 100 ms" is matched with nearby RSU/MNO agents whose Agent Cards advertise compatible ICFs.¶

* Cooperative Perception via SDV-to-SDV and SDV-to-RSU A2A (I8, I10): SDV agents directly negotiate sensor data exchange, fusion responsibility, and confidence reporting with neighboring SDV agents (I10) and RSU agents (I8). Heavy fusion ICFs can be delegated to the RSU Agent when the SDV is compute-constrained, while the SDV Agent retains decision authority. This pattern mirrors the agent-interconnection and multi-level inference approach discussed in [I-D.chuyi-nmrg-agentic-network-inference].¶

* Intent-Based Slice and Edge Negotiation with MNO (I4, I6): An SDV Agent or a VRU Agent expresses a high-level intent (e.g., "platooning session, 50 vehicles, end-to-end latency budget 20 ms, reliability 99.999 percent") to the MNO Agent via A2A. The MNO Agent translates the intent into slice configuration and edge ICF placement, consistent with the agentic network optimization patterns described in [I-D.bernardos-nmrg-agentic-network-optimization].¶

* Cross-Domain Safety Coordination (I3, I6, I9): When a Government Public Center Agent detects a hazardous event, it issues an A2A task to the MNO Agent and C-ITS Infra Agent, which fan out the task to local RSU and SDV agents. VRU agents in the affected area receive targeted alerts via I6/I9 under privacy-preserving identifiers provided by the Cyber Security System.¶

* Agentic Network Digital Twin for C-ITS (I1, I2, I4): Center Cloud agents maintain an agentic NDT of the C-ITS network and use it to simulate ICF placement before pushing configurations to C-ITS Infra and MNO agents. This use case aligns with the agent-driven NDT architecture in [I-D.wmz-nmrg-agent-ndt-arch] and with the problem statement for agentic AI in network management in [I-D.hong-nmrg-agenticai-ps].¶

* Tool-Augmented Agent Operations via MCP (all interfaces): Agents may expose their local management tools (e.g., RSU firmware update, SDV diagnostic, slice reconfiguration) as MCP-style tools, and other agents may invoke them under A2A authorization. The applicability of MCP to such network management tasks is discussed in [I-D.yang-nmrg-mcp-nm]; the I2ICF framework reuses this pattern to keep tool invocation auditable and policy-bound.¶

* Autonomous Reaction and Human-in-the-Loop Oversight: Following the agentic-AI architectural principles in [I-D.jadoon-nmrg-agentic-ai-autonomous-networks], I2ICF agents operate within explicit autonomy levels. Routine ICF reconfiguration (e.g., adjusting aggregation thresholds at an RSU) runs autonomously, while safety-critical reconfiguration (e.g., revoking a compromised agent or resetting cryptographic material) requires escalation to a Center Cloud agent and, where appropriate, a human operator.¶

6. Agent Cards for SDVs and C-ITS Entities

Following the A2A protocol model adopted by [I-D.yang-nmrg-a2a-nm], every agent in the I2ICF framework MUST publish an Agent Card: a JSON metadata document that describes the agent's identity, endpoint, advertised ICF-related capabilities, skills, and authentication requirements. Agent Cards are the basis for capability discovery and intent matching across I1 to I10. Agent Cards are signed and attested by the Cyber Security System and SHOULD be discoverable by peer agents either via a well-known URI on the hosting entity or via a Center Cloud registry.¶

The following non-normative examples illustrate Agent Cards for representative C-ITS entities. The "capabilities" field lists ICF classes exposed by the agent, and "skills" enumerate concrete actions invocable through A2A messages.¶

{
  "name": "RSUAgent-01",
  "description": "Agent for a roadside unit that exposes
                  perception offload and message aggregation ICFs.",
  "url": "https://rsu-01.cits.example.net/a2a/tasks",
  "capabilities": ["PerceptionOffload", "MessageAggregation",
                   "V2X-Relay"],
  "skills": [
    {
      "id": "offload_perception",
      "name": "Cooperative perception offload",
      "description": "Run sensor fusion on behalf of an SDV
                      within RSU coverage.",
      "inputModes":  ["application/json", "text/structured"],
      "outputModes": ["application/json", "text/status"]
    },
    {
      "id": "aggregate_cam",
      "name": "CAM/BSM aggregation",
      "description": "Aggregate and forward V2X awareness
                      messages to the C-ITS Infra.",
      "inputModes":  ["application/json"],
      "outputModes": ["text/status"]
    }
  ]
}

{
  "name": "SDVAgent-VIN-XYZ",
  "description": "In-vehicle agent representing an SDV in the
                  A2A overlay for cooperative driving.",
  "url": "https://sdv-xyz.veh.example.net/a2a/tasks",
  "capabilities": ["CooperativePerception", "Platooning",
                   "Telemetry", "OTA-KeyRotation"],
  "skills": [
    {
      "id": "request_perception",
      "name": "Request cooperative perception",
      "description": "Request fused object lists from nearby
                      RSU or SDV agents.",
      "inputModes":  ["application/json"],
      "outputModes": ["application/json"]
    },
    {
      "id": "join_platoon",
      "name": "Join platoon",
      "description": "Negotiate joining an existing platoon
                      session with neighboring SDV agents.",
      "inputModes":  ["application/json"],
      "outputModes": ["text/status"]
    }
  ]
}

{
  "name": "MNOAgent-OpA",
  "description": "Operator-side agent exposing slice selection
                  and edge ICF placement for C-ITS clients.",
  "url": "https://mno-a.example.net/a2a/tasks",
  "capabilities": ["NetworkSlicing", "EdgeICFPlacement",
                   "QoSModulation"],
  "skills": [
    {
      "id": "select_slice",
      "name": "Slice selection",
      "description": "Select or instantiate a network slice
                      matching the requested intent.",
      "inputModes":  ["application/json"],
      "outputModes": ["application/json"]
    },
    {
      "id": "place_edge_icf",
      "name": "Edge ICF placement",
      "description": "Place an ICF on an MEC node close to the
                      requesting SDV/VRU agent.",
      "inputModes":  ["application/json"],
      "outputModes": ["text/status"]
    }
  ]
}

7. YANG-based Structured Data for A2A Communication in SDV and C-ITS

While the A2A protocol natively supports unstructured textual content for inter-agent exchange, the orchestration of ICFs in C-ITS demands clarity, unambiguous intent transmission, and machine-interpretable data, especially when safety-critical actuation (e.g., emergency rerouting, key revocation, slice reconfiguration) is involved. Natural-language-only payloads carry the inherent ambiguity of human language and can lead to inconsistent ICF configuration or large-scale service degradation, which is unacceptable for C-ITS.¶

This document adopts the approach of [I-D.yang-nmrg-a2a-nm], which uses YANG [RFC7950] as the structured data layer for A2A payloads, with NETCONF [RFC6241] and RESTCONF [RFC8040] as candidate underlying management protocols when an agent needs to actuate an ICF on a programmable network device. Building on that approach, this document defines a non-normative YANG module, "ietf-cits-icf-intent", whose data nodes are carried inside the "data" part of A2A messages exchanged across I1 to I10. The module provides a machine-interpretable representation of C-ITS ICF intents and supplements the natural-language "text" parts that the same A2A message may carry. The intent is that an SDV, RSU, MNO, or Center agent that receives an A2A message can validate the "data" part against this YANG module before acting upon it, and can use existing NETCONF or RESTCONF tooling to persist or actuate the intent on a programmable network device.¶

In the C-ITS context, YANG-modeled payloads carried as the "data" part of A2A messages are RECOMMENDED for the following content categories:¶

* ICF descriptors (capability schemas of RSU/MNO/SDV ICFs), modeled by the "icf-descriptor" container of "ietf-cits-icf-intent".¶

* C-ITS intent objects (e.g., platooning, cooperative perception, hazard alert) expressed as structured intents under the "cits-intent" container of "ietf-cits-icf-intent".¶

* Telemetry and incident reports between RSU/SDV agents and Center Cloud agents, reusing the YANG model in [I-D.ietf-nmop-network-incident-yang] where applicable.¶

* Cryptographic material lifecycle events (rotation, revocation) managed by the Cyber Security System.¶

The high-level tree structure of the "ietf-cits-icf-intent" module, expressed using the YANG tree diagram notation, is shown in Figure 5. The corresponding YANG module skeleton is shown in Figure 6. Both artifacts are non-normative and are intended as a starting point for a companion YANG document.¶

module: ietf-cits-icf-intent

  +--rw cits-icf-intents
     +--rw intent* [intent-id]
        +--rw intent-id            string
        +--rw type                 identityref
        +--rw requester            string
        +--rw target-icf           identityref
        +--rw safety-class?        enumeration
        +--rw priority?            uint8
        +--rw response-deadline?   yang:date-and-time
        +--rw interface?           enumeration
        +--rw constraints
        |  +--rw max-latency-ms?      uint32
        |  +--rw min-reliability?     decimal64
        |  +--rw min-confidence?      decimal64
        |  +--rw region-of-interest?  string
        |  +--rw bandwidth-mbps?      uint32
        +--rw participants*        string
        +--ro status?              enumeration
        +--ro last-updated?        yang:date-and-time

  notifications:
    +---n icf-intent-event
       +--ro intent-id    -> /cits-icf-intents/intent/intent-id
       +--ro event-type   enumeration
       +--ro details?     string

module ietf-cits-icf-intent {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-cits-icf-intent";
  prefix "cits-icf";

  import ietf-yang-types {
    prefix yang;
  }

  organization
    "IETF NMRG (Network Management Research Group)";
  contact
    "WG Web:   <https://datatracker.ietf.org/rg/nmrg/>
     Editor:  Byoungman An <bman@keti.re.kr>
     Editor:  Jaehoon Paul Jeong <pauljeong@skku.edu>";
  description
    "This YANG module defines a data model for representing
     Cooperative Intelligent Transportation System (C-ITS)
     In-Network Computing Function (ICF) intents that are carried
     as the 'data' part of Agent-to-Agent (A2A) messages between
     SDV, RSU, MNO, VRU, and Center agents of the I2ICF framework.";

  revision 2026-02-05 {
    description "Initial revision.";
    reference "draft-an-nmrg-i2icf-cits-02";
  }

  /* Identities for ICF intent types and target ICF classes */

  identity intent-type {
    description "Base identity for C-ITS ICF intent types.";
  }
  identity cooperative-perception {
    base intent-type;
    description "Cooperative perception intent (e.g., SDV-RSU).";
  }
  identity platooning {
    base intent-type;
    description "Platooning session intent among SDVs.";
  }
  identity hazard-alert {
    base intent-type;
    description "Hazard alert dissemination intent.";
  }
  identity slice-request {
    base intent-type;
    description "Network slice/edge ICF placement intent to MNO.";
  }
  identity ota-key-rotation {
    base intent-type;
    description "OTA key rotation intent managed by the Cyber
                 Security System.";
  }

  identity icf-class {
    description "Base identity for ICF capability classes.";
  }
  identity PerceptionOffload    { base icf-class; }
  identity MessageAggregation   { base icf-class; }
  identity NetworkSlicing       { base icf-class; }
  identity EdgeICFPlacement     { base icf-class; }
  identity OTAKeyRotation       { base icf-class; }

  /* Top-level data tree */

  container cits-icf-intents {
    description
      "Collection of C-ITS ICF intents currently known to the
       hosting agent.";
    list intent {
      key "intent-id";
      description "A single C-ITS ICF intent.";

      leaf intent-id {
        type string;
        description "Globally unique intent identifier.";
      }
      leaf type {
        type identityref { base intent-type; }
        mandatory true;
        description "Intent type (e.g., cooperative-perception).";
      }
      leaf requester {
        type string;
        mandatory true;
        description "Agent name of the requesting agent.";
      }
      leaf target-icf {
        type identityref { base icf-class; }
        mandatory true;
        description "Targeted ICF capability class.";
      }
      leaf safety-class {
        type enumeration {
          enum QM;     enum ASIL-A; enum ASIL-B;
          enum ASIL-C; enum ASIL-D;
        }
        description "ISO 26262 ASIL classification of the intent.";
      }
      leaf priority {
        type uint8 { range "0..7"; }
        description "Relative priority (0 = lowest).";
      }
      leaf response-deadline {
        type yang:date-and-time;
        description "Latest acceptable response time.";
      }
      leaf interface {
        type enumeration {
          enum I1; enum I2; enum I3; enum I4; enum I5;
          enum I6; enum I7; enum I8; enum I9; enum I10;
        }
        description "I2ICF interface over which the intent flows.";
      }
      container constraints {
        description "Operational constraints attached to the intent.";
        leaf max-latency-ms     { type uint32; units "milliseconds"; }
        leaf min-reliability    { type decimal64 { fraction-digits 5; } }
        leaf min-confidence     { type decimal64 { fraction-digits 2; } }
        leaf region-of-interest { type string; }
        leaf bandwidth-mbps     { type uint32; units "Mbit/s"; }
      }
      leaf-list participants {
        type string;
        description "Other agents participating in this intent.";
      }
      leaf status {
        type enumeration {
          enum requested; enum accepted; enum running;
          enum completed; enum failed;   enum revoked;
        }
        config false;
        description "Lifecycle status of the intent.";
      }
      leaf last-updated {
        type yang:date-and-time;
        config false;
        description "Time of the last status update.";
      }
    }
  }

  /* Event-driven A2A notification */

  notification icf-intent-event {
    description
      "Notification emitted when an intent changes state, used by
       event-driven A2A pub/sub channels (see Section
       'Event-driven A2A for Safety Signalling').";
    leaf intent-id {
      type leafref {
        path "/cits-icf:cits-icf-intents/cits-icf:intent"
           + "/cits-icf:intent-id";
      }
    }
    leaf event-type {
      type enumeration {
        enum accepted; enum rejected; enum progress;
        enum completed; enum failed;   enum revoked;
      }
    }
    leaf details { type string; }
  }
}

The following non-normative example illustrates an A2A message sent from an SDV Agent to an RSU Agent over I8 to request a cooperative perception ICF. The "data" part carries an instance of the "ietf-cits-icf-intent" YANG module shown above, encoded as JSON per [RFC8040] ("application/yang-data+json"), while the "text" part preserves a human-readable summary.¶

POST /a2a/tasks HTTP/1.1
Host: rsu-01.cits.example.net
Content-Type: application/json
{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "message_id": "c1ts-7f3e-4a21-9b12-0e2d6a8c4f10",
      "context_id": "intersection-42:approach-east",
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "Request cooperative perception within 100 ms
                   for intersection-42, eastbound approach.",
          "media_type": "text/plain"
        },
        {
          "data": {
            "ietf-cits-icf-intent:cits-icf-intents": {
              "intent": [
                {
                  "intent-id": "intent-9921",
                  "type":
                    "ietf-cits-icf-intent:cooperative-perception",
                  "requester": "SDVAgent-VIN-XYZ",
                  "target-icf":
                    "ietf-cits-icf-intent:PerceptionOffload",
                  "safety-class": "ASIL-B",
                  "priority": 6,
                  "response-deadline": "2026-02-10T06:00:00Z",
                  "interface": "I8",
                  "constraints": {
                    "max-latency-ms": 100,
                    "min-confidence": 0.85,
                    "region-of-interest":
                      "intersection-42:east"
                  },
                  "participants": ["RSUAgent-01"]
                }
              ]
            }
          },
          "media_type": "application/yang-data+json",
          "metadata": {
            "yang_module": "ietf-cits-icf-intent",
            "revision": "2026-02-05"
          }
        }
      ]
    },
    "configuration": {
      "accepted_output_modes": ["application/yang-data+json",
                                "text/status"],
      "blocking": false,
      "history_length": 3
    },
    "metadata": {
      "request_type": "icf_invocation",
      "priority": "high",
      "response_deadline": "2026-02-10T06:00:00Z"
    }
  }
}

The YANG module shown above is non-normative and is expected to be refined in a companion YANG document, reusing IETF building blocks for incident management [I-D.ietf-nmop-network-incident-yang] and existing C-ITS/V2X data dictionaries.¶

8. Operational Considerations

The introduction of an A2A overlay on top of the I2ICF framework has several operational implications that need to be considered when deploying the architecture in large-scale, safety-critical C-ITS environments. This section is aligned with the operational considerations discussed in [I-D.yang-nmrg-a2a-nm] and adapts them to C-ITS.¶

9. IANA Considerations

TBD.¶

Acknowledgments

This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No.RS-2024-00397615, Development of an automotive software platform for Software-Defined-Vehicle (SDV) integrated with an AI framework required for intelligent vehicles).¶

This work was in part supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No. RS-2024-00398199 and RS-2022-II221015).¶

Authors' Addresses