jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: rtcweb-overview

Commentary: ekr had the following comment : S 2.4 . Why do you have two terminology sections ? I would merge them . 
 Most of my comments are consequential .
A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is
something that conforms to both the protocol specification and the
Javascript API cited above.
A WebRTC non-browser is something that conforms to the protocol
specification, but does not claim to implement the Javascript API.
This can also be called a "WebRTC device" or "WebRTC native
application".
A WebRTC endpoint is either a WebRTC browser or a WebRTC non-
browser.  It conforms to the protocol specification.
A WebRTC-compatible endpoint is an endpoint that is able to
successfully communicate with a WebRTC endpoint, but may fail to
meet some requirements of a WebRTC endpoint.  This may limit where
in the network such an endpoint can be attached, or may limit the
security guarantees that it offers to others.  It is not
constrained by this specification; when it is mentioned at all, it
is to note the implications on WebRTC-compatible endpoints of the
requirements placed on WebRTC endpoints.
A WebRTC gateway is a WebRTC-compatible endpoint that mediates
media traffic to non-WebRTC entities.
A specification of a set of calls and events, usually tied to a
programming language or an abstract formal specification such as
WebIDL, with its defined semantics.
Something that conforms to the protocol specification, but does
not claim to implement the Javascript API.  This can also be
called a "WebRTC device" or "WebRTC native application".
Either a WebRTC browser or a WebRTC non-browser.  It conforms to
the protocol specification.
An endpoint that is able to successfully communicate with a WebRTC
endpoint, but may fail to meet some requirements of a WebRTC
endpoint.  This may limit where in the network such an endpoint
can be attached, or may limit the security guarantees that it
offers to others.  It is not constrained by this specification;
when it is mentioned at all, it is to note the implications on
WebRTC-compatible endpoints of the requirements placed on WebRTC
endpoints.
A WebRTC-compatible endpoint that mediates media traffic to non-
WebRTC entities.
The list is in alphabetical order.
Application Programming Interface - a specification of a set of
calls and events, usually tied to a programming language or an
abstract formal specification such as WebIDL, with its defined
semantics.
Draft: rtcweb-overview

Commentary: ekr had the following comment : You should probably list  , SCTP , and SDP in this section . It 's not like we have n't decided we need them . 
 LGTM with nits
Data framing: RTP, SCTP and other data formats that serve as
containers, and their functions for data confidentiality and
integrity.
Data framing: RTP, SCTP, DTLS, and other data formats that serve
as containers, and their functions for data confidentiality and
integrity.
Connection management: Setting up connections, agreeing on data
formats, changing data formats during the duration of a call; SIP
and Jingle/XMPP belong in this category.
Connection management: Setting up connections, agreeing on data
formats, changing data formats during the duration of a call; SDP,
SIP, and Jingle/XMPP belong in this category.
Draft: rtcweb-overview

Commentary: LGMT 
 ekr provided the following comment for s3 : I would say  ) in this diagram .
Note that HTTP and WebSockets are also offered to the Javascript
application through browser APIs.
Note that HTTPS and WebSockets are also offered to the Javascript
application through browser APIs.
Draft: rtcweb-overview

Commentary: EKR entered the following DISCUSS : Your citation to ICE is to 5245 - bis , but at least the JSEP editor consensus was that WebRTC depended on 5245 , so this needs to be resolved one way or the other . 
 Sean asked me to leave this one open . Personally , I 'd somewhat prefer to 5245bis because it separates out the SDP machinery , but JSEP has a specific section reference ( section 15.4 ) that has to go to either 5245 or to mmusic - ice - sip - sdp , and one could argue that we need to pull in -sip - sdp here too . I 'm OK with 5245 as a reference , but will let the chairs make the call . 
 I no longer care about this distinction .
