I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready with Nits.

The security considerations section adequately addresses the (rather mild) security issues introduced by this mechanism for differential treatment of self-identified NQB traffic. There are no new substantive privacy issues: the very coarse signaling of traffic class is likely insignificant when compared to the potential totality of traffic analysis.

Nits:

- Even though sections with domain-specific jargon are primarily directed at readers with pre-existing subject matter expertise in those domains, it is probably helpful for casual readability of the document for abbreviations to be expanded once on first use, perhaps with a short appositional description suitable for a general engineering audience. I refer mainly to the subsections of section 7 regarding mapping to standards of other SDOs.

- In section 7.3.1, the conclusion in the second to last bullet should probably be restricted to exploitation of wi-fi devices that do not explicitly support NQB PHB.

- Later in section 7.3.1, an assertion is made that because "the NQB DSCP brings with it the potential for degradation of non-compliant applications", in particular due to "a shallow queue" leading to packet loss or relegation of some packets to the default queue, that "NQB non-compliant applications that are seeking prioritization in the Wi-Fi uplink would be better off selecting one of those other DSCPs". The security considerations section more precisely indicates that it would be *other devices on the same path* that might have shallow queues for NQB-classified traffic, effectively enforcing discipline and eliminating the incentive to mark QB traffic as NQB. It is not clear to me at all that existing NQB PHB-oblivious wi-fi devices themselves would have shallower queues for traffic with DSCP 45 than for other traffic.

Other thoughts:

- Does it make sense to include any recommendations for treatment of NQB traffic by devices employing fair queueing a la fq_codel or CAKE?

Otherwise, this looks good. I haven't been following the development of this draft in quite some time, but I'm glad to see it about to be published.