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

Commentary: lgtm with justin 's comments . 
 Ping on this 
 overall this LG for consistency with the surrounding text , I would change the usage of " [ XXXX ] ( see Section 3 ) " to " [ XXXX ] , Section 3 "
Paragraph (version A):
For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in RFC4566, Section 6.  For audio, the codecs specified
in I-D.ietf-rtcweb-audio, Section 3, MUST be be supported.
Paragraph (version B):
For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in RFC4566, Section 6.  The REQUIRED audio and video
codecs to support are specified in I-D.ietf-rtcweb-audio (see
Section 3) and I-D.ietf-rtcweb-video (see Section 5).
Paragraph (version A):
For each supported codec that is present in the offer, "a=rtpmap"
and "a=fmtp" lines, as specified in RFC4566, Section 6, and
RFC3264, Section 6.1.  For audio, the codecs specified in I-
D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for
simplicity, the answerer MAY use different payload types for
codecs than the offerer, as it is not prohibited by Section 6.1.
Paragraph (version B):
For each supported codec that is present in the offer, "a=rtpmap"
and "a=fmtp" lines, as specified in RFC4566, Section 6, and
RFC3264, Section 6.1.  The REQUIRED audio and video codecs to
support are specified in I-D.ietf-rtcweb-audio (see Section 3) and
I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity,
the answerer MAY use different payload types for codecs than the
offerer, as it is not prohibited by Section 6.1.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 lgtm 
 If you know the remote side is going to use BUNDLE and RTCP mux , it 's desirable to only gather a single set of ports , since the RTCP ports wo n't be used . Since    is already trying to minimize port gathering , it should probably assume rtcp mux . If there is a need to keep  - bundle as is , we could also add a fourth policy , e.g. force - bundle , that differs from    in that it forces use of RTCP mux . 
 I think we need another one , since currently    is minimally compatible with old endpoints and if you force rtcp - mux , then you will have ann interop problem . That 's what I have on my slides now . Feel free to comment . 
 I can go with whatever the WG decides . 
 WG decision is to add an additional policy . Name will be force - bundle unless someone comes up with a better one .
Paragraph (version B):
Similar to max-bundle, but RTCP candidates are not gathered.  This
policy reduces the candidates that must be gathered to the
absolute minimum, but will not be compatible with legacy endpoints
that do not support RTCP mux.
Draft: draft-ietf-rtcweb-jsep

Commentary:   regarding RTP header extension . Also included advice on MID size . 
 lgtm
Paragraph (version A):
An "a=mid" line, as specified in RFC5888, Section 4.
Paragraph (version B):
An "a=mid" line, as specified in RFC5888, Section 4.  When
generating mid values, it is RECOMMENDED that the values be 3
bytes or less, to allow them to efficiently fit into the RTP
header extension defined in I-D.ietf-mmusic-sdp-bundle-
negotiation, Section 11.
Paragraph (version A):
For each supported RTP header extension, an "a=extmap" line, as
specified in RFC5285, Section 5.  The list of header extensions
that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-
usage, Section 5.2.  Any header extensions that require encryption
MUST be specified as indicated in RFC6904, Section 4.
Paragraph (version B):
For each supported RTP header extension, an "a=extmap" line, as
specified in RFC5285, Section 5.  The list of header extensions
that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-
usage, Section 5.2.  [TODO: ensure that urn:ietf:params:rtp-
hdrext:sdes:mid appears either there or here] Any header
extensions that require encryption MUST be specified as indicated
in RFC6904, Section 4.
Paragraph (version A):
For each supported RTP header extension that is present in the
offer, an "a=extmap" line, as specified in RFC5285, Section 5.
The list of header extensions that SHOULD/MUST be supported is
specified in I-D.ietf-rtcweb-rtp-usage, Section 5.2.  Any header
extensions that require encryption MUST be specified as indicated
in RFC6904, Section 4.
Paragraph (version B):
For each supported RTP header extension that is present in the
offer, an "a=extmap" line, as specified in RFC5285, Section 5.
The list of header extensions that SHOULD/MUST be supported is
specified in I-D.ietf-rtcweb-rtp-usage, Section 5.2.  [TODO:
Ensure this contains MID header] Any header extensions that
require encryption MUST be specified as indicated in RFC6904,
Section 4.
Draft: draft-ietf-rtcweb-jsep

Commentary: Also , update IceCandidate section to use consistent “ m= line ” terminology , and also make it clearer that use of MID , if present , is a MUST . 
 WFM 
 The current example in S 3.2 refers to SDES , but that 's not in JSEP any more . We need a new example .
