Original text:
<del> A Network YANG Model for Service Attachment Points </del>  draft-ietf-opsawg-sap-latest Abstract view of the provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, network slices).  The data model augments the 'ietf-network' data <del> model by adding the concept of service attachment points (SAPs).  The service attachment points are the points to which network services (such as L3VPN or L2VPN) can be attached.  The customer endpoint of an attachment circuits are not covered in the SAP network topology. </del>  1. <del> The service attachment point (SAP) is an important architectural </del>  concept in many implementations and deployments of services such as <del> VPNs, SDWAN, or managed VoIP services.  It has already been used to decide where to attach and, thus, deliver the service in the L3SM RFC8299 and the L2SM RFC8466. </del>  This document defines a YANG network model for representing, <del> managing, and controlling the service attachment points (SAPs).  The data model augments the 'ietf-network' module RFC8345 by adding the concept of service attachment points.  The service attachment points are abstraction of the points where network services such as L3VPNs or L2VPNs can be attached. </del>  <del> This document does not make any assumption about the service provided by the network to the users.  VPN services are used for illustration purposes.  This concept can also be used to decide network slice SAPs I-D.ietf-teas-ietf-network-slices. </del>  In the context of Software-Defined Networking (SDN) RFC7426, the defined YANG data model in this document can be used to exchange provision and resource management discussed in I-D.ietf-opsawg-l2nm. Through this data model, the service orchestration layer can learn the available endpoints (i.e., SAPs) of interconnection resource of <del> the underlying network. The service orchestration layer can determine which endpoint of interconnection to add to L2VPN or L3VPN service.  With the help of other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical control elements could determine the feasibility of an end-to-end IP connectivity or L2VPN connectivity and therefore derive the sequence of domains and the points of interconnection to use. </del>  This document explains the scope and purpose of a SAP network model <del> and its relation with the service models and describes how it can be used by a network operator.  The document also shows how the topology and service models fit together. </del>  The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) RFC8342. of RFC6241, RFC7950, and RFC8309.  The document uses terms from those documents. <del> Tree diagrams used in this document follow the notation defined in [RFC8340]. </del>  This document uses the term "network model" defined in Section 2.1 of RFC8969. An equipment owned and managed by the SP that can support multiple services (e.g., VPNs) for different customers.  A PE is directly <del> connected to one or more CEs via attachment circuits.  A PE is usually located at an SP point of presence (PoP). </del>  <del> Describes a service's end point characteristics and its reference </del>  to a Termination Point (TP) of the PE; used as service access point for service. Let us consider the example of a typical service provider network (fi2), with PE and P nodes. <del> The Service Orchestration layer does not need to know about the </del>  internals of the underlying network (e.g., P nodes). fi2a shows the abstract network view as seen by the Service Orchestrator.  However, this view is not enough to provide to the Service Orchestration layer Orchestration. A single SAP network topology can be used for one of multiple service <del> types (e.g., L3VPN, EVPN).  The network controller can then expose the service type(s) and associated interfaces via the SAPs. </del>  As shown in fi3a, the Service Orchestration layer will have also access to a set of Customer Service Model, e.g., an L3SM or L2SM data model in the customer-facing interface and a set of network models, <del> e.g., L3NM and Network topology data models in the resource-facing interface.  In this use case, it is assumed that the network </del>  controller is unaware of what happens beyond the PEs towards the CEs; it is only responsible for the management and control of the network between PEs. 4. The SAP network model builds on the network data model defined in the <del> 'ietf-network' module RFC8345, augmenting the nodes with service attachment points, which anchor the links and are contained in nodes. </del>  The 'service-attachment-point' attribute defined in the SAP network model is not a tunnel termination point (TTP) nor a link, but an abstraction of the termination point defined in RFC8345. Network slice I-D.ietf-teas-ietf-network-slices. <del> A service attachment point is identified by an interface name </del>  ("attachment-id"), an interface type ("type"), a status ("admin- <del> status", and "oper-status"), an encapsulation type ("encapsulation- type"), one or a list of service types ("sap-type") such as L3VPN or network slice, a description of the service(s) ("service- description"). </del>  5. The SAP network model can be seen as an inventory data associated <del> with service attachment points.  The model maintains an inventory of nodes contained in a network based on [RFC8345]. </del>  fig5 depicts the relationship of the SAP network model to other models.  The SAP network model augments from the Network model

Reviewer comments:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:

