jiebi/TextFlow huggingface dataset:
Original text:
that can differ for different types of services and for different providers/solutions. <del> The top layer represents the application/flow view of </del>  connectivity. <del> Basis for the Operator Network and Services Models that provides topological information of the network.  It provides the core multi-layer topology model/data and how to connect them to the other models/data. </del>  The set of principles, guidelines, and conventions to model the Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other <del> entities o. </del>  Defines the core topological entities, their role in the network, <del> core properties and relationships both inside each layer and between the layers. </del>  It is the basic topological model with the links to other models and connects them all: configuration, maintenance, assurance

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
that can differ for different types of services and for different providers/solutions.  <ins> The top layer represents the application/flow view of service </ins> connectivity.  <ins> The document defines the following terms: Digital Map is a data model that provides a view of the operator's networks and services, including how it is connected to other models/data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate amongs layers and correlate between them.  This model is applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). </ins> The set of principles, guidelines, and conventions to model the Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other  <ins> entities. </ins> Defines the core topological entities, their role in the network,  <ins> core topological properties and relationships both inside each layer and between the layers. </ins> It is the basic topological model with the links to other models and connects them all: configuration, maintenance, assurance
Original text:
nodes, links and termination points inside a network, relationships between instances belonging to different networks, links to functional data for the instances, including <del> configuration, health, symptoms.  :The data can be historical, real-time, or future data for 'what-if' scenarios. </del>  3.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
nodes, links and termination points inside a network, relationships between instances belonging to different networks, links to functional data for the instances, including  <ins> configuration, health, symptoms. The data can be historical, real-time, or future data for 'what- if' scenarios. </ins> 3.
Original text:
operations use cases, but it is also a requirement for the Digital Twin.  4. 4.1.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
operations use cases, but it is also a requirement for the Digital Twin. <ins> The following sections shows some example use case descriptions to initiate the discussion what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases, from the perspective of what is the value of the digital map for each use case and how the Digital Map API can be used.  This will also clarify if only read and if/when write interface is needed per use case. 3.1. The application will be able to retrieve physical topology from the controller via Digital Map API and from the response it will be able to retrieve physical inventory of individual devices and cables. The application may request either one or multiple layers of topology via the Digital Map API and and from the response it will be able to retrieve both physical and logical inventory. 3.2. 3.3. The application will be able to retrieve all services from the Digital Map API for selected network type.  The application will be able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it will be able to determine what logical resources are used by the service.  The supporting relations to the lowest layer will help application to determine what physical resources are used by the service. 3.4. The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example, the application will be able to select the resouce and by navigation the supporting relationship bottom-up come to the service and its nodes, tps and links. 3.5. The application will be able to retrieve topology layer and any network/node/tp/link instances from the controller via Digital Map API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. 3.6. The application will be able to retieve the topology at any layer from the controller via Digital Map API and from the response it will be able to navigate any retrieve any KPIs for selected topology entity. 3.7. 3.8. 3.9. 3.10. 3.11. </ins> 4. 4.1.
Original text:
that some of them are supported by default by RFC8345): Basic model with network, node, link, and interface entity types. This means that users of the Digital Map model must be able to understand topology model at any layer via these core concepts only, without having to go to the details of the specific

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
that some of them are supported by default by RFC8345): Basic model with network, node, link, and interface entity types. This means that users of the Digital Map model must be able to understand topology model at any layer via these core concepts only, without having to go to the details of the specific
Original text:
capability to retrieve the links to external data/models. Digital Map models and APIs must be common over different network <del> domains (campus, core, data center, etc.).  This means that clients of the Digital Map API must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains. </del>  Digital Map must provide semantics for layered network topologies and for linking external models/data.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
capability to retrieve the links to external data/models. Digital Map models and APIs must be common over different network  <ins> domains (campus, core, data center, etc.). This means that clients of the Digital Map API must be able to understand the topology model of layers of any domain without having to understand the details of any technologies and domains. </ins> Digital Map must provide semantics for layered network topologies and for linking external models/data.
Original text:
4.2. <del> The following are design requirements for modelling the Digital Map: </del>  Digital Map should contain only topological information.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
4.2.  <ins> The following are design requirements for modelling the Digital Map. Theey are derived from the core requerements collected from the operators and although there is some duplication, these are focused on summarizing the requirements for the design of the model and API: </ins> Digital Map should contain only topological information.
Original text:
identify topological entities at different layers, identify their roles, and topological relationships between them. <del> Digital Map should contain only topological relationships inside each layer or between the layers (underlay/overlay). </del>  Provide capability for conditional retrieval of parts of Digital Map. Must support geo-spatial, temporal, and historical data.  The <del> temporal and historical can be supported external to the Digital Map. </del>  4.3. <del> The following are the architectural requirements for the Digital Map: </del>  Scale, performance, ease of integration.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7

