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

Commentary: This LGTM . Actually , I thought I had written something like this :) 
 LGTM 
 Always remember to update both the offer and answer sections :)
Paragraph (version A):
If this m= section is for video media, an "a=imageattr" line, as
specified in sec.imageattr.
Paragraph (version B):
If this m= section is for video media, and there are known
limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in sec.imageattr.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 G. Section 5.2.1 : This section contains the following : Each m= section MUST include the following attribute lines : o If this m= section is for video media , an " a = imageattr " line , as specified in Section 3.6 . But , Section 3.6 does not mandate that a = imageattr always is included . Thus the text must be modified to allow the selective inclusion of the attribute based on what needs to be said . 
 Agreed ; although 3.6 allows it to be omitted , we should update the text in 5.2.1 to avoid confusion .
Paragraph (version A):
If this m= section is for video media, an "a=imageattr" line, as
specified in sec.imageattr.
Paragraph (version B):
If this m= section is for video media, and there are known
limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in sec.imageattr.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM - I think that makes it clear what can and can not work . 
 lgtm
Paragraph (version A):
In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated
MediaStreamTrack.  For the answerer, these mandatory constraints can
be applied to the remote MediaStreamTracks that are created by a
setRemoteDescription call, and will affect the output of the ensuing
createAnswer call.  For the offerer, since it does not know about any
remote MediaStreamTracks until it receives theanswer, this implies
that it can only set these constraints after the initial offer-answer
exchange is complete, and as a result, a new offer-answer is needed
to communicate them.
Paragraph (version B):
In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated
MediaStreamTrack.  For the answerer, these mandatory constraints can
be applied to the remote MediaStreamTracks that are created by a
setRemoteDescription call, and will affect the output of the ensuing
createAnswer call.  Any constraints set after setLocalDescription is
used to set the answer will result in a new offer-answer exchange.
For the offerer, because it does not know about any remote
MediaStreamTracks until it receives the answer, the offer can only
reflect decoder hard limits.  If the offerer wishes to set mandatory
constraints on video resolution, it must do so after receiving the
answer and the result will be a new offer-answer to communicate them.
Draft: draft-ietf-rtcweb-jsep

Commentary: Still needs updates to createOffer / Answer . 
  still seems sad . 
 Since I wo n't be on the call , I give this my preemptive LGTM , provided you at least look at my comments ( and maybe reject them ) and fix the build 
  , did you want to take another look at this ? 
 There one sentence I think we need to deal with ( see other comment ) but rest of this LGTM 
 It still seems like my proposed change of replacing " the initial offer - answer exchange is complete , and as a result , a new offer - answer is needed to communicate them " with " receiving the initial answer or pr - answer . " would make this more or less right for both cases and as the API developers , or does not develop , for this then we can fill in more details 
 Well , as far as I can tell , you ca n't do it after the pr - answer , since you ca n't do an offer at that stage . 
 PTAL at PR . I think with this change we are ready to go . If that makes you happy , merge in PR into here and then merge this PR . 
 With EKR 's this LGTM 
 OK , I will push the buttons now . 
 OK , I worked this over a bit to incorporate PR and also handle the case where the decoder hard limits are not known . The changes are minor but I will hold off for the next few hours to get a sanity check from one of you . 
 LGTM 
 I will read it and get back to you I 30 minutes 
 LGTM 
 Fixed merge conflict and merged .
Paragraph (version A):
In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated
MediaStreamTrack.  For the answerer, these mandatory constraints can
be applied to the remote MediaStreamTracks that are created by a
setRemoteDescription call, and will affect the output of the ensuing
createAnswer call.  For the offerer, since it does not know about any
remote MediaStreamTracks until it receives theanswer, this implies
that it can only set these constraints after the initial offer-answer
exchange is complete, and as a result, a new offer-answer is needed
to communicate them.
Paragraph (version A):
The resulting resolution space formed by intersecting the decoder
hard limits with any mandatory constraints will be used as the x= and
y= values for the generated "a=imageattr" attribute for the
associated MediaStreamTrack.  With only one set of preferences
expressed, the q= value is not important; it SHOULD be set to 1.0.
Paragraph (version A):
If the intersection is the null set, i.e., there are no resolutions
that are permitted by both the decoder and the mandatory constraints,
this SHOULD be represented using x=0 and y=0 values.
Paragraph (version A):
The "a=imageattr" field is payload type specific.  When all video
codecs supported have the same capabilities, use of a single
attribute, with the wildcard payload type (*), is RECOMMENDED.
However, when the supported video codecs have differing capabilities,
a specific "a=imageattr" attribute is inserted for each payload type.
Draft: draft-ietf-rtcweb-jsep

