jiebi/TextFlow huggingface dataset:
Original text:
identical.  This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed.  Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

Reviewer comments:
I did add a MUST here, but I think it's just a restatement of what is already true.
BLOCKER: Several of the SDP-building procedures in this document call out addition of "a=fingerprint" to individual media sections, while the canonical definition of "a=fingerprint" allows these to be added at either the session level or the media level. The same is true of ice-pwd and ice-ufrag. While the process of SDP building in this document appears to be prescriptive on purpose, one assumes that it is allowed some variation so as to accommodate deployment of future SDP extensions. Because of this state of affairs, it is unclear whether implementations that consolidate these attributes at the session level when they would otherwise be identical among all media sections is such an allowable variation. Ambiguity in specifications is never a good thing, so I believe that the draft needs to do one of: (a) specifically call out this kind of aggregation as allowed; (b) specifically call out this kind of aggregation as disallowed; or (c) include a blanket statement that implementations are allowed to emit SDP that is semantically equivalent to that which is generated by the procedures in this document, but which may vary in exact structure. I have a strong preference for (c) -- implementations will be required to deal with such variations anyway to interop with legacy SDP, so prohibiting JSEP clients from generating them serves no goal.
My suggestion would be to expand the para below to say (a), i.e. that applications that wish to aggregate may do so, even though we recommend not aggregating. 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.
(and also fine with suggestions Justin is suggesting)

Revised text:
identical.  This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed. <ins> However, implementations MAY choose to aggregate attributes at the session level and JSEP implementations MUST be prepared to receive attributes in either location. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically
Original text:
section if its mid property is non-null; otherwise it is said to be disassociated.  The associated m= section is determined using a mapping between transceivers and m= section indices, formed when <del> creating an offer or applying a remote offer.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </del>  RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds

Reviewer comments:
PTAL
Section 3.5.1 talks about a "recycled m= section" without any context for what this means. Please provide a forward reference to the section that discusses m= section recycling.
is where m= section recycling is first defined, but it's as a bullet point in how to generate an offer, which makes a direct reference problematic. I guess we could say "as spelled out in [ref]"

Revised text:
section if its mid property is non-null; otherwise it is said to be disassociated.  The associated m= section is determined using a mapping between transceivers and m= section indices, formed when  <ins> creating an offer or applying a remote offer. An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver.  However, in certain cases where a m= section has been rejected, as discussed in sec.subsequent-offers below, that m= section will be "recycled" and associated with a new RtpTransceiver with a new mid value. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds
Original text:
descriptions to the API, the API would produce and consume messages from this protocol.  While providing a more high-level API, this put more control of signaling within the JSEP implementation, forcing it <del> to have to understand and handle concepts like signaling glare.  In addition, it prevented the application from driving the state machine to a desired state, as is needed in the page reload case. </del>  A second approach that was considered but not chosen was to decouple the management of the media control objects from session

Reviewer comments:
NAME done. NAME still waiting for you.
Section 1.2 uses the term "glare" without describing it. This term may be unfamiliar to readers, and should be explained or cited.
Agreed.
See URL for a definition.
LGTM, but see comment

Revised text:
descriptions to the API, the API would produce and consume messages from this protocol.  While providing a more high-level API, this put more control of signaling within the JSEP implementation, forcing it  <ins> to have to understand and handle concepts like signaling glare (see RFC3264, Section 4). </ins> A second approach that was considered but not chosen was to decouple the management of the media control objects from session
Original text:
of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to <del> Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  Both Alice and Bob are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </del>  The SDP for |offer-A1| looks like:

Reviewer comments:
I think I got all the things Justin mentioned.
Will take a final look once Eric's comments are resolved.
Made a slight change to one sentence to mention user agents. PTAL.
For the examples, please expand the acronyms "JS" and "UA".
I think we're going to want to do it once.
I think I want to define some of theses instead of replace all of them because we can't stay in the column limit if they are expanded.

