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

Commentary: Also making the " need - ice - restart " bit get set for ANY policy change , rather than just more restrictive changes , to go along with this warning . 
 Needs merge to master 
 LGTM 
 lgtm 
 LGTM 
 If a candidate is in use and  changes such that this candidate is not longer allowed , do we have text that says to stop using that candidate and restart ice ? 
 yes , I think this is covered in the setConfiguration text . Do you want to look and see if there is anything missing ? 
 The current text says no ICE restart happens here , and it 's not clear it should , since the cat is already out of the bag .  is going to look at adding a warning mentioning this . 
 Discussed in Kirkland and we think it is simplest to trigger ICE restart regardless of which way the policy changes .
Paragraph (version A):
Any changes to the ICE candidate policy also affect the next
gathering phase.  If the policy is being made more liberal (i.e.,
more permitted candidates), and an ICE gathering phase has already
started or completed, the 'needs-ice-restart' bit will be set.  If
the policy is being made more strict, no ICE restart is needed,
and the bit will not be set.  Either way, changes to the policy
have no effect on the candidate pool, because pooled candidates
are not surfaced to the application until a gathering phase
occurs, and so any necessary filtering can still be done on any
pooled candidates.
Paragraph (version B):
Any change to the ICE candidate policy affects the next gathering
phase.  If an ICE gathering phase has already started or
completed, the 'needs-ice-restart' bit will be set.  Either way,
changes to the policy have no effect on the candidate pool,
because pooled candidates are not surfaced to the application
until a gathering phase occurs, and so any necessary filtering can
still be done on any pooled candidates.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 C. Section 3.6.1 : As an example , consider a system with a HD - capable , multiformat video decoder , where the application has constrained the received track to at most 360p . In this case , the implemention would generate this attribute : a = imageattr :* recv [ x=[16:640],y=[16:360],q=1.0 ] Maybe this example should discuss the minimal aspect of this . What it really is expressing in that it can handle any resolution between 16x16 pixels up to 640x360 as the longest in respective side . No limitations to any picture aspect ratio . That the examples expresses this is missing in the example text . 
 I think this is a realistic example , so I suggest we just add more descriptive text .
Paragraph (version B):
This declaration indicates that the receiver is capable of decoding
any image resolution from 16x16 up to 640x360 pixels.
Paragraph (version A):
This specification prescribes more specific behavior.  When a sender
of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first
check to see if the original resolution meets the criteria specified
in the attribute, and transmit it untouched if so.  If the original
resolution is too large for the attribute criteria, the sender SHOULD
apply downscaling to the output of the MediaStreamTrack in order to
satisfy the criteria.
Paragraph (version B):
This specification prescribes more specific behavior.  When a sender
of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first
check to see if the original resolution meets the criteria specified
in the attribute, and transmit it untouched if so.  Note that when
considering a MediaStreamTrack that is producing rotated video, the
unrotated resolution MUST be used.  This is required regardless of
whether the receiver supports performing receive-side rotation (e.g.,
through CVO), as it significantly simplifies the matching logic.
Paragraph (version B):
If the original resolution is too large for the attribute criteria,
the sender SHOULD apply downscaling to the output of the
MediaStreamTrack in order to satisfy the criteria.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 LGTM .
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.  The audio and video codecs that MUST be
supported 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.
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 audio and video codecs that MUST be
supported are specified in I-D.ietf-rtcweb-audio (see Section 3)
and I-D.ietf-rtcweb-video (see Section 5).
Draft: draft-ietf-rtcweb-jsep

Commentary: Here 's a first attempt at 
 Have not worked through this in detail but I do n't see any problems on initial read