Commentary: is this OK ? 
 lgtm with the one comment above 
 Ignored is the wrong word to use here . The value is not used is true but ignored is just simply not true . 
  .... We 're not checking it and not doing anything with it . I 'm happy to use another word , but I 'm going to need you to suggest one . ,   wrote : 
 please r+ if you are happy . please merge if you are happy . 
 I really do n't care but it like 1 of the 3 things I raised got fixed 
 I see I missed the trickle thing . What else is there ? ,   wrote : 
 Around line 2216 I had another change " SHOULD be ignored " to " is not used " . I think we are running into the limitations of using github for review here . 
 Indeed , I think I missed it . ,   wrote : 
 I think this is ready to merge if you are still happy . 
 LGTM 
 lgtm with minor change 
 When  recommends that lines are ignored ( absent some syntax validation ) , it violates a rule in RFC 5245 regarding mismatch processing . 5245 requires that the values for port and IP address in and correspond to a candidate that appears in the media section . Consensus in Dallas was to prohibit checking of the value in against and , which requires an explicit mention in the draft , since this is different to what  says . 
 The sole point of mismatch processing is to allow applications to see if some SBC messed with their addresses : If the agent is not proceeding with ICE because there were a = candidate attributes , but none that matched the default destination of the media stream , the agent MUST include an a = ice- mismatch attribute in its answer . Not proceeding with ICE is n't an option here , and this is somewhat problematic with trickle ice ( at least the initial 0.0.0.0 candidate ) , so I think ignoring makes sense .
Paragraph (version B):
The "c=" line MUST be checked for syntax but its value is not
used.  This supersedes the guidance in RFC5245, Section 6.1, to
use "ice-mismatch" to indicate mismatches between "c=" and the
candidate lines; because JSEP always uses ICE, "ice-mismatch" is
not useful in this context.
Paragraph (version A):
The "c=" line, if present, MUST be parsed as specified in RFC4566,
Section 5.7, and its contents stored.
Paragraph (version B):
As with the "c=" line at the session level, the "c=" line MUST be
parsed according to RFC4566, Section 5.7, but its value is not
used.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 http://rtcweb- mentions its use at media level ; this should be clarified .
Paragraph (version A):
If present, a single "a=ice-lite" line is parsed as specified in
RFC5245, Section 15.3, and a value indicating the presence of ice-
lite is stored.
Draft: draft-ietf-rtcweb-jsep

Commentary: lgtm 
 lgtm
Paragraph (version A):
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 B):
Session description objects (RTCSessionDescription) may be of type
"offer", "pranswer", "answer" or "rollback".  These types provide
information as to how the description parameter should be parsed, and
how the media state should be changed.
Draft: draft-ietf-rtcweb-jsep

Commentary: ... 14 
 LGTM 
 Cullen thinks it should accept and non - mux . EKR and Justin currently believe it should reject the offer . 
 Original text : when acting as answerer will reject any m= section that does not provide an " a = rtcp - mux " attribute . 
 LGTM at IETF 92 
 open issue in text to be removed
Paragraph (version A):
The browser will only gather RTP candidates.  [[OPEN ISSUE: how
should the answerer behave.  https://github.com/rtcweb-wg/jsep/
issues/114]] This halves the number of candidates that the offerer
needs to gather.
Paragraph (version B):
The browser will only gather RTP candidates.  This halves the
number of candidates that the offerer needs to gather.  When
acting as answerer, the browser will reject any m= section that
does not provide an "a=rtcp-mux" attribute.
Draft: draft-ietf-rtcweb-jsep

Commentary: lgtm 
 need to be to " an " like in line 854 ? ? 
 Fixed by 
 The word  is missing ?
