Change:
of packets with certain DSCP markings.  The detection of these conditions is implementation dependent. <ins> A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed.  This is allowed even within a single media flow for video in I-D.ietf-tsvwg-rtcweb-qos.  Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected.  If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0.  This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent.  This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes.  Other flows on the same transport, using different DSCP code points, don't need to change. </ins> All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point.  The code point used SHOULD be that recommended by I-D.ietf-tsvwg-rtcweb-qos for the

Discussion:
Note that this differs from what was said at the IETF meeting - after considering, I didn't see a reason to recommend ICE restart. The text does not contain MUST or SHOULD. This is implementation advice.
FWIW ... This looks good to me
Per Martin, need to be explicit that switching to DSCP 0 needs doing for the media type as a whole, because the DSCP codepoints in a transport are chosen for compatibility on classes (AF4x for instance).
From Magnus Westerlund in IETF LC: Section 4.2: The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. As raised on the TSVWG and RTCWEB mailing list recently in regards to draft-ietf-tsvwg-rtcweb-qos there have been a recent study (URL) showing that non zero DSCP values resulted in consistent failures in 10-13% of the tested paths. So I think it worth considering if this text needs to be sharpen, and possibly actually point to a solution that needs to be specified?
Resolution in WG in Berlin: "We will treat DSCP-induced path failure parallel with other types of path failure, and resolve it by using an ICE restart". Note: There is a problem with multiple DSCP codepoints on a single transport, where one might be blocked and another might get through. In this case, the ICE probes (using one DSCP code point) may succeed while others fail. This is complex, and should be warned about - likely mode of solution is ICE restart with DSCP markings turned off, but detection requires watching the multiple DSCP-codepoint-using channels for differential failures. See minutes for details.
From Martin Thomson: URL - I know what you mean, of course. Presumably if DSCP 0 passes, but probes with DSCP N fails, only traffic that was intended to be sent with DSCP N would be sent with DSCP 0. If DSCP M succeeds, then you could continue to use that; your text implies otherwise. You might like to point out that switching DSCP marking mid-flow can have negative effects on things like congestion controllers and loss recovery.