Paragraph (version A):
An "a=ice-options" line with the "trickle" option MUST be added,
as specified in I-D.ietf-mmusic-trickle-ice, Section 4.
Paragraph (version B):
If the RtpTransceiver's RtpSender is active, an "a=rid" line for
each encoding specified by the application in the RtpSenders's
parameters.  If no encodings have been specified, then one RID
line is generated.  The rid line is specified in I-D.ietf-mmusic-
rid.  The direction MUST be "send".  If the application has chosen
a RID value, it MUST be used as the rid-identifier; otherwise a
RID value MUST be generated by the implementation.  When
generating RID 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-avtext-rid, Section 11.
Paragraph (version B):
For RtpTransceivers that are still present, the "a=simulcast" line
MUST stay the same.
Paragraph (version A):
The first step in generating an initial answer is to generate
session-level attributes.  The process here is identical to that
indicated in the Initial Offers section above, except that the
"a=ice-options" line, with the "trickle" option as specified in I-
D.ietf-mmusic-trickle-ice, Section 4, is only included if such an
option was present in the offer.
Paragraph (version B):
If present, any "a=rid" lines MUST be parsed as specified in I-
D.ietf-mmusic-rid, Section 10, and their values stored.
Paragraph (version B):
If present, one "a=simulcast" line MUST be parsed as specified in
I-D.ietf-mmusic-sdp-simulcast, and its values stored.  The "send"
portion of the "a=simulcast" line from a remote description MUST
be ignored, since receiving of simulcast is not supported, and any
additional "a=simulcast" line MUST be ignored.
Paragraph (version B):
All RID referenced in an "a=simulcast" line must exist as
"a=rid" lines.
Paragraph (version B):
If the directional attribute in the answer is of type
"sendrecv" or "sendonly", prepare to start transmitting media
using the specified primary SSRC and one of the selected
payload types, once the underlying transport layers have been
established.  Otherwise, stop transmitting RTP media, although
RTCP should still be sent, as described in RFC3264,
Section 5.1.  If RID values are specified, include the RID
header extension in the RTP streams, as indicated in I-D.ietf-
mmusic-rid, Section 4).  If simulcast is negotiated, send the
number of Source RTP Streams as specified in I-D.ietf-mmusic-
sdp-simulcast, Section 6.2.2.
Draft: draft-ietf-rtcweb-jsep

Commentary: Fixes warnings , and also clarifies text around when an ICE restart is needed .
Paragraph (version A):
Any changes to the STUN/TURN servers to use affect the next
gathering phase.  With the exception of the initial state where
ICE gathering has not yet occurred, the 'needs-ice-restart' bit
mentioned in sec.ice-gather-overview will be set.  This will cause
the next call to createOffer to generate new ICE credentials, for
the purpose of forcing an ICE restart and kicking off a new
gathering phase, in which the new servers will be used.  If the
ICE candidate pool has a nonzero size, any existing candidates
will be discarded, and new candidates will be gathered from the
new servers.
Paragraph (version A):
Any changes to the ICE candidate policy also affect the next
gathering phase.  If the policy is being made more liberal (i.e.,
more permitted candidates), the 'needs-ice-restart' bit will be
set.  If the policy is being made more strict, no ICE restart is
needed, and the bit will not be set.  Either way, changes to the
policy have no effect on the candidate pool, because pooled
candidates are not surfaced to the application until a gathering
phase occurs, and so any necessary filtering can still be done on
any pooled candidates.
Paragraph (version B):
Any changes to the STUN/TURN servers to use affect the next
gathering phase.  If an ICE gathering phase has already started or
completed, the 'needs-ice-restart' bit mentioned in sec.ice-
gather-overview will be set.  This will cause the next call to
createOffer to generate new ICE credentials, for the purpose of
forcing an ICE restart and kicking off a new gathering phase, in
which the new servers will be used.  If the ICE candidate pool has
a nonzero size, any existing candidates will be discarded, and new
candidates will be gathered from the new servers.
Paragraph (version B):
Any changes to the ICE candidate policy also affect the next
gathering phase.  If the policy is being made more liberal (i.e.,
more permitted candidates), and an ICE gathering phase has already
started or completed, the 'needs-ice-restart' bit will be set.  If
the policy is being made more strict, no ICE restart is needed,
and the bit will not be set.  Either way, changes to the policy
have no effect on the candidate pool, because pooled candidates
are not surfaced to the application until a gathering phase
occurs, and so any necessary filtering can still be done on any
pooled candidates.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 lgtm 
 From " public " is probably something the browser should control , not the application . " none " was previously removed , but apparently  has implemented it . 
 Keep in mind that anything less than all means that mobile apps will work better than   . Public tries to just reveal what is already revealed simply by browsing the web with no webrtc . 
 Right , but that 's what " all " does when the browser is configured as recommended by draft - rtcweb - shieh - ip - handling . It 's not clear why a " public " mode also needs to exist ; the point of this draft is to protect the user from the application , so we ca n't really give the app the ability to choose whether it wants non - public addresses . I think the real remaining question is whether " none " is worth keeping . 
 I think the motivation for " none " was a lot stronger when we had automatic gathering prior to setLD ( ) in some situations . Now , it seems like you can just get the same effect by deferring setLD ( ) . I agree that " public " is silly .
