| Internet-Draft | AINETOps Task and Evidence Information M | October 2026 |
| Sun, et al. | Expires 30 April 2027 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
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.¶
[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.¶
[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.¶
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 |
+----------------------+ +----------------------+
¶
Figure 1: Task and Evidence Information Models¶
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.¶
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.¶
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.¶
+----------------------+
| 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¶
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.¶
+=======================+======+============+====+===============+ | 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.¶
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.¶
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.¶
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"
}
}
}
}
¶
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.¶
+----------------------+
| 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¶
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.¶
+=======================+======+============+====+===============+ | 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.¶
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.¶
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¶
The following JSON illustrates one possible representation of the Evidence Information Model.¶
{
"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"
}
}
]
}
¶
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.¶
This document defines only protocol-independent information models and requests no IANA registrations.¶
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.¶
[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.¶