jiebi/TextFlow huggingface dataset:
Original text:
MUST be returned. Next, the SessionDescription is parsed into a data structure, as <del> described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be returned. </del>  Finally, the parsed SessionDescription is applied as described in the sec.applying-a-local-desc section below.

Reviewer comments:
It seems like there are two implementation strategies here: Keep a parsed version Re-parse. I think we probably could dispense with this sentence, but I don't object to it, because I think of "lookup in cache" as "parse".
Knowing how things go in the real world, I'm a bit reluctant to make this change, but it should address Adam's concern.

Revised text:
MUST be returned. Next, the SessionDescription is parsed into a data structure, as  <ins> described in the sec.parsing-a-desc section below. </ins> Finally, the parsed SessionDescription is applied as described in the sec.applying-a-local-desc section below.
Original text:
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 <del> identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </del>  Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

Reviewer comments:
Page 41 contains a statement reading "This promotes readability," which might be read by some as promoting machine parsing rather than troubleshooting. I propose replacing "readability" with "troubleshooting."
Full text: 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. I'm not sure that 'troubleshooting' is the exact word we're looking for here, but I think we can come up with something.

Revised text:
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  <ins> 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> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically
Original text:
5.7. <del> When a SessionDescription of any type is supplied to setLocal/ RemoteDescription, the implementation must parse it and reject it if it is invalid.  The exact details of this process are explained below. </del> The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in RFC4566, Section 5.  The SDP is read, line-by-line, and

Reviewer comments:
Adam's concern here was that the local description could never be invalid, since it was generated by the implementation.
Correct. I think you need to either remove setLocal or do: parse and (if setRemote, choke one error).
Editor discussion: this paragraph seems redundant so just remove it? NAME to look.
NAME NAME - ready for re-review
Section 5.7, first paragraph: similar to above, change "setLocal/RemoteDescription" to "setRemoteDescription."
Section Parsing a Session Description Text is When a SessionDescription of any type is supplied to setLocal/ RemoteDescription, the implementation must parse it and reject it if it is invalid. The exact details of this process are explained below. Fix as adam sugested

Revised text:
5.7.  The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in RFC4566, Section 5.  The SDP is read, line-by-line, and
Original text:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> As required by RFC4566, Section 5.13, unknown attribute lines MUST be </del>  ignored. Once all the session-level lines have been parsed, processing as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default. <del> As required by RFC4566, Section 5.13, unknown attribute lines MUST be </del>  ignored. 5.7.3.

Reviewer comments:
Not sure I love what I have done here.
Section 5.7.2 should include a statement (probably at the end) that implementations may know and process attributes other than those described in this section.
Section Media Section Parsing Text As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. proposal update that text to say something about OK to process things are known but not specified in JSEP.

Revised text:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.  <ins> Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize.  As required by RFC4566, Section 5.13, unknown attribute lines MUST be </ins> ignored. Once all the session-level lines have been parsed, processing as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default.  <ins> Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize.  As required by RFC4566, Section 5.13, unknown attribute lines MUST be </ins> ignored. 5.7.3.
Original text:
continuation of the previous line.  In addition, some blank lines have been added to improve readability but are not valid in SDP. <del> More examples of SDP for WebRTC call flows can be found in I- D.nandakumar-rtcweb-sdp. </del>  7.1.

Reviewer comments:
Section 7 does not acknowledge IPv6. The IAB statement on IPv6 has a recommendation that all protocol specifications have IPv6 examples in them. Since we have a separate example document, and Suhas has indicated that he will be including some IPv6 examples in it, I think you can get away in this document by amending the final paragraph of section 7 as: "More examples of SDP for WebRTC call flows, including examples of IPv6 addresses, can be found in [I-D.ietf-rtcweb-sdp]." I make no promise that other IESG members will find this sufficient, but I'm personally okay with it.

Revised text:
continuation of the previous line.  In addition, some blank lines have been added to improve readability but are not valid in SDP.  <ins> More examples of SDP for WebRTC call flows, including examples with IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp. </ins> 7.1.
Original text:
section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating an m= section for the added RtpTransceiver as if the m= <del> section were being added to the session description, placed at the same index as the m= section with a zero port. </del>  If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it.  This For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same. <del> If any RtpTransceiver has been stopped, the port MUST be set to zero and all "a=msid" lines MUST be removed. If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating a m= section for the added RtpTransceiver as if the m= section were being added to session description, except that instead of adding it, the generated m= section replaces the m= section with a zero port.  The new m= section MUST contain a new MID. </del> If the initial offer was applied using setLocalDescription, and an answer from the remote side has been applied using setRemoteDescription, meaning the PeerConnection is in the "remote-