Paragraph (version A):
All candidates will be gathered and used.
Paragraph (version A):
Candidates with private IP addresses [RFC1918] will be filtered
out.  This prevents exposure of internal network details, at the
cost of requiring relay usage even for intranet calls, if the NAT
does not allow hairpinning as described in [RFC4787], section 6.
Paragraph (version B):
All candidates permitted by browser policy will be gathered and
used.
Paragraph (version A):
The default ICE candidate policy MUST be set to allow all candidates,
as this is generally the desired policy, and also typically reduces
use of application TURN server resources significantly.
Paragraph (version B):
The default ICE candidate policy MUST be set to "all" as this is
generally the desired policy, and also typically reduces use of
application TURN server resources significantly.
Draft: draft-ietf-rtcweb-jsep

Commentary: Not sure if this is done but what is there LGTM 
 Yes , I think this is complete . 
 LGTM 
 talks about browser local policy . It should make this more concrete by referring to as the source of this policy . 
 Do you see it as normatively depending on that or more just " useful implementor advice can be found in ... " 
 I guess it depends on what we think the purpose of the ip - handling draft is . If we think all browsers should implement this , then it should be a normative dependency . I 'll make a PR as such and we can debate the details there . 
 I think if it is something all browser need to implement , then we probably just want to move the normative text into this draft . 
 I think there is enough text that it warrants being in its own document .
Paragraph (version A):
are used in a session.  In addition, administrators may also wish to
control the set of ICE candidates, and so the browser SHOULD also
allow control via local policy, with the most restrictive policy
prevailing.
Paragraph (version B):
are used in a session.  Note that this filtering is applied on top of
any restrictions the browser chooses to enforce regarding which IP
addresses are permitted for the application, as discussed in I-
D.shieh-rtcweb-ip-handling.
Paragraph (version A):
Although it can be overridden by local policy, the default ICE
candidate policy MUST be set to allow all candidates, as this
minimizes use of application STUN/TURN server resources.
Paragraph (version B):
The default ICE candidate policy MUST be set to allow all candidates,
as this is generally the desired policy, and also typically reduces
use of application TURN server resources significantly.
Draft: draft-ietf-rtcweb-jsep

Commentary: This 
 Thanks for doing this . A few minor comments . 
 All your comments make sense - I 'll update this next week to reflect that and leave the mapping as a TODO . 
 LGTM . I have n't double - checked all the references are right . Suggest we outsource to  . 
 LGTM with minor comment 
 If you do n't have active work going on this one , I could do a PR for this ... 
 Resolved by