Paragraph (version B):
Whether a session description applies to the local side or the remote
side affects the meaning of that description.  For example, the list
of codecs sent to a remote party indicates what the local side is
willing to receive, which, when intersected with the set of codecs
the remote side supports, specifies what the remote side should send.
However, not all parameters follow this rule; for example, the DTLS-
SRTP parameters RFC5763 sent to a remote party indicate what
certificate the local side will use in DTLS setup, and thereby what
the remote party should expect to receive; the remote party will have
to accept these parameters, with no option to choose different
values.
Paragraph (version B):
In addition, various RFCs put different conditions on the format of
offers versus answers.  For example, a offer may propose an arbitrary
number of media streams (i.e. m= sections), but an answer must
contain the exact same number as the offer.
Paragraph (version A):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m line can be identified in
one of two ways; either by a m-line index, or a MID.  The m-line
index is a zero-based index, with index N referring to the N+1th
m-line in the SDP sent by the entity which sent the IceCandidate.
The MID uses the "media stream identification", as defined in
RFC5888, to identify the m-line.  WebRTC implementations creating an
ICE Candidate object MUST populate both of these fields.
Implementations receiving an ICE Candidate object SHOULD use the MID
if they implement that functionality, or the m-line index, if not.
Paragraph (version B):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m= line can be identified in
one of two ways; either by a m= line index, or a MID.  The m= line
index is a zero-based index, with index N referring to the N+1th m=
line in the SDP sent by the entity which sent the IceCandidate.  The
MID uses the "media stream identification" attribute, as defined in
RFC5888, Section 4, to identify the m= line.  JSEP implementations
creating an ICE Candidate object MUST populate both of these fields.
Implementations receiving an ICE Candidate object MUST use the MID if
present, or the m= line index, if not (as it could have come from a
non-JSEP endpoint).
Paragraph (version A):
The number, type and port number of m-lines.
Paragraph (version B):
The number, type and port number of m= lines.
Draft: draft-ietf-rtcweb-jsep

Commentary: I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be . I do n't believe the changes are controversial , or change the intention of the draft . 
 These changes look good - I agree the rewrite of the offer / answer paragraph is a nice improvement . 
 Looks fine to me
Paragraph (version A):
When the call is accepted, the callee uses the createAnswer() API to
generate an appropriate answer, applies it using
setLocalDescription(), and sends the answer back to the initiator
over the signaling channel.  When the offerer gets that answer, it
installs it using setRemoteDescription(), and initial setup is
complete.  This process can be repeated for additional offer/answer
exchanges.
Paragraph (version B):
To complete the offer/answer exchange, the remote party uses the
createAnswer() API to generate an appropriate answer, applies it
using the setLocalDescription() API, and sends the answer back to the
initiator over the signaling channel.  When the initiator gets that
answer, it installs it using the setRemoteDescription() API, and
initial setup is complete.  This process can be repeated for
additional offer/answer exchanges.
Paragraph (version A):
Start exchanging media to a given remote peer, but keep all the
resources reserved in the offer.
Paragraph (version B):
Start exchanging media with a given remote peer, but keep all the
resources reserved in the offer.
Paragraph (version A):
Session description objects (RTCSessionDescription) may be of type
"offer", "pranswer", and "answer".  These types provide information
as to how the description parameter should be parsed, and how the
media state should be changed.
Paragraph (version B):
Session description objects (RTCSessionDescription) may be of type
"offer", "pranswer", or "answer".  These types provide information as
to how the description parameter should be parsed, and how the media
state should be changed.
Paragraph (version A):
If setRemoteDescription was previously called with an offer, and
setLocalDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission.
Paragraph (version B):
If setLocalDescription was previously called with an offer, and
setRemoteDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission.
Draft: draft-ietf-rtcweb-jsep

Commentary: Late breaking , so if we decide to hold this until after Toronto , no worries 
 LGTM 
 Close enough for me . Merge it .
Paragraph (version A):
If the "VoiceActivityDetection" option is specified, with a value of
"true", the offer MUST indicate support for silence suppression in
the audio it receives by including comfort noise ("CN") codecs for
each supported clock rate, as specified in RFC3389, Section 5.1.
This option allows for significant bandwidth reductions with codecs
such as G.711.
Paragraph (version B):
If the "VoiceActivityDetection" option is specified, with a value of
"true", the offer MUST indicate support for silence suppression in
the audio it receives by including comfort noise ("CN") codecs for
each offered audio codec, as specified in RFC3389, Section 5.1,
except for codecs that have their own internal silence suppression
support.  For codecs that have their own internal silence suppression
support, the appropriate fmtp parameters for that codec MUST be
specified to indicate that silence suppression for received audio is
desired.  For example, when using the Opus codec, the "usedtx=1"
parameter would be specified in the offer.  This option allows the
endpoint to significantly reduce the amount of audio bandwidth it
receives, at the cost of some fidelity, depending on the quality of
the remote VAD algorithm.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM with comment above 
 LGTM and +1 and Justin 's suggested change .
