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

Commentary: Addressing . 
 LGTM modulo the change below .
Paragraph (version A):
When RFC8829 was published, inconsistencies regarding BUNDLE RFC9143
operation were identified with regard to both the specification text
as well as implementation behavior.  The former concern was addressed
via an update to RFC9143.  For the latter concern, it was observed
that some implementations implemented the "max-bundle" bundle policy
defined in RFC8829 by assuming that bundling had already been
negotiated, rather than marking "m=" sections as bundle-only as
indicated by the specification.  In order to prevent unexpected
changes to applications relying on the pre-standard behavior, the
decision was made to deprecate "max-bundle" and instead introduce an
identically defined "must-bundle" policy that, when selected,
provides the behavior originally specified by RFC8829.
Paragraph (version B):
When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843
operation were identified with regard to both the specification text
as well as implementation behavior.  The former concern was addressed
via an update to BUNDLE (see RFC9143).  For the latter concern, it
was observed that some implementations implemented the "max-bundle"
bundle policy defined in RFC8829 by assuming that bundling had
already been negotiated, rather than marking "m=" sections as bundle-
only as indicated by the BUNDLE specification.  In order to prevent
unexpected changes to applications relying on the pre-standard
behavior, the decision was made to deprecate "max-bundle" and instead
introduce an identically defined "must-bundle" policy that, when
selected, provides the behavior originally specified by RFC8829.
Draft: draft-ietf-rtcweb-jsep

