Change:
3.5.2.1. <del> As with session descriptions, the syntax of the IceCandidate object provides some abstraction, but can be easily converted to and from the SDP candidate lines. The candidate lines are the only SDP information that is contained within IceCandidate, as they represent the only information needed that is not present in the initial offer (i.e., for trickle candidates).  This information is carried with the same syntax as the "candidate-attribute" field defined for ICE.  For example: </del> <ins> In JSEP, ICE candidates are abstracted by an IceCandidate object, and as with session descriptions, SDP syntax is used for the internal representation. The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in RFC5245, Section 15.1.  For example: The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC5245, Section 15.4.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </ins> The IceCandidate object also contains fields to indicate which m= <del> section it should be associated with.  The m= section can be identified in one of two ways; either by a m= section index, or a MID.  The m= section index is a zero-based index, with index N referring to the N+1th m= section in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= section.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a- remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= section index, if not (the non-JSEP remote endpoint case). </del> <ins> section it is associated with, which can be identified in one of two ways, either by a m= section index, or a MID.  The m= section index is a zero-based index, with index N referring to the N+1th m= section in the session description referenced by this IceCandidate.  The MID is a "media stream identification" value, as defined in RFC5888, Section 4, which provides a more robust way to identify the m= section in the session description, using the MID of the associated RtpTransceiver object (which may have been locally generated by the answerer when interacting with a non-JSEP endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  If the MID field is present in a received IceCandidate, it MUST be used for identification; otherwise, the m= section index is used instead. When creating an IceCandidate object, JSEP implementations MUST populate all of these fields. </ins> 3.5.3.

Discussion:
Updated to address Eric's comment
I note the following new text: "The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in , Section 15.4. This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts." Exactly what value does this field contain? How does one use it to determine to which session description the IceCandidate belongs?