This has been created by cut-and-paste from
https://www.w3.org/TR/security-privacy-questionnaire/, as requested in the TAG review instructions.

3. Questions to Consider
   3.1. Does this specification deal with personally-identifiable information? NO
   3.2. Does this specification deal with high-value data? NO
   3.3. Does this specification introduce new state for an origin that persists across browsing sessions? NO
   3.4. Does this specification expose persistent, cross-origin state to the web? NO
   3.5. Does this specification expose any other data to an origin that it doesn’t currently have access to? NO

3.6. Does this specification enable new script execution/loading mechanisms? NO

3.7. Does this specification allow an origin access to a user’s location? NO

3.8. Does this specification allow an origin access to sensors on a user’s device? NO

3.9. Does this specification allow an origin access to aspects of a user’s local computing environment? YES - it allows it to affect the DSCP codepoints used on outgoing packets, and will therefore allow the application to figure out how DSCP codepoints are handled in the user's networking environment.

3.10. Does this specification allow an origin access to other devices? NO

3.11. Does this specification allow an origin some measure of control over a user agent’s native UI?
(showing, hiding, or modifying certain details, especially if those details are relevant to security)? NO - it has no UI.

3.12. Does this specification expose temporary identifiers to the web?
(e.g. TLS features like Channel ID, session identifiers/tickets, etc)? NO

3.13. Does this specification distinguish between behavior in first-party and third-party contexts?
Section 2.1 of [FIRST-PARTY-ONLY] defines "first-party" in line with existing browser behavior (Chrome and Firefox). NO

3.14. How should this specification work in the context of a user agent’s "incognito" mode? It does not interact with "incognito" mode.

3.15. Does this specification persist data to a user’s local device? NO

3.16. Does this specification have a "Security Considerations" and "Privacy Considerations" section?
NO - the security properties do not change compared to the full WebRTC spec.

3.17. Does this specification allow downgrading default security characteristics? NO

Simplest is to put "= "low"" in the dictionary definition of RTCDataChannelInit.priority.

The background rule for the editor's draft is:

background: url("https://www.w3.org/StyleSheets/TR/logo-ED") top left no-repeat white; 

It should be:

background: url("https://www.w3.org/StyleSheets/TR/logo-ED") top left no-repeat var(--bg);

@dontcallmedom probably knows where this belongs, which isn't this repo, I suspect.

There is one nearly done: web-platform-tests/wpt#21462
This issue is filed to keep track of it.

By the principles of wpt test naming, tests that reference "priority" should now be in a new webrtc-dscp-exp directory.

(which brings to mind: should we rename this spec "webrtc-priority"?)

TAG question: w3ctag/design-reviews#560 (comment)

Per Document review guidance:

• I18N review request
• TAG review request
• Privacy review request
• Accessibility review request
• Security review request
• Chairs review request

And usual groups:

• Media & Entertainment Interest Group
• Media Working Group

As per TPAC decision sept 2019, Priority, being an at-risk feature, should be in an extension spec. This is the logical place to move it.
As part of the move, I suggest we also define a "queuePriority" control that only affects the local-prioirty part of the "priority" control.

Hi,

Not sure if this is the right place, but wanted to bring into your attention network tokens (https://networktokens.org), a new project/IETF I-D that might be relevant with WebRTC and QoS.

In a nutshell: Network tokens are an open and secure method for end users and application providers to coordinate with the network about how their traffic is treated ( e.g., to access a 5G slice, a firewall whitelist, a zero-rating, or a QoS service ). Network Tokens replace complex, insecure, and privacy-invasive DPI application signatures with a deterministic and unified mechanism to build network services, and complement DSCP codepoints across network boundaries.

We have a prototype implementation using network tokens as part of WebRTC, and I'd be very interested to understand what's the best way to engage with the WebRTC group and get feedback/guidance on next steps.

https://w3c.github.io/webrtc-priority/ is now just the README, I'm guessing something went wrong with #20.

In terms of spec text, this requires merging #5.
We have a review questionnaire. Must check what other things need filling out.

As we've worked on this, it's become clear that the decisions taken for local scheduling and the decisions taken on DSCP markings may want to be controlled independently of each other.

The method to set local priority only (set networkPriority explicitly to the default value and set Priority in order to influence local prioirty) is clumsy.

We can add another field localPriority that works just like networkPriority does now, but controls the "other half" only. Then priority will only be used by people who don't care to differentiate.