Original text:
These values MAY either be present at the media level, or inherited from the session level. <del> ICE ufrag and password values </del>  <del> DTLS fingerprint and setup values </del>  If this session description is of type "pranswer" or "answer", the following additional checks are applied: The session description must follow the rules defined in RFC3264, <del> Section 6. </del>  <del> For each m= section, the protocol value MUST exactly match the protocol value in the corresponding m= section in the associated offer. </del>  5.7. bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> TODO </del>  Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section 5.8. <del> TODO </del>  5.9. <del> TODO </del>  6.

Reviewer comments:
Still have a bunch of stuff to flesh out, but wanted to get this out for initial review. NAME NAME
Looks like good stuff to me. - The text in start of section 5 seem fine for making it clear that this does not override the referenced specs.
Thanks for the comments. Ran out of time to resolve them today but will take another shot at it Saturday.
Updated based on comments. I'd like to go ahead and merge this ASAP, and then hopefully still get another rev in before the deadline.
I'm fine with merging what we have here right now.
The text relies on the phrase "most recent gathering phase" to describe which candidates are present in SDP. Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section (or component thereof): when a new m= section is added (which happens for a new RTCPeerConnection obviously) when an m= section did have a port of 0, but is repurposed for new media (basically the same scenario as above) ICE restart This needs a clearer definition, or maybe just a single clear description of what it means to do this. This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription.
Martin, could you give us a PR that would satisfy you

Revised text:
These values MAY either be present at the media level, or inherited from the session level.  <ins> ICE ufrag and password values, which MUST comply with the size limits specified in RFC5245, Section 15.4. </ins>  <ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5, and MUST be consistent with the selected role of the current DTLS connection, if one exists.[TODO: may need revision, i.e., use of actpass DTLS fingerprint values, where at least one fingerprint MUST be present. Each m= section is also checked to ensure prohibited features are not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied: The session description must follow the rules defined in RFC3264,  <ins> Section 6, including the requirement that the number of m= sections MUST exactly match the number of m= sections in the associated offer. </ins>  <ins> For each m= section, the media type and protocol values MUST exactly match the media type and protocol values in the corresponding m= section in the associated offer. </ins> 5.7. bounds, or cannot be applied, processing MUST stop and an error MUST be returned.  <ins> If this media section is new, begin gathering candidates for it, as defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. Or, if the ICE ufrag and password values have changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates for the media section, as defined in RFC5245, Section 9.1.1.1, unless it has been marked as bundle-only. If the media section proto value indicates use of RTP: If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. For each specified RTP header extension, establish a mapping between the extension ID and URI.  If any indicated RTP header extension is unknown, this MUST result in an error.  [TODO: ref] If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension.  [TODO: ref] For each specified payload type, establish a mapping between the payload type ID and the actual media format.  [TODO: ref] If any indicated payload type is unknown, this MUST result in an error. For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type.  [TODO: ref] If any referenced primary payload types are not present, this MUST result in an error. If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media. </ins> Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section 5.8.  <ins> The following steps are performed at the media engine level to apply a remote description. For each media section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. If the description is of type "offer", and the ICE ufrag or password changed from the previous remote description, [TODO: ref], mark that an ICE restart is needed. Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks. Pair any supplied ICE candidates with any gathered local candidates, as described in [TODO: ref] and start connectivity checks with the appropriate credentials. If the media section proto value indicates use of RTP: [TODO: header extensions] For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format.  [TODO: ref] If any indicated payload type is unknown, it MUST be ignored.  [TODO: should fail on answers] For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type.  [TODO: ref] If any referenced primary payload types are not present, this MUST result in an error. For each specified fmtp parameter that is supported by the local implementation, enable them on the associated payload types. For each specified RTCP feedback mechanism that is supported by the local implementation, enable them on the associated payload types. For any specified "TIAS" bandwidth value, set this value as the maximum RTP bitrate to be used when sending media.  If a "TIAS" value is not present, but an "AS" value is, generate a TIAS a value using this formula: [TODO: convert AS to TIAS]. [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio: For any specified "ptime" value, configure the available payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section below. </ins> 5.9.  <ins> In addition to the steps mentioned above for processing a local or remote description, the following steps are performed when processing a description of type "pranswer" or "answer". For each media section, the following steps MUST be performed: If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for this section, and discard any associated ICE components.  [TODO: ref] If the remote DTLS fingerprint has been changed, tear down the existing DTLS connection. If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. If the media section proto value indicates use of RTP: If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise, transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced- size RTCP, as specified in [TODO: ref] If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  Otherwise, stop transmitting RTP media, although RTCP should still be sent.  [TODO: ref] If the media section proto value indicates use of SCTP: If no SCTP association yet exists, prepare to initiate a SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote description.  [TODO: ref] If the answer contains valid BUNDLE groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref] If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </ins> 6.