Paragraph (version A):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=ice-options", "a=fingerprint", and "a=setup" lines MUST be
included as mentioned above, along with an "a=fmtp:webrtc-
datachannel" line and an "a=sctp-port" line referencing the SCTP port
number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1.
Paragraph (version B):
The first step in generating an initial answer is to generate
session-level attributes.  The process here is identical to that
indicated in the Initial Offers section above, except that the
"a=ice-options" line, with the "trickle" option, as specified in I-
D.ietf-mmusic-trickle-ice, Section 4 is only included if such an
option was present in the offer.
Paragraph (version A):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines
MUST be included as mentioned above, along with an "a=fmtp:webrtc-
datachannel" line and an "a=sctp-port" line referencing the SCTP port
number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1.
Paragraph (version A):
For each specified payload type, establish a mapping between
the payload type ID and the actual media format.  [TODO: ref]
If any indicated payload type is unknown, this MUST result in
an error.
Paragraph (version A):
If the description is of type "offer", and the ICE ufrag or
password changed from the previous remote description, [TODO:
ref], mark that an ICE restart is needed.
Paragraph (version A):
Pair any supplied ICE candidates with any gathered local
candidates, as described in [TODO: ref] and start connectivity
checks with the appropriate credentials.
Paragraph (version B):
Pair any supplied ICE candidates with any gathered local
candidates, as described in Section 5.7 of RFC5245 and start
connectivity checks with the appropriate credentials.
Paragraph (version B):
If the answer contains valid BUNDLE groups, discard any ICE
components for the m= sections that will be bundled onto the primary
ICE components in each BUNDLE, and begin muxing these m= sections
accordingly, as described in I-D.ietf-mmusic-sdp-bundle-negotiation,
Section 8.2.
Draft: draft-ietf-rtcweb-jsep

Commentary: It goes something like and so on . But it is not clear if the answer can contain an line if there was none in the offer . 
 Quoth RFC 5888 : Mid Value in Answers The " mid " attribute is an identifier for a particular media stream . Therefore , the " mid " value in the offer MUST be the same as the " mid " value in the answer . Besides , subsequent offers ( e.g. , in a re - INVITE ) SHOULD use the same " mid " value for the already existing media streams . So the answer seems to be " no " 
 Given the quote from 5888 , is it fair to conclude that should be resolved with " null " for the mid property on the transceiver if there has been no mid in the SDP ? .mid was just an example , the same text is present for e.g. rtcp - mux , ice - option : trickle , rtcp - size .
Paragraph (version A):
If present in the offer, an "a=mid" line, as specified in RFC5888,
Section 9.1.  The "mid" value MUST match that specified in the
offer.
Paragraph (version B):
If and only if present in the offer, an "a=mid" line, as specified
in RFC5888, Section 9.1.  The "mid" value MUST match that
specified in the offer.
Draft: draft-ietf-rtcweb-jsep

Commentary: lgtm 
 LGTM