Reviewer comments:
BLOCKER: The second bullet on page 43 ("If an RtpTranceiver has been stopped and is associated..." is normative and redundant with (and slightly contradictory to) the bullet on page 44 starting "If any RtpTranceiver has been slopped...") which is also normative. Remove one.
Looks like an editorial oversight. I'm inclined to remove the second instance. NAME as FYI
BLOCKER: The bullet at the bottom of of page 42 ("If any RtpTranceiver has been added...") is normative and redundant with the bullet in the middle of page 44 ("If any RtpTranceiver has been added..."), which is also normative. Remove one.
Agreed. Let's remove the second one. NAME as FYI

Revised text:
section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating an m= section for the added RtpTransceiver as if the m=  <ins> section were being added to the session description (including a new MID value), and placing it at the same index as the m= section with a zero port. </ins> If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it.  This For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same.  If the initial offer was applied using setLocalDescription, and an answer from the remote side has been applied using setRemoteDescription, meaning the PeerConnection is in the "remote-
Original text:
RTCP transmission for this m= section to use reduced-size RTCP, as specified in RFC5506. <del> If the directional attribute in the answer is of type "sendrecv" or "sendonly", choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del>  specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to

Reviewer comments:
BLOCKER: The final bullet of page 68 refers to answer directionality of "sendrecv" and "sendonly." These are incorrect when applying remote answers, for which these should be "sendrecv" and "recvonly." Please rephrase in terms of whether media is to be sent, or fix in some other way that doesn't get the sense reversed for remote answers.

Revised text:
RTCP transmission for this m= section to use reduced-size RTCP, as specified in RFC5506.  <ins> If the directional attribute in the answer indicates that the JSEP implementation should be sending media ("sendonly" for local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to
Original text:
between the RTX payload type and its associated primary payload type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an <del> error. </del>  For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media

Reviewer comments:
The bullet in the middle of page 66 (starting "For each specified media format...") states that unsupported media formats must be ignored. The following bullet specifies that "rtx" media formats that refer to "primary payload types [that] are not present" MUST result in an error. Read naïvely, implementors may very well discard a payload type for lack of understanding, and then discover an "rtx" for that discarded PT, and generate an error ("it's not present!"). These bullets need additional text regarding how they interact with each other.
LGTM with comment

Revised text:
between the RTX payload type and its associated primary payload type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an  <ins> error.  Note that RTX payload types may refer to primary payload types which are not supported by the local media implementation, in which case, the RTX payload type MUST also be ignored. </ins> For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media
Original text:
The RTCP feedback extensions MUST only include those that are present in the most recent answer. <del> The "a=rtcp" line MUST only be added if the most recent answer did not include an "a=rtcp-mux" line. </del>  <del> The "a=rtcp-mux" line MUST only be added if present in the most </del>  recent answer. The "a=rtcp-mux-only" line MUST NOT be added. <del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. </del>  An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP

Reviewer comments:
The bullets on page 45 use the construct "MUST only" three times. This is confusing, and likely to lead to implementors doing the wrong thing. Please rewrite in the form "The 'a=rtcp' line MUST NOT be added unless..."
In the section "Subsequent Offers" we have the text o The RTCP feedback extensions MUST only include those that are present in the most recent answer. o The "a=rtcp" line MUST only be added if the most recent answer did not include an "a=rtcp-mux" line. o The "a=rtcp-mux" line MUST only be added if present in the most recent answer. Next step - Rewrite as adam suggested.
This works for me.

Revised text:
The RTCP feedback extensions MUST only include those that are present in the most recent answer.  <ins> The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. </ins>  <ins> The "a=rtcp-mux" line MUST NOT be added unless present in the most </ins> recent answer. The "a=rtcp-mux-only" line MUST NOT be added.  <ins> The "a=rtcp-rsize" line MUST NOT be added unless present in the most recent answer. </ins> An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP
Original text:
the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. <del> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue sending RTCP, as described in RFC3264, Section 5.1. </del>  If the m= section proto value indicates use of SCTP:

Reviewer comments:
BLOCKER: The first bullet on page 70 exhibits the same error.
Maybe I am just dumb but I am not seeing this in the text.
Sorry, I mis-entered this one. This is regarding media directionality again.
NAME PTAL and see if there's anything from that we need to do here.

Revised text:
the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use.  <ins> If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for local answers, "sendonly" for remote answers, or "inactive" for either type of answer) stop transmitting all RTP media, but continue sending RTCP, as described in RFC3264, Section 5.1. </ins> If the m= section proto value indicates use of SCTP:
Original text:
Section 5.14.  For the m= line itself, the following rules MUST be followed: <del> The port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del>  To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8.

