This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document describes basing VPNs on Network Resource Partitions (NRPs) from the IETF Network Slices Framework in RFC 9543 in order to support the needs of applications with specific traffic performance requirements. Use of existing mechanisms such as DetNet and Segment Routing is described as providing means to deliver enhanced VPNs - these techniques have transport considerations that are appropriate to cover in the documents that specify those mechanisms, not in this document. As a result, this document is basically OK from a transport perspective. I noticed a few additional minor issues and nits. -- Minor Issues [A] RFC 9543's notion of Service Demarcation Point is mentioned briefly in the Introduction and not elsewhere in the document. This document's introduction of VPNs to the RFC 9543 IETF Network Slices Framework raises questions about which network is the context for the SDP's "unique identifier (e.g., an IP address or Media Access Control (MAC) address)" (RFC 9543 section 3.2). I believe an SDP identifier is always an underly network identifier (as having it be an overlay network identifier creates a circular dependency for VPN deployment), and a statement to that effect would be appropriate to add to section 4.1. Something also ought to be said about the relationship between SDPs and VPN end points. I suspect that an SDP may or may not co-located with be a VPN endpoint and this may depend on the location of the SDP in the network (e.g., may vary among the four possibilities shown in Figure 1 in Section 5.2 of RFC 9543). It would be good to point that out, and also in section 4.1 of this document, explain where in Figure 1 (especially at what layer), SDPs are resident and/or visible. Finally, the use of "end points" fourth paragraph in Section 5.5 on management of VPN endpoints appears to implicitly assume that the managed VPN endpoints are located at SDPs, which may be a limiting assumption. [B] 3.2. Interaction between Enhanced VPN Services "There is a fine distinction between how a customer requests limits on interaction between enhanced VPN services, and how that is delivered by the service provider." I think this concern is broader - it encompasses interactions between an enhanced VPN service and all other services and traffic on a network, not just between/among enhanced VPN services. The needed change here also also affects the title and first paragraph of section 3.2.3 [C] 5.1. Forwarding Resource Partitioning "Several candidate layer-2 packet-based or frame-based forwarding plane mechanisms which can provide the required traffic isolation and performance guarantees are described in the following sections." Some of those candidates (e.g., DetNet, SR) are layer-3 mechanisms or mechanisms that are able to be used at layer-3. Rephrase sentence appropriately. [D] 9. Manageability Considerations This section should be connected to (e.g., reference) Section 5.5 on Management Plane, as much of the Section 5.5 material is Manageability Considerations material wit a strong focus on service provisioning, modification and decommissioning. [E] 15. Informative References - RFC 9543 While this is intended to be an Informational RFC, I would have expected RFC 9543 to be a normative reference, as that RFC has to be understood in order to understand this document. [F] 15. Informative References - TSN What is the [TSN] reference referring to? Keep in mind that an RFC is an archive document. -- Nits 1. Introduction "Customers of a network operator may request connectivity services with advanced characteristics, such as low latency guarantees, bounded jitter, or isolation from other services or customers so that changes in some other services (e.g., changes in network load, or events such as congestion or outages) have no or only acceptable effect on the observed throughput or latency of the services delivered to the customer." some other services -> other services have no or acceptable effect -> have no effect or only acceptable effects 3.5. Customized Control In many cases the customers are delivered with enhanced VPN services without information about the underlying NRPs. Would be better phrased as: In many cases enhanced VPN services are delivered to customers without information about the underlying NRPs. 4.4. Scalable Service Mapping "Solutions must consider minimizing and controlling the scale of such state," That phrase needs to be rewritten because "must consider" is entirely too close to "should consider" - see Section 2 of RFC 6919 and take note of RFC 6919's 1 April date of publication. 5.4. Control Plane "The control plane of NRP-based enhanced VPNs would likely be based on a hybrid control mechanism" "would likely" is entirely too close to "would probably" - see RFC 6919 section 5. "There are two candidate control plane mechanisms for the setup of paths in the NRP: RSVP-TE and Segment Routing (SR)." Rephrase as: "Two candidate control plane mechanisms for path setup in the NRP are:" to avoid any implication that these are the only two candidates.