NMOP Working Group T. Hu Internet-Draft CMCC Intended status: Standards Track L. M. Contreras Expires: 24 March 2027 Telefonica Q. Wu Huawei N. Davis Ciena C. Feng 20 September 2026 A YANG Data Model for Network Incident Management draft-ietf-nmop-network-incident-yang-15 Abstract This document defines a YANG data model for the network incident lifecycle management. This YANG module provides a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable root cause analysis. 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 24 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Hu, et al. Expires 24 March 2027 [Page 1] Internet-Draft Network Incident Management September 2026 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Incident-Based Trouble Tickets Dispatching . . . . . . . 7 3.2. Incident Derivation from L3VPN Service Unavailability . . 7 3.3. Multi-layer Fault Demarcation . . . . . . . . . . . . . . 8 4. Network Incident Management Architecture . . . . . . . . . . 9 5. Functional Interface Requirements between the Client and the Server . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Incident Identification . . . . . . . . . . . . . . . . . 12 5.2. Incident Diagnosis . . . . . . . . . . . . . . . . . . . 15 5.3. Incident Resolution . . . . . . . . . . . . . . . . . . . 15 6. Incident Data Model Concepts . . . . . . . . . . . . . . . . 15 6.1. Identifying the Incident Instance . . . . . . . . . . . . 15 6.2. The Incident Lifecycle . . . . . . . . . . . . . . . . . 15 6.2.1. Network Incident Instance Lifecycle . . . . . . . . . 16 6.2.2. Operator Incident Lifecycle . . . . . . . . . . . . . 16 7. Incident Data Model Design . . . . . . . . . . . . . . . . . 16 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Incident Notifications . . . . . . . . . . . . . . . . . 20 7.3. Incident Acknowledge . . . . . . . . . . . . . . . . . . 21 7.4. Incident Diagnose . . . . . . . . . . . . . . . . . . . . 22 7.5. Incident Resolution . . . . . . . . . . . . . . . . . . . 22 7.6. RPC Failure . . . . . . . . . . . . . . . . . . . . . . . 22 8. Network Incident Management YANG Module . . . . . . . . . . . 23 9. Operational Considerations . . . . . . . . . . . . . . . . . 45 9.1. Interworking with Alarm Management . . . . . . . . . . . 45 9.2. Interworking with SAIN . . . . . . . . . . . . . . . . . 47 9.3. Relationship with RFC8969 . . . . . . . . . . . . . . . . 48 9.4. Relationship with Trace Context . . . . . . . . . . . . . 49 9.5. Relationship with Network Anomaly Detection Architecture . . . . . . . . . . . . . . . . . . . . . . 49 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 10.1. Huawei Implementation . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 12.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . 52 12.2. The "YANG Module Names" Registry . . . . . . . . . . . . 52 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 52 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Hu, et al. Expires 24 March 2027 [Page 2] Internet-Draft Network Incident Management September 2026 Normative References . . . . . . . . . . . . . . . . . . . . . 52 Informative References . . . . . . . . . . . . . . . . . . . . 54 Appendix A. Examples of Network Incident Format Representation . . . . . . . . . . . . . . . . . . . . . 58 A.1. Network Incident Correlated with Specific Network Topology and the Network Service . . . . . . . . . . . . . . . . . 58 A.2. JSON Example on Incident Notifications . . . . . . . . . 60 A.3. Network Incident Correlated with Trouble Tickets . . . . 61 A.4. Intent Based Networking with Incident Diagnosis Task List . . . . . . . . . . . . . . . . . . . . . . . . . . 63 A.5. Multi-Domain Fault Demarcation with Network Incident Management . . . . . . . . . . . . . . . . . . . . . . . 66 A.6. Service Complaint triggered Network Diagnosis . . . . . . 67 Appendix B. Changes between Revisions . . . . . . . . . . . . . 68 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 1. Introduction [RFC8969] defines a framework for Automating Service and Network Management with YANG [RFC7950] for full life cycle network management. A set of YANG data models have already been developed in IETF for network performance monitoring and fault monitoring, e.g., a YANG data model for alarm management [RFC8632] defines a standard interface for alarm management. A data model for Network and VPN Service Performance Monitoring [RFC9375] defines a standard interface for network performance management. In addition, distributed tracing mechanism defined in [W3C-Trace-Context] can be used to analyze and debug operations, such as configuration transactions, across multiple distributed systems. However, these YANG data models for network maintenance are based on specific data source information and manage alarms and performance metrics data separately at different layers in various separate management systems. In addition, the frequency and quantity of alarms and performance metrics data reported to Operating Support System (OSS) have increased dramatically (in many cases multiple orders of magnitude) with the growth of service types and complexity and greatly overwhelm OSS platforms [TMF724A]; with existing known dependency relationships between metric, alarm, and events at each layer (e.g., packet layer or optical layer), it is possible to compress series of alarms (see Section 3.5.3 of [RFC8632]) into fewer network incidents and there are many solutions in the market when this document was written that essentially do this to some degree. However, conventional solutions such as data compression are time- consuming and labor-intensive, usually rely on maintenance engineers' experience for data analysis, which, in many cases, result in low processing efficiency, inaccurate Probable Root Cause identification Hu, et al. Expires 24 March 2027 [Page 3] Internet-Draft Network Incident Management September 2026 and duplicated tickets. It is also difficult to assess the impact of alarms, performance metrics and other anomaly data on network services without known relation across layers of the entire network topology data or the relation with other network topology data. To address these challenges, this document specifies a network-wide, incident-centric solution to establish the global view on dependency relationships with both network service and network topology at various different layers, which not only can be used at a specific layer in one domain but also can be used to span across layers for multi-layer network troubleshooting. As described in [RFC9940], a network incident refers to an undesired Occurrence such as an unexpected interruption of a network service, degradation of the quality of a network service, or the below-target performance of a network service. Different data sources, including alarms, metrics, and other anomaly information, can be correlated and combined into one or a few network incidents, regardless of layer, informed by correlation analysis and service impact assessment. For example, if the protocol-related interface fails to work properly, a large amount of alarms may be reported to the upper-layer management system. Although a lot of network services may be affected by the interface, only one aggregated network incident pertaining to the abnormal interface will be reported. A network incident may also be raised through the analysis of some network performance metrics, for example, as described in SAIN [RFC9417], network services can be decomposed to several sub-services, specific metrics can be monitored for each sub-service. Therefore symptoms will occur if services/sub- services are unhealthy (after analyzing metrics), in addition, these symptoms may give rise to a network incident when it causes degradation of the network services. In addition, Artificial Intelligence (AI) and Machine Learning (ML) are key technologies in the processing of large amounts of data with complex data correlations (see Section 6.1 of [I-D.irtf-nmrg-ai-challenges]). For example, Neural Network Algorithm or Hierarchy Aggregation Algorithm [BERT] can be used to replace manual alarm data correlation. Through online and offline self-learning, these algorithms can be continuously optimized to improve the efficiency of fault diagnosis. This document defines a YANG data model for network incident lifecycle management, which improves troubleshooting efficiency, and improves network automation [RFC8969] with remote process call (RPC) operations in this YANG module. Hu, et al. Expires 24 March 2027 [Page 4] Internet-Draft Network Incident Management September 2026 2. Conventions and Definitions 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. The following terms are defined in [RFC9543],[RFC9940] and are not redefined here: * Alarm * Resource * Fault * Event * Problem * Incident * Anomaly * Cause * Symptom * Characteristic * Occurrence * SLA (Service Level Agreement) * SLO (Service Level Objective) The following terms are defined in this document: Service Impact Assessment: A process that uses algorithmic techniques (e.g., machine learning, automated reasoning, conformance checking, graph traversal, among others) to evaluate whether the network service has been impacted by the network incident and map the network incident to one or a set of network services. This process can reduce the volume of fault/alarms reporting, facilitate troubleshooting, and assure network service performance and availability. Hu, et al. Expires 24 March 2027 [Page 5] Internet-Draft Network Incident Management September 2026 Network Incident Management: Lifecycle management of network incidents, including network incident identification, reporting, acknowledgement, diagnosis, and resolution. Unlike previous fault management, it takes various different data sources including alarms, metrics, and other anomaly information and aggregates them into one or a few network incidents irrespective of layer through data correlation analysis and the Service Impact Assessment. A network incident might impact one or a set of network services. The network incident can also been seen as customer incident [TMF724A] when the service SLA [RFC9543] associated with one specific network service and network incident has been affected. How a customer incident is translated from the network incident is beyond the scope of this document. Note that a customer incident specifically arises when an issue or problem identified by a customer (or derived from a service-level threshold/SLO violation) impacts their service experience. Incident Management System: An entity that implements network Incident Management. It includes (but not limited to) Incident Server and Incident Client. Incident Server: An entity that is responsible for detecting and reporting one network incident, performing network incident diagnosis, resolution and prediction in specific domain, etc. Incident Client: An entity that can manage network incidents based on global view on network topology data correlation. For example, it can receive network incident notifications, query the information of network incidents, instruct an Incident Server to diagnose, help resolve, etc. In addition, it can trigger issue tickets and involve repair crew to fix the problem. Incident Handler: An entity that can receive network incident notifications, store and query the information of network incidents for data analysis. Unlike the Incident Client, it does not control the incident server and cannot instruct it to perform network incident diagnosis or resolution. Incident Process: A multi-step workflow used by network operation teams to identify, analyze, and unexpected service disruptions or quality reductions, with the primary goal of restoring normal operations as quickly as possible while minimizing service impact. Probable Root Cause: If removing a fault condition completely s the ongoing incident (specifically, regarding network outage or service impairments and their associated subsequent failures and symptoms) and prevents the problem from recurring, then such fault condition is considered as a Probable Root Cause of a problem. Hu, et al. Expires 24 March 2027 [Page 6] Internet-Draft Network Incident Management September 2026 Since one fault may give rise to another fault or problem, a Probable Root Cause is commonly meant to describe the original event or combination of circumstances that is the foundation of all related faults. Conversely, a causal fault condition is a contributing action that influences the outcome of the incident or event, but is not the Probable Root Cause. 3. Sample Use Cases 3.1. Incident-Based Trouble Tickets Dispatching Usually, the dispatching of trouble tickets in a network is mostly based on alarm data analysis and often requires operators' maintenance engineers. These operators' maintenance engineers are responsible for monitoring, detecting and correlating alarms, e.g., that alarms at both endpoints of a specific tunnel or at both optical and IP layers which are associated with the same network fault. Therefore, they can correlate these alarms to the same trouble ticket, which offers a low level of automation. If there are more alarms, then the human costs for network maintenance are increased accordingly. Some operators preconfigure accept-lists and adopt some coarse granularity data correlation rules for the alarm management. This approach seems to improve fault management automation. However, some trouble tickets might be missed if the filtering conditions are too restrictive. If the filtering conditions are not restrictive, it might end up with multiple trouble tickets being dispatched for the same network fault. It is hard to achieve a perfect balance between the network management automation and duplicated trouble tickets under the conventional working situations. With the help of the Network Incident Management, massive sets of alarms can be aggregated into a few network incidents based on Service Impact Assessment, so the number of trouble tickets will be reduced. At the same time, the efficiency of network troubleshooting can be largely improved, which addresses the pain points of trouble ticket dispatching. 3.2. Incident Derivation from L3VPN Service Unavailability The Service Attachment Points (SAPs) defined in [RFC9408] represent the network reference points where network services can be delivered or are being delivered to customers. Hu, et al. Expires 24 March 2027 [Page 7] Internet-Draft Network Incident Management September 2026 SLOs [RFC9543] can be used to characterize the ability of a particular set of nodes to communicate according to certain measurable expectations [RFC9544]. For example, an SLA might state that any given SLO applies to at least a certain percentage of packets, allowing for a certain level of packet loss and exceeding packet delay threshold to take place. For example, an SLA might establish a multi-tiered SLO of end-to-end latency as follows: * Not to exceed 30 ms for any packet. * Not to exceed 25 ms for 99.999% of packets. * Not to exceed 20 ms for 99% of packets. This SLA information can be bound with two SAPs or multiple SAPs defined in [RFC9408], so that the service orchestration layer can use these interfaces to commit the delivery of a service on specific point-to-point service topology or point to multi-point topology. When a given SLO threshold is violated, a network incident (or customer incident [TMF724A] associated with an L3VPN service) may be derived. 3.3. Multi-layer Fault Demarcation When a fault occurs in a network that contains both packet layer devices and optical-layer devices, it may cause correlative faults in both layers, i.e., packet layer and optical layer. Specifically, fault propagation could be classified into three typical types. First, faults occurring at a packet layer device might further cause fault at an optical-layer device (e.g., Wavelength Division Multiplexing (WDM) client fault). Second, faults occurring at an optical-layer device might further cause faults at a packet layer device (e.g., Layer 3 link down). Third, faults occurring at the inter-layer link between a packet layer device and an optical-layer device might further cause faults at both devices. Multiple operation teams are usually needed to first analyse a large amount of alarms (triggered by the above-mentioned faults) from single network layer (either packet layer or optical layer) independently, then cooperate to locate the Probable Root Cause through manually analyzing multi-layer topology data and service data, thus fault demarcation becomes more complex and time-consuming in multi-layer scenario than in single-layer scenario. With the help of Network Incident Management, the management systems first automatically analyze Probable Root Cause of the alarms at each layer and report corresponding network incidents to the multi-layer, multi-domain management system, then such management system comprehensively analyzes the topology relationship and service Hu, et al. Expires 24 March 2027 [Page 8] Internet-Draft Network Incident Management September 2026 relationship between the Probable Root Causes of both layers. The inner relationship among the alarms will be identified and finally the Probable Root Cause will be located among multiple layers. By cooperating with a test tool that checks fiber optic cables (e.g.,the integrated Optical time-domain reflectometer (OTDR)) embedded within the network device, we can determine the target optical exchange station before site visits. Therefore, the overall fault demarcation process is simplified and automated, the analysis result could be reported and visualized in time. In this case, operation teams only have to confirm the analyzed result and dispatch site engineers to perform relevant maintenance actions (e.g., splice fiber) based on the Probable Root Cause. 4. Network Incident Management Architecture Hu, et al. Expires 24 March 2027 [Page 9] Internet-Draft Network Incident Management September 2026 +-------------------------------------------------+ | | | | | Incident Client | | | | | +----^------------+------------+------------+-----+ | | | | |Incident |Incident |Incident |Incident |Notification| Ack |Diagnose |Resolve | | | | | | | | | | | | +----+------------V------------V------------V-----+ | | | | | | | | | | | | | Incident Server | | | | | | | | | | | | | +----^-----------^-------------^------------^-----+ | | | | | | | | |Alarm |Abnormal |Network |Network |Report |Operation |Performance |Diagnosis | | Report |Metrics/ |using | | |Telemetry |OAM Test | | | | | | | | +--------+-----------+-------------|------------V-------+ | | | | | Network in the Autonomous Domain | | | +-------------------------------------------------------+ Figure 1: Network Incident Management Architecture Figure 1 illustrates the Network Incident Management architecture. Two key components for the Network Incident Management are the Incident Client and the Incident Server. Hu, et al. Expires 24 March 2027 [Page 10] Internet-Draft Network Incident Management September 2026 The Incident Server can be deployed in network operation platforms, network analytic platforms, controllers [RFC8969] in each domain and provides functionality such as network incident identification, report, diagnosis, resolution, or querying for the network incident lifecycle management. The Incident Client can be deployed within a single domain as the Incident Server or across domains with the global view of network data. It can be deployed either in the same network operation platforms, network analytic platforms, controllers as the Incident Server within a single domain, or at the upper-layer network operation platforms, network analytic platforms or controllers (i.e., multi-domain controllers), to invoke the functionalities provided by the Incident Server in each domain to meet business requirements of the fault management. A typical workflow of network incident lifecycle management is as follows: * Some alarm or abnormal operations, network performance metrics, network diagnosis information [I-D.ietf-opsawg-scheduling-oam-tests] are reported from the network to the Incident Server. The Incident Server receives these alarms/abnormal operations/metrics and try to analyze the correlation of them, e.g., generate a symptom if some metrics are evaluated as unhealthy, the Probable Root Cause can be detected based on the data correlation analysis. If a network incident is identified, the "incident-notification" notification will be reported to the Incident Client. The impact of network services will be further analyzed and will update the network incident if the network service is impacted. * Incident Client receives the network incident from the "incident- notification" notification reported by Incident Server, and acknowledges it with the subsequent 'incident-acknowledge' RPC operation. The Incident Client may further invoke the 'incident- diagnose' RPC to diagnose this network incident to find the Probable Root Causes. * If the Probable Root Causes have been found, the Incident Client can resolve this network incident by invoking the 'incident- resolve' RPC operation to ask the Incident Server to resolve it, or dispatching a troubleshooting ticket or using other network functions (routing calculation, configuration, etc.) without being known by the Incident Server. Hu, et al. Expires 24 March 2027 [Page 11] Internet-Draft Network Incident Management September 2026 * In case of the 'incident-resolve' RPC operation invoked by the Incident Client, the Incident Server will monitor the status of the network incident and update the status of network incident to 'cleared' if the incident can be fixed. For more detailed workflow, please refer to section 5.3. 5. Functional Interface Requirements between the Client and the Server 5.1. Incident Identification As depicted in Figure 2, multiple alarms, metrics, or hybrid can be aggregated into a network incident after analysis. +--------------+ +--| Incident1 | | +--+-----------+ | | +-----------+ | +--+ alarm1 | | | +-----------+ | | | | +-----------+ | +--+ alarm2 | | | +-----------+ | | | | +-----------+ | +--+ alarm3 | | +-----------+ | +--------------+ +--| Incident2 | | +--+-----------+ | | +-----------+ | +--+ metric1 | | | +-----------+ | | +-----------+ | +--+ metric2 | | +-----------+ | | +--------------+ +--| Incident3 | | +--+-----------+ | | +-----------+ | +--+ alarm1 | | | +-----------+ | | +-----------+ | +--| metric1 | | +-----------+ Figure 2: Incident Identification Hu, et al. Expires 24 March 2027 [Page 12] Internet-Draft Network Incident Management September 2026 The Incident Server is capable of identifying network incidents. Multiple alarms, metrics and other information are reported to the Incident Server, and the server needs to analyze it and find out the correlations of them, if the correlation match the network incident rules, network incident is identified, and reported to the client. If the network incident is repeated many times, the problem needs to be raised based on the incident and the operator's policy. Service Impact Assessment SHOULD be performed if a network incident is identified, and the content of network incident SHOULD be updated if impacted network services are detected. AI/ML may be used to identify the network incident. Expert system and online learning can help AI to identify the correlation of alarms, metrics and other information by time-base correlation algorithm, topology-based correlation algorithm, etc. For example, if the interface is down, then many protocol alarms will be reported, AI may find some correlations within the raised alarms. These new correlations will be put into the knowledge base [I-D.mackey-nmop-kg-for-netops], and the network incident will be identified faster according to knowledge base next time. +----------------------+ | | | Orchestrator | | | +--------^-------------+ |VPN A Unavailable | +-------+------------+ | | | Controller | | | | | +-^-^------------^---+ | | | IGP | |Interface |IGP Peer Down | |Down | Abnormal | | | VPN A | | | +----------+-+------------+-------------------------+ | \ +---+ ++-++ +-+-+ +---+ /| | \ | | | | | | | | / | | \|PE1+-------| P1+X--------|P2 +--------|PE2|/ | | +---+ +---+ +---+ +---+ | +---------------------------------------------------+ Figure 3: Example 1 of Network Incident Identification Hu, et al. Expires 24 March 2027 [Page 13] Internet-Draft Network Incident Management September 2026 As described in Figure 3, VPN A a is deployed from PE1 to PE2, if an interface of P1 is going down, many alarms are triggered, such as interface down, IGP down, and IGP peer abnormal from P2. These alarms are aggregated and analyzed by the controller/Incident Server, and then the network incident 'VPN unavailable' is triggered by the controller/Incident Server. If the network incident 'VPN unavailable' is repeated, the problem can be raised. Note that Incident Server within the controller can rely on data correlation technology such as Service Impact Assessment and data analytic component to evaluate the real effect on the relevant service and understand whether lower level or device level network anomaly has impact on the service (e.g., IGP down). +----------------------+ | | | Orchestrator | | | +----------+-----------+ |VPN A Degradation | +---------+----------+ | | | controller | | | | | +--^------------^----+ | | |Packet |Path Delay |Loss | | | VPN A | | +-----------+------------+---------------------------+ | \ +---+ ++-++ +-+-+ +---+ / | | \ | | | | | | | | / | | \|PE1+-------|P1 +---------|P2 +--------|PE2|/ | | +---+ +---+ +---+ +---+ | +----------------------------------------------------+ Figure 4: Example 2 of Network Incident Identification As described in Figure 4, controller collect the network metrics from network elements, it finds the packet loss of P1 and the path delay of P2 exceed the thresholds, a network incident 'VPN A degradation' may be triggered after the Service Impact Assessment. Hu, et al. Expires 24 March 2027 [Page 14] Internet-Draft Network Incident Management September 2026 5.2. Incident Diagnosis After a network incident is reported to the network Incident Client, the Incident Client may diagnose the incident to determine the Probable Root Cause. Some diagnosis operations may affect the running network services. The Incident Client can choose not to perform that diagnosis operation after determining the impact is not trivial. The Incident Server can also perform self-diagnosis. However, the self-diagnosis MUST NOT affect the running network services. Possible diagnosis methods include link reachability detection, link quality detection, alarm/log analysis, and short-term fine-grained monitoring of network quality metrics, etc. 5.3. Incident Resolution After the Probable Root Cause is diagnosed, the Incident Client may resolve the network incident. The Incident Client may choose to resolve the network incident by invoking other functions, such as routing calculation function, configuration function, dispatching a ticket or asking the server to resolve it. Generally, the Incident Client would attempt to directly resolve the Probable Root Cause. If the Probable Root Cause cannot be resolved, an alternative solution SHOULD be sought. For example, if a network incident caused by a physical component failure and cannot be automatically resolved, the standby link can be used to bypass the faulty component. Incident Server monitors the status of the network incident, if the faults are fixed, the Incident Server will update the status of network incident to 'cleared', and report the updated network incident to the client. Please refer to Section 6.2 for the Incident Lifecycle and its status. Network incident resolution may affect the running network services. The client can choose not to perform those operations based on operator's policy after determining the impact is not trivial. 6. Incident Data Model Concepts 6.1. Identifying the Incident Instance An 'incident-no' is used as an identifier of an incident instance, if an incident instance is identified, a new 'incident-no' is created. The 'incident-no' MUST be unique in the whole system. 6.2. The Incident Lifecycle The network incident model clearly separates network incident instance lifecycle from operator incident lifecycle: Hu, et al. Expires 24 March 2027 [Page 15] Internet-Draft Network Incident Management September 2026 * Network incident instance lifecycle: The network incident instrumentation that controls whether a network incident is 'raised', 'updated', or 'cleared'. * Operator incident lifecycle: Operators acting upon the network incident with RPCs like 'incident-acknowledge', 'incident- diagnose' and 'incident-resolve'. 6.2.1. Network Incident Instance Lifecycle From a network incident instance perspective, a network incident can have the following lifecycle: 'raised', 'updated', 'cleared'. When a network incident instance is first generated, the status is 'raised'. If the status changes after the network incident instance is generated, (for example, self-diagnosis, diagnosis command issued by the client, or any other condition causes the status to change but does not reach the 'cleared' level) , the status changes to 'updated'. When a network incident is successfully resolved, the status changes to 'cleared'. 6.2.2. Operator Incident Lifecycle Operators can act upon network incident with network incident RPCs. From an operator perspective, the lifecycle of a network incident instance includes 'acknowledged', 'diagnosed', and 'resolved'. When a network incident instance is generated, the operator SHOULD acknowledge the network incident with 'incident-acknowledge' RPC. And then the operator attempts to diagnose the network incident with 'incident-diagnose' PRC (for example, find out the Probable Root Cause and affected components). Diagnosis is not mandatory. If the Probable Root Cause and affected components are known when the network incident is generated, diagnosis is not required. After locating the Probable Root Cause and affected components, operator can try to resolve the network incident by invoking 'incident- resolve' RPC. 7. Incident Data Model Design 7.1. Overview There is one YANG module in the "ietf-incident" model, which defines technology independent abstraction of network incident construct for alarm, log, performance metrics, etc. The information reported in the network incident include Probable Root Cause, priority, impact, suggestion, etc. Hu, et al. Expires 24 March 2027 [Page 16] Internet-Draft Network Incident Management September 2026 At the top of "ietf-incident" module is the Network Incident. Network incident is represented as a list and indexed by "name type incident-qualifier". Each Network Incident is associated with a network service instance, domain and sources. Under sources, there is one or more sources. Each source corresponds to a node defined in the network topology model and network resource in the network device, e.g., interface. In addition, "ietf-incident" supports one general notification to report network incident state changes and three RPCs to manage the network incidents. =============== NOTE: '\' line wrapping per RFC 8792 ================ module: ietf-incident +--ro incidents +--ro incident* [name type incident-qualifier] +--ro incident-no uint64 +--ro name string +--ro type identityref +--ro incident-qualifier string +--ro service-instance* string +--ro domain identityref +--ro priority incident-priority +--ro status? enumeration +--ro ack-status? enumeration +--ro category identityref +--ro detail? string +--ro resolve-advice? string +--ro sources | +--ro source* [node-ref] | +--ro node-ref -> /nw:networks/network[nw:\ network-id=current()/../network-ref]/node/node-id | +--ro network-ref? -> /nw:networks/network/network-id | +--ro resource* [name] | +--ro name al:resource +--ro probable-causes | +--ro probable-cause* [node-ref] | +--ro node-ref -> /nw:networks/network[nw:\ network-id=current()/../network-ref]/node/node-id | +--ro network-ref? -> /nw:networks/network/network-id | +--ro resource* [name] | | +--ro name al:resource | | +--ro cause-name? string | | +--ro detail? string | +--ro cause-name? string | +--ro detail? string +--ro probable-events | +--ro probable-event* [type event-id] | +--ro type -> ../../../events/event/type Hu, et al. Expires 24 March 2027 [Page 17] Internet-Draft Network Incident Management September 2026 | +--ro event-id -> ../../../events/event[type = \ current()/../type]/event-id +--ro events | +--ro event* [type event-id] | +--ro type identityref | +--ro event-id string | +--ro (event-type-info)? | +--:(alarm) | | +--ro alarm | | +--ro resource? -> /al:alarms/\ alarm-list/alarm/resource | | +--ro alarm-type-id? -> /al:alarms/\ alarm-list/alarm[al:resource = current()/../resource]/alarm-type-id | | +--ro alarm-type-qualifier? -> /al:alarms/\ alarm-list/alarm[al:resource = current()/../resource][al:alarm-type-\ id = current()/../alarm-type-id]/al:alarm-type-qualifier | +--:(metric) | | +--ro metric | | +--ro resource? al:resource | | +--ro metric-name? string | | +--ro threshold-value? decimal64 | | +--ro observed-value? decimal64 | +--:(notification) | +--ro notification | +--ro event-time? yang:date-and-time | +--ro hostname? inet:host | +--ro sequence-number? yang:counter32 +--ro raise-time? yang:date-and-time +--ro occur-time? yang:date-and-time +--ro clear-time? yang:date-and-time +--ro ack-time? yang:date-and-time +--ro last-updated? yang:date-and-time rpcs: +---x incident-acknowledge | +---w input | +---w incident-no* incident-ref +---x incident-diagnose | +---w input | +---w incident-no* incident-ref +---x incident-resolve +---w input +---w incident-no* incident-ref notifications: +---n incident-notification +--ro incident-no incident-ref +--ro name? string Hu, et al. Expires 24 March 2027 [Page 18] Internet-Draft Network Incident Management September 2026 +--ro type? identityref +--ro incident-qualifier? string +--ro service-instance* string +--ro domain identityref +--ro priority incident-priority +--ro status? enumeration +--ro ack-status? enumeration +--ro category identityref +--ro detail? string +--ro resolve-advice? string +--ro sources | +--ro source* [node-ref] | +--ro node-ref -> /nw:networks/network[nw:network\ -id=current()/../network-ref]/node/node-id | +--ro network-ref? -> /nw:networks/network/network-id | +--ro resource* [name] | +--ro name al:resource +--ro probable-causes | +--ro probable-cause* [node-ref] | +--ro node-ref -> /nw:networks/network[nw:network\ -id=current()/../network-ref]/node/node-id | +--ro network-ref? -> /nw:networks/network/network-id | +--ro resource* [name] | | +--ro name al:resource | | +--ro cause-name? string | | +--ro detail? string | +--ro cause-name? string | +--ro detail? string +--ro probable-events | +--ro probable-event* [type event-id] | +--ro type -> ../../../events/event/type | +--ro event-id -> ../../../events/event[type = \ current()/../type]/event-id +--ro events | +--ro event* [type event-id] | +--ro type identityref | +--ro event-id string | +--ro (event-type-info)? | +--:(alarm) | | +--ro alarm | | +--ro resource? -> /al:alarms/\ alarm-list/alarm/resource | | +--ro alarm-type-id? -> /al:alarms/\ alarm-list/alarm[al:resource = current()/../resource]/alarm-type-id | | +--ro alarm-type-qualifier? -> /al:alarms/\ alarm-list/alarm[al:resource = current()/../resource][al:alarm-type-\ id = current()/../alarm-type-id]/al:alarm-type-qualifier | +--:(metric) Hu, et al. Expires 24 March 2027 [Page 19] Internet-Draft Network Incident Management September 2026 | | +--ro metric | | +--ro resource? al:resource | | +--ro metric-name? string | | +--ro threshold-value? decimal64 | | +--ro observed-value? decimal64 | +--:(notification) | +--ro notification | +--ro event-time? yang:date-and-time | +--ro hostname? inet:host | +--ro sequence-number? yang:counter32 +--ro time? yang:date-and-time Figure 5: Incident YANG Tree Diagram 7.2. Incident Notifications notifications: +---n incident-notification +--ro incident-no incident-ref +--ro name? string +--ro type? identityref +--ro incident-qualifier? string +--ro service-instance* string +--ro domain identityref +--ro priority incident-priority +--ro status? enumeration +--ro ack-status? enumeration +--ro category identityref +--ro detail? string +--ro resolve-advice? string +--ro sources | +--ro source* [node-ref] | +--ro node-ref leafref | +--ro network-ref? leafref | +--ro resource* [name] | +--ro name al:resource +--ro probable-causes | +--ro probable-cause* [node-ref] | +--ro node-ref leafref | +--ro network-ref? leafref | +--ro resource* [name] | | +--ro name al:resource | | +--ro cause-name? string | | +--ro detail? string | +--ro cause-name? string | +--ro detail? string +--ro probable-events | +--ro probable-event* [type event-id] Hu, et al. Expires 24 March 2027 [Page 20] Internet-Draft Network Incident Management September 2026 | +--ro type leafref | +--ro event-id leafref +--ro events | +--ro event* [type event-id] | +--ro type identityref | +--ro event-id string | +--ro (event-type-info)? | +--:(alarm) | | +--ro alarm | | +--ro resource? leafref | | +--ro alarm-type-id? leafref | | +--ro alarm-type-qualifier? leafref | +--:(metric) | | +--ro metric | | +--ro resource? al:resource | | +--ro metric-name? string | | +--ro threshold-value? decimal64 | | +--ro observed-value? decimal64 | +--:(notification) | +--ro notification | +--ro event-time? yang:date-and-time | +--ro hostname? inet:host | +--ro sequence-number? yang:counter32 +--ro time? yang:date-and-time A general notification, "incident-notification", is provided here. When a network incident instance is identified, the notification is sent from the incident server to the incident client . After a notification is generated, if the incident server performs self diagnosis or the Incident Client uses the interfaces provided by the Incident Server to deliver diagnosis and resolution actions, the notification update behavior is triggered, for example, the Probable Root Cause objects and affected objects are updated. When a network incident is successfully resolved, the status of the network incident would be set to 'cleared'. 7.3. Incident Acknowledge rpcs: +---x incident-acknowledge | +---w input | | +---w incident-no* incident-ref After an incident is generated, updated, or cleared, the operator confirms the incident to ensure that the client knows the incident. Hu, et al. Expires 24 March 2027 [Page 21] Internet-Draft Network Incident Management September 2026 In some scenarios where automatic diagnosis and resolution are supported, the status of an incident may be updated multiple times or even automatically resolved. Therefore the 'incident-acknowledge' RPC can confirm multiple incidents at a time. 7.4. Incident Diagnose rpcs: +---x incident-diagnose | +---w input | | +---w incident-no* incident-ref After a network incident is generated, 'incident-diagnose' RPC can be used to diagnose the network incident and locate the Probable Root Causes. On-demand Diagnosis can be performed on some detection tasks, such as bfd detection, flow detection, telemetry collection, short-term threshold alarm, configuration error check, or test packet injection. After the on-demand diagnosis is performed successfully, a separate network incident update notification will be triggered to report the latest status of the network incident asynchronously. 7.5. Incident Resolution rpcs: +---x incident-resolve +---w input | +---w incident-no* incident-ref After the Probable Root Causes and impacts are determined, incident- resolve RPC can be used to resolve the incident (if the server can resolve it). How to resolve an incident instance is out of the scope of this document. 'incident-resolve' RPC allows multiple network incident instances to be resolved at a time. If a network incident instance is successfully resolved, a separate notification is triggered to update the network incident status to 'cleared'. If the network incident content is changed during this process, a notification update will be triggered. 7.6. RPC Failure If the RPC fails, the RPC error response MUST indicate the reason for the failure. The structures defined in this document MUST encode specific errors and be inserted in the error response to indicate the reason for the failure. Hu, et al. Expires 24 March 2027 [Page 22] Internet-Draft Network Incident Management September 2026 The tree diagram [RFC8340] for structures is defined as follows: structure incident-acknowledge-error-info: +-- incident-acknowledge-error-info +-- incident-no? uint64 +-- reason? identityref +-- description? string structure incident-diagnose-error-info: +-- incident-diagnose-error-info +-- incident-no? uint64 +-- reason? identityref +-- description? string structure incident-resolve-error-info: +-- incident-resolve-error-info +-- incident-no? uint64 +-- reason? identityref +-- description? string Valid errors that can occur for each structure defined in this document are described as follows: incident-acknowledge-error-info ----------------------------------- repeated-acknowledge incident-not-found incident-diagnose-error-info ----------------------------------- probable-cause-unlocated permission-denied operation-timeout resource-unavailable incident-not-found incident-resolve-error-info ----------------------------------- probable-cause-unresolved permission-denied operation-timeout resource-unavailable incident-not-found 8. Network Incident Management YANG Module This module imports types from [RFC9911], [RFC8632], [RFC8345], [RFC8791] and uses types defined in [RFC9376], [RFC1136], [RFC6373], [RFC8348], [RFC8632], [RFC5277], [RFC9940], [RFC9375], [RFC5277], [RFC8639], [RFC8641], [I-D.ietf-netconf-notif-envelope]. Hu, et al. Expires 24 March 2027 [Page 23] Internet-Draft Network Incident Management September 2026 file "ietf-incident@2026-07-30.yang" module ietf-incident { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-incident"; prefix inc; import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types, Section 3"; } import ietf-inet-types { prefix inet; reference "RFC 9911: Common YANG Data Types, Section 4"; } import ietf-alarms { prefix al; reference "RFC 8632: A YANG Data Model for Alarm Management"; } import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } organization "IETF NMOP Working Group"; contact "WG Web: https://datatracker.ietf.org/wg/nmop/; WG List: NMOP Author: Chong Feng Author: Tong Hu Author: Luis Miguel Contreras Murillo Author: Qin Wu Author: Nigel Davis "; Hu, et al. Expires 24 March 2027 [Page 24] Internet-Draft Network Incident Management September 2026 description "This module defines the interfaces for incident management lifecycle. This module is intended for the following use cases: * incident lifecycle management: - incident report: report incident instance to client when an incident instance is detected. - incident acknowledge: acknowledge an incident instance. - incident diagnose: diagnose an incident instance. - incident resolve: resolve an incident instance. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2026-07-30 { description "Initial version."; reference "RFC XXXX: A YANG Data Model for Network Incident Management."; } // Identities identity incident-domain { description "The base identity to indicate the domain of an incident."; Hu, et al. Expires 24 March 2027 [Page 25] Internet-Draft Network Incident Management September 2026 } identity single-domain { base incident-domain; description "Indicates single domain."; } identity access { base single-domain; description "Indicates access domain."; } identity ran { base access; description "Indicates a radio access network domain."; } identity transport { base single-domain; description "Indicates a transport domain."; } identity otn { base transport; description "Indicates an optical transport network domain."; reference "RFC 9376: Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network"; } identity ip { base single-domain; description "Indicates an IP domain."; reference "RFC 1136: Administrative Domains and Routing Domains A Model for Routing in the Internet"; } identity ptn { base ip; description "Indicates a packet transport network domain."; Hu, et al. Expires 24 March 2027 [Page 26] Internet-Draft Network Incident Management September 2026 reference "RFC 6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework"; } identity cross-domain { base incident-domain; description "Indicates a cross domain."; } identity incident-category { description "The abstract identity for incident category."; } identity device { base incident-category; description "Device category."; reference "RFC 8348: A YANG Data Model for Hardware Management"; } identity power-environment { base device; description "Power environment category."; reference "RFC 8348: A YANG Data Model for Hardware Management"; } identity device-hardware { base device; description "Device hardware category."; reference "RFC 8348: A YANG Data Model for Hardware Management"; } identity device-software { base device; description "Device software category."; reference "RFC 8348: A YANG Data Model for Hardware Management"; } Hu, et al. Expires 24 March 2027 [Page 27] Internet-Draft Network Incident Management September 2026 identity line-card { base device-hardware; description "Line card category."; reference "RFC 8348: A YANG Data Model for Hardware Management"; } identity maintenance { base incident-category; description "Maintenance category."; } identity network { base incident-category; description "Network category."; } identity protocol { base incident-category; description "Protocol category."; } identity overlay { base incident-category; description "Overlay category."; } identity vm { base incident-category; description "Virtual Machine category."; } identity event-type { description "The abstract identity for Event type."; reference "RFC 9940: Some Key Terms for Network Fault and Problem Management"; } identity alarm { base event-type; Hu, et al. Expires 24 March 2027 [Page 28] Internet-Draft Network Incident Management September 2026 description "Alarm event type."; reference "RFC 8632: A YANG Data Model for Alarm Management"; } identity notif { base event-type; description "Notification event type."; reference "RFC 5277: NETCONF Event Notifications and RFC 8639: Subscription to YANG Notifications and RFC 8641: Subscription to YANG Notifications for Datastore Updates and I-D.ietf-netconf-notif-envelope: Extensible YANG Model for YANG-Push Notifications"; } identity metric { base event-type; description "Metric event type."; reference "RFC 9375: A YANG Data Model for Network and VPN Service Performance Monitoring"; } identity unknown { base event-type; description "Unknown event type."; } identity incident-type { description "The abstract identity for Incident type."; } identity problem { base incident-type; description "It indicates the class of the incident is a problem (i.e., cause of the incident) for example an interface fails to work."; reference "RFC 9940: Some Key Terms for Network Fault and Problem Management"; Hu, et al. Expires 24 March 2027 [Page 29] Internet-Draft Network Incident Management September 2026 } identity sla-violation { base incident-type; description "It indicates the class of the incident is an SLA violation, for example high CPU rate may cause a fault in the future."; } identity acknowledge-error { description "Base identity for the problem found while attempting to fulfill an 'incident-acknowledge' RPC request."; } identity diagnose-error { description "Base identity for the problem found while attempting to fulfill an 'incident-diagnose' RPC request."; } identity resolve-error { description "Base identity for the problem found while attempting to fulfill an 'incident-resolve' RPC request."; } identity repeated-acknowledge { base acknowledge-error; description "The incident referred to has already been acknowledged."; } identity incident-not-found { base acknowledge-error; base diagnose-error; base resolve-error; description "The incident is triggered when the incident does not exist in the datastore and a Client performs the RPCs."; } identity probable-cause-unlocated { base diagnose-error; description "Fail to locate the Probable Root Causes when performing the diagnosis operation. The detailed reason MUST be included Hu, et al. Expires 24 March 2027 [Page 30] Internet-Draft Network Incident Management September 2026 in the 'description'."; } identity probable-cause-unresolved { base resolve-error; description "Fail to resolve the Probable Root Causes when performing the resolution operation. The detailed reason MUST be included in the 'description'."; } identity permission-denied { base diagnose-error; base resolve-error; description "The permission required for performing specific detection/resolution task is not granted."; } identity operation-timeout { base diagnose-error; base resolve-error; description "The diagnosis/resolution time exceeds the preset time."; } identity resource-unavailable { base diagnose-error; base resolve-error; description "The resource is unavailable to perform the diagnosis/resolution operation."; } // Typedefs typedef incident-priority { type enumeration { enum critical { description "The 'critical' priority level indicates that a service- affecting condition has occurred and an immediate corrective action is required. Such a priority can be reported, for example, when a resource becomes totally out of service and its capability must be restored."; } enum high { description Hu, et al. Expires 24 March 2027 [Page 31] Internet-Draft Network Incident Management September 2026 "The 'high' priority level indicates that a service- affecting condition has developed and an urgent corrective action is required. Such a priority can be reported, for example, when there is a severe degradation in the capability of the resource and its full capability must be restored."; } enum medium { description "The 'medium' severity level indicates the existence of a non-service-affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service-affecting) fault. Such a priority can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the resource."; } enum low { description "The 'low' priority level indicates the detection of a potential or impending service-affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service-affecting fault."; } } description "Defines the priority of incident."; } typedef incident-ref { type leafref { path "/inc:incidents/inc:incident/inc:incident-no"; require-instance false; } description "Provides a reference to a network incident using incident-no note that incident no is unique but not incident list key. The incident-ref is used for correlation between incident no and incident list key in the RPCs and Notification."; } // Groupings grouping probable-cause-info { description "The information of Probable Root Cause."; Hu, et al. Expires 24 March 2027 [Page 32] Internet-Draft Network Incident Management September 2026 leaf cause-name { type string; description "Specifies the cause name."; } leaf detail { type string; description "The detail information of the cause."; } } grouping resources-info { description "The grouping which defines the network resources of a node."; uses nw:node-ref; list resource { key "name"; description "The resources of a network node."; leaf name { type al:resource; description "Network resource name."; } } } grouping incident-time-info { description "The grouping defines incident time information."; leaf raise-time { type yang:date-and-time; description "The time when an incident instance is raised."; } leaf occur-time { type yang:date-and-time; mandatory true; description "The time when an incident instance occurs. It's the occur time of the first event during incident detection."; } leaf clear-time { type yang:date-and-time; description Hu, et al. Expires 24 March 2027 [Page 33] Internet-Draft Network Incident Management September 2026 "The time when an incident instance is resolved."; } leaf ack-time { type yang:date-and-time; description "The time when an incident instance is acknowledged."; } leaf last-updated { type yang:date-and-time; description "The latest time when an incident instance is updated."; } } grouping incident-info { description "The grouping defines the information of an incident."; leaf name { type string; description "The name of an incident."; } leaf type { type identityref { base incident-type; } description "The type of an incident."; } leaf incident-qualifier { type string; description "The unique qualifier of an incident instance type. This leaf is used when the 'type' leaf cannot uniquely identify the incident instance type. Normally, this is not the case, and this leaf is the empty string."; } leaf-list service-instance { type string; description "The related network service instances of the incident instance."; } Hu, et al. Expires 24 March 2027 [Page 34] Internet-Draft Network Incident Management September 2026 leaf domain { type identityref { base incident-domain; } mandatory true; description "The domain of an incident."; } leaf priority { type incident-priority; mandatory true; description "The priority of an incident instance."; } leaf status { type enumeration { enum raised { description "An incident instance is raised."; } enum updated { description "The information of an incident instance is updated."; } enum cleared { description "An incident is cleared."; } } description "The status of an incident instance."; } leaf ack-status { type enumeration { enum acknowledged { description "The incident has been acknowledged by user."; } enum unacknowledged { description "The incident hasn't been acknowledged."; } } description "The acknowledge status of an incident."; } leaf category { Hu, et al. Expires 24 March 2027 [Page 35] Internet-Draft Network Incident Management September 2026 type identityref { base incident-category; } mandatory true; description "The category of an incident."; } leaf detail { type string; description "Detailed information of this incident."; } leaf resolve-advice { type string; description "The advice to resolve this incident."; } container sources { description "The source components."; list source { key "node-ref"; description "The source components of incident. An Incident might be created even if we don't know yet the sources (hence we can not populate source list in the sources container). Therefore the min-elements for the source list is set to 0 which is default value. Once the Incident is diagnosed, the source(s) will be populated."; uses resources-info; } } container probable-causes { description "The Probable Root Cause objects."; list probable-cause { key "node-ref"; description "The Probable Root Causes of incident."; uses resources-info { augment "resource" { description "Augment Probable Root Cause information."; //if Probable Root Cause object is a resource of a node uses probable-cause-info; } } //if Probable Root Cause object is a node Hu, et al. Expires 24 March 2027 [Page 36] Internet-Draft Network Incident Management September 2026 uses probable-cause-info; } } container probable-events { description "The Probable Root Cause related events of the incident."; list probable-event { key "type event-id"; description "The Probable Root Cause related event of the incident."; leaf type { type leafref { path "../../../events/event/type"; } description "The event type."; } leaf event-id { type leafref { path "../../../events/event[type = current()/../type]" + "/event-id"; } description "The event identifier, such as uuid, sequence number, etc."; } } } container events { description "Related events."; list event { key "type event-id"; description "Related events."; leaf type { type identityref { base event-type; } description "Event type."; } leaf event-id { type string; description "The event identifier, such as uuid, sequence number, etc."; } Hu, et al. Expires 24 March 2027 [Page 37] Internet-Draft Network Incident Management September 2026 choice event-type-info { description "Various different event type information."; case alarm { when "derived-from-or-self(type, 'alarm')" { description "Only applies when type is alarm."; } container alarm { description "Alarm type event."; leaf resource { type leafref { path "/al:alarms/al:alarm-list/al:alarm" + "/al:resource"; require-instance false; } description "This is an identification of the alarming resource."; reference "RFC 8632: A YANG Data Model for Alarm Management"; } leaf alarm-type-id { type leafref { path "/al:alarms/al:alarm-list/al:alarm" + "[al:resource = current()/../resource]" + "/al:alarm-type-id"; require-instance false; } description "Alarm type id."; reference "RFC 8632: A YANG Data Model for Alarm Management"; } leaf alarm-type-qualifier { type leafref { path "/al:alarms/al:alarm-list/al:alarm" + "[al:resource = current()/../resource]" + "[al:alarm-type-id = current()/.." + "/alarm-type-id]/al:alarm-type-qualifier"; require-instance false; } description "Alarm type qualifier."; reference Hu, et al. Expires 24 March 2027 [Page 38] Internet-Draft Network Incident Management September 2026 "RFC 8632: A YANG Data Model for Alarm Management"; } } } case metric { when "derived-from-or-self(type, 'metric')" { description "Only applies when type is metric."; } container metric { description "Metric type event. Performance metrics exceeding SLO thresholds."; leaf resource { type al:resource; description "This is an identification of the network resource such as interface, where the metric can be collected or measured."; reference "RFC 8632: A YANG Data Model for Alarm Management"; } leaf metric-name { type string; description "Metric Name."; } leaf threshold-value { type decimal64 { fraction-digits 2; } description "Threshold value for the specific metric."; } leaf observed-value { type decimal64 { fraction-digits 2; } description "Observed value for the specific metric."; } } } case notification { when "derived-from-or-self(type, 'notif')" { description Hu, et al. Expires 24 March 2027 [Page 39] Internet-Draft Network Incident Management September 2026 "Only applies when type is notification."; } container notification { description "Notification type event."; leaf event-time { type yang:date-and-time; description "The date and time the event was generated by the network node."; reference "I-D.ietf-netconf-notif-envelope: Extensible YANG Model for YANG-Push Notifications"; } leaf hostname { type inet:host; description "The hostname of the network node. This value is usually configured on the node by the administrator to identify the node in the network uniquely."; reference "I-D.ietf-netconf-notif-envelope: Extensible YANG Model for YANG-Push Notifications"; } leaf sequence-number { type yang:counter32; description "Unique sequence number for each published message by the publisher process. The initial number is 1 and counts up by 1 at every published notification message until it reaches 4294967295. Then, it wraps around and restarts at 0. The value 0 is used to detect wrap arounds."; reference "I-D.ietf-netconf-notif-envelope: Extensible YANG Model for YANG-Push Notifications"; } anydata contents { description "This contains the values defined by the 'notification' statement unchanged."; } } } } } Hu, et al. Expires 24 March 2027 [Page 40] Internet-Draft Network Incident Management September 2026 } } // RPCs rpc incident-acknowledge { description "This rpc can be used to acknowledge the specified incidents."; input { leaf-list incident-no { type incident-ref; min-elements 1; description "The unique number of an incident instance based on the incident-no which is corresponding to the name type incident-id keys."; } } } rpc incident-diagnose { description "This rpc can be used to diagnose the specified incidents. The result of diagnosis will be reported by incident notification."; input { leaf-list incident-no { type incident-ref; min-elements 1; description "The unique number of an incident instance based on the incident-no which is corresponding to the name type incident-id keys."; } } } rpc incident-resolve { description "This rpc can be used to resolve the specified incidents. The result of resolution will be reported by incident notification."; input { leaf-list incident-no { type incident-ref; min-elements 1; description Hu, et al. Expires 24 March 2027 [Page 41] Internet-Draft Network Incident Management September 2026 "The unique number of an incident instance based on the incident-no which is corresponding to the name type incident-id keys."; } } } sx:structure incident-acknowledge-error-info { container incident-acknowledge-error-info { description "This structure data must be inserted in the RPC error response to indicate the reason for the incident acknowledge failure."; leaf incident-no { type uint64; description "Indicate the incident instance identifier that fails the operation."; } leaf reason { type identityref { base acknowledge-error; } description "Indicates the reason why the operation is failed."; } leaf description { type string; description "Indicates the detailed description about the failure."; } } } sx:structure incident-diagnose-error-info { container incident-diagnose-error-info { description "This structure data must be inserted in the RPC error response to indicate the reason for the incident diagnose failure."; leaf incident-no { type uint64; description "Indicate the incident instance identifier that fails the operation."; } leaf reason { Hu, et al. Expires 24 March 2027 [Page 42] Internet-Draft Network Incident Management September 2026 type identityref { base diagnose-error; } description "Indicates the reason why the operation is failed."; } leaf description { type string; description "Indicates the detailed description about the failure."; } } } sx:structure incident-resolve-error-info { container incident-resolve-error-info { description "This structure data must be inserted in the RPC error response to indicate the reason for the incident resolution failure."; leaf incident-no { type uint64; description "Indicate the incident instance identifier that fails the operation."; } leaf reason { type identityref { base resolve-error; } description "Indicates the reason why the operation is failed."; } leaf description { type string; description "Indicates the detailed description about the failure."; } } } // Notifications notification incident-notification { description "Incident notification. It will be triggered when the incident is raised, updated or cleared."; Hu, et al. Expires 24 March 2027 [Page 43] Internet-Draft Network Incident Management September 2026 leaf incident-no { type incident-ref; mandatory true; description "The identifier of an incident instance. With incident-no used in both incident-notification and RPCs, an Incident Client know which notification is the result of a given RPC."; } uses incident-info; leaf time { type yang:date-and-time; description " The time when an incident instance occurs. It is the occur time of the first event during incident detection."; } } // Data definitions container incidents { config false; description "The information of incidents."; list incident { key "name type incident-qualifier"; unique "incident-no"; description "The information of incident."; leaf incident-no { type uint64; mandatory true; description "The unique identifier of the incident instance based on the name type incident-qualifier keys."; } uses incident-info; uses incident-time-info; } } } Hu, et al. Expires 24 March 2027 [Page 44] Internet-Draft Network Incident Management September 2026 9. Operational Considerations The "ietf-incident" YANG module introduces an incident-centric architecture designed to overcome the structural silo of management systems that handle alarms and performance metrics separately at different network layers. Operators need to ensure that the underlying management system feeding this model maintains continuous, real-time read access to diverse end to end network topology data spanning multiple layers. Because accurate multi-layer troubleshooting depends on establishing a global view of cross-layer dependency relationships, any disruption or stale state in the underlying network topology discovery mechanisms will directly degrade the accuracy of the Incident Process's probable root cause identification and service impact analysis. In addition, the YANG module defined in this document is intended to automate and streamline incident dispatching at the network layer so that integration with trouble-ticketing management system at the OSS layer is required. Operators should implement a deterministic translation layer between the "ietf-incident" model states (e.g., raised, cleared, acknowledged) and external ticket states (e.g., Open, Assigned, In-Progress, Resolved) to prevent split-brain visibility scenarios where an incident is closed in the network layer but remains active in the ticketing system, or vice versa. This incident data model states that the tuple (name, type and incident-qualifier) corresponds to a single incident instance. This means that incident notifications for the same name and same type and incident-qualifier are matched to update the same incident instance. These three leafs are therefore used as the key in the incident list: list incident { key "name type incident-qualifier"; ... } In the meanwhile, in order to improve processing efficiency, this incident data model also allows using the unique sequence number 'incident-no' to identify each incident instance, this means that incident RPCs or notifications for the same incident-no are matched to update the same incident instance. 9.1. Interworking with Alarm Management Hu, et al. Expires 24 March 2027 [Page 45] Internet-Draft Network Incident Management September 2026 +-----------------------------+ | OSS | | +--------+ +-----------+ | | |Alarm | | Incident | | | |handler | | handler | | | +--------+ +-----------+ | +---^---------------^---------+ | | |alarm |incident +---|---------------|---------+ | | controller | | | | | | |+--+----+ +-----------+ | ||Alarm | | Incident | | ||process+----->| Process | | || |alarm | | | |+-------+ +-----------+ | | ^ ^ | +---|--------------|----------+ |alarm | metrics/trace/etc. | | +-------+--------------+---------------+ | | | Network in the Autonomous Domain | | | +--------------------------------------+ Figure 6: Interworking with Alarm Management A YANG model for the alarm management [RFC8632] defines a standard interface to manage the lifecycle of alarms. Alarms represent the undesirable state of network resources [RFC9940], The alarm data model also defines the Probable Root Causes and impacted services fields, but there may be insufficient information to determine them at lower layer system (mainly in devices level), so alarms do not always tell the status of network services or necessarily point to the Probable Root Causes of problems. As described in [RFC8632], the alarm management acts as a starting point for high-level fault management. While Network Incident Management often works at the network level, so it is possible to have enough information to perform data correlation and Service Impact Assessment. Alarms can work as one of data sources of Network Incident Management and may be aggregated into a few network incidents by the correlation analysis, network service impact and Probable Root Causes may be determined during the Incident Process. Hu, et al. Expires 24 March 2027 [Page 46] Internet-Draft Network Incident Management September 2026 Network Incident also contains some related alarms, if needed users can query the information of alarms by alarm management interface [RFC8632]. In some cases, e.g., cutover scenario, the Incident Server may use alarm management interface [RFC8632] to shelve some alarms. Alarm management may keep the original process, alarms are reported from network to network controller or network analytic platform and then reported to upper-layer system (e.g., the alarm handler within the OSS). Similarly, the network incident is reported from the network to the network controller or network analytic platform and then reported to the upper-layer system (e.g., Incident Handler within the OSS). Upper-layer system may store these network incidents and provide the information for fault analysis (e.g., deeper customer incident analysis based on network incident). Different from alarm management, Incident Process within the controller comprising both Incident Client and Incident Server functionalities provides not only network incident reporting but also diagnosis and resolution functions, it's possible to support self- healing and may be helpful for single-domain closed-loop control. Network Incident Management is not a substitute for alarm management. Instead, they can work together to implement fault management. 9.2. Interworking with SAIN SAIN [RFC9417] defines an architecture of network service assurance. Hu, et al. Expires 24 March 2027 [Page 47] Internet-Draft Network Incident Management September 2026 +----------------+ |Incident Handler| +----------------+ ^ |incident +-------+--------+ |Incident Process| +----------------+ ^ |symptoms +-------+--------+ | SAIN | | | +----------------+ ^ |metrics +---------------+-----------------+ | | |Network in the Autonomous Domain | | | +---------------------------------+ Figure 7: Interworking with SAIN A network service can be decomposed into some sub-services, and specific metrics can be monitored for sub-services. For example, a tunnel service can be decomposed into some peer tunnel interface sub- services and IP connectivity sub-service. If some metrics are evaluated to indicate unhealthy for specific sub-service, some symptoms will be present. Incident Process comprising both Incident Client and Incident Server functionalities may identify the network incident based on symptoms, and then report it to Incident Handler within the Operation Support System (OSS). So, SAIN can be one way to identify network incident, services, sub-services and metrics can be preconfigured via APIs defined by service assurance YANG model [RFC9418] and the network incident will be reported if symptoms match certain condition or characteristic considered as an indication of a problem or potential problem. 9.3. Relationship with RFC8969 [RFC8969] defines a framework for network automation using YANG, this framework breaks down YANG modules into three layers, service layer, network layer and device layer, and contains service deployment, service optimization/assurance, and service diagnosis. Network incident works at the network layer and aggregates alarms, metrics and other information from device layer, it's helpful to provide service assurance. And the network incident diagnosis may be one way Hu, et al. Expires 24 March 2027 [Page 48] Internet-Draft Network Incident Management September 2026 of service diagnosis. 9.4. Relationship with Trace Context W3C defines a common trace context [W3C-Trace-Context] for distributed system tracing, [I-D.ietf-netconf-trace-ctx-extension] defines a netconf extension for [W3C-Trace-Context] and [I-D.ietf-netconf-configuration-tracing] defines a mechanism for configuration tracing. If some errors occur when services are deploying, it's very easy to identify these errors by distributed system tracing, and a network incident SHOULD be reported. 9.5. Relationship with Network Anomaly Detection Architecture [I-D.ietf-nmop-network-anomaly-architecture] and related network anomaly detection documents describe how anomaly detection is applied to detect service interruption in IP networks by performing outlier detection on all 3 network planes, preserve relationships among them and score the result with a concern and with a confidence score. Section 3 of [I-D.ietf-nmop-network-anomaly-architecture] describes the elements of the system architecture where the "Alarm Management System" maps to the "Incident Server" in Section 4 of this document. The "relevant-state" YANG notification defined in Section 8.2 of [I-D.ietf-nmop-network-anomaly-lifecycle] defines an "id" which SHOULD be mapped to "event-id" in the 'ietf-incident' YANG module described in this document on the "Incident Server". [I-D.ietf-nmop-network-anomaly-semantics] augments relevant-state YANG notification with 'ietf-network-anomaly-symptom' YANG module symptom semantics described in Section 4.2 and service and network relationships with 'ietf-network-anomaly-service-topology' YANG module in Section 4.3. "hostname" in "vpn-node-termination" grouping of 'ietf-network-anomaly-service-topology' YANG module maps to "node- ref" in "node-ref" grouping respectively the "vpn-id" in the "vpn- service" list of the "vpn-service" grouping maps to the "service- instance" leaf-list of the "incident-info" grouping in 'ietf- incident' YANG module. Thus, preserving the mapping between relevant-state notification id, service id and hostname in the network where the outlier was detected. 10. Implementation Status This section records the status of known implementations of the YANG module defined by this specification at the time of posting of this document and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has Hu, et al. Expires 24 March 2027 [Page 49] Internet-Draft Network Incident Management September 2026 been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and MUST NOT be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Note to the RFC Editor: As per [RFC7942] guidelines, please remove this Implementation Status Section prior to publication. 10.1. Huawei Implementation Huawei iMaster NCE has implemented incident model with the intent management framework and AI tools to support intelligent Network Incident Management. The Huawei Implementation of Incident model covers the following a) RESTCONF support b) Incident Lifecycle management including incident instance lifecycle and operator incident lifecycle. c) Incident Notification d) Incident List Query Contact information: Qin Wu (bill.wu@huawei.com) 11. Security Considerations The YANG module specified in this document defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) MUST use a secure transport layer (e.g., SSH Transport Layer [RFC4253]) and (2) MUST use mutual authentication (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]). The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: Hu, et al. Expires 24 March 2027 [Page 50] Internet-Draft Network Incident Management September 2026 '/incidents/incident': This list specifies the network incident entries, such as the service-instance leaf-list and the sources/ probable-causes containers may reveal customer-identifiable information (e.g., which VPN services are affected, which customer endpoints are involved). Unauthorized read access of this list can allow intruders to access network incident information and potentially get a picture of the broken state of the network. Intruders may exploit the vulnerabilities of the network to lead to further negative impact on the network. Care must be taken to ensure that this list is accessed only by authorized users. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: "incident-diagnose": This RPC operation performs network incident diagnosis and Probable Root Cause locating. If a malicious or buggy client performs an unexpectedly large number of this operation, the result might be an excessive use of system resources [RFC9940] on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they can choose to block the connection (e.g., block abusive IP address) to this client and/or reject the request using rpc errors defined in section 7.6. "incident-resolve": This RPC operation is used to resolve the network incident. If a malicious or buggy client performs an unexpectedly large number of this operation, the result might be an excessive use of system resources on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they can choose to reject the request without compromise on security of data-at-rest in the server. "incident-acknowledge": This RPC operation is used to confirm the incident to ensure that the client knows the incident. If a malicious or buggy client repeatedly confirms multiple incidents at a time, the result might be an excessive use of system resources on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they can choose to block connection (e.g., block abusive IP address) to this client and/or reject the request using rpc errors defined in section 7.6. 12. IANA Considerations Hu, et al. Expires 24 March 2027 [Page 51] Internet-Draft Network Incident Management September 2026 12.1. The "IETF XML" Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-incident Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces. 12.2. The "YANG Module Names" Registry IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. Name: ietf-incident Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-incident Prefix: inc Reference: RFC XXXX // RFC Ed.: Replace RFC xxxx with this RFC id, when published and remove this comment Acknowledgements The authors would like to thank Mohamed Boucadair, Robert Wilton, Benoit Claise, Oscar Gonzalez de Dios, Adrian Farrel, Mahesh Jethanandani, Paul Aitken, Balazs Lengyel, Dhruv Dhody,Bo Wu, Qiufang Ma, Haomian Zheng, YuanYao, Wei Wang, Peng Liu, Zongpeng Du, Zhengqiang Li, Andrew Liu, Joe Clark, Roland Scott, Alex Huang Feng, Kai Gao, Jensen Zhang, Ziyang Xing, Mingshuang Jin, Aihua Guo, Zhidong Yin, Guoxiang Liu, Kaichun Wu for their valuable comments and great input to this work. References 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, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . Hu, et al. Expires 24 March 2027 [Page 52] Internet-Draft Network Incident Management September 2026 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Hu, et al. Expires 24 March 2027 [Page 53] Internet-Draft Network Incident Management September 2026 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, . [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9375] Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de Dios, O., and B. Wen, "A YANG Data Model for Network and VPN Service Performance Monitoring", RFC 9375, DOI 10.17487/RFC9375, April 2023, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, . Informative References [BERT] "Pre-training of Deep Bidirectional Transformers for Language Understanding", 2019, . [I-D.ietf-netconf-configuration-tracing] Quilbeuf, J., Claise, B., Graf, T., Lopez, D., and S. Qiong, "External Trace ID for Configuration Tracing", Work in Progress, Internet-Draft, draft-ietf-netconf- configuration-tracing-06, 3 November 2025, . Hu, et al. Expires 24 March 2027 [Page 54] Internet-Draft Network Incident Management September 2026 [I-D.ietf-netconf-notif-envelope] Feng, A. H., Francois, P., Graf, T., and B. Claise, "Extensible YANG Model for YANG-Push Notifications", Work in Progress, Internet-Draft, draft-ietf-netconf-notif- envelope-06, 14 September 2026, . [I-D.ietf-netconf-trace-ctx-extension] Gagliano, R., Rennerskog, C., Larsson, K., and J. Lindblad, "NETCONF Extension to support Trace Context propagation", Work in Progress, Internet-Draft, draft- ietf-netconf-trace-ctx-extension-09, 17 September 2026, . [I-D.ietf-nmop-network-anomaly-architecture] Graf, T., Du, W., Francois, P., and A. H. Feng, "A Framework for a Network Anomaly Detection Architecture", Work in Progress, Internet-Draft, draft-ietf-nmop-network- anomaly-architecture-08, 6 July 2026, . [I-D.ietf-nmop-network-anomaly-lifecycle] Riccobene, V., Graf, T., Du, W., and A. H. Feng, "An Experiment: Network Anomaly Detection Lifecycle", Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly- lifecycle-07, 6 September 2026, . [I-D.ietf-nmop-network-anomaly-semantics] Graf, T., Du, W., Feng, A. H., and V. Riccobene, "Semantic Metadata Annotation for Network Anomaly Detection", Work in Progress, Internet-Draft, draft-ietf-nmop-network- anomaly-semantics-06, 6 July 2026, . [I-D.ietf-opsawg-scheduling-oam-tests] Contreras, L. M., Lopez, V., and Q. Wu, "A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests", Work in Progress, Internet-Draft, draft-ietf- opsawg-scheduling-oam-tests-09, 14 September 2026, . Hu, et al. Expires 24 March 2027 [Page 55] Internet-Draft Network Incident Management September 2026 [I-D.irtf-nmrg-ai-challenges] François, J., Clemm, A., Papadimitriou, D., Fernandes, S., and S. Schneider, "Research Challenges in Coupling Artificial Intelligence and Network Management", Work in Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges- 06, 6 July 2026, . [I-D.mackey-nmop-kg-for-netops] Mackey, M., Claise, B., Graf, T., Keller, H., Voyer, D., Lucente, P., and I. D. Martinez-Casanueva, "Knowledge Graph Framework for Network Operations", Work in Progress, Internet-Draft, draft-mackey-nmop-kg-for-netops-04, 7 April 2026, . [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136, DOI 10.17487/RFC1136, December 1989, . [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . [RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar, N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS- TP) Control Plane Framework", RFC 6373, DOI 10.17487/RFC6373, September 2011, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . Hu, et al. Expires 24 March 2027 [Page 56] Internet-Draft Network Incident Management September 2026 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . [RFC9376] Wang, Q., Ed., Valiveti, R., Ed., Zheng, H., Ed., van Helvoort, H., and S. Belotti, "Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network", RFC 9376, DOI 10.17487/RFC9376, March 2023, . [RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, June 2023, . [RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023, . [RFC9418] Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, July 2023, . [RFC9544] Mirsky, G., Halpern, J., Min, X., Clemm, A., Strassner, J., and J. François, "Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs)", RFC 9544, DOI 10.17487/RFC9544, March 2024, . [RFC9940] Davis, N., Ed., Farrel, A., Ed., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", RFC 9940, DOI 10.17487/RFC9940, April 2026, . [TMF724A] "Incident Management API Profile v1.0.0", 2023, . Hu, et al. Expires 24 March 2027 [Page 57] Internet-Draft Network Incident Management September 2026 [W3C-Trace-Context] "W3C Recommendation on Trace Context", 2021, . Appendix A. Examples of Network Incident Format Representation A.1. Network Incident Correlated with Specific Network Topology and the Network Service In this example, we show a network incident that are associated with the service-instance "optical-svc-A", the node 'D1', the network topology 'L2-Topo' and the domain 'PTN'. The Probable Root Cause is also analysed. { "ietf-incident:incidents": { "incident": [ { "name": "line fault", "type": "ietf-incident:problem", "incident-qualifier": "line fault", "incident-no": 56433218, "service-instance": [ "optical-svc-A" ], "domain": "ptn", "priority": "critical", "occur-time": "2026-03-10T04:01:12Z", "clear-time": "2026-03-10T06:01:12Z", "ack-time": "2026-03-10T05:01:12Z", "last-updated": "2026-03-10T05:31:12Z", "ack-status": "unacknowledged", "category": "ietf-incident:network", "sources": { "source": [ { "node-ref": "example:D1", "network-ref": "example:L2-topo", "resource": [ { "name": "7985e01a-5aad-11ea-b214-286ed488cf99" } ] } ] }, "probable-causes": { Hu, et al. Expires 24 March 2027 [Page 58] Internet-Draft Network Incident Management September 2026 "probable-cause": [ { "name": "Feeder fiber great loss change", "detail-information": "The connector of the optical fiber is\ contaminated, Or the optical fiber is\ bent too much.", "probable-cause": { "network-ref": "example:L2-topo", "node-ref": "example:D1", "resource": [ { "name": "7985e01a-5aad-11ea-b214-286ed488cf99", "cause-name": "ltp", "detail": "Frame=0, Slot=6, Subslot=65535, Port=7,\ ODF= ODF001,Level1Splitter= splitter0025" } ] } } ] }, "probable-events": { "probable-event": [ { "event-id": "8921834", "type": "alarm" } ] }, "events": { "event": [ { "event-id": "8921832", "type": "alarm" }, { "event-id": "8921833", "type": "alarm" }, { "event-id": "8921834", "type": "alarm" } ] } } ] } Hu, et al. Expires 24 March 2027 [Page 59] Internet-Draft Network Incident Management September 2026 } A.2. JSON Example on Incident Notifications In this example, we show an example of the Incident notification in JSON encoding for the incident base model. { "example-incident-module:incident-notification": { "incident-no": "INC-2026-98765", "name": "Link Failure Core Router", "type": "example-types:hardware-fault", "incident-qualifier": "interface-down", "service-instance": [ "srv-mpls-vpn-01", "srv-voip-05" ], "domain": "example-types:transport-network", "priority": "critical", "status": "active", "ack-status": "unacknowledged", "category": "example-types:network-infrastructure", "detail": "Interface GigabitEthernet0/0/1 reports a Link Down state due\ to loss of signal.", "resolve-advice": "Check physical fiber connections and optics transceiver\ at local node.", "sources": { "source": [ { "node-ref": "router-core-01", "network-ref": "backbone-east", "resource": [ { "name": "GigabitEthernet0/0/1" } ] } ] }, "probable-causes": { "probable-cause": [ { "node-ref": "router-core-01", "network-ref": "backbone-east", "resource": [ { "name": "GigabitEthernet0/0/1", "cause-name": "example-types:los-of-signal", Hu, et al. Expires 24 March 2027 [Page 60] Internet-Draft Network Incident Management September 2026 "detail": "Laser rx power below operational threshold." } ], "cause-name": "example-types:interface-hardware-failure", "detail": "SFP module may need replacement." } ] }, "probable-events": { "probable-event": [ { "type": "example-types:link-down-event", "event-id": "EV-10293" } ] }, "events": { "event": [ { "type": "example-types:alarm-event", "event-id": "AL-55443", "alarm": { "resource": "GigabitEthernet0/0/1", "alarm-type-id": "link-down", "alarm-type-qualifier": "port-failure" } } ] }, "time": "2026-09-12T08:47:00Z" } } A.3. Network Incident Correlated with Trouble Tickets In this document, the objective of the Incident Management is to identify Probable Root Causes and reduce duplicated tickets. Previously, a troubleshooting ticket was created upon receipt of a critical alert by the OSS system, e.g., due to excessive BGP flaps on a particular device. Such troubleshooting ticket will trigger Network Incident Management in the network controller. Therefore normally troubleshooting tickets and network incident are managed by the OSS and the network controller respectively. However Network troubleshooting is sometimes complicated and requires data gathering and analysis from many different tools from the controllers, therefore correlation between troubleshooting ticket and network incident becomes necessary. Hu, et al. Expires 24 March 2027 [Page 61] Internet-Draft Network Incident Management September 2026 +------------------------------------------------+ |OSS +---------------------------------------+ | | | Ticket System | | | +----------------+----------------------+ | | |1.Ticket | | | Creation | | +----------------V----------------------+ | | | Incident Handler | | | +------+-------+------------+---------^-+ | +-----------+-------+------------+---------+-----+ 2.Incident 3.Incident 4.|Incident |5.Incident Ack with Diagnosis |Resolve |Update Ticket-no with |with |Notification | ticket-no |Ticket-no|with Ticket-no +-----------+-------+------------+---------+-----+ |Controller | | | | | | +-------V-------V------------V---------+-+ | | | Incident Process | | | +----------------------------------------+ | +------------------------------------------------+ Figure 8: Correlation with troubleshooting tickets In order to manage the correlation between network incidents and trouble tickets in the YANG data model, three RPCs to manage the network incidents and one notification to report on network incident state changes defined in "ietf-incident" module can be further extended to include "ticket-no" attribute so that such correlation can be carried in the incident update notification and report the upper-layer OSS system. Such correlation can be used by the incident handler in the upper-layer OSS system for further fault demarcation, e.g., identify whether the fault is on the user side or on the network side. Hu, et al. Expires 24 March 2027 [Page 62] Internet-Draft Network Incident Management September 2026 rpcs: +---x incident-acknowledge | +---w input | +---w incident-no* incident-ref | +---w ticket-no? string +---x incident-diagnose | +---w input | | +---w incident-no* incident-ref | | +---w ticket-no? string | +--ro output | | +--ro task-id? string +---x incident-resolve | +---w input | +---w incident-no* incident-ref | +---w ticket-no? string notifications: +---n incident-notification | +--ro incident-no? incident-ref | +--ro ticket-no? string +-- ... A.4. Intent Based Networking with Incident Diagnosis Task List In this document, the incident-diagnosis RPC defined in "ietf- incident" module can be used to identify Probable Root Causes; and an incident update notification can be triggered to report the diagnosis status if successful. In some cases, workflows may span a long duration or involve multiple steps task. In such case, intent based networking concept can be used to support such multiple step task and provide more detailed network diagnosis information. Hu, et al. Expires 24 March 2027 [Page 63] Internet-Draft Network Incident Management September 2026 +------------------------------------------------+ | OSS | | +---------------------------------------+ | | | Incident Handler | | | +------+-----------^-----------+--------+ | +-----------+-----------+-------------+----------+ |Diagnosis |Diagnosis |NETCONF |Task |Task | |Creation |Notification | +-----------+-----------+-------------+----------+ |Controller | | | | | +-------V-----------------------V--------+ | | | Incident Process | | | +----------------------------------------+ | +------------------------------------------------+ Figure 9: Diagnosis Task Management To do so, the new "diagnosis task creation" RPC can be further defined to support "task-id" attribute in the output parameters and other auxiliary attributes in the input parameters. such RPC can be used to return task-id from the controller. The controller is responsible for task-id allocation and maintaining task-id list. +---x diagnose-task-creation | +---w input | | +---w incident-no? string | | +---w ticket-no? string | | +---w occur-time? yang:date-and-time | | +---w context? string | | +---w related-events | | | +---w probable-event* [] | | | +---w type? leafref | | | +---w event-id? leafref | | +---w related-objects | | +---w source* [node-ref] | | +---w node-ref leafref | | +---w network-ref? leafref | | +---w resource* [name] | | +---w name al:resource | +--ro output | +--ro task-id? string "ietf-incident" module can be further extended to include "incident- diagnosis-task" list with the following diagnosis information: * The current status (e.g., created, diagnosing, diagnosed, finished) of each diagnosis task. Hu, et al. Expires 24 March 2027 [Page 64] Internet-Draft Network Incident Management September 2026 * Task start time, end time, diagnosis result (succeeded, failed), failure description, etc. * Probable Root Causes, probable events, repair recommendations, etc. so that OSS system can use NETCONF operation to look up the diagnosis task detailed information based on such module extension. augment /inc:incidents/inc:incident: +--ro incident-diagnosis-tasks | +--ro incident-diagnosis-task* [task-id] | +--ro task-id? string | +--ro incident-no* incident-ref | +--ro ticket-no? string | +--ro start-time? yang:date-and-time | +--ro end-time? yang:date-and-time | +--ro task-state? enumeration | +--ro diagnosis-result? enumeration | +--ro diagnosis-result-description? string | +--ro probable-causes leafref //List ... | +--ro probable-events leafref //List ... | +-- ro repair-advices | +-- ro state enumeration // Incident states such as // Creation, Update, Clear ... In addition, the new Diagnosis Task Notification can be defined to support Diagnosis Task related attributes reporting. Hu, et al. Expires 24 March 2027 [Page 65] Internet-Draft Network Incident Management September 2026 +---n task-notification | +--ro task-id? string | +--ro incident-no? string | +--ro ticket-no? string | +--ro start-time? yang:date-and-time | +--ro end-time? yang:date-and-time | +--ro task-state? task-state | +--ro diagnosis-result? diagnosis-result | +--ro diagnosis-result-description? string | +--ro probable-causes | | +--ro probable-cause* [] | | +--ro node-ref? leafref | | +--ro network-ref? leafref | | +--ro resource* [name] | | | +--ro name al:resource | | | +--ro cause-name? identityref | | | +--ro detail? string | | +--ro cause-name? identityref | | +--ro detail? string | +--ro probable-events | | +--ro probable-event* [] | | +--ro type? leafref | | +--ro event-id? leafref | +--ro repair-advices? string | +--ro incident-status? incident-status-value So that the controller can send diagnosis task notification to the OSS system upon diagnosis task completes and outputs repair suggestion. A.5. Multi-Domain Fault Demarcation with Network Incident Management Take multi-domain fault demarcation as an example, when both base station incident in the RAN network and Network Link incident in the IP network are received and base station incident from user side results from network incident in other domains, the OSS system is unable to find network side problem simply based on base station incident. Therefore incident diagnosis RPC will be invoked with IP address of Base station and incident start time as input and sent to the network controller. The network controller can use network diagnosis related intent based interface to find the corresponding network side port according to the base station IP address, and then further associated with transmission path (current path, historical path) to the base station and current and historical network performance, network resources, and incident status data, to diagnose the Probable Root Cause of the network incident and provide repair suggestions. Hu, et al. Expires 24 March 2027 [Page 66] Internet-Draft Network Incident Management September 2026 +------------------------------------------------+ |OSS +------------------------------------------+| | | Incident Handler || | +----^------------------------^------+-----+| +---------+------------------------|------|------+ Incident | | | | | Update | Incident Incident Notification | Update Diagnosis | | Notification | | | | +---------------+ | | | | +-----------+ | | +-----|------+--+ | | Incident | | | | +---+------V+ | | | Process | | | | | Incident | | | +-----------+ | | | Process | | | RAN Controller| | | +-----------+ | +---------------+ | | IP Controller | | +---------------+ | RAN Autonomous Domain | IP Autonomous Domain | Diagnosis Key Parameters: { ticket-no, string incident-no, string occur-time, yang:date-and-time context? string related-events? leafref //List related-objects? leafref //List .... } Figure 10: Multi-Domain Fault Demarcation A.6. Service Complaint triggered Network Diagnosis Hu, et al. Expires 24 March 2027 [Page 67] Internet-Draft Network Incident Management September 2026 Customer Complaint | on Service | Degradation +-----------------V-----------------------+ |OSS +-----------------------------------+| | | Incident Handler || | +------------^------^---------------+| +-----------------+------+----------------+ Diagnosis Incident | |Incident Update Key Parameters: Diagnosis| | Notification { +-----|------+--+ incident-no, | +---V------|+ | ticket-no, | | Incident | | occur-time, | | Process | | context?, | | | | related-events?, | | | | related-objects?, | | | | ... | +-----------+ | | IP Controller | } +---------------+ IP Autonomous Domain Figure 11: Service Complaint triggered Network Diagnosis Similarly, in case of service degradation for a lease line service receiving from the customer, the OSS system can request network diagnosis at the network side conducted by the network controller. The network controller can use network diagnosis related intent based interface to find the corresponding network side port based on the dedicated line service, and then further associate the transmission path (current path, historical path) and current and historical network performance, network resources, and incident status data to diagnose the Probable Root Cause of the fault and provide repair suggestions. Appendix B. Changes between Revisions NOTE TO THE RFC-EDITOR: Please remove this appendix before publication v14 - v15 * Replace incident-id with incident-qualifier * Add a new definition for the incident process Hu, et al. Expires 24 March 2027 [Page 68] Internet-Draft Network Incident Management September 2026 * replace probable cause with probable root cause in the YANG model * Clean up probable cause in the normative text * Remove cause-name identity to align with example in A.1 * Change the type of root cause into string * Fix invalid yang instance in the appendix A.1 * Clean up unused references * Fix Incident priority issue raised by Adrian * Add JSON example on YANG notification for Base Model * Add Security Consideration for incident-acknowledgement * Add implementation status section * Add incident-not-found support * Other Editorial changes v10 - v11 * Remove log identity * Add other cases such metric, notification * Replace incident-class with incident-type * Replace factor with fault condition * Reference RFC9375 for metric event type * Replace probable cause with probable root cause v08 - v09 * Second alignment with RFC9940 * Fix document references to match Model references * Allow create incident without knowing the source * Make incident-no mandatory Hu, et al. Expires 24 March 2027 [Page 69] Internet-Draft Network Incident Management September 2026 * Add clarification text for min-element set to unknown * Update YANG model tree diagram to align with update of YANG data model * Create ietf-incident-tree diagram v07 - v08 * Add a new section to clarify Relationship with network anomaly architecture; * Clarify the relation with OAM Schdule YANG in section 4; * Abstract update; * Terminology alignment with RFC9940; * Other Editorial changes; v06 - v07 * Fix Yanglint issue in the YANG data model. * Align with RFC8407bis section 3.8.3.1 IANA template. * Align with YANG Module Security Considerations template. * Probable Root Cause Definition Polishing. * Tree diagram update for RPC error construct v05 - v06 * Break down A.3 into 3 sections covering 3 examples. v04 - v05 * Replace probable cause with probable root cause based on Adrian and Benoit's suggestion. * Address editorial comments raised by Aitken Paul. * YANG Model editorial changes based on Aitken Paul's comments. v03 - v04 Hu, et al. Expires 24 March 2027 [Page 70] Internet-Draft Network Incident Management September 2026 * Remove constraint of using machine learning for service impact assessment and replace machine learning with algorithmic techniques. * Replace root cause with probable cause based on IETF 122 NMOP Session Discussion. * Add two ITU-T references for probable cause definition in the terminologies section. * Add Lionel Tailhardat from Orange as new contributors based on his input. * Add two new examples in the Appendix to explore correlation between troubleshooting ticket and incident management and intent based network diagnoisis interaction. v02 - v03 * Cross-checking terminology across NMOP drafts based on Adrian's comments. * Align with the Terminology draft based on Thomas's comments. * Clarify the relation between the Network Incident, and Customer Incident. * Add service impact assessment term and its definition. * Clarify the relation between fault, problem, incident, service. * Other Editorial changes. v01 - v02 * Clarify the relation between fault, incident and problem. * Clarify the relation between fault management and incident management. * Add clarification text to make draft focus on network level incident management, not be tied with OSS or under the control of OSS. * Other Editorial changes. v00 - v01 Hu, et al. Expires 24 March 2027 [Page 71] Internet-Draft Network Incident Management September 2026 * Clarify the relationship between incident-no and incident-id. * Fix Tree Diagram to align with YANG module code change. * Add json example in the appendix. * Add failure handling process for RPC error. * Clarify the relationship between events and cause. * Clarify synchronous nature of these RPCs. * Clarify the relationship between inter-layer and inter-domain. * Refer to terminology draft for terminology alignment. * Fix pyang compilation issue and yang lint issue. * Fix Broken ref by using node-ref defined in RFC8345. * Update YANG data model based on issues raised in issue tracker of the github. * Shorten the list of authors to 5 based on chairs' comment and move additional authors to top 3 contributors. * Merge ietf-incident-type.yang into ietf-incident.yang * Fix enumeration on leaf type * Clarify the scope in the abstract and introduction and make the scope focus on YANG data model * Provide text around figure 5 to clarify how the incident server know the real effect on the relevant services. * Other editorial changes. v00 (draft-ietf-nmop-network-incident-yang) * Change draft name from draft-feng-opsawg-incident-management into draft-feng-nmop-netwrok-incident-yang * Change title into A YANG Data Model for Network Incident Management * open issues is tracked in https://github.com/billwuqin/network- incident/issues Hu, et al. Expires 24 March 2027 [Page 72] Internet-Draft Network Incident Management September 2026 Contributors Lionel Tailhardat Orange Email: lionel.tailhardat@orange.com Thomas Graf Swisscom Switzerland Email: thomas.graf@swisscom.com Zhenqiang Li CMCC Email: li_zhenqiang@hotmail.com Yanlei Zheng China Unicom Email: zhengyanlei@chinaunicom.cn Yunbin Xu CAICT Email: xuyunbin@caict.ac.cn Xing Zhao CAICT Email: zhaoxing@caict.ac.cn Chaode Yu Huawei Email: yuchaode@huawei.com Authors' Addresses Tong Hu CMCC Building A01, 1600 Yuhangtang Road, Wuchang Street, Yuhang District Hangzhou 311121 China Email: hutong@cmhi.chinamobile.com Hu, et al. Expires 24 March 2027 [Page 73] Internet-Draft Network Incident Management September 2026 Luis M. Contreras Telefonica Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China Email: bill.wu@huawei.com Nigel Davis Ciena Email: ndavis@ciena.com Chong Feng Email: fengchongllly@gmail.com Hu, et al. Expires 24 March 2027 [Page 74]