Network Working Group Q. Sun Internet-Draft X. Song Intended status: Standards Track Y. Yu Expires: 30 April 2027 Y. Fu R. Luo China Telecom 27 October 2026 Task and Evidence Information Model for AINETOps draft-sun-ainetops-task-and-evidence-model-01 Abstract As Network Management Agents (NMAs) increasingly collaborate in scenarios such as fault diagnosis, network optimization, and service assurance, consistent task descriptions and evidence information are needed across vendors and management domains. This document defines a Task and Evidence Information Model for AI-Enabled Network Operations (AINETOps). The model consists of Task Core, Evidence Core, and a Profile extension mechanism for different task and evidence types. This document does not specify communication protocols, request or response formats, task execution methods, or network configuration operations. 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 30 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Sun, et al. Expires 30 April 2027 [Page 1] Internet-Draft AINETOps Task and Evidence Information M October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Relationship to Existing Work . . . . . . . . . . . . . . . . 4 3.1. AINETOps Use Cases . . . . . . . . . . . . . . . . . . . 4 3.2. NMA Northbound Task Interface . . . . . . . . . . . . . . 4 4. Overall Information Model . . . . . . . . . . . . . . . . . . 4 4.1. Scope and Relationships . . . . . . . . . . . . . . . . . 5 4.2. Common Profile Requirements . . . . . . . . . . . . . . . 5 5. Task Information Model . . . . . . . . . . . . . . . . . . . 5 5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Elements . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Task Profile Example . . . . . . . . . . . . . . . . . . 8 5.5. Example Task Instance . . . . . . . . . . . . . . . . . . 9 6. Evidence Information Model . . . . . . . . . . . . . . . . . 9 6.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Evidence Profile Example . . . . . . . . . . . . . . . . 12 6.5. Example Evidence Instance . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Sun, et al. Expires 30 April 2027 [Page 2] Internet-Draft AINETOps Task and Evidence Information M October 2026 1. Introduction Network operational tasks may be handled collaboratively by multiple Network Management Agents (NMAs). For example, one agent may collect network state information while another proposes path optimization. Because different systems may represent task objectives, network objects, and related evidence differently, semantic inconsistencies can arise in cross-vendor or cross-domain collaboration. To address this issue, this document defines two related information models. The Task Information Model describes the objectives, scope, expected outcomes, and execution constraints of network operational tasks. The Evidence Information Model describes task-related evidence, including its source, time, and type. The two models are logically associated through task identifiers. To support different network operational scenarios, both models distinguish a common part (Core) from extensions for particular domains (Profiles). This document specifies common information elements and Profile extension rules; specific message encodings and transport protocols are outside its scope. The JSON representations in this document are illustrative only. 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. * *NMA (Network Management Agent)*: A software agent that performs or assists with network management tasks. * *Business Task*: Work with a defined network operational objective that may be handled collaboratively by one or more NMAs. * *Task Core*: Information elements and their semantics common to different network operational tasks. * *Task Profile*: Extended information and its semantics for a particular type of task. * *Evidence Core*: Information elements and their semantics common to different types of evidence. * *Evidence Profile*: Information and its semantics defined for a particular type of evidence. Sun, et al. Expires 30 April 2027 [Page 3] Internet-Draft AINETOps Task and Evidence Information M October 2026 In the structure diagrams, (1) indicates a mandatory element that occurs exactly once, (0..1) indicates an optional element, and (1..n) indicates one or more occurrences. In the Elements tables in Sections 5 and 6, Req indicates whether an element is mandatory or optional, while Type denotes its conceptual type. All elements listed in the Elements tables belong to the Core. In the Ext column, T means Task Profile, E means Evidence Profile, and - means a non-extension element. The marked containers permit their Profile to define internal information elements. 3. Relationship to Existing Work 3.1. AINETOps Use Cases [I-D.king-rokui-ainetops-usecases] discusses AINETOps application scenarios, including network fault handling, network optimization, and service assurance. This document provides reusable task descriptions and evidence information semantics for these scenarios without specifying particular network operational algorithms. 3.2. NMA Northbound Task Interface [I-D.wu-nmop-nma-nti-problem-statement] discusses requirements for the northbound interface through which an OSS or management system delegates tasks to an NMA. This document is related to the representation of task objectives and constraints, but defines general Task and Evidence information models applicable to different network operational scenarios rather than an interface for a particular direction of communication. 4. Overall Information Model The Task Information Model and the Evidence Information Model each consist of a Core and a Profile. The Core defines information elements that remain consistent across scenarios, while a Profile defines information specific to a particular task or evidence type. Figure 1 illustrates the relationship between the two models. Task Information Model Evidence Information Model +----------------------+ +----------------------+ | Task Core | | Evidence Core | +----------+-----------+ +----------+-----------+ | | +----------v-----------+ +----------v-----------+ | Task Profile | | Evidence Profile | +----------------------+ +----------------------+ Sun, et al. Expires 30 April 2027 [Page 4] Internet-Draft AINETOps Task and Evidence Information M October 2026 Figure 1: Task and Evidence Information Models 4.1. Scope and Relationships This document specifies the common information elements of Task Core and Evidence Core, as well as requirements for Profiles. Specific Profiles, such as those for path optimization, fault diagnosis, and network observation, may be defined in separate specifications. The Profiles presented in Sections 5 and 6 only illustrate the extension mechanism; implementations are not required to support all of them. Each Business Task is identified by task_id and may be associated with another Business Task through ref_task_id. An evidence set is identified by evidence_id, and related evidence may refer to a Business Task through ref_task_id. 4.2. Common Profile Requirements Consistent interpretation of scenario-specific information across vendors requires recognition of the same Profile and its semantics. Therefore, each Profile MUST have a clearly defined identifier. Its specification MUST define versioning and compatibility rules and describe the meanings, required or optional status, units, and value constraints of its information elements. A Profile MUST NOT change the meaning or type of information elements defined by the Core, nor may it introduce undefined top-level elements. 5. Task Information Model 5.1. Structure The Task Information Model represents a Business Task as a Task Instance. Figure 2 shows the corresponding information structure. The extensible elements under task_spec are defined by the applicable Task Profile. Sun, et al. Expires 30 April 2027 [Page 5] Internet-Draft AINETOps Task and Evidence Information M October 2026 +----------------------+ | Task Instance | +----------------------+ |- task_id (1) |- ref_task_id (0..1) |- task_type (1) |- task_spec (1) |- objective (1) |- scope (0..1) |- target (0..1) |- constraints (0..1) |- profile_data (0..1) Figure 2: Task Information Model Structure 5.2. Elements Table 1 summarizes the common information elements of Task Core. Req uses MUST and MAY to indicate mandatory and optional elements, respectively. Requirements for nested elements apply within their parent elements. Type denotes a conceptual type rather than a particular programming-language or network-protocol data type. Sun, et al. Expires 30 April 2027 [Page 6] Internet-Draft AINETOps Task and Evidence Information M October 2026 +=======================+======+============+====+===============+ | Element | Req | Type | Ext| Purpose | +=======================+======+============+====+===============+ | task_id | MUST | identifier | - | Business task | | | | | | identifier | +-----------------------+------+------------+----+---------------+ | ref_task_id | MAY | identifier | - | Related | | | | | | business task | +-----------------------+------+------------+----+---------------+ | task_type | MUST | identifier | - | Identifies | | | | | | Task Profile | +-----------------------+------+------------+----+---------------+ | task_spec | MUST | structured | - | Task | | | | | | specification | +-----------------------+------+------------+----+---------------+ | task_spec.objective | MUST | text | - | Objective of | | | | | | the task | +-----------------------+------+------------+----+---------------+ | task_spec.scope | MAY | structured | T | Network | | | | | | objects or | | | | | | scope | +-----------------------+------+------------+----+---------------+ | task_spec.target | MAY | structured | T | Expected | | | | | | outcome or | | | | | | metrics | +-----------------------+------+------------+----+---------------+ | task_spec.constraints | MAY | structured | T | Task execution| | | | | | restrictions | +-----------------------+------+------------+----+---------------+ | task_spec.profile_data| MAY | structured | T | Profile- | | | | | | specific | | | | | | context | +-----------------------+------+------------+----+---------------+ Table 1: Task Core Elements task_id identifies the Business Task, and ref_task_id associates it with other Business Tasks. task_type identifies the task type, allowing the recipient to determine the corresponding Task Profile. task_spec.objective describes the task objective and is a mandatory textual element of the task specification. scope indicates the network objects or scope to which the task applies, target indicates the expected outcomes or metrics, and constraints indicates restrictions that the task must observe. profile_data accommodates additional scenario-specific information that does not fall into these categories. The internal structures of these four composite elements are defined by the Task Profile. Sun, et al. Expires 30 April 2027 [Page 7] Internet-Draft AINETOps Task and Evidence Information M October 2026 5.3. Constraints task_id MUST be unique within the management domain of the task publisher. When used across management domains, the parties involved SHOULD specify the scope of the task identifier. ref_task_id indicates a business association only. task_type MUST identify an applicable Task Profile. scope, target, constraints, and profile_data are optional in the Core; a Profile may determine their specific content and conditions of use according to the requirements of the task type. 5.4. Task Profile Example This section uses the path_optimization type to illustrate a Task Profile. The Profile uses scope to identify the source and destination nodes, target to specify desired latency and bandwidth, constraints to indicate whether changes to production network configurations are permitted, and profile_data to specify the analysis time window. Figure 3 applies only to this illustrative Profile. Path Optimization Profile (illustrative) task_spec |- scope (1) | |- source (1) | |- destination (1) |- target (0..1) | |- latency_lt_ms (0..1) | |- bandwidth_gte_gbps (0..1) |- constraints (0..1) | |- no_production_changes (0..1) |- profile_data (0..1) |- analysis_window (0..1) |- start (1) |- end (1) Figure 3: Illustrative Path Optimization Profile latency_lt_ms specifies that end-to-end latency must be strictly less than the given value in milliseconds. bandwidth_gte_gbps specifies that the available bandwidth must be greater than or equal to the given value in Gbps. no_production_changes indicates whether changes to production configurations are prohibited. The start and end times of analysis_window define the analysis time window. Sun, et al. Expires 30 April 2027 [Page 8] Internet-Draft AINETOps Task and Evidence Information M October 2026 5.5. Example Task Instance The following JSON illustrates one possible representation of the Task Information Model. { "task_id": "TASK-001", "task_type": "path_optimization", "task_spec": { "objective": "Optimize the service path from CE-A to CE-B", "scope": { "source": "CE-A", "destination": "CE-B" }, "target": { "latency_lt_ms": 20, "bandwidth_gte_gbps": 1 }, "constraints": { "no_production_changes": true }, "profile_data": { "analysis_window": { "start": "2026-10-27T08:00:00Z", "end": "2026-10-27T08:15:00Z" } } } } 6. Evidence Information Model 6.1. Structure The Evidence Information Model represents an evidence collection as an Evidence Set, which contains at least one Evidence Entry. Figure 4 shows the corresponding information structure. The internal structure of content is defined by the applicable Evidence Profile. Sun, et al. Expires 30 April 2027 [Page 9] Internet-Draft AINETOps Task and Evidence Information M October 2026 +----------------------+ | Evidence Set | +----------------------+ |- evidence_id (1) |- ref_task_id (0..1) |- evidence (1..n) |- item_id (1) |- type (1) |- source (1) |- timestamp (1) |- content (1) Figure 4: Evidence Information Model Structure 6.2. Elements Table 2 summarizes the common information elements of Evidence Core. evidence[].* denotes elements within each Evidence Entry; therefore, the corresponding MUST requirements apply to every entry. Sun, et al. Expires 30 April 2027 [Page 10] Internet-Draft AINETOps Task and Evidence Information M October 2026 +=======================+======+============+====+===============+ | Element | Req | Type | Ext| Purpose | +=======================+======+============+====+===============+ | evidence_id | MUST | identifier | - | Evidence set | | | | | | identifier | +-----------------------+------+------------+----+---------------+ | ref_task_id | MAY | identifier | - | Related | | | | | | business task | +-----------------------+------+------------+----+---------------+ | evidence | MUST | collection | - | One or more | | | | | | evidence | | | | | | entries | +-----------------------+------+------------+----+---------------+ | evidence[].item_id | MUST | identifier | - | Evidence entry| | | | | | identifier | | | | | | within set | +-----------------------+------+------------+----+---------------+ | evidence[].type | MUST | identifier | - | Identifies | | | | | | Evidence | | | | | | Profile | +-----------------------+------+------------+----+---------------+ | evidence[].source | MUST | identifier | - | Origin of the | | | | / text | | evidence | +-----------------------+------+------------+----+---------------+ | evidence[].timestamp | MUST | date-time | - | Collection or | | | | | | creation time | +-----------------------+------+------------+----+---------------+ | evidence[].content | MUST | structured | E | Profile- | | | | | | specific | | | | | | evidence | +-----------------------+------+------------+----+---------------+ Table 2: Evidence Core Elements evidence_id identifies the Evidence Set, and ref_task_id associates it with a Business Task. item_id identifies an individual entry within the evidence set. type identifies the evidence type and its Evidence Profile; source identifies the system from which the evidence originates; and timestamp indicates when the evidence was collected or generated. content contains evidence-type-specific information and is interpreted according to the corresponding Profile. Sun, et al. Expires 30 April 2027 [Page 11] Internet-Draft AINETOps Task and Evidence Information M October 2026 6.3. Constraints evidence_id MUST be unique within the management domain of the evidence publisher. An Evidence Set MUST contain at least one Evidence Entry; each Evidence Entry MUST contain item_id, type, source, timestamp, and content. item_id MUST be unique within its Evidence Set. An individual evidence entry can be referenced by the combination of evidence_id and item_id. When evidence is associated with a specific Business Task, ref_task_id SHOULD be provided. timestamp indicates when evidence was collected or generated. source and timestamp describe only the provenance and time of the evidence; they do not, by themselves, establish its authenticity or integrity. 6.4. Evidence Profile Example This section uses the observation type to illustrate an Evidence Profile. It uses content to represent the observed object, metrics, and measured values. In Figure 5, measurements is a collection containing at least one measurement record; method is an optional description of the measurement method. Network Observation Profile (illustrative) evidence[].content |- resource (1) |- measurements (1..n) | |- metric (1) | |- value (1) | |- unit (1) |- method (0..1) Figure 5: Illustrative Network Observation Profile 6.5. Example Evidence Instance The following JSON illustrates one possible representation of the Evidence Information Model. Sun, et al. Expires 30 April 2027 [Page 12] Internet-Draft AINETOps Task and Evidence Information M October 2026 { "evidence_id": "EV-001", "ref_task_id": "TASK-001", "evidence": [ { "item_id": "E-001", "type": "observation", "source": "Monitoring-System-A", "timestamp": "2026-10-27T08:10:00Z", "content": { "resource": "CE-A-to-CE-B", "measurements": [ { "metric": "latency", "value": 18, "unit": "ms" }, { "metric": "available_bandwidth", "value": 2, "unit": "Gbps" } ], "method": "network-measurement" } } ] } 7. Security Considerations Task information may contain network topology, device identifiers, and service paths. Evidence information may expose network operational status, measurement data, or sensitive service information. Systems using this model should provide appropriate access controls and transport protection according to the sensitivity of the information. A task description does not itself constitute authorization for network operations, and the source and timestamp associated with evidence do not guarantee its authenticity. Authentication, access control, and evidence integrity protection are provided by other security mechanisms used in the deployment. 8. IANA Considerations This document defines only protocol-independent information models and requests no IANA registrations. Sun, et al. Expires 30 April 2027 [Page 13] Internet-Draft AINETOps Task and Evidence Information M October 2026 9. Future Work Future work may map these information models to specific data models and further define Profile naming, versioning, and compatibility rules. Profiles for fault diagnosis, path optimization, telemetry, and simulation may be standardized separately. 10. References 10.1. Normative References * [RFC2119], _Key words for use in RFCs to Indicate Requirement Levels_. * [RFC8174], _Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words_. 10.2. Informative References * [I-D.king-rokui-ainetops-usecases], _Artificial Intelligence (AI) for Network Operations_. * [I-D.wu-nmop-nma-nti-problem-statement], _Problem Statement for Standardizing the Northbound Task Interface (NTI) of the Network Management Agent_. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.king-rokui-ainetops-usecases] Rokui, R., Li, C., Wu, Q., and D. King, "Artificial Intelligence (AI) for Network Operations", Work in Progress, Internet-Draft, draft-king-rokui-ainetops- usecases-02, 10 August 2026, . Sun, et al. Expires 30 April 2027 [Page 14] Internet-Draft AINETOps Task and Evidence Information M October 2026 [I-D.wu-nmop-nma-nti-problem-statement] Wu, B., Wang, M., XingZhao, Ceccarelli, D., Zheng, H., and J. Zhou, "Problem Statement for Standardizing the northbound Task Interface (NTI) of the Network Management Agent", Work in Progress, Internet-Draft, draft-wu-nmop- nma-nti-problem-statement-00, 6 July 2026, . Authors' Addresses Qiong Sun China Telecom Email: sunqiong@chinatelecom.cn Xin Song China Telecom Email: songx18@chinatelecom.cn YunFu Yu China Telecom Email: Yuyf12@chinatelecom.cn Yu Fu China Telecom Email: fuy44@chinatelecom.cn RunZe Luo China Telecom Email: luorz4@chinatelecom.cn Sun, et al. Expires 30 April 2027 [Page 15]