Last Call Review of draft-ietf-teas-ietf-network-slice-nbi-yang-17
review-ietf-teas-ietf-network-slice-nbi-yang-17-tsvart-lc-rose-2025-01-06-00

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.

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?