Revised text:
of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to  <ins> Bob's endpoint.  The messages from the Javascript application in Alice's browser to the Javascript in Bob's browser, abbreviated as AliceJS and BobJS respectively, are assumed to flow over some signaling protocol via a web server.  The Javascript on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  The user agents (JSEP implementations) in Alice and Bob's browsers, abbreviated as AliceUA and BobUA respectively, are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </ins> The SDP for |offer-A1| looks like:
Original text:
MUST occur in a specific order, and with a specific syntax, as defined in RFC4566, Section 5.  Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the <del> same type (typically "a=") can occur in any order, and their ordering is not meaningful. </del>  The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked.

Reviewer comments:
BLOCKER: Section 5.7.1, first paragraph: this claims that a= lines are order insensitive. Nothing in SDP's base definition makes this true, and nothing precludes specific attributes from assigning meaning to the order in which they appear. See draft-ietf-slim-negotiating-human-language-08 for an example of an SDP extension that does apply meaning to the order in which attributes appear (for better or worse).
Section Session-Level Parsing Text is First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as defined in [RFC4566], Section 5. Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the same type (typically "a=") can occur in any order, and their ordering is not meaningful. Remove the text "and their ordering is not meaningful." from above para
FWIW ... some of SDP implementations I work with save a lines in non ordered sets and I never knew this was a bug. Bummer
Agree with proposal.
LGTM

Revised text:
MUST occur in a specific order, and with a specific syntax, as defined in RFC4566, Section 5.  Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the  <ins> same type (typically "a=") can occur in any order. </ins> The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked.
Original text:
generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: </del>  <del> Any profile in the offer matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP|TCP)/TLS/RTP/SAVP[F]". </del>  The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.

Reviewer comments:
BLOCKER: The first bullet on page 35 has a normative statement about the AVT profile strings that must be accepted, but uses an unspecified grammar to actually specify the string. If this is normative, it needs to be formal. Either specify the string using a formal and cited grammar, or provide an exhaustive list.
Proposal on editor's call is to use POSIX extended regular expressions. URL I believe this would give us the expressions. (UDP|TCP)/TLS/RTP/SAVPF? and: RTP/S?AVPF?
You're sure you want to pull in another reference for regexes instead of just listing all eight valid values?

Revised text:
generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its  <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: </ins>  <ins> Any profile in the offer matching one of the following MUST be accepted: "RTP/AVP" "RTP/AVPF" "RTP/SAVP" "RTP/SAVPF" "UDP/TLS/RTP/AVP" "UDP/TLS/RTP/AVPF" "UDP/TLS/RTP/SAVP" "UDP/TLS/RTP/SAVPF" "TCP/TLS/RTP/SAVP" "TCP/TLS/RTP/SAVPF" </ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.
Original text:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC8122, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Reviewer comments:
certificate. This was updated in RFC 8122.
NAME PTAL
NAME PTAL
Section 5.2.1 (creating an offer) still has this paragraph: In RFC4572-update, this requirement doesn't exist. So should this be changed to reference RFC4572-update, removing the second half of this paragraph?
Related webrtc-pc issue: URL

Revised text:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  <ins> For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in RFC8122, Section 5. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
Original text:
defined in I-D.ietf-ice-trickle, Section 5.1. I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into <del> different categories.  To avoid unnecessary duplication when bundling I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1, specifies that attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </del>  The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:

Reviewer comments:
I like the text in your comment and changed to that.
Worth taking an editorial pass over this if time permits
I prob have time to run this one down.

Revised text:
defined in I-D.ietf-ice-trickle, Section 5.1. I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into  <ins> different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, as specified in I-D.ietf-mmusic-sdp- bundle-negotiation, Section 8.1.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:
Original text:
appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired. For example, when using the Opus codec, the "usedtx=0" parameter <del> would be specified in the offer. Note that setting the "VoiceActivityDetection" parameter when generating an offer is a request to receive audio with silence suppression.  It has no impact on whether the local endpoint does silence suppression for the audio it sends. </del>  The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN <del> codecs and "usedtx=0"). </del>  5.4.

Reviewer comments:
LGTM
I am going to land this and then make a followup PR for S 5.9.
You'll also need to update S 5.9 to ensure CN is only enabled when support is bilateral: For each specified "CN" media format, enable DTX for all supported media formats with the same clockrate, as described in [RFC3389], Section 5, except for formats that have their own internal DTX mechanisms. DTX for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2.

