Original text:
Abstract <del> This document defines a L2VPN Network YANG Model (L2NM) that can be </del>  used to manage the provisioning of Layer 2 Virtual Private Network (VPN) services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a Refers to the YANG module that describes an L2VPN service with a network-centric view.  It contains information of the service <del> providers network and might include allocated resources.  Network </del>  controllers can use it to manage the Layer 2 VPN service configuration in the service providers network.  The YANG module can be consumed by a service orchestrator to request a VPN service controller. Denotes a functional entity responsible for the management of the <del> service providers network. </del>  Is an abstraction that represents a set of policies applied on a PE and that belong to a single VPN service.  A VPN service Is an abstraction that represents the network interfaces that are associated to a given VPN node.  Traffic coming from the VPN network access belongs to the VPN.  The attachment circuits <del> (bearers) between Customer Edges (CEs) and PEs are terminated in the VPN network access. </del>  Is a service providers that offers L2VPN-related services. related L2VPN types.  More details are provided in es. The 'vpn-services' container maintains the set of L2VPN services <del> managed in the service providers network.  The module allows to </del>  create a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (l2_vpn_service). For the particular case of EVPN, the L2NM supports RT auto-derivation based on the Ethernet Tag ID specified in Section 7.10.1 of RFC7432. A VPN service provider can enable/disable this functionality by means <del> of 'auto-rt-enable'.  The asigned RT can be retrieved using 'auto- </del>  route-target'. For all BGP-based L2VPN flavors, other data nodes such as RD and RT

Reviewer comments:
Abstract s/This document defines a L2VPN/This document defines an L2VPN/ Section 2 s/contains information of the service providers/contains information of the service provider’s/ s/management of the service providers network/management of the service provider’s network/ s/Is a service providers that offers/Is a service provider that offers/ …between Customer Edges (CEs) and PEs… You expand CE but never PE (until the acronym section). I thought it might be good for maximum clarity to outright define CE and PE in your terminology section. Section 6.1 s/managed in the service providers network/managed in the service provider’s network/ Section 6.5 s/Global parameters profile are defined/Global parameters profiles are defined/ You misspelled ce-vlan-cos-preservation here and in the YANG module below. Since this is a leaf, it really should have correct spelling. Section 6.6.1 s/The asigned RT can be/The assigned RT can be/ Section 6.6.2 s/Address Resolution Protocol (ARP) and Nighbour Discovery (ND)/ Address Resolution Protocol (ARP) and Neighbor Discovery (ND)/ On this, should you have a reference for ARP and ND? Section 6.7.1 You mention LAG and LACP here and below in the module. But I never see a reference or expansion for either. I think both the text and the module would benefit from both. Section 6.7.4 s/they take precendence over the one inlcudes/they take precedence over the one includes/ In your two IANA modules you have identities for PPP and VPLS and a couple of others where the description is the identity name itself. This is where I wonder if slightly better descriptions would add more clarity. At least expanding the acronym would be useful IMHO. YANG module s/The RObust Header Compression (ROHC) Framework/The Robust Header Compression (ROHC) Framework/ YANG module Concerning identity “precedence-type”: First, you misspelled “backup”. You say active and backup here, but you use primary and backup below. I typically see primary with secondary and active with backup. Either way, I think you need to be consistent. Also, since the base identity mentions the two defined sub-identities, should this really be an enumeration? Or should you just simplify this description so as not to mention any possible sub-identities? YANG module s/Indicates whether BGP auto-discovey/Indicates whether BGP auto-discovery/ s/Sets the indentifier of the VPN node/Sets the identifier of the VPN node/ s/contex of a VPN/context of a VPN/ s/Controles/Controls/g s/symetric/symmetric/ s/automatically assigned either withor/automatically assigned either with or/ s/maixmum/maximum/g YANG module Concerning leaf group-color: Okay, dumb question. What does a string for color provide here? While I’ve seen the concept of color used a lot in VPN examples, a free-form string that should be a color seems over-done here. The group-id is another open string. Why couldn’t that also be a color? I’d love to see some canonical reference that explains color use (if there is one). YANG module Concerning the number of different MTU-related leafs: The PW interface MTU is limited to 16-bits. Does it make sense to have a 32-bit service MTU here, then? Other than the pw-mtu, the other MTU leafs are all 32-bit, and I wonder if they shouldn’t all be 16. YANG module Concerning leaf color-type: Here is another use of color, but this time at least tied to an identity. Why couldn’t the other use also use this identity?
Thanks for taking care of the comments. Please see below some edits

Revised text:
Abstract  <ins> This document defines an L2VPN Network YANG Model (L2NM) that can be </ins> used to manage the provisioning of Layer 2 Virtual Private Network (VPN) services within a network (e.g., service provider network). The L2NM complements the Layer 2 Service Model (L2SM) by providing a Refers to the YANG module that describes an L2VPN service with a network-centric view.  It contains information of the service  <ins> provider's network and might include allocated resources.  Network </ins> controllers can use it to manage the Layer 2 VPN service configuration in the service providers network.  The YANG module can be consumed by a service orchestrator to request a VPN service controller. Denotes a functional entity responsible for the management of the  <ins> service provider's network. </ins> Is an abstraction that represents a set of policies applied on a PE and that belong to a single VPN service.  A VPN service Is an abstraction that represents the network interfaces that are associated to a given VPN node.  Traffic coming from the VPN network access belongs to the VPN.  The attachment circuits  <ins> (bearers) between Customer Edges (CEs) and Provider Edges (PEs) are terminated in the VPN network access. </ins> Is a service providers that offers L2VPN-related services. related L2VPN types.  More details are provided in es. The 'vpn-services' container maintains the set of L2VPN services  <ins> managed in the service provider's network.  The module allows to </ins> create a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (l2_vpn_service). For the particular case of EVPN, the L2NM supports RT auto-derivation based on the Ethernet Tag ID specified in Section 7.10.1 of RFC7432. A VPN service provider can enable/disable this functionality by means  <ins> of 'auto-rt-enable'.  The assigned RT can be retrieved using 'auto- </ins> route-target'. For all BGP-based L2VPN flavors, other data nodes such as RD and RT