Original text:
1. This document describes how the W3C WEBRTC RTCPeerConnection <del> interface W3C.WD-webrtc-20140617 is used to control the setup, management and teardown of a multimedia session. </del>  1.1. willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; for example, the <del> fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </del>  In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all <del> have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or these value(s) MUST be session-level attributes. </del>  Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be Section 15.4. An "a=fingerprint" line for each of the endpoint's certificates, <del> as specified in RFC4572, Section 5; the digest algorithm used for </del>  the fingerprint MUST match that used in the certificate signature. An "a=setup" line, as specified in RFC4145, Section 4, and in RFC5245, Section 15.5, and the set of specified options is stored. <del> Any "a=fingerprint" lines are parsed as specified in RFC4572, </del>  Section 5, and the set of fingerprint and algorithm values is stored. parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. <del> Any "a=fingerprint" lines are parsed as specified in RFC4572, </del>  Section 5, and the set of fingerprint and algorithm values is stored. formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified in RFC4585, Section 4.2.  When sending RTCP feedback, follow <del> the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. </del>  If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows, including examples with <del> IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp. </del>  7.1.

Reviewer comments:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.

Revised text:
1. This document describes how the W3C WEBRTC RTCPeerConnection  <ins> interface W3C.webrtc is used to control the setup, management and teardown of a multimedia session. </ins> 1.1. willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; for example, the  <ins> fingerprints RFC8122 sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all  <ins> have the same RFC8122 fingerprint value(s), or these value(s) MUST be session-level attributes. </ins> Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be Section 15.4. An "a=fingerprint" line for each of the endpoint's certificates,  <ins> as specified in RFC8122, Section 5; the digest algorithm used for </ins> the fingerprint MUST match that used in the certificate signature. An "a=setup" line, as specified in RFC4145, Section 4, and in RFC5245, Section 15.5, and the set of specified options is stored.  <ins> Any "a=fingerprint" lines are parsed as specified in RFC8122, </ins> Section 5, and the set of fingerprint and algorithm values is stored. parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored.  <ins> Any "a=fingerprint" lines are parsed as specified in RFC8122, </ins> Section 5, and the set of fingerprint and algorithm values is stored. formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified in RFC4585, Section 4.2.  When sending RTCP feedback, follow  <ins> the rules and recommendations from RFC8108, Section 5.4.1 to select which SSRC to use. </ins> If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows, including examples with  <ins> IPv6 addresses, can be found in I-D.ietf-rtcweb-sdp. </ins> 7.1.