Draft: draft-ietf-opsawg-l2nm

Commentary: 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 could n’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 should n’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 could n’t the other use also use this identity ? 
 Thanks for taking care of the comments . Please see below some edits
Paragraph (version A):
This document defines a L2VPN Network YANG Model (L2NM) that can be
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
network-centric view of the service that is internal to a service
providers.  As such, the L2NM is meant to be used by a network
controller to derive the configuration information that will be sent
to relevant network devices.
Paragraph (version B):
This document defines an L2VPN Network YANG Model (L2NM) that can be
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
network-centric view of the service that is internal to a service
providers.  As such, the L2NM is meant to be used by a network
controller to derive the configuration information that will be sent
to relevant network devices.
Paragraph (version A):
Refers to the YANG module that describes an L2VPN service with a
network-centric view.  It contains information of the service
providers network and might include allocated resources.  Network
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
to a network controller or to expose the list of active L2VPN
services.
Paragraph (version B):
Refers to the YANG module that describes an L2VPN service with a
network-centric view.  It contains information of the service
provider's network and might include allocated resources.  Network
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
to a network controller or to expose the list of active L2VPN
services.
Paragraph (version A):
Denotes a functional entity responsible for the management of the
service providers network.
Paragraph (version B):
Denotes a functional entity responsible for the management of the
service provider's network.
Paragraph (version A):
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
(bearers) between Customer Edges (CEs) and PEs are terminated in
the VPN network access.
Paragraph (version B):
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
(bearers) between Customer Edges (CEs) and Provider Edges (PEs)
are terminated in the VPN network access.
Paragraph (version A):
The 'vpn-services' container maintains the set of L2VPN services
managed in the service providers network.  The module allows to
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).
Paragraph (version B):
The 'vpn-services' container maintains the set of L2VPN services
managed in the service provider's network.  The module allows to
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).
Paragraph (version A):
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
of 'auto-rt-enable'.  The asigned RT can be retrieved using 'auto-
route-target'.
Paragraph (version B):
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
of 'auto-rt-enable'.  The assigned RT can be retrieved using 'auto-
route-target'.