Paragraph (version A):
"answer" indicates that a description should be parsed as an answer,
the offer-answer exchange should be considered complete, and any
resources (decoders, candidates) that are no longer needed can be
released.  A description used as an "answer" may be applied as a
response to a "offer", or an update to a previously sent "pranswer".
Paragraph (version B):
"answer" indicates that a description should be parsed as an answer,
the offer-answer exchange should be considered complete, and any
resources (decoders, candidates) that are no longer needed can be
released.  A description used as an "answer" may be applied as a
response to an "offer", or an update to a previously sent "pranswer".
Paragraph (version A):
The setLocalDescription method instructs the PeerConnection to apply
the supplied SDP blob as its local configuration.  The type field
indicates whether the blob should be processed as an offer,
provisional answer, or final answer; offers and answers are checked
differently, using the various rules that exist for each SDP line.
Paragraph (version B):
The setLocalDescription method instructs the PeerConnection to apply
the supplied session description as its local configuration.  The
type field indicates whether the description should be processed as
an offer, provisional answer, or final answer; offers and answers are
checked differently, using the various rules that exist for each SDP
line.
Paragraph (version A):
The setRemoteDescription method instructs the PeerConnection to apply
the supplied SDP blob as the desired remote configuration.  As in
setLocalDescription, the type field of the indicates how the blob
should be processed.
Paragraph (version B):
The setRemoteDescription method instructs the PeerConnection to apply
the supplied session description as the desired remote configuration.
As in setLocalDescription, the type field of the description
indicates how it should be processed.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM ! 
  on two occasions says " SDP media description " where it seems " SDP session description " or similar would be more appropriate . " media description " seem to reference m - lines rather than the full SDP in other documents ( 4566 , 3264 ) . 
 agree - see if that pull request fixes it 
 to my understanding it does fix it !
Paragraph (version A):
JSEP does not specify a particular signaling model or state machine,
other than the generic need to exchange SDP media descriptions in the
fashion described by RFC3264 (offer/answer) in order for both sides
of the session to know how to conduct the session.  JSEP provides
mechanisms to create offers and answers, as well as to apply them to
a session.  However, the browser is totally decoupled from the actual
mechanism by which these offers and answers are communicated to the
remote side, including addressing, retransmission, forking, and glare
handling.  These issues are left entirely up to the application; the
application has complete control over which offers and answers get
handed to the browser, and when.
Paragraph (version B):
JSEP does not specify a particular signaling model or state machine,
other than the generic need to exchange session descriptions in the
fashion described by RFC3264 (offer/answer) in order for both sides
of the session to know how to conduct the session.  JSEP provides
mechanisms to create offers and answers, as well as to apply them to
a session.  However, the browser is totally decoupled from the actual
mechanism by which these offers and answers are communicated to the
remote side, including addressing, retransmission, forking, and glare
handling.  These issues are left entirely up to the application; the
application has complete control over which offers and answers get
handed to the browser, and when.
Draft: draft-ietf-rtcweb-jsep

Commentary: Justin , this is n't done , but PTAL and see if you think it 's going in the right direction . 
 looks on right path to me 
 My only issue with this is what happens if you get an offer that does not do mux , I think it should be accepted regardless of what this is set to . I think this should be purely about what is generated in offer . Other than that it looks good . 
 We should discuss this on today 's call .  and I spent a while on it last time and one of the relevant arguments was consistency . Specifically , say you have two endpoints , one of which is old ( i.e. , pre - WebRTC ) and does n't support mux at all and the other of which is set to " require " , i.e. , only do mux . With the current text , any attempt between these two to communicate will fail . If you only apply these polices to the offer , however : If the old endpoint is the offerer , then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed . If the new endpoint is the offerer , then it will only provide mux candidates and the call will fail in a fairly ugly fashion . The point being that the current text allows you to fail fast . 
 lgtm 
  -f due to rebase screwup . Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set " require " . In the interest of landing the rest of this , I have an issue and an open issue section in the draft . Cullen , Justin , if this is acceptable  and I will merge this PR in . 
 This seems fine to me - good topic to discuss in Dallas , if we are still of two minds at that point . 
 can you confirm this matches your expectations ? 
 LGTM and this open issue is not a huge deal one way or the other 
 Cullen thinks it should accept and non - mux . EKR and Justin currently believe it should reject the offer . 
 Original text : when acting as answerer will reject any m= section that does not provide an " a = rtcp - mux " attribute . 
 LGTM at IETF 92 
 open issue in text to be removed
Paragraph (version A):
Any changes to the BUNDLE policy take effect immediately, i.e.
any future tracks added to the PeerConnection will have their
bundle-only state marked accordingly.
Paragraph (version B):
The BUNDLE and RTCP-multiplexing policies MUST NOT be changed
after the construction of the PeerConnection.
Paragraph (version A):
If present in the offer, an "a=rtcp-mux" line, as specified in
RFC5761, Section 5.1.1.
Paragraph (version A):
This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel.  Trickle ICE
is used in full trickle mode with a policy of max-bundle-and-rtcp-mux
and a single TURN server.  Later, two video flows, one for the
presenter and one for screen sharing, are added to the session.  This
example shows Alice's browser initiating the session to Bob's
browser.  The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server.
Draft: draft-ietf-rtcweb-jsep

