Thanks for your comments. See below.
On Sun, Feb 17, 2019 at 1:59 PM מנחם דודג' <menachemdodge1@xxxxxxxxx> wrote:
Reviewer: Menachem DodgeReview Result: Has NitsThis document has "Intended Status" for the Standards Track but the document is written as an informational guide. I suggest that the ADs decide whether this is informational or for the Standards Track.
Not sure exactly how this is decided, but this document is trying to set specific requirements for how browsers should operate. As such, it seems like Standards Track is probably the better opion.
On the whole the document is written well and is understandable.In Section 5.2 it states that:"Mode 1 MUST only be used when user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. "I'm not sure what "getUserMedia consent" refers to.
I can add a reference to security-arch, e.g. https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#section-6.2
While the document defines that Mode 1 should be used when there is user consent and Mode 2 should be used when there is no User consent , however when should Mode 3 and Mode 4 be used?
These modes roughly equate to stops on a maximum-performance<-->minimum-disclosure tradeoff slider. Implementations that are willing to incur the performance consequences may decide to adopt stricter default modes (and, we have seen that the Brave browser does exactly that.) As noted in the document:
However, implementations MAY
choose stricter modes if desired, e.g., if a user indicates they want
all WebRTC traffic to follow the default route.
The document also states that:"Future documents may define additional modes and/or update the recommended default modes. "If this is the case should there be a "version" defined so that the webRTC client and Server no which implementation has been implemented?
The server doesn't need to know which mode has been selected; the modes are entirely specific to client behavior.