Paragraph (version A):
The intent of the WebRTC protocol suite is to provide an environment
that is securable by default: all media is encrypted, keys are
exchanged in a secure fashion, and the Javascript API includes
functions that can be used to verify the identity of communication
partners.
Paragraph (version B):
The IETF has published separate documents I-D.ietf-rtcweb-security-
arch I-D.ietf-rtcweb-security describing the security architecture
for WebRTC as a whole.  The remainder of this section describes
security considerations for this document.
Paragraph (version B):
While formally the JSEP interface is an API, it is better to think of
it is an Internet protocol, with the JS being untrustworthy from the
perspective of the browser.  Thus, the threat model of RFC3552
applies.  In particular, JS can call the API in any order and with
any inputs, including malicious ones.  This is particularly relevant
when we consider the SDP which is passed to setLocalDescription().
While correct API usage requires that the application pass in SDP
which was derived from createOffer() or createAnswer() (perhaps
suitably modified as described in sec.configurable-sdp-paramete,
there is no guarantee that applications do so.  The browser MUST be
prepared for the JS to pass in bogus data instead.
Paragraph (version B):
Conversely, the application programmer MUST recognize that the JS
does not have complete control of browser behavior.  One case that
bears particular mention is that editing ICE candidates out of the
SDP or suppressing trickled candidates does not have the expected
behavior: implementations will still perform checks from those
candidates even if they are not sent to the other side.  Thus, for
instance, it is not possible to prevent the remote peer from learning
your public IP address by removing server reflexive candidates.
Applications which wish to conceal their public IP address should
instead configure the ICE agent to use only relay candidates.
Draft: draft-ietf-rtcweb-jsep

Commentary: Sure , I can do that . 
 Justin and I discussed on the call and this is still borked due to some git pilot error . 
 PTAL now . 
 LGTM 
 Section 6 indicates that programmers can edit the SDP and lists changes which can and can not be made . It explicitly is preliminary and needs to be fleshed out . 
 There are three categories - must reject , must act on , and ones that the browser can do whatever it wants but if it is not acted on then an error is generated 
 General approach is most things are in the " browser can do what it wants case " 
 Discussed in DC : this applies only to changes on the local side ; the gap between createOffer / createAnswer and setLocalDescription . Proposed path is to mandate one of two actions : Accept the changes and apply them Reject the changes outright We will enumerate certain changes that fall into either category , but these lists will not be exhaustive . All unspecified changes will either be accepted or rejected , and that decision will be left to the browser , but they can not be ignored . Obviously , some types of changes will be ignored . For instance , reordering of a= lines might not be detected as a change . These might carry semantics ( as a = group - id does ) , but we ca n't require perfect detection .
Paragraph (version A):
Note: This section is still very early and is likely to significantly
change as we get a better understanding of a) the use cases for this
b) the implications at the protocol level c) feedback from
implementors on what they can do.
Paragraph (version B):
Accept the changes and adjust its behavior to match the SDP.
Paragraph (version B):
Reject the changes and return an error via the error callback.
Paragraph (version B):
Changes MUST NOT be silently ignored.
Paragraph (version A):
For example, an application could implement call hold by adding an
a=inactive attribute to its local description, and then applying and
signaling that description.
Paragraph (version A):
The application can also modify the SDP to reduce the capabilities in
the offer it sends to the far side in any way the application sees
fit, as long as it is a valid SDP offer and specifies a subset of
what the browser is expecting to do.
Paragraph (version B):
Implementations MAY choose to either honor or reject any elements not
listed in the above two categories, but must do so explicitly as
described at the beginning of this section.  Note that future
standards may add new SDP elements to the list of elements which must
be accepted or rejected, but due to version skew, applications must
be prepared for implementations to accept changes which must be
rejected and vice versa.
Paragraph (version B):
The application can also modify the SDP to reduce the capabilities in
the offer it sends to the far side or the offer that it installs from
the far side in any way the application sees fit, as long as it is a
valid SDP offer and specifies a subset of what was in the original
offer.  This is safe because the answer is not permitted to expand
capabilities and therefore will just respond to what is actually in
the offer.
Draft: draft-ietf-rtcweb-jsep