Paragraph (version B):
The contents of BUNDLE groups, bundle-only parameters, or "a=rtcp-
mux" parameters.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM with the change indicated above . 
 I rearranged the text a bit to make the policy concept more clear . PTAL . 
 LGTM 
 LGTM 
 For example , some decoders may have min limits , expressed in imageattr . By default , upscaling can be used for this , but there should be some control to turn this off ( e.g. do n't want to send " HD " video that is just upscaled to HD ) 
 Thoughts on if default should be upscale is allowed or not allowed ? 
 Generally it seems like a bad practice so I would default to not .
Paragraph (version A):
This specification prescribes more specific behavior.  When a sender
of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST first
check to see if the original resolution meets the criteria specified
in the attribute, and transmit it untouched if so.  If the original
resolution is too large for the attribute criteria, the sender SHOULD
apply downscaling to the output of the MediaStreamTrack in order to
satisfy the criteria.  In rare cases, where a receiver requires a
minimum resolution which is greater than the native resolution of the
video, the sender SHOULD apply upscaling in order to provide that
resolution.  The sender SHOULD NOT apply upscaling in any other
cases.
Paragraph (version A):
If there is no appropriate scaling mechanism that allows the received
criteria to be satisfied, the sender MUST NOT transmit the track.
Draft: draft-ietf-rtcweb-jsep

Commentary: Did not carefully review but looks fine to me 
 lgtm 
 Section 5.2.1 Within the data m= section , the " a = mid " , " a = ice - ufrag " , " a = ice- passwd " , " a = ice - options " , " a = candidate " , " a = fingerprint " , and " a = setup " lines MUST be included as mentioned above , along with an " a = sctpmap " line referencing the SCTP port number and specifying the application protocol indicated in [ I - D.ietf - rtcweb - data - protocol ] . [ OPEN ISSUE : the -01 of this document is missing this information . ] 
 According to -07 , a = sctpmap is no more , and replaced with a = fmtp , plus a = sctp - port . We still need to reference the appropriate string for the m= line .
Paragraph (version B):
Lastly, if a data channel has been created, a m= section MUST be
generated for data.  The <media> field MUST be set to "application"
and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default
candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt"
value MUST be set to "webrtc-datachannel" as specified in I-D.ietf-
mmusic-sctp-sdp, Section 4.1.
Paragraph (version B):
If a data channel m= section has been offered, a m= section MUST also
be generated for data.  The <media> field MUST be set to
"application" and the <proto> and "fmt" fields MUST be set to exactly
match the fields in the offer.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 lgtm 
 In ' certificates ' is a set , and the PeerConnection selects which certificate to use . The SDP should have one ' a = fingerprint ' line per certificate , and that is not reflected in the JSEP draft AFAICU . 
 Prague : One a = fingerprint line per cert , but we can go down to a single cert one DTLS has been established . The DTLS cert has to match one of the supplied a = fingerprints . ( correct as necessary ) 
 PR for allowing multiples . Processing rules go in the TBD applying section
Paragraph (version A):
Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no
effect; support for DTLS-SRTP is determined by the presence of the
"a=fingerprint" attribute.  Note that lack of an "a=fingerprint"
attribute will lead to negotiation failure.
Paragraph (version B):
Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no
effect; support for DTLS-SRTP is determined by the presence of one
or more "a=fingerprint" attribute.  Note that lack of an
"a=fingerprint" attribute will lead to negotiation failure.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 lgtm 
 The question has come up about what the default candidate should be set to during trickle ICE but after at least one candidate has been gathered so at least in principle you could set c= to one of those candidates . See also ; 
 Want to pick a solution that works even if we we do continous trickle and ice does not finish . 
  on today 's call is : Before ICE is completed , follow the 5245 guidance and pick the " best " candidate . Once ICE is completed , pick whatever you are actually using . 
 If we move to a mode where ICE never completes , perhaps use the active pair . 
 It turns out that this was pretty clear already . I have made it slightly clearer .
Paragraph (version A):
Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as
described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line
MUST also be filled in with the port and address of the
appropriate default candidate, either the default RTP or RTCP
candidate, depending on whether RTCP multiplexing is currently
active or not.  Note that if RTCP multiplexing is being offered,
but not yet active, the default RTCP candidate MUST be used, as
indicated in RFC5761, section 5.1.3.  In each case, if no
candidates of the desired type have yet been gathered, dummy
values MUST be used, as described above.
Paragraph (version B):
Each "m=" and c=" line MUST be filled in with the port, protocol,
and address of the default candidate for the m= section, as
described in RFC5245, Section 4.3.  If ICE checking has already
completed for one or more candidate pairs and a candidate pair is
in active use, then that pair MUST be used, even if ICE has not
yet completed.  Note that this differs from the guidance in
RFC5245, Section 9.1.2.2, which only refers to offers created when
ICE has completed.  Each "a=rtcp" attribute line MUST also be
filled in with the port and address of the appropriate default
candidate, either the default RTP or RTCP candidate, depending on
whether RTCP multiplexing is currently active or not.  Note that
if RTCP multiplexing is being offered, but not yet active, the
default RTCP candidate MUST be used, as indicated in RFC5761,
section 5.1.3.  In each case, if no candidates of the desired type
have yet been gathered, dummy values MUST be used, as described
above.