Original text:
although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m= <del> sections.  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 desc).  This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to <del> null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del>  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection.  Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only m= sections MUST NOT contain any The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: <del> An "a=mid" line, as specified in RFC5888, Section 4.  All mid </del>  values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp- <del> bundle-negotiation, Section 14. </del>  A direction attribute which is the same as that of the associated transceiver. If the media section proto value indicates use of RTP: If there is no RtpTransceiver associated with this m= section <del> (which should only happen when applying an offer), find one and </del>  associate it with this m= section according to the following steps: <del> Find the RtpTransceiver that corresponds to the m= section with the same MID in the created offer. </del>  <del> Set the value of the RtpTransceiver's mid property to the </del>  MID of the m= section. If RTCP mux is indicated, prepare to demux RTP and RTCP from If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by <del> setting its mid attribute to null. </del>  If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step), Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> property to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver's mid property, following the guidance for "a=mid" mentioned in sec.initial-offers. </del>  For each specified media format that is also supported by the local implementation, establish a mapping between the specified

Reviewer comments:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM

Revised text:
although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m=  <ins> sections.  An RtpTransceiver is said to be associated with an m= 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 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. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds desc).  This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to  <ins> null, and the mapping between the transceiver and its m= section index MUST be discarded.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. <ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m= section. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only m= sections MUST NOT contain any The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:  <ins> An "a=mid" line, as specified in RFC5888, Section 4.  All MID </ins> values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-mmusic-sdp-  <ins> bundle-negotiation, Section 14.  Note that this does not set the RtpTransceiver mid property, as that only occurs when the description is applied.  The generated MID value can be considered a "proposed" MID at this point. </ins> A direction attribute which is the same as that of the associated transceiver. If the media section proto value indicates use of RTP: If there is no RtpTransceiver associated with this m= section  <ins> (which will only happen when applying an offer), find one and </ins> associate it with this m= section according to the following steps:  <ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section indices established when creating the offer. </ins>  <ins> Set the value of this RtpTransceiver's mid property to the </ins> MID of the m= section. If RTCP mux is indicated, prepare to demux RTP and RTCP from If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by  <ins> setting its mid property to null, and discard the mapping between the transceiver and its m= section index. </ins> If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step), Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid  <ins> property to the MID of the m= section, and establish a mapping between the transceiver and the index of the m= section.  If the m= section does not include a MID (i.e., the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in sec.initial- offers. </ins> For each specified media format that is also supported by the local implementation, establish a mapping between the specified