IETF Last Call Review of draft-ietf-tsvwg-nqb-29
review-ietf-tsvwg-nqb-29-secdir-lc-rose-2025-06-11-00

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.