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.

I am not an expert on YANG or DiffServ, and I have not followed the development and discussion related to this draft. This review is hence necessarily written from a generalist transport perspective. Please accept my apologies if I touch on topics that have been considered before in the working group.

The draft looks to be defining mechanisms to configure the use of existing QoS mechanisms and to report on their effects. As such, any new transport protocol impact would seem limited. The mechanisms described may make it easier to deploy QoS, but the QoS techniques exist and can be used irrespective of whether this draft is published.

For AQM, this draft specifies configuration parameters for RED and WRED. These AQM algorithms have certainly been widely implemented and used, but there are more modern alternatives that have been defined in IETF and that are also starting to see use (e.g., PIE – RFC 8033, and several variants on CoDel – RFC 8289/8290). Has consideration been given to whether any other AQM algorithms should be included? Is the mechanism extensible to support these and other future AQM approaches? 
From a transport perspective I would not recommend use of RED or WRED today, since the alternatives perform better and are harder to misconfigure. Some discussion about extensibility and alternatives would be helpful.

Similarly there are only two traffic classifiers specified, which may warrant an extension point.

Otherwise, this seems broadly ready.

Colin