Change:
NAME I looked at the deletion issue and I don't think it's worth leaving it in as an exception, because you'd have to DTLS re-handshake anyway.

Discussion:
When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer.  In addition, the offerer includes one or more SDP <del> 'fingerprint' attributes.  The set of fingerprints MUST be the same as the set to which the identity assertion is bound. </del> <ins> 'fingerprint' attributes.  The 'identity' attribute MUST be bound to all the 'fingerprint' attributes in the session description. </ins> 5.1.2.

5.1.5. <del> When an endpoint has provided its identity assertion in a previous successful offer/answer exchange, and when the endpoint later in the session sends an offer or answer, the endpoint can either keep the identity assertion value unchanged, modify the value, or revoke the identity assertion.  This section describes the procedures for doing so. </del> <ins> When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute.  In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. </ins> <del> If the endpoint wants to maintain the previously provided identity assertion, it MUST include an 'identity' attribute with the previously provided attribute value in the offer or answer. If the endpoint wants to modify its identity assertion within the session, it MUST include an 'identity' attribute value with the new identity assertion in the offer or answer. If the endpoint maintains or modifies its identity assertion within the session, it includes one or more SDP 'fingerprint' attributes. The set of fingerprints MUST be the same as the set to which the identity assertion is bound. If the endpoint wants to revoke its identity assertion from the session, it MUST NOT include an 'identity' attribute in the offer or answer. Specific usages might restrict the modification and/or revoking of the identity assertion within a session.  Endpoints can add, modify, or remove 'fingerprint' attributes when modifying a session.  If a modified session retains the 'identity' attribute, there MUST be at least one 'fingerprint' attribute included. </del> <ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in fingerprints also causes a new DTLS connection to be established, the receiver MUST discard all previously established identities. </ins> 6.

11.1. <ins> Rewrite the Identity section in more conventional offer/answer format. Clarify rules on changing identities. 11.2. </ins> Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority

Require support for ECDSA, PFS, and AEAD <del> 11.2. </del> <ins> 11.3. </ins> Update cipher suite profiles. Rework IdP interaction based on implementation experience in Firefox. <del> 11.3. </del> <ins> 11.4. </ins> Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG

Assorted editorial work. <del> 11.4. </del> <ins> 11.5. </ins> The following changes have been made since the -05 draft.

Editorial cleanup. <del> 11.5. </del> <ins> 11.6. </ins> Version -04 was a version control mistake.  Please ignore.

Editorial cleanup. <del> 11.6. </del> 11.7. <ins> 11.8. </ins> The following changes have been made since the -02 draft. Forbid persistent HTTP permissions.