Reviewer: Kyle Rose Review result: Almost Ready 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@xxxxxxxx if you reply to or forward this review. The summary of this review is Almost Ready. # Summary This document describes a YANG model for the RFC 9543 "Network Slice" service. After reading the main part of 9543, my interpretation is that this service is (and I'm sure I will be butchering this slightly, so apologies in advance) essentially one for requesting a black box generalization of a VPN (an overlay network) that meets certain requirements related to topology, performance, etc. Notably, the "black box" aspect of this means that the provider of the slice is free to choose any combination of underlying network or transport technologies (for the underlay network) that meet the requirements specified in the request. Consequently, no transport-specific critique is possible, as outside of the MTI control plane protocols (SSH and TLS underlying NETCONF and RESTCONF, respectively) no specific transport technologies for the underlay are even recommended. # Transport-related comments Not being an expert in YANG data modeling, it is unclear to me how some of the examples are to be properly validated against the module from the draft. For example, in figure 6, how is the two-way bandwidth specified in a machine-readable and therefore -verifiable way? "1 Gbps" and "95th percentile latency 50ms" are both included as part of the "description", but I see no metric bound for bandwidth corresponding to the "metric-bound" for "two-way-delay-percentile". Are the machine-readable elements for bandwidth missing simply in error? More generally, how is the module implementing the model to be validated for completeness prior to publication? # General comments Related to the above concern, it's unclear to me whether this model or the Network Slice service it represents should be published as an RFC rather than (say) on a wiki, where it can be updated more rapidly. It seems inevitable that someone will quickly discover some useful but heretofore-unanticipated network slice QoS property or SLO not captured in the published Network Slice description or associated YANG module, necessitating a non-standard extension. Indeed, Appendix A anticipates this. Is the plan to see how this ecosystem evolves over time and to publish a set of bis documents with an augmented set of standard Network Slice properties? And if so, is there a plan to capture and publish extensions to the standard in a central place (such as a wiki) to minimize drift or variance in custom extensions clearly aimed at solving the same problem? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