Revised text:
 <ins> A Network YANG Model for Service Attachment Points (SAPs) </ins> draft-ietf-opsawg-sap-latest Abstract view of the provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, network slices).  The data model augments the 'ietf-network' data  <ins> model by adding the concept of Service Attachment Points (SAPs).  The Service Attachment Points are the points to which network services (such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN)) can be attached. The customer endpoints of an attachment circuit (Customer Edges (CEs), topically) are not covered in the SAP network topology. </ins> 1.  <ins> The Service Attachment Point (SAP) is an important architectural </ins> concept in many implementations and deployments of services such as  <ins> Virtual Private Networks (VPNs), Software-Defined Wide Area Network (SDWAN), or managed Voice over IP (VoIP) services.  It is used to decide where to attach and, thus, deliver the service in the Layer 3 VPN Service Model (L3SM) RFC8299 and the Layer 2 VPN Service Model (L2SM) RFC8466.  It can also be used to retrieve where services, such as the Layer 3 VPN Network Model (L3NM) I-D.ietf-opsawg-l3sm-l3nm, and the Layer 2 VPN Network Model (L2NM) I-D.ietf-opsawg-l2nm, are delivered. </ins> This document defines a YANG network model for representing,  <ins> managing, and controlling the Service Attachment Points.  The data model augments the 'ietf-network' module RFC8345 by adding the concept of Service Attachment Points.  The Service Attachment Points are abstraction of the points where network services can be attached. </ins>  <ins> This document does not make any assumption about the service(s) provided by the network to the users.  VPN services (such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN)) are used for illustration purposes.  The SAP concept can be used to decide network slice SAPs I-D.ietf-teas-ietf-network-slices. </ins> In the context of Software-Defined Networking (SDN) RFC7426, the defined YANG data model in this document can be used to exchange provision and resource management discussed in I-D.ietf-opsawg-l2nm. Through this data model, the service orchestration layer can learn the available endpoints (i.e., SAPs) of interconnection resource of  <ins> the underlying network.  The service orchestration layer can determine which interconnection endpoints to add to an L2VPN or L3VPN service.  With the help of other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical control elements can also assess the feasibility of an end-to-end IP connectivity or L2VPN connectivity and, therefore, derive the sequence of domains and the points of interconnection to use. </ins> This document explains the scope and purpose of a SAP network model  <ins> and its relation with the service models. </ins> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) RFC8342. of RFC6241, RFC7950, and RFC8309.  The document uses terms from those documents.  <ins> The meanings of the symbols in tree diagrams are defined in RFC8340. </ins> This document uses the term "network model" defined in Section 2.1 of RFC8969. An equipment owned and managed by the SP that can support multiple services (e.g., VPNs) for different customers.  A PE is directly  <ins> connected to one or more CEs via attachment circuits. </ins>  <ins> Describes a service's endpoint characteristics and its reference </ins> to a Termination Point (TP) of the PE; used as service access point for service. Let us consider the example of a typical service provider network (fi2), with PE and P nodes.  <ins> The Service orchestration layer does not need to know about the </ins> internals of the underlying network (e.g., P nodes). fi2a shows the abstract network view as seen by the Service Orchestrator.  However, this view is not enough to provide to the Service Orchestration layer Orchestration. A single SAP network topology can be used for one of multiple service  <ins> types (e.g., L3VPN, Ethernet VPN (EVPN)).  The network controller can then expose the service type(s) and associated interfaces via the SAPs. </ins> As shown in fi3a, the Service Orchestration layer will have also access to a set of Customer Service Model, e.g., an L3SM or L2SM data model in the customer-facing interface and a set of network models,  <ins> e.g., the L3NM and Network topology data models in the resource- facing interface.  In this use case, it is assumed that the network </ins> controller is unaware of what happens beyond the PEs towards the CEs; it is only responsible for the management and control of the network between PEs. 4. The SAP network model builds on the network data model defined in the  <ins> 'ietf-network' module RFC8345, augmenting the nodes with Service Attachment Points, which anchor the links and are contained in nodes. </ins> The 'service-attachment-point' attribute defined in the SAP network model is not a tunnel termination point (TTP) nor a link, but an abstraction of the termination point defined in RFC8345. Network slice I-D.ietf-teas-ietf-network-slices.  <ins> A Service Attachment Point is identified by an interface name </ins> ("attachment-id"), an interface type ("type"), a status ("admin-  <ins> status" and "oper-status"), an encapsulation type ("encapsulation- type"), one or a list of service types ("sap-type"), a description of the service(s) ("service-description"). "attachment-id" may include a reference to a physical or a logical interface.  For example, an "attachment-id" may be the interface identifier of a VPN network access used in Section 7.6 of I-D.ietf- opsawg-l3sm-l3nm. </ins> 5. The SAP network model can be seen as an inventory data associated  <ins> with SAPs.  The model maintains an inventory of nodes contained in a network based on RFC8345. </ins> fig5 depicts the relationship of the SAP network model to other models.  The SAP network model augments from the Network model