Original text:
feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf-rtcweb-rtp-usage. If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. <del> An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf- rtcweb-rtp-usage. If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to <del> zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines removed. </del>  <del> For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same if they are present in the current description. </del>  Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </del>  For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to <del> zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed. </del>  If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. <del> An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf- rtcweb-rtp-usage. If RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </del>  5.3.3.

Reviewer comments:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.

Revised text:
feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1.  If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.  If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to  <ins> zero and the "a=msid" line removed. </ins>  <ins> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. </ins> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  <ins> For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. </ins> For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to  <ins> zero and the "a=msid" line MUST be removed. </ins> If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.  Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  <ins> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same. </ins> 5.3.3.