Commentary: This is OK with me 
 S 5.2.2 says : If the initial offer was applied using setLocalDescription , but an answer from the remote side has not yet been applied , meaning the PeerConnection is still in the " local - offer " state , an offer is generated by following the steps in the " stable " state above , along with these exceptions : o The " s= " and " t= " lines MUST stay the same . o Each " a = mid " line MUST stay the same . o Each " a = ice - ufrag " and " a = ice - pwd " line MUST stay the same . However , Section 5.2.3.4 says : If the " IceRestart " constraint is specified , with a value of " true " , the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes , as specified in RFC5245 , Section 9.1.1.1 . If this constraint is specified on an initial offer , it has no effect ( since a new ICE ufrag and pwd are already generated ) . 
 Yes , if this is an ICE restart , then ufrag / pwd need to change . 
 Discussed in DC : restart requires a change of credentials . Might want to add text that notes the dangers in doing this ( i.e. , do n't do this ) .
Paragraph (version A):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same.
Paragraph (version B):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless
the "IceRestart" option (sec.options-handling was specified.  Note
that it's not clear why you would actually want to do this, since
at this point ICE has not yet started and is thus unlikely to need
a restart.
Draft: draft-ietf-rtcweb-jsep

Commentary: This is OK with me but fine if we want to call out identity or anything that is different . 
 How 's this ? 
 LGTM 
 S 5.2.1 says : Attributes that are common between all m= sections MAY be moved to session - level , if explicitly defined to be valid at session - level . This seems like it would be better as a should 
 Discussed in DC : Some concerns that things that appear at the session level have , in the past , missed by bad implementations . 
 Dc - decdie to change to SHOULD NOT and for things that are big , like idientiy , will put MUST
Paragraph (version A):
Attributes that are common between all m= sections MAY be moved to
session-level, if explicitly defined to be valid at session-level.
Paragraph (version B):
Attributes which SDP permits to either be at the session level or the
media level SHOULD generally be at the media level even if they are
identical.  This promotes readability, especially if one of a set of
initially identical attributes is subsequently changed.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 LGTM
Paragraph (version A):
becomes depleted, either because a larger than expected number of
candidates is needed, or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
Paragraph (version B):
becomes depleted, either because a larger-than-expected number of
media streams is used, or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
Paragraph (version A):
The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN
servers and credentials to use when gathering candidates.  The size
of the ICE candidate pool can also be set, if desired.  If the
application does not indicate a candidate pool size, the browser may
select any default candidate pool size.
Paragraph (version B):
The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN
servers and credentials to use when gathering candidates.  The size
of the ICE candidate pool can also be set, if desired; this indicates
the number of ICE components to pre-gather candidates for.  If the
application does not indicate a candidate pool size, the browser may
select any default candidate pool size.
Draft: draft-ietf-rtcweb-jsep

Commentary: Looks good to me 
  says : S 4.1.1 . " The PeerConnection constructor allows the application to specify global parameters for the media session , such as the STUN / TURN servers and credentials to use when gathering candidates . The size of the ICE candidate pool can also be set , if desired ; by default the candidate pool size is zero . " The WebRTC spec says : " At this point the ICE Agent does not know how many ICE components it needs ( and hence the number of candidates to gather ) , but it can make a reasonable assumption such as 2 . As the RTCPeerConnection object gets more information , the ICE Agent can adjust the number of components " 
 Imagine 4 is more realistic . 
 so default in not defined but their is way for the JS to to set the default for a PC 
 Discussed in DC : default will be unspecified and left up to browsers , there will need to be a setting for applications to override this default . 
 w3c bug is
Paragraph (version B):
The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN
servers and credentials to use when gathering candidates.  The size
of the ICE candidate pool can also be set, if desired.  If the
application does not indicate a candidate pool size, the browser may
select any default candidate pool size.
Draft: draft-ietf-rtcweb-jsep

Commentary: Looks good to me 
 LGTM
Paragraph (version A):
For each offered m= section of a given media type, if there is a
local MediaStreamTrack of the specified type which has been added to
the PeerConnection via addStream and not yet associated with a m=
section, and the specific m= section is either sendrecv or recvonly,
the MediaStreamTrack is associated with the m= section at this time.
If there are more m= sections of a certain type than
MediaStreamTracks, some m= sections will not have an associated
MediaStreamTrack.  If there are more MediaStreamTracks of a certain
type than compatible m= sections, only the first N MediaStreamTracks
will be able to be associated in the constructed answer.  The
remainder will need to be associated in a subsequent offer.
Paragraph (version B):
For each offered m= section of a given media type, if there is a
local MediaStreamTrack of the specified type which has been added to
the PeerConnection via addStream and not yet associated with a m=
section, and the specific m= section is either sendrecv or recvonly,
the MediaStreamTrack is associated with the m= section at this time.
MediaStreamTracks are assigned to m= sections using the canonical
order described in sec.initial-offers.  If there are more m= sections
of a certain type than MediaStreamTracks, some m= sections will not
have an associated MediaStreamTrack.  If there are more
MediaStreamTracks of a certain type than compatible m= sections, only
the first N MediaStreamTracks will be able to be associated in the
constructed answer.  The remainder will need to be associated in a
subsequent offer.