Original text:
A rollback discards any proposed changes to the session, returning the state machine to the stable state, and setting the pending local <del> and/or remote description back to null.  Any resources or candidates </del>  that were allocated by the abandoned local description are discarded; any media that is received will be processed according to the previous local and remote descriptions.  Rollback can only be used to 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 null.  RtpTransceivers that were created by applying a remote offer <del> 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

Reviewer comments:
Is there any other action to be taken for the issues mentioned in ?
NAME I concluded no.
Grouping these as one bug. Section 4.1.7.1 - the term "inactive" final answer is introduced without a defintion. Need to either define "inactive" or use another term. Section 4.1.7.2 Rollback - "and possibly the answerer as well" is wishy-washy. Suggest "and the answerer if it has done set-remote-description". Section 4.1.7.2 This is the first mention of "pending local / remote description". Suggest link to definition. Section 4.1.7.2 "RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed". The term "removed" is undefined. Deleted, discarded, destroyed or detached from the PeerConnection? Suggestion: "stopped and removed from the PeerConnection". (if the JS app still has a reference to them, it may still inspect the object).
LG % nit

Revised text:
A rollback discards any proposed changes to the session, returning the state machine to the stable state, and setting the pending local  <ins> and/or remote description (see sec.pendinglocaldescription and sec.pendingremotedescription) to null.  Any resources or candidates </ins> that were allocated by the abandoned local description are discarded; any media that is received will be processed according to the previous local and remote descriptions.  Rollback can only be used to 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 null.  RtpTransceivers that were created by applying a remote offer  <ins> that was subsequently rolled back MUST be stopped and removed from the PeerConnection.  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