An implementation of the Interactive Connectivity Establishment
(ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be
an SDP Agent, but there exist ICE Agents that do not use SDP (for
instance those that use Jingle XEP-0166).
An implementation of the Interactive Connectivity Establishment
(ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent,
but there exist ICE Agents that do not use SDP (for instance those
that use Jingle XEP-0166).
Draft: rtcweb-overview

Commentary:  provided the following comment : s7 , list item 1 : The citiation to [ 3264 ] seems misplaced . It describes the offer / answer model , not SIP in general . I suggest moving the citation to after the word " semantics ” .
The WebRTC media negotiations will be capable of representing the
same SDP offer/answer semantics that are used in SIP RFC3264, in
such a way that it is possible to build a signaling gateway
between SIP and the WebRTC media negotiation.
The WebRTC media negotiations will be capable of representing the
same SDP offer/answer semantics RFC3264 that are used in SIP, in
such a way that it is possible to build a signaling gateway
between SIP and the WebRTC media negotiation.
Draft: rtcweb-overview

Commentary: Jingle and XMPP already had references by BOSH did n't so I it . 
  had the following comment : I had to look up jingle and BOSH , you may want to consider adding references to the XMPP specifications .
For example, if both operators' servers implement SIP, SIP could be
used for communication between servers, along with either a
standardized signaling mechanism (e.g.  SIP over WebSockets) or a
proprietary signaling mechanism used between the application running
in the browser and the web server.  Similarly, if both operators'
servers implement Extensible Messaging and Presence Protocol (XMPP),
XMPP could be used for communication between XMPP servers, with
either a standardized signaling mechanism (e.g.  XMPP over WebSockets
or BOSH) or a proprietary signaling mechanism used between the
application running in the browser and the web server.
For example, if both operators' servers implement SIP, SIP could be
used for communication between servers, along with either a
standardized signaling mechanism (e.g.  SIP over WebSockets) or a
proprietary signaling mechanism used between the application running
in the browser and the web server.  Similarly, if both operators'
servers implement Extensible Messaging and Presence Protocol (XMPP),
XMPP could be used for communication between XMPP servers, with
either a standardized signaling mechanism (e.g.  XMPP over WebSockets
or BOSH XEP-0124 or a proprietary signaling mechanism used between
the application running in the browser and the web server.
Draft: rtcweb-overview

Commentary:  had the following comment / nit : massage the signals " : not sure if " massage " is actually a meaningful word here …
On this drawing, the critical part to note is that the media path
("low path") goes directly between the browsers, so it has to be
conformant to the specifications of the WebRTC protocol suite; the
signaling path ("high path") goes via servers that can modify,
translate or massage the signals as needed.
On this drawing, the critical part to note is that the media path
("low path") goes directly between the browsers, so it has to be
conformant to the specifications of the WebRTC protocol suite; the
signaling path ("high path") goes via servers that can modify,
translate or manipulate the signals as needed.
Draft: rtcweb-overview

Commentary:  had the following comment : section 3 : " Data transport : TCP , UDP and the means to securely set up connections between entities , as well as the functions for deciding when to send data : Congestion management , bandwidth estimation and so on . " This seems to implicitly assume that only TCP or something encapsulated over UDP can be used . Even though that might be true , I assume this was not intentionally , maybe : NEW " Data transport : such as TCP or UDP and the means to securely set up connections between entities , as well as the functions for deciding when to send data : Congestion management , bandwidth estimation and so on . "
Data transport: TCP, UDP and the means to securely set up
connections between entities, as well as the functions for
deciding when to send data: Congestion management, bandwidth
estimation and so on.
Data transport: such as TCP, UDP and the means to securely set up
connections between entities, as well as the functions for
deciding when to send data: Congestion management, bandwidth
estimation and so on.
Draft: rtcweb-overview

Commentary: Tweaks to future proof document . 
  had the following comment : I found the reference to MMUSIC WG in When a new codec is specified , and the SDP for the new codec is specified in the MMUSIC WG , no other standardization should be required for it to be possible to use that in the web browsers . to be odd . MMUSIC may be around forever , but this work might be refactored at some point in the future . Is the point that When SDP for a new codec is specified , no other standardization should be required for it to be used in the web browsers . Or is there another way to say this ? I 'm also wondering if the statement is true for any WebRTC endpoint , not just browsers .
When a new codec is specified, and the SDP for the new codec is
specified in the MMUSIC WG, no other standardization should be
required for it to be possible to use that in the web browsers.
Adding new codecs which might have new SDP parameters should not
change the APIs between the browser and Javascript application.
As soon as the browsers support the new codecs, old applications
written before the codecs were specified should automatically be
able to use the new codecs where appropriate with no changes to
the JS applications.
When an SDP for a new codec is specified, no other standardization
should be required for it to be possible to use that in the web
browsers.  Adding new codecs which might have new SDP parameters
should not change the APIs between the browser and Javascript
application.  As soon as the browsers support the new codecs, old
applications written before the codecs were specified should
automatically be able to use the new codecs where appropriate with
no changes to the JS applications.
Draft: rtcweb-overview

Commentary: Spencer had the following comment : I 'm not sure how tutorial you want section 4 to be , but I 'd at least mention appropriate retransmission and in - order delivery , in addition to congestion control , since you get that with SCTP on the data channel .
It includes necessary functions for congestion control: When not to
send data.
It includes necessary functions for congestion control,
retransmission, and in-order delivery.
Draft: rtcweb-overview

Commentary: Spencer had the following comment : This is a nit , but in this text , Other efforts , for instance the W3C WEBRTC , Web Applications and Device API working groups , focus on making standardized APIs and interfaces available , within or alongside the HTML5 effort , it would be nice to have the names here match what 's on the W3C website . So , " Web Real - Time Communication " , " Web Application Security " , and " Device and Sensors " , unless I 'm guessing at the mapping wrong . It 's also easy to read that text with " Web Applications and Device API " as a single working group , so using a comma after " Web Application Security " would be helpful . 
 LGTM with editorial
Other efforts, for instance the W3C WEBRTC, Web Applications and
Device API working groups, focus on making standardized APIs and
interfaces available, within or alongside the HTML5 effort, for those
functions; this memo concentrates on specifying the protocols and
subprotocols that are needed to specify the interactions that happen
across the network.
Other efforts, for instance the W3C Web Real-Time Communications, Web
Applications Security, and Device and Sensor working groups, focus on
making standardized APIs and interfaces available, within or
alongside the HTML5 effort, for those functions.  This memo
concentrates on specifying the protocols and subprotocols that are
needed to specify the interactions over the network.
Draft: rtcweb-overview

Commentary: Please double check this , but it did say " functions for ... function such as " so I changed the second function to application . 
  had the following comment : 3 , first paragraph : This is also convoluted and hard to parse .
The model of real-time support for browser-based applications does
not assume that the browser will contain all the functions that need
to be performed in order to have a function such as a telephone or a
video conferencing unit; the vision is that the browser will have the
functions that are needed for a Web application, working in
conjunction with its backend servers, to implement these functions.
For browser-based applications, the model for real-time support does
not assume that the browser will contain all the functions needed for
an application such as a telephone or a video conference.  The vision
is that the browser will have the functions needed for a Web
application, working in conjunction with its backend servers, to
implement these functions.
Draft: rtcweb-overview

Commentary:  noted is his comments : 2.3 , last paragraph : The paragraph is a single , convoluted sentence that is hard to parse . ( It 's also a comma splice ) . Please consider breaking into multiple simpler sentences . 
 This text is gross , but the changes are fine .
The alternative - that of having no mandatory to implement - does not
mean that you cannot communicate, it merely means that in order to be
part of the communications partnership, you have to implement the
standard "and then some" - that "and then some" usually being called
a profile of some sort; in the version most antithetical to the
Internet ethos, that "and then some" consists of having to use a
specific vendor's product only.
The alternative, that is having no mandatory to implement, does not
mean that you cannot communicate, it merely means that in order to be
part of the communications partnership, you have to implement the
standard "and then some".  The "and then some" is usually called a
profile of some sort; in the version most antithetical to the
Internet ethos, that "and then some" consists of having to use a
specific vendor's product only.
Draft: rtcweb-overview

Commentary: Made changes to address Warren 's first and third , but not 2nd nit . I 'm unsure whether the changes in the spacing I introduced will fix the odd spacing in Olle 's name . 
  noted the following nits in his ballot : 1 : " Development of The Universal Solution has proved hard , however , for all the usual reasons . " -- this is cute , but leaves people wondering what " all the usual reasons are " . Perhaps just " Development of The Universal Solution has , however , proved hard . " ( or just cut after the " however in the original " ) . 2 : I 'm not sure why you have " Protocol " in the terminology section . It does n't seem like it is useful for the document , and this document does n't seem like the right place to ( re ) define it . 3 : Acknowledgements : Funny spacing in "
Development of The Universal Solution has proved hard, however, for
all the usual reasons.
Development of The Universal Solution has, however, proved hard.
Draft: rtcweb-overview

Commentary:  submitted a DISCUSS related to management . It was discussed and adding the following text as the penultimate paragraph in s1 ought will resolve it : Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network , and may result in a shift in the kinds of devices used to create and consume such media . In the case of signaling , WebRTC session setup will typically occur over TLS - secured web technologies ( such as WebSockets [ RFC6455 ] ) using application - specific protocols . Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation [ RFC3361 ] or through the transparent insertion of of SIP Application Level Gateways ( ALGs ) -- will not work with such signaling . In the case of networks using cooperative endpoints , the approaches defined in [ RFC8155 ] may serve as a suitable replacement for [ RFC3361 ] . The increase in browser - based communications may also lead to a shift away from dedicated real - time - communications hardware , such as SIP desk phones . This will diminish the efficacy of operational techniques that place dedicated real - time devices on their own network segment , address range , or VLAN for purposes such as applying traffic filtering and QoS. The markings described in [ ] may be appropriate replacements for such techniques .
Operators should note that deployment of WebRTC will result in a
change in the nature of signaling for real time media on the network,
and may result in a shift in the kinds of devices used to create and
consume such media.  In the case of signaling, WebRTC session setup
will typically occur over TLS-secured web technologies using
application-specific protocols.  Operational techniques that involve
inserting network elements to interpret SDP -- either through
endpoint cooperation RFC3361 or through the transparent insertion of
SIP Application Level Gateways (ALGs) -- will not work with such
signaling.  In the case of networks using cooperative endpoints, the
approaches defined in RFC8155 may serve as a suitable replacement for
RFC3361.  The increase in browser-based communications may also lead
to a shift away from dedicated real-time-communications hardware,
such as SIP desk phones.  This will diminish the efficacy of
operational techniques that place dedicated real-time devices on
their own network segment, address range, or VLAN for purposes such
as applying traffic filtering and QoS.  Applying the markings
described in I-D.ietf-tsvwg-rtcweb-qos may be appropriate
replacements for such techniques.
Draft: rtcweb-overview

Commentary: Fixing up some ID - nit reported outdated references .
This memo describes a set of building blocks that can be made
accessible and controllable through a Javascript API in a browser,
and which together form a sufficient set of functions to allow the
use of interactive audio and video in applications that communicate
directly between browsers across the Internet.  The resulting
protocol suite is intended to enable all the applications that are
described as required scenarios in the use cases document I-D.ietf-
rtcweb-use-cases-and-requirements.
This memo describes a set of building blocks that can be made
accessible and controllable through a Javascript API in a browser,
and which together form a sufficient set of functions to allow the
use of interactive audio and video in applications that communicate
directly between browsers across the Internet.  The resulting
protocol suite is intended to enable all the applications that are
described as required scenarios in the use cases document RFC7478.
WebRTC endpoints that support audio and/or video MUST implement the
codecs and profiles required in I-D.ietf-rtcweb-audio and I-D.ietf-
rtcweb-video.
WebRTC endpoints that support audio and/or video MUST implement the
codecs and profiles required in RFC7874 and RFC7742.
The requirements on WebRTC systems with regard to audio processing
are found in I-D.ietf-rtcweb-audio; the proposed API for control of
local devices are found in W3C.WD-mediacapture-streams-20120628.
The requirements on WebRTC systems with regard to audio processing
are found in RFC7874; the proposed API for control of local devices
are found in W3C.WD-mediacapture-streams-20120628.
Draft: rtcweb-overview

Commentary: ID - nits turned up that the 2119 language section was missing . I it as a new section , but could also see it being in the existing section 2 . 
 I think I prefer it in section 2.4 , with the rest of terminology .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.