The IESG has concluded that there is no conflict between this document and IETF work. Comments for the ISE and authors from Stewart Bryant, who was kind enough to review the draft: This is a useful and well written document and could be published as is. However I do have some comments that you may wish to consider. In terms of connectivity you have characterized an IP unicast service, but in the general case there is multicast and there are a variety of LAN and pseudowire connectivity services that require a connectivity provisioning profile. There is considerable overlap between the IP and non-IP profiles, so you may wish to extend the work here to cover that case, or you could reasonably leave it for the future. If you omit non-IP services you might wish to amend the title accordingly. The various multipoint service needs a specialist review and I suspect will increase the complexity of the profile. Again you might wish to reflect a limited scope in the title and introductory material. This is fine as an independent stream document, but I wonder if it (or a development of this text) needs to be considered for publication in one of the OPS WGs or as input to I2RS. In terms of the various performance parameters delay, loss, availability it occurs to me that you need to be specifying a mask rather than point parameters. Now the state of the art in technical metrics may not be sufficiently developed buy I would be surprised if contracts were no written in those terms. === Minor typo: The CPP reference architectures are depicted in Figure 3Figure 4Figure 5. === These nodes should be unambiguously identified (e.g., using a unique Service_identifier). For each Customer Node, a border link or a node that belongs to the domain that connects the Customer Nodes should be identified. Is the above sufficient? I can imagine that you will need to consider other parameters such as VLANs, MAC addresses etc. === 3.4. Availability Guarantees o Enable IP Fast Reroute features (e.g., [RFC5286]). It occurs to me that there are no well developed metrics for FRR in the IETF an perhaps there need to be for these types a specification. === In view of recent global events, at some stage this work will need to be extended to consider privacy requirements and geographic routing restrictions. === 3.9. Flow Identification This is a section that could certainly do with some privacy considerations. === 3.10. Routing & Forwarding I would expect that the profile needed to contain some indication of how reachability/topology information was exchanged between the provider network and the client network. In a pure OTT network this is not needed, but where the provider network is providing an IP service BGP is a consideration. === 3.13. Notifications Does NETCONF/YANG need to be called up? === 6. Security Considerations You probably need to consider privacy in this section. === Two typos in the following "CPP documents should be protected againts illegitame modifications" ===============