jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-security

Commentary:  cleared his discuss after  's response , but we still need to include text to address the .
It should be noted that the use of this secure media mode is left to
the discretion of the site.  When such a mode is engaged, the browser
will need to provide indicia to the user that the associated media
has been authenticated as coming from the identified user.  This
allows WebRTC services that wish to claim end-to-end security to do
so in a way that can be easily verified by the user.  This model
requires that the remote party's browser be included in the TCB, as
described in sec.web-security.
Draft: draft-ietf-rtcweb-security

Commentary: PTAL 
 Either way , this is fine .
Verifying receiver consent requires some sort of explicit handshake,
but conveniently we already need one in order to do NAT hole-
punching.  ICE RFC8445 includes a handshake designed to verify that
the receiving element wishes to receive traffic from the sender.  It
is important to remember here that the site initiating ICE is
presumed malicious; in order for the handshake to be secure the
receiving element MUST demonstrate receipt/knowledge of some value
not available to the site (thus preventing the site from forging
responses).  In order to achieve this objective with ICE, the STUN
transaction IDs must be generated by the browser and MUST NOT be made
available to the initiating script, even via a diagnostic interface.
Verifying receiver consent also requires verifying the receiver wants
to receive traffic from a particular sender, and at this time; for
example a malicious site may simply attempt ICE to known servers that
are using ICE for other sessions.  ICE provides this verification as
well, by using the STUN credentials as a form of per-session shared
secret.  Those credentials are known to the Web application, but
would need to also be known and used by the STUN-receiving element to
be useful.
Verifying receiver consent requires some sort of explicit handshake,
but conveniently we already need one in order to do NAT hole-
punching.  Interactive Connectivity Establishment (ICE) RFC8445
includes a handshake designed to verify that the receiving element
wishes to receive traffic from the sender.  It is important to
remember here that the site initiating ICE is presumed malicious; in
order for the handshake to be secure the receiving element MUST
demonstrate receipt/knowledge of some value not available to the site
(thus preventing the site from forging responses).  In order to
achieve this objective with ICE, the STUN transaction IDs must be
generated by the browser and MUST NOT be made available to the
initiating script, even via a diagnostic interface.  Verifying
receiver consent also requires verifying the receiver wants to
receive traffic from a particular sender, and at this time; for
example a malicious site may simply attempt ICE to known servers that
are using ICE for other sessions.  ICE provides this verification as
well, by using the STUN credentials as a form of per-session shared
secret.  Those credentials are known to the Web application, but
would need to also be known and used by the STUN-receiving element to
be useful.
Draft: draft-ietf-rtcweb-security

Commentary: Addressing  's comments . I also to periods that I noticed were missing . 
 PTAL 
 Scratch that , I 'm reading backwards . The references are fine .
The attacker forges the response apparently http://calling-
service.example.com/ to inject JS to initiate a call to himself.
The attacker forges the response apparently from http://calling-
service.example.com/ to inject JS to initiate a call to himself.
In ordinary operation, the site learns the browser's IP address,
though it may be hidden via mechanisms like Tor
[http://www.torproject.org] or a VPN.  However, because sites can
cause the browser to provide IP addresses, this provides a mechanism
for sites to learn about the user's network environment even if the
user is behind a VPN that masks their IP address.  Implementations
may wish to provide settings which suppress all non-VPN candidates if
the user is on certain kinds of VPN, especially privacy-oriented
systems such as Tor.
In ordinary operation, the site learns the browser's IP address,
though it may be hidden via mechanisms like Tor
[http://www.torproject.org] or a VPN.  However, because sites can
cause the browser to provide IP addresses, this provides a mechanism
for sites to learn about the user's network environment even if the
user is behind a VPN that masks their IP address.  Implementations
may wish to provide settings which suppress all non-VPN candidates if
the user is on certain kinds of VPN, especially privacy-oriented
systems such as Tor.  See I-D.ietf-rtcweb-ip-handling for additional
information.
source of call linkage I-D.ietf-rtcweb-ip-handling.
Any new set of API features adds a risk of browser fingerprinting,
and WebRTC is no exception.  Specifically, sites can use the presence
or absence of specific devices as a browser fingerprint.  In general,
the API needs to be balanced between functionality and the
incremental fingerprint risk.  See Fingerprinting.
Draft: draft-ietf-rtcweb-security

Commentary: I suspect we 'll get dinged here for referring to the RTCWEB WG by name . I 'm thinking we can just trim it down to be a one sentence blurb ( stolen from overview ) and then say this is the threat model / analysis .
The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC".  The major use cases
for WebRTC technology are real-time audio and/or video calls, Web
conferencing, and direct data transfer.  Unlike most conventional
real-time systems (e.g., SIP-based soft phones) WebRTC communications
are directly controlled by a Web server, which poses new security
challenges.  For instance, a Web browser might expose a JavaScript
API which allows a server to place a video call.  Unrestricted access
to such an API would allow any site which a user visited to "bug" a
user's computer, capturing any activity which passed in front of
their camera.  This document defines the WebRTC threat model and
analyzes the security threats of WebRTC in that model.
WebRTC is a protocol suite for use with real-time applications that
can be deployed in browsers - "real time communication on the Web".
This document defines the WebRTC threat model and analyzes the
security threats of WebRTC in that model.