Commentary: This includes the changes requested at IETF 111 ( summarized in ) , which are : modified text in S 1.3 ( requested by to spell out that " must - bundle " is the behavior formerly known as "  - bundle " brief discussion of interaction of BUNDLE and TPCC ( requested by 
 FYI 
 LGTM . 
 Should we add a reference to rfc8843bis ? The rest looks good . 
 LGTMLGTM
Paragraph (version A):
When [RFC8829] was published, an inconsistency regarding BUNDLE
RFC8843 operation was identified concerning both the specification
text as well as implementation behavior.  The former concern was
addressed via an update to RFC8843.  For the latter concern, it was
observed that some implementations implemented the "max-bundle"
bundle policy by assuming that bundling had already been negotiated,
rather than marking "m=" sections as bundle-only as indicated by
RFC8829.  In order to prevent unexpected changes to applications
relying on the pre-standard behavior, the decision was made to
deprecate the use of "max-bundle" and instead introduce a new "must-
bundle" policy that, when selected, provides the correct behavior.
Paragraph (version B):
When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843
operation were identified with regard to both the specification text
as well as implementation behavior.  The former concern was addressed
via an update to RFC8843.  For the latter concern, it was observed
that some implementations implemented the "max-bundle" bundle policy
defined in RFC8829 by assuming that bundling had already been
negotiated, rather than marking "m=" sections as bundle-only as
indicated by the specification.  In order to prevent unexpected
changes to applications relying on the pre-standard behavior, the
decision was made to deprecate "max-bundle" and instead introduce an
identically defined "must-bundle" policy that, when selected,
provides the behavior originally specified by RFC8829.
Paragraph (version B):
Note that if bundling has been negotiated, unbundling is no longer
possible, and media sections will not be marked as bundle-only.  This
is by design, but could cause issues in the rare case of sending a
subsequent offer as an initial offer to a non-bundle-aware endpoint
via Third Party Call Control (3PCC).
Draft: draft-ietf-rtcweb-jsep

Commentary: Updated text with RFC Editor version , approving
Paragraph (version B):
Since the approval of the WebRTC specification documents, the IETF
has become aware of an inconsistency between the document specifying
JSEP and the document specifying BUNDLE (this RFC and RFC8843,
respectively).  Rather than delaying publication further to come to a
resolution, the documents are be ing published as they were
originally approved.  The IETF intends to restart wor k on these
technologies, and revised versions of these documents will be publish
ed as soon as a resolution becomes available.
Draft: draft-ietf-rtcweb-jsep

Commentary: is supplied to the ICE agent . In the case of a new remote candidate , connectivity checks will be sent to the new candidate . However , if you do this prior to setLD ( ) this will not cause connectivity checks to be sent , right ? 
 That is correct . 
 Do you think we should change the text to say that ? Perhaps " In the case of a new remote candidate , connectivity checks will be sent to the new candidate as soon as setLD(answer ) is called , or immediately if it has been called already . " 
 Something like that seems like a good idea . It wo n't always be setLD with an answer though . 
 maybe just add " , assuming setLocalDescription has already been called to initialize the ICE gathering process . "
Paragraph (version A):
Otherwise, the new remote candidate or end-of-candidates indication
is supplied to the ICE agent.  In the case of a new remote candidate,
connectivity checks will be sent to the new candidate.
Paragraph (version B):
Otherwise, the new remote candidate or end-of-candidates indication
is supplied to the ICE agent.  In the case of a new remote candidate,
connectivity checks will be sent to the new candidate, assuming
setLocalDescription has already been called to initialize the ICE
gathering process.
Draft: draft-ietf-rtcweb-jsep

Commentary: This also adds in a sentence about using the MID header extension in outgoing streams , which was previously omitted despite there being a corresponding sentence for incoming streams . 
 The comment " [ rfced ] Please let us know if any changes are needed for the ... " should also be removed . 
 AUTH48 on this document started with sixty [ rfced ] questions sent to the authors ( 2020 July 7 . These questions were as GitHub issues through . Follow on issues were created ( in particular , splitting issues and ) to isolate some of the questions and to review normative text ( ) . When PR is merged , all AUTH48 [ rfced ] questions will have been addressed , but there are some remaining XML comments that need to be removed . 
 This is sort of nuts but LGTM
Paragraph (version A):
When using JSEP to transmit multiple encodings from an RtpSender, the
techniques from RFC8853 and RFC8851 are used.  Specifically, when
multiple encodings have been configured for an RtpSender, the "m="
section for the RtpSender will include an "a=simulcast" attribute, as
defined in RFC8853, with a "send" simulcast stream description that
lists each desired encoding, and no "recv" simulcast stream
description.  The "m=" section will also include an "a=rid" attribute
for each encoding, as specified in RFC8851; the use of Restriction
Identifiers (RIDs) allows the individual encodings to be
disambiguated even though they are all part of the same "m=" section.
Paragraph (version B):
When using JSEP to transmit multiple encodings from an RtpSender, the
techniques from RFC8853 and RFC8851 are used.  Specifically, when
multiple encodings have been configured for an RtpSender, the "m="
section for the RtpSender will include an "a=simulcast" attribute, as
defined in RFC8853, with a "send" simulcast stream description that
lists each desired encoding, and no "recv" simulcast stream
description.  The "m=" section will also include an "a=rid" attribute
for each encoding, as specified in RFC8851; the use of Restriction
Identifiers (RIDs, also called rid-ids or RtpStreamIds) allows the
individual encodings to be disambiguated even though they are all
part of the same "m=" section.
Paragraph (version A):
Once the proper "m=" section or sections are known, RTP/RTCP is
delivered to the RtpTransceiver(s) associated with the "m="
section(s) and further processing of the RTP/RTCP is done at the
RtpTransceiver level.  This includes using RID RFC8851 to distinguish
between multiple encoded streams, as well as to determine which
Source RTP stream should be repaired by a given redundancy RTP
stream.
Paragraph (version B):
Once the proper "m=" section or sections are known, RTP/RTCP is
delivered to the RtpTransceiver(s) associated with the "m="
section(s) and further processing of the RTP/RTCP is done at the
RtpTransceiver level.  This includes using the RID mechanism RFC8851
and its associated RtpStreamId and RepairedRtpStreamId identifiers to
distinguish between multiple encoded streams and determine which
Source RTP stream should be repaired by a given redundancy RTP
stream.
Draft: draft-ietf-rtcweb-jsep

Commentary: The following changes have been made : changed to " set to zero " from " set to 0 " , removed comment . formatted media - field subfields consistently , removed comment . 
 fmt value / " fmt " value  : Would we also do media , port , and proto ? This one needs more discusison . 
 RFC 4566 ( SDP ) was inconsistent in the formatting of fmt ( , " fmt " ) , proto ( " proto " , ) , and port ( port , ) . For the most part , media was just formatted media . RFC 8866 ( SDP ) , which obsoletes RFC 4566 , consistently formats these " m= " line subfields as , , , and . This document uses the following formats : fmt ( 3 instances ) vs ( 2 instances ) proto ( 7 instances ) vs ( 5 instances ) port ( 31 ) vs ( 0 instances ) -- most are not referring specifically to the subfield , though I suggest using angle brackets ( but not formatting -- I was just working around GitHub 's markdown with that ) for these terms when discussing " m= " line subfields . 
 SGTM , let 's align with 8866 usage when an instance of these words refers specifically to a m= line subfield . 
 set to zero / set to 0 ( May we use the latter , because of ' " dummy " port value of 9 ' in Sections 5.2.1 and 5.3.1 ? )  : What 's the IETF style guide say on this sort of thing ? ' zero ' looks more natural to me , and matches RFC 3264 's usage of ' zero ' . 
 From our style guide : " In general text , we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits . However , if a value is followed by a unit of measure ( e.g. , 8 bytes , 3 octets ) , it should be in digit form regardless of value . " There is one instance of " set to 0 " in this document vs four instances of " set to zero " . I can change that one instance to match the other four . 
 LGTM
Paragraph (version A):
The "m=" line itself MUST be parsed as described in RFC4566, and the
media, port, proto, and fmt values stored.
Paragraph (version B):
The "m=" line itself MUST be parsed as described in RFC4566, and the
<media>, <port>, <proto>, and <fmt> values stored.
Draft: draft-ietf-rtcweb-jsep

Commentary: clarified that there are four conditions , removed comment . issue 14 
 14 ) [ rfced ] Sections 4.1.9 and 4.1.10 : We had trouble following the purpose of all of the " and"s in these sentences . Are four conditions set in these sentences , or fewer ? Original : 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 is available to send , this will result in the starting of media transmission . ... 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 is available to send , this will result in the starting of media transmission . Possibly : If ( 1 ) setRemoteDescription was previously called with an offer , ( 2 ) setLocalDescription is called with an answer ( provisional or final ) , ( 3 ) the media directions are compatible , and ( 4 ) media is available to send , media transmission can start . ... If ( 1 ) setLocalDescription was previously called with an offer , ( 2 ) setRemoteDescription is called with an answer ( provisional or final ) , ( 3 ) the media directions are compatible , and ( 4 ) media is available to send , media transmission can start . 
 need to keep ' this will result in the starting of media transmission ' 
 There are 4 conditions that have to be satisfied , as noted .
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 is available to
send, this will result in the starting of media transmission.
Paragraph (version B):
If (1) setRemoteDescription was previously called with an offer, (2)
setLocalDescription is called with an answer (provisional or final),
(3) the media directions are compatible, and (4) media is available
to send, this will result in the starting of media transmission.
Paragraph (version A):
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 is available to
send, this will result in the starting of media transmission.
Paragraph (version B):
If (1) setLocalDescription was previously called with an offer, (2)
setRemoteDescription is called with an answer (provisional or final),
(3) the media directions are compatible, and (4) media is available
to send, this will result in the starting of media transmission.
Draft: draft-ietf-rtcweb-jsep

Commentary: used suggestion 2 , deleted comments , issue 12 
 12 ) [ rfced ] Section 4.1.8.1 : We had trouble with this sentence . If neither suggestion below is correct , please clarify . Original : While this could also be done with a " sendonly " pranswer , followed by a " sendrecv " answer , the initial pranswer leaves the offer - answer exchange open , which means that the caller can not send an updated offer during this time . Suggestion : While this could also be done with a " sendonly " pranswer , if followed by a " sendrecv " answer the initial pranswer leaves the offer / answer exchange open , which means that the caller can not send an updated offer during this time . Suggestion : While this could also be done with a " sendonly " pranswer followed by a " sendrecv " answer , the initial pranswer leaves the offer / answer exchange open , which means that the caller can not send an updated offer during this time . 
 suggestion seems right
Paragraph (version A):
this could also be done with a "sendonly" pranswer, followed by a
"sendrecv" answer, the initial pranswer leaves the offer/answer
exchange open, which means that the caller cannot send an updated
offer during this time.
Paragraph (version B):
this could also be done with a "sendonly" pranswer followed by a
"sendrecv" answer, the initial pranswer leaves the offer/answer
exchange open, which means that the caller cannot send an updated
offer during this time.
Draft: draft-ietf-rtcweb-jsep

Commentary: use ' prepares to gather ' instead of ' goes to gather ' , removed comments , issue 9 
 9 ) [ rfced ] We suggest clarifying " goes to gather " - perhaps " gathers " , " starts to gather " , " prepares to gather " , etc . " goes to gather " may be confusing for some readers . Original : When setLocalDescription is eventually called , and the JSEP implementation goes to gather the needed ICE candidates , it SHOULD start by checking if any candidates are available in the pool . 
 ' prepares to gather ' seems like the right choice . 
 please close this issue once you consider it resolved .
Paragraph (version A):
When setLocalDescription is eventually called and the JSEP
implementation goes to gather the needed ICE candidates, it SHOULD
start by checking if any candidates are available in the pool.  If
there are candidates in the pool, they SHOULD be handed to the
application immediately via the ICE candidate event.  If the pool
becomes depleted, either because a larger-than-expected number of ICE
components are used or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
This only occurs for the first offer/answer exchange, after which the
candidate pool is emptied and no longer used.
Paragraph (version B):
When setLocalDescription is eventually called and the JSEP
implementation prepares to gather the needed ICE candidates, it
SHOULD start by checking if any candidates are available in the pool.
If there are candidates in the pool, they SHOULD be handed to the
application immediately via the ICE candidate event.  If the pool
becomes depleted, either because a larger-than-expected number of ICE
components are used or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
This only occurs for the first offer/answer exchange, after which the
candidate pool is emptied and no longer used.
Draft: draft-ietf-rtcweb-jsep

Commentary: clarified TLS fingerprints , removed comments , issue 7 
 7 ) [ rfced ] Section 3.2 : We do not see any mention of DTLS in RFC 8122 ; we only see " TLS . " Will this citation be clear to readers ? Original : An example of such a parameter is the DTLS fingerprints [ RFC8122 ] , which are calculated based on the local certificate(s ) offered , and are not subject to negotiation . Possibly : An example of such a parameter is the TLS fingerprints [ RFC8122 ] as used in the context of DTLS [ RFC6347 ] ; these fingerprints are calculated based on the local certificate(s ) offered and are not subject to negotiation . 
 Comment is correct , suggestion seems reasonable . 
 please close this issue once you consider it resolved .
Paragraph (version A):
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; some parameters are
declarative, and the remote side MUST either accept them or reject
them altogether.  An example of such a parameter is the DTLS
fingerprints RFC8122, which are calculated based on the local
certificate(s) offered and are not subject to negotiation.
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; some parameters are
declarative, and the remote side MUST either accept them or reject
them altogether.  An example of such a parameter is the TLS
fingerprints RFC8122 as used in the context of DTLS RFC6347; these
fingerprints are calculated based on the local certificate(s) offered
and are not subject to negotiation.
Draft: draft-ietf-rtcweb-jsep

Commentary: If an answerer rejects the " offerer tagged " m= section ( the one listed first in " a = group : BUNDLE " ) , the BUNDLE spec requires rejecting all m= sections in the BUNDLE group . This means that stopping one transceiver between setting an offer and creating an answer may potentially cause multiple m= sections to be rejected . See :
Paragraph (version B):
This m= section is in a bundle group, and the group's offerer
tagged m= section is being rejected due to one of the above
reasons.  This requires all m= sections in the bundle group to be
rejected, as specified in I-D.ietf-mmusic-sdp-bundle-negotiation,
Section 7.3.3.
Draft: draft-ietf-rtcweb-jsep

Commentary: I 'm sure the RFC editor would have caught this nit : While formally the JSEP interface is an API , it is better to think of it is an Internet protocol s / is an Internet / as an Internet/
Paragraph (version A):
While formally the JSEP interface is an API, it is better to think of
it is an Internet protocol, with the application JavaScript being
untrustworthy from the perspective of the JSEP implementation.  Thus,
the threat model of RFC3552 applies.  In particular, JavaScript 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(), there is no guarantee that applications do so.
The JSEP implementation MUST be prepared for the JavaScript to pass
in bogus data instead.
Paragraph (version B):
While formally the JSEP interface is an API, it is better to think of
it as an Internet protocol, with the application JavaScript being
untrustworthy from the perspective of the JSEP implementation.  Thus,
the threat model of RFC3552 applies.  In particular, JavaScript 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(), there is no guarantee that applications do so.
The JSEP implementation MUST be prepared for the JavaScript to pass
in bogus data instead.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM . 
 In spite of what was said at the W3C WebRTC WG virtual meeting yesterday I think the aspect ratio preservation can be an issue also in context of . Just to take as example that the video resolution of the track is 595 by 753 ( e.g. capturing a part of the screen ) and has limited what can be transmitted to 480 by 640 . Scaling according to JSEP section 3.6 ( if I read right ) gives a transmission resolution of 480 by 607.4621 .. but since we ca n't transmit fractional pixels we would transmit 480 by 607 and have a slight aspect ratio mismatch . The spec should clarify what to do in situations like this . 
 OK , perhaps then we change this text : the encoder SHOULD apply downscaling in order to satisfy the limits , although the downscaling MUST NOT change the picture aspect ratio of the encoding . to allow for rounding . 
 Makes sense to me . 
 LGTM
Paragraph (version A):
If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits, although the downscaling MUST NOT change the
picture aspect ratio of the encoding.  For example, if the encoder
resolution is 1280x720, and the attribute specified a maximum of
640x480, the expected output resolution would be 640x360.  If
downscaling cannot be applied, the attribute MUST NOT be used.
Paragraph (version B):
If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits.  Downscaling MUST NOT change the picture
aspect ratio of the encoding, ignoring any trivial differences due
to rounding.  For example, if the encoder resolution is 1280x720,
and the attribute specified a maximum of 640x480, the expected
output resolution would be 640x360.  If downscaling cannot be
applied, the attribute MUST NOT be used.