Change:
We created a placeholder for items that seem to overlap. reconsider if access-diversity makes sense in the l2nm.
Certainly ethernet-segment-identifier is needed somewhere. But it could go directly under vpn-network-access. I don't think we need group-id and constraints in the l2nm, do you know a use-case for it?
Update Ethernet segment identifier to cover explicit generated and auto-asign according to the rules of section 5 of RFC 7432
Include DF election method (see draft-ietf-bess-evpn-pref-df-06)
This part of the module makes sense in the service module as it may impact how to attach a site. at the network level, these constraints are supposed to be taken into account (selection of PE, interfaces, etc.). I suggest we remove this from the L2NM.
This part is redundant with "esi-redundancy-mode" for the evpn case.
I lost the context about these two. What is the purpose of these two and how this is used to infer the underlying config?
The description refers to primary and secondary "L2VPN". That's vague.
The use case for the precedence is the following: ! The group-id combined with the precedence serves to model the primary and backup on the same vpn-node. So we agree to improve the description of the Leaf and Identities to reflect the use case usage and make it more clear. The figure for the usage must be inlcuded in the draft NAME

Discussion:
between the administrative status vs. the operational status can be used as a trigger to detect anomalies. <del> Represents the point to which sites are connected. Note that, unlike in L2SM, the L2NM does not need to model the customer site, only the points where the traffic from the site are received (i.e., the PE side of PE-CE connections).  Hence, the VPN network access contains the connectivity information between the provider's network and the customer premises.  The VPN profiles ('vpn-profiles') have a set of routing policies that can be applied during the service creation. See sna for more details. 6.3.2.1. This sub-tree defines the L2VPN service type, according to the several signalling options to exchange membership information between PEs of an L2VPN.  The following signaling options are supported: Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. Refers to LDP-signaled pseudowires RFC6074. Refers to L2TP-signaled pseudowires RFC6074. 6.3.2.2. A 'vpn-network-access' represents an entry point to a VPN service . In other words, this container encloses the parameters that describe the access information for the traffic that belongs to a particular L2VPN.  As such, every 'vpn-network-access' MUST belong to one and only one 'vpn-node'. A 'vpn-network-access' includes information such as the connection on which the access is defined , the specific layer 2 service requirements, etc. The VPN network access is comprised of: Identifier of the VPN network access. Text describing the VPN network access. Administrative and operational status of the service. Carries information about the service OAM. 6.3.2.2.1. The connection container is used to configure the relevant properties of the interface that is attached to the VPN, for example the encapsulation type, the physical interface or creating a lag. 6.3.2.2.2. This container is used to indicate the details of the ethernet service such as bandwidth or qos. </del> 7. 8.