Commentary: lgtm 
 lgtm
Paragraph (version A):
A null object will be returned if the local description has not yet
been established, or if the PeerConnection has been closed.
Paragraph (version B):
A null object will be returned if the local description has not yet
been established.
Paragraph (version A):
A null object will be returned if the remote description has not yet
been established, or if the PeerConnection has been closed.
Paragraph (version B):
A null object will be returned if the remote description has not yet
been established.
Draft: draft-ietf-rtcweb-jsep

Commentary: It has a new name . 
 Overall this LG , although having thought about it a bit more , .canTrickleIce seems like a not - fully - formed clause . .canTrickleIceCandidates seems like it might match better to addIceCandidate ( ) . 
 LGTM .  if you have any issues with this 
 The diff is incomprehensible due to the all the gratuitous whitespace changes . I 'll make a diff I can review at some point and see if I can figure it out . 
 LGTM 
 I will manually merge this .
Paragraph (version A):
As described in sec.ice-candidate-trickling, JSEP implementations
always provide candidates to the application individually, consistent
with what is needed for Trickle ICE.  However, applications can use
the canTrickleIce property to determine whether their peer can
actually do Trickle ICE, i.e., whether it is safe to send an initial
offer or answer followed later by candidates as they are gathered.
As "true" is the only value that definitively indicates remote
Trickle ICE support, an application which compares canTrickleIce
against "true" will by default attempt Half Trickle on initial offers
and Full Trickle on subsequent interactions with a Trickle ICE-
compatible agent.
Paragraph (version B):
As described in sec.ice-candidate-trickling, JSEP implementations
always provide candidates to the application individually, consistent
with what is needed for Trickle ICE.  However, applications can use
the canTrickleIceCandidates property to determine whether their peer
can actually do Trickle ICE, i.e., whether it is safe to send an
initial offer or answer followed later by candidates as they are
gathered.  As "true" is the only value that definitively indicates
remote Trickle ICE support, an application which compares
canTrickleIceCandidates against "true" will by default attempt Half
Trickle on initial offers and Full Trickle on subsequent interactions
with a Trickle ICE-compatible agent.
Draft: draft-ietf-rtcweb-jsep

Commentary: PTAL 
 This LGTM . Have you run it through a parser ? If not , I 'm going to give that a shot . 
 Addressed all comments , save the parser . PTAL . 
 LGTM . Fluffy ? 
 LGTM - I did not really have time to review it but again , looks close enough I 'd like to see it merged into the draft and that will make it easier to fix any nits .
Paragraph (version A):
This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel.  Trickle ICE
is used in full trickle mode with a policy of max-bundle-and-rtcpmux
and a single TURN server.  Later, two video flows, one for the
presenter and one for screen sharing, are added to the session.  This
example shows Alice's browser initiating the session to Bob's
browser.  The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server.
Paragraph (version B):
This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel.  Trickle ICE
is used in full trickle mode with a policy of max-bundle-and-rtcp-mux
and a single TURN server.  Later, two video flows, one for the
presenter and one for screen sharing, are added to the session.  This
example shows Alice's browser initiating the session to Bob's
browser.  The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server.
Draft: draft-ietf-rtcweb-jsep

Commentary: I just rewrote this . 
 Overall this LG - if you can resolve these nits tonight , great - otherwise let 's land it and clean it up later 
 I do n't think I can get to these tonight , but I may be able to get to them tomorrow AM before Cullen does . 
 lgtm
Paragraph (version A):
RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RTP
profile.
Paragraph (version B):
RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF
RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana-
registration RTP profiles.
Paragraph (version A):
Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP profile,
as specified in RFC5764, MUST be used.
Paragraph (version B):
For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/
RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of
these two profiles for each media m= line they produce in an offer.
For data m= sections, JSEP endpoints must support both the "UDP/TLS/
SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two
profiles for each data m= line they produce in an offer.  Because ICE
can select either TCP or UDP transport depending on network
conditions, both advertisements are consistent with ICE eventually
selecting either either UDP or TCP.
Paragraph (version B):
The profile in any "m=" line in any answer MUST exactly match the
profile provided in the offer.
Paragraph (version B):
For data m= sections, JSEP endpoints MUST support receiving the
"UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles.
Paragraph (version B):
To properly indicate use of DTLS, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the
default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as
specified inI-D.nandakumar-mmusic-proto-iana-registration if the
default candidate uses TCP transport.
Paragraph (version B):
The <proto> field MUST be set to exactly match the <proto> field
for the corresponding m= line in the offer.