Revised text:
identify topological entities at different layers, identify their roles, and topological relationships between them.  <ins> Digital Map should contain all topological relationships inside each layer or between the layers (underlay/overlay) Digital Map should contain links to other models/data to enable generic navigation to other YANG models in generic way. </ins> Provide capability for conditional retrieval of parts of Digital Map. Must support geo-spatial, temporal, and historical data.  The  <ins> temporal and historical can also be supported external to the Digital Map. </ins> 4.3.  <ins> The following are the architectural requirements for the controller that provides Digital Map API: </ins> Scale, performance, ease of integration.
Original text:
The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the <del> operator troubleshooting or optimizating the routing, while the </del>  optical layer may be of interest to the user managing the optical network.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Revised text:
The topology layer can also represent what needs to be managed by a specific user, for example IGP layer can be of interest to the  <ins> operator troubleshooting or optimizing the routing, while the </ins> optical layer may be of interest to the user managing the optical network.
Original text:
operations use cases, but it is also a requirement for the Digital Twin. <del> The following sections shows some example use case descriptions to initiate the discussion what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases, from the perspective of what is the value of the digital map for each use case and how the Digital Map API can be used.  This will also clarify if only read and if/when write interface is needed per use case. </del>  3.1.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Revised text:
operations use cases, but it is also a requirement for the Digital Twin.  <ins> The following sections includes some initial use case descriptions to initiate the discussion about what type of info is needed to describe the use cases in the context of Digital Map.  The next version of the draft will include more info on these use cases and more input from the operaotors, from the perspective of what the value of the digital map for each use case is and how the Digital Map API can be used. This will also clarify if only read and if/when write interface is needed per use case. </ins> 3.1.
Original text:
3.3. The application will be able to retrieve all services from the <del> Digital Map API for selected network type.  The application will be </del>  able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Revised text:
3.3. The application will be able to retrieve all services from the  <ins> Digital Map API for selected network types.  The application will be </ins> able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it
Original text:
The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example, <del> the application will be able to select the resouce and by navigation </del>  the supporting relationship bottom-up come to the service and its nodes, tps and links.

Reviewer comments:
Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits

Revised text:
The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example,  <ins> the application will be able to select the resouce and by navigating </ins> the supporting relationship bottom-up come to the service and its nodes, tps and links.
Original text:
The document defines the following terms: <del> Digital Map is a data model that provides a view of the operator's </del>  networks and services, including how it is connected to other models/data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate <del> amongs layers and correlate between them.  This model is </del>  applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). The set of principles, guidelines, and conventions to model the <del> Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other entities. </del>  Defines the core topological entities, their role in the network, core topological properties and relationships both inside each

Reviewer comments:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Revised text:
The document defines the following terms:  <ins> SIMAP is a data model that provides a view of the operator's </ins> networks and services, including how it is connected to other models/data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate  <ins> amongs layers and correlate between them.  This includes layers from physical topology to service topology.  This model is </ins> applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). The set of principles, guidelines, and conventions to model the  <ins> Service & Infrastructure Maps (SIMAP) using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other entities. </ins> Defines the core topological entities, their role in the network, core topological properties and relationships both inside each
Original text:
3. <del> The following are sample use cases that require Digital Map: </del>  Generic inventory queries

Reviewer comments:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Revised text:
3.  <ins> The following are sample use cases that require SIMAP: </ins> Generic inventory queries
Original text:
Intent/service assurance <del> Service E2E and per-link KPIs on the Digital Map (connectivity status, high-availability, delay, jitter, and loss) </del>  Capacity planning

Reviewer comments:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Revised text:
Intent/service assurance  <ins> Service E2E and per-link KPIs on SIMAP (connectivity status, high- availability, delay, jitter, and loss) </ins> Capacity planning
Original text:
3.5. The application will be able to retrieve topology layer and any <del> network/node/tp/link instances from the controller via Digital Map API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. </del>  3.6. The application will be able to retieve the topology at any layer <del> from the controller via Digital Map API and from the response it will </del>  be able to navigate any retrieve any KPIs for selected topology entity.

Reviewer comments:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Revised text:
3.5. The application will be able to retrieve topology layer and any  <ins> network/node/tp/link instances from the controller via the SIMAP API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. </ins> 3.6. The application will be able to retieve the topology at any layer  <ins> from the controller via the SIMAP API and from the response it will </ins> be able to navigate any retrieve any KPIs for selected topology entity.
Original text:
5. <del> As this document covers the Digital Map concepts, requirements, and use cases, there is no specific security considerations.  However, the RFC 8345 Security Considerations aspects will be useful when </del>  designing the solution. 6.

Reviewer comments:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Revised text:
5.  <ins> As this document covers the SIMAP concepts, requirements, and use cases, there is no specific security considerations.  However, the RFC 8345 Security Considerations aspects will be useful when </ins> designing the solution. 6.
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> 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. </del> The following terms are defined in RFC8632 and are not redefined here:

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:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  The following terms are defined in RFC8632 and are not redefined here:
Original text:
The following terms are defined in this document: <del> Network Incident: An unexpected interruption of a network service, degradation of network service quality, or sub-health of a network service TMF724A. Problem: The cause of one or more incidents.  The cause is not usually known when a problem record is created, and the problem management process is responsible for further investigation TMF724A. Incident management: Lifecycle management of incidents including incident identification, reporting, acknowledge, diagnosis, and resolution. Incident management system: An entity which implements incident management.  It include incident management server and incident management client. Incident management server: An entity which provides some functions of incident management.  For example, it can detect an incident, perform incident diagnosis, resolution and prediction,etc. Incident management client: An entity which can manage incidents. For example, it can receive incident notifications, query the information of incidents, instruct the incident management server to diagnose, resolve, etc. </del> 3. 3.1. <del> Traditionally, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers.  These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </del>  Some operators preconfigure whitelist and adopt some coarse granularity data correlation rules for the alarm management.  It

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:
The following terms are defined in this document:  3. 3.1.  <ins> Usually, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers. These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </ins> Some operators preconfigure whitelist and adopt some coarse granularity data correlation rules for the alarm management.  It