Original text:
The setLocalDescription method instructs the PeerConnection to apply the supplied session description as its local configuration.  The type field indicates whether the description should be processed as <del> an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del>  This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the transceiver direction is intersected with the offered direction, as <del> explained in the sec.generating-an-answer section below. </del>  Note that while setDirection sets the direction property of the transceiver immediately (sec.transceiver-direction), this property When a SessionDescription is supplied to setLocalDescription, the following steps MUST be performed: <del> First, the type of the SessionDescription is checked against the current state of the PeerConnection: </del>  If the type is "offer", the PeerConnection state MUST be either "stable" or "have-local-offer". MUST be returned. Next, the SessionDescription is parsed into a data structure, as <del> described in the sec.parsing-a-desc section below. </del>  Finally, the parsed SessionDescription is applied as described in <del> the sec.applying-a-local-desc section below. </del>  5.6. When a SessionDescription is supplied to setRemoteDescription, the following steps MUST be performed: <del> First, the type of the SessionDescription is checked against the current state of the PeerConnection: </del>  If the type is "offer", the PeerConnection state MUST be either "stable" or "have-remote-offer". stop and an error 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 <del> the sec.applying-a-remote-desc section below. </del>  5.7. Section 5, and the set of fingerprint and algorithm values is stored. <del> If the "m=" proto value indicates use of RTP, as described in the sec.profile-names section above, the following attribute lines MUST be processed: </del>  The "m=" fmt value MUST be parsed as specified in RFC4566, Section 5.14, and the individual values stored. "recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer", <del> follow the processing defined in the sec.applying-an-answer section below. </del>  5.9. use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", <del> follow the processing defined in the sec.applying-an-answer section below. </del>  5.10.

Reviewer comments:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM

Revised text:
The setLocalDescription method instructs the PeerConnection to apply the supplied session description as its local configuration.  The type field indicates whether the description should be processed as  <ins> an offer, provisional answer, final answer, or rollback; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the transceiver direction is intersected with the offered direction, as  <ins> explained in sec.generating-an-answer below. </ins> Note that while setDirection sets the direction property of the transceiver immediately (sec.transceiver-direction), this property When a SessionDescription is supplied to setLocalDescription, the following steps MUST be performed:  <ins> If the description is of type "rollback", follow the processing defined in sec.rollback and skip the processing described in the rest of this section. Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: </ins> If the type is "offer", the PeerConnection state MUST be either "stable" or "have-local-offer". MUST be returned. Next, the SessionDescription is parsed into a data structure, as  <ins> described in sec.parsing-a-desc below. </ins> Finally, the parsed SessionDescription is applied as described in  <ins> sec.applying-a-local-desc below. </ins> 5.6. When a SessionDescription is supplied to setRemoteDescription, the following steps MUST be performed:  <ins> If the description is of type "rollback", follow the processing defined in sec.rollback and skip the processing described in the rest of this section. Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: </ins> If the type is "offer", the PeerConnection state MUST be either "stable" or "have-remote-offer". stop and an error MUST be returned. Next, the SessionDescription is parsed into a data structure, as  <ins> described in sec.parsing-a-desc below.  If parsing fails for any reason, processing MUST stop and an error MUST be returned. </ins> Finally, the parsed SessionDescription is applied as described in  <ins> sec.applying-a-remote-desc below. </ins> 5.7. Section 5, and the set of fingerprint and algorithm values is stored.  <ins> If the "m=" proto value indicates use of RTP, as described in sec.profile-names above, the following attribute lines MUST be processed: </ins> The "m=" fmt value MUST be parsed as specified in RFC4566, Section 5.14, and the individual values stored. "recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer",  <ins> follow the processing defined in sec.applying-an-answer below. </ins> 5.9. use the next closest value instead. Finally, if this description is of type "pranswer" or "answer",  <ins> follow the processing defined in sec.applying-an-answer below. </ins> 5.10.