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 WIT 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.

Colin Perkins' earlier TSV-ART review of the -11 version of this draft (https://datatracker.ietf.org/doc/review-ietf-rtgwg-qos-model-11-tsvart-lc-perkins-2023-12-06/) continues to be applicable to this -13 version of the draft.  That review notes the use of dated AQM algorithms (RED, WRED) and recommends inclusion of support for more modern AQM algorithms, which appears to have been done.  The color-based markers (overview in sections 3.1 and 3.2) are analogously dated, and the authors are likewise encouraged to make an updated check on "commonly used algorithms in industry" (quoted from section 2 of the draft), as "grouping meter" does not appear to contain any meters aside from those used in the color-based markers. Token bucket and/or leaky bucket metering would be possibilities to include.  In general, it's important to provide support for mechanisms used by network operators, not just those for which RFC or other documentation can be readily located, and I concur with Colin's observations on the importance of extensibility (e.g., so that network operators are able to add their own operator-specific mechanisms).

The DSCP modeling in this draft uses ranges to specify the DSCP code points for classifiers.  This appears to violate RFC 2474, which states (in Section 3): "DS-compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device." To be pedantic, a range match condition can be viewed as an optimized implementation and/or representations of a collection of individual match conditions on each value in the range, but this needs some discussion and guidance to network administrators.  The Configuration example for QoS Classifier in Appendix C.1 provides a worked example of how to get in trouble in this area, as the DSCP range of 11-13 consists of (see https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp-registry-1): a Pool 2 DSCP reserved for experimental or Local Use (11), a Pool 1 DSCP that is the default for the AF12 PHB (12), and a Pool 3 DSCP whose default behavior is effectively reserved for future standardization (13).  While use of this DSCP range is not prohibited, it's not a good example of 3 DSCPs that are generally reasonable to map to the same PHB and/or result in packets marked with them receiving the same packet handling treatment.  If this draft continues to use DSCP ranges, the draft needs some discussion about how that use of DSCP ranges aligns with the requirement quoted from RFC 2474, and the example in Appendix C.1 probably should be revised to something more reasonable.  In general, range match and match under mask are not good ways to match DSCPs due to the structure of the DSCP value pools (see the IANA registry).

Beyond these two concerns, I concur with Colin's concluding remarks that this draft seems broadly ready.  Like Colin, I have not reviewed the YANG in detail.