Original text:
System (OSS) are increased dramatically (in many cases multiple orders of magnitude) with the growth of service types and complexity and greatly overwhelm OSS platforms; with existing known dependency <del> relation between fault, alarm and events at each layer (e.g.,packet layer or optical layer), , it is possible to compress a series of alarms into fewer incidents and there are many solutions in the market today that essentially do this to some degree.  However traditional solutions such as data compression are time-consuming and labor-intensive, usually rely on maintenance engineers' experience for data analysis, which result in low processing efficiency, inaccurate root cause identification and duplicated tickets.  In addition, it is also difficult to assess the impact of alarms, performance metrics and other anomaly data on network services without known relation across layer of the network topology data or the relation with other network topology data. </del>  To address these challenges, a network wide incident-centric solution <del> is proposed to establish dependency relation with both network service and network topology at different layers , which not only can be used at specific layer in specific domain but also can be used to span across layer for multi-layer network troubleshooting.  A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service TMF724A.  Different data sources including alarms, metrics and other anomaly information can be aggregated into few amount of incidents irrespective layer by correlation analysis and the service impact analysis.  For example, the protocols related to the interface fail to work properly due to Service Level Objective (SLO) violation, large amount of alarms may be reported to upper layer management system and aggregated into one or a few incidents when some network services may be affected by this incident (e.g.  L3VPN services related with the interface will become unavailable I-D.ietf-ippm-pam ).  An 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 are monitored for each sub- service, symptoms will occur if services/sub-services are unhealthy (after analyzing metrics), these symptoms may raise one incident when it causes degradation of the network services. </del>  In addition, Artificial Intelligence (AI) and Machine Learning (ML) <del> play a important role in the processing of large amounts of data with </del>  complex data correlations.  For example, Neural Network Algorithm or Hierarchy Aggregation Algorithm can be used to replace manual alarm data correlation.  Through online and offline learning, these

Reviewer comments:
We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.

Revised text:
System (OSS) are increased dramatically (in many cases multiple orders of magnitude) with the growth of service types and complexity and greatly overwhelm OSS platforms; with existing known dependency  <ins> relation between fault, alarm and events at each layer (e.g., packet layer or optical layer), it is possible to compress series of alarms into fewer incidents and there are many solutions in the market today 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 result in low processing efficiency, inaccurate root cause identification 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 network topology data or the relation with other network topology data. </ins> To address these challenges, a network wide incident-centric solution  <ins> is specified to establish the dependency relation with both network service and network topology at different layers, which not only can be used at a specific layer in a domain but also can be used to span across layers for multi-layer network troubleshooting. A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service TMF724A.  Different data sources including alarms, metrics, and other anomaly information can be aggregated into few amount of incidents irrespective layer by correlation analysis and the service impact analysis.  For example, if the protocols related to the interface fail to work properly due to Service Level Objective (SLO) violation, large amount of alarms may be reported to upper layer management system and aggregated into one or a few incidents when some network services may be affected by this incident (e.g., L3VPN services bound to this interface will become unavailable I- D.ietf-ippm-pam).  An 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 are monitored for each sub- service, symptoms will occur if services/sub-services are unhealthy (after analyzing metrics), these symptoms may raise one incident when it causes degradation of the network services. </ins> In addition, Artificial Intelligence (AI) and Machine Learning (ML)  <ins> are key technologies in the processing of large amounts of data with </ins> complex data correlations.  For example, Neural Network Algorithm or Hierarchy Aggregation Algorithm can be used to replace manual alarm data correlation.  Through online and offline learning, these