Paragraph 2, bullet 2:  "Any contention in placement of the work will be resolved by the chairs and responsible Area Directors."  Has there been issues in the past? I see that there is a version of this in the previous charter.  It seems like an unusual statement, since that is the way it usually works?  Work that isn't in charter is resolved by either chairs or AD.  I guess if it happens often, then spelling it out in the charter makes it crystal clear.
[note:  I see Med calls this 'business as usual'.  I do agree, unless there have been issues in the past.]

Thank you for updating the charter.

Please find some comments below. Comments marked as (*) are important to avoid overlapping with other groups. The last point is about a gentle request for consideration :-)
	
# VPN as the only supported service 

CURRENT:
  The BGP Enabled Services (BESS) working group is responsible for defining,
  specifying, and extending network services over a packet switched
  network (PSN) where the VPN signaling uses BGP. In particular, the working
  group will work on the following services:

This text implicitly assumes that VPN is the only supported service as implied by “VPN signaling uses BGP” part. 

I think I would prefer having an explicit statement here.

# Business as usual 

There are several statements that I think can be simply removed as this is about business as usual:

(1)
  Any contention in placement of the work will be
  resolved by the chairs and responsible Area Directors.

(2)
  these may be added to the working group charter subject to
  rechartering, and they will not be adopted in the working group until such
  rechartering.

# On data models (*)

CURRENT: e) Definition of YANG models for provisioning and operations

## VPN-related service and network data models (L2SM, L3SM, L2NM, L3SM, draft-ietf-opsawg-ac-lxsm-lxnm-glue, ietf-network-vpn-pm, etc.) are products of other WGs, not BESS. The plan for their maintenance is to hand those over to ONIONS.

I suggest that we indicate that the work in BESS will be specifically on device models.

## Many expired I-Ds on YANG

The WG adopted several drafts in the past (e.g., draft-ietf-bess-l3vpn-yang, draft-ietf-bess-mvpn-yang, draft-ietf-bess-l2vpn-yang, draft-ietf-bess-evpn-yang) but all these were expired. Does the WG plan to revive some of this work? Any plan how to make this part better :-)?

## Be consistent with 8407bis

OLD: e) Definition of YANG models …

NEW: e) Definition of YANG data models …

# nit: ”P” of BGP stands for “protocol”

OLD: the core BGP protocol, 

NEW: the core BGP specification, 

# Add MBONED to this list for multicast-related matters (*)

CURRENT:
  The WG will also liaise with other relevant WGs, including but not limited
  to MPLS, SPRING, 6man, NVO3, and BFD, as appropriate. 

Btw, please use a consistent form to list WGs: s/6man/6MAN.

# Lastly, an OPS matter

The WG produced many documents on EVPN that I find very useful. However, it is not always that easy to digest them. I wonder whether the WG considered developing some deployment recommendations or simply an architecture overview with the various EVPN specifications and how they fit together?

Cheers,
Med