Reviewer comments:
BLOCKER: The first bullet on page 37 says that port 9 "MUST be used," which contradicts the behavior required of BUNDLE-only sections (for which port 0 MUST be used). Clarify.
Yes - we need to indicate that bundle-only sections use 0 instead of 9.

Revised text:
Section 5.14.  For the m= line itself, the following rules MUST be followed:  <ins> If the m= section is marked as bundle-only, then the port value MUST be set to 0.  Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8.
Original text:
exact same number as the offer. Lastly, while the exact media parameters are only known only after an <del> offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. </del>  Therefore, in order to handle session descriptions properly, the user agent needs: calls to createOffer and createAnswer. When creating offers, the transceiver direction is directly reflected <del> in the output, even for reoffers.  When creating answers, the </del>  transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below.

Reviewer comments:
Section 3.2 has a paragraph starting "Lastly, while the actual media parameters are only know after an offer..."; the entire contents of this paragraph appear to be actually false if both ICE and DTLS are in use. I know there's conversation underway on MMUSIC and the WebRTC mailing lists on this topic, but none of them have yet described a situation in which this paragraph is actually true. Please remove it or add a sequence diagram showing how it arises.
It may not be able to receive media (due to lack of DTLS fingerprint), but it can certainly receive ICE checks. We should clarify accordingly.

Revised text:
exact same number as the offer. Lastly, while the exact media parameters are only known only after an  <ins> offer and an answer have been exchanged, the offerer may receive ICE checks, and possibly media (e.g., in the case of a re-offer after a connection has been established) before it receives an answer.  To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. </ins> Therefore, in order to handle session descriptions properly, the user agent needs: calls to createOffer and createAnswer. When creating offers, the transceiver direction is directly reflected  <ins> in the output, even for re-offers.  When creating answers, the </ins> transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below.
Original text:
I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation <del> specifies that attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections. </del>  The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:

Reviewer comments:
Page 37 contains a statement that "attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections". Two issues: this reads as normative, so consider "SHOULD NOT" rather than "should not." Also, I think this is true of bundle-only sections, not bundled sections in general.
If we are going to use normative language, seems like we should match the language from BUNDLE, which probably says 'MUST NOT'. The statement is correct regarding any actively bundled sections (which includes bundle-only), but this part of the text has caused enough confusion that some extra explanation is probably warranted.

Revised text:
I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation  <ins> 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. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:
Original text:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= sections; other m= sections continue to <del> use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= sections referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp- bundle-negotiation. </del>  3.5.2. JSEP applications typically inform the JSEP implementation to begin ICE gathering via the information supplied to setLocalDescription, as <del> this is where the app specifies the number of media streams, and thereby ICE components, for which to gather candidates.  However, to accelerate cases where the application knows the number of ICE </del>  components to use ahead of time, it may ask the implementation to gather a pool of potential ICE candidates to help ensure rapid media setup.

Reviewer comments:
I tried to clarify bundle-only while Iw as in here.
BLOCKER: The final paragraph in section 3.5.1 says that candidates are only gathered for m= sections referenced in BUNDLE tags. Section 3.5.4 talks about gathering more candidates than that under certain circumstances. Please make these consistent with each other.
Agree this needs to be rewritten; with BUNDLE, # of media streams is not the number of ICE components.

Revised text:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= sections; other m= sections continue to  <ins> use their existing candidates.  Also, if an m= section is bundled (either by a successful bundle negotiation or by being marked as bundle-only), then candidates will be gathered and exchanged for that m= section if and only if its MID is a BUNDLE-tag, as described in I- D.ietf-mmusic-sdp-bundle-negotiation. </ins> 3.5.2. JSEP applications typically inform the JSEP implementation to begin ICE gathering via the information supplied to setLocalDescription, as  <ins> the local description indicates the number of ICE components which will be needed and for which candidates must be gathered.  However, to accelerate cases where the application knows the number of ICE </ins> components to use ahead of time, it may ask the implementation to gather a pool of potential ICE candidates to help ensure rapid media setup.