Revised text:
appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired. For example, when using the Opus codec, the "usedtx=0" parameter  <ins> would be specified in the offer.  In addition, the implementation MUST NOT use silence suppression for media it generates, regardless of whether the "CN" codecs or related fmtp parameters appear in the peer's description.  The impact of these rules is that silence suppression in JSEP depends on mutual agreement of both sides, which ensures consistent handling regardless of which codec is used. </ins> The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN  <ins> codecs and "usedtx=0").  The impact of this rule is that an answerer will not try to use silence suppression with any endpoint that does not offer it, making silence suppression support bilateral even with non-JSEP endpoints. </ins> 5.4.
Original text:
should have its track removed.  The sender's track is cleared, and the sender stops sending.  Future calls to createOffer will mark the m= section associated with the sender as recvonly (if <del> transceiver.currentDirection is sendrecv) or as inactive (if transceiver.currentDirection is sendonly). </del>  4.1.4. The currentDirection property indicates the last negotiated direction for the transceiver's associated m= section.  More specifically, it indicates the RFC3264 directional attribute of the associated m= <del> section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". </del>  If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection is set to

Reviewer comments:
is meant to represent "direction in effect", whereas represents "direction the application wants to negotiate". So, the direction that both inspects and modifies should be ; its purpose is to change the application's desired direction for a transceiver, regardless of the current state of negotiation. Also clarifying that also reflects the direction negotiated in a provisional answer, which was the intent (I believe) but wasn't explicitly stated. This is consistent with it being the direction "in effect", since applying a provisional answer allows the endpoint to start sending/receiving media.
NAME do you want to look at this? I believe this is straightforward.
Section 4.1.3, removeTrack, states: This should say "transceiver.direction". Using "currentDirection" doesn't work because it may be null, and it also may result in un-intuitive behavior, where ends up not having any effect and results in a "sendrecv" or "sendonly" direction being negotiated.
Want to make a PR?

Revised text:
should have its track removed.  The sender's track is cleared, and the sender stops sending.  Future calls to createOffer will mark the m= section associated with the sender as recvonly (if  <ins> transceiver.direction is sendrecv) or as inactive (if transceiver.direction is sendonly). </ins> 4.1.4. The currentDirection property indicates the last negotiated direction for the transceiver's associated m= section.  More specifically, it indicates the RFC3264 directional attribute of the associated m=  <ins> section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". </ins> If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection is set to
Original text:
1.1. <del> The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible.  The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case.  In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. </del>  With these considerations in mind, this document describes the JavaScript Session Establishment Protocol (JSEP) that allows for full

Reviewer comments:
Fixed my own comment, now LGTM
I think this got all the text from Robert, it was just not a change so it does not show up in diff.
Suggested change to the first sentence of 1.1 OLD: The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible. New: WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible.
OK

Revised text:
1.1.  <ins> WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible.  The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case.  In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. </ins> With these considerations in mind, this document describes the JavaScript Session Establishment Protocol (JSEP) that allows for full
Original text:
a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. <del> Next, m= sections are processed.  For each m= section, the following </del>  steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.

Reviewer comments:
The second paragraph of 6.8 starts "Next, ". I think it should start "First, ".
I agree with this.

Revised text:
a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps.  <ins> First, m= sections are processed.  For each m= section, the following </ins> steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.
Original text:
present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the offer that are also valid as media-level attributes are considered to <del> be present in each m= section. The next step is to go through each offered m= section.  Each offered m= section will have an associated RtpTransceiver, as described in sec.applying-a-remote-desc.  If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. </del>  For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as

Reviewer comments:
There are two paragraphs on page 50 that start "The next step is to". They are both referring to the same step. I suggest combining the paragraphs.
I think I would just change the second one to "Finally"
LGTM

Revised text:
present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the offer that are also valid as media-level attributes are considered to  <ins> be present in each m= section.  Each offered m= section will have an associated RtpTransceiver, as described in sec.applying-a-remote- desc.  If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. </ins> For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as