Original text:
JSEP gathers ICE candidates as needed by the application.  Collection of ICE candidates is referred to as a gathering phase, and this is <del> triggered either by the addition of a new or recycled m= line to the local session description, or new ICE credentials in the description, indicating an ICE restart.  Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. </del>  When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is process is complete. Note that gathering phases only gather the candidates needed by <del> new/recycled/restarting m= lines; other m= lines continue to use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= lines referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation. </del>  3.5.2. "candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m= <del> line it should be associated with.  The m= line can be identified in one of two ways; either by a m= line index, or a MID.  The m= line index is a zero-based index, with index N referring to the N+1th m= line 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= line.  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= line index, if not (the non-JSEP remote endpoint case). </del>  3.5.3. and/or pending remote description according to the rules defined for Trickle ICE.  The pair of MID and ufrag is used to determine the m= section and ICE candidate generation to which the candidate belongs. <del> If the MID is not present, the m= line index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. </del>  The purpose of the ufrag is to resolve ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is absent, the object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all <del> m= lines where the offerer chose to perform ICE restart. </del>  The following options are supported in RTCAnswerOptions.

Reviewer comments:
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST

Revised text:
JSEP gathers ICE candidates as needed by the application.  Collection of ICE candidates is referred to as a gathering phase, and this is  <ins> triggered either by the addition of a new or recycled m= section to the local session description, or new ICE credentials in the description, indicating an ICE restart.  Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. </ins> When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is process is complete. Note that gathering phases only gather the candidates needed by  <ins> new/recycled/restarting m= sections; other m= sections continue to use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= sections referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp- bundle-negotiation. </ins> 3.5.2. "candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m=  <ins> 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). </ins> 3.5.3. and/or pending remote description according to the rules defined for Trickle ICE.  The pair of MID and ufrag is used to determine the m= section and ICE candidate generation to which the candidate belongs.  <ins> If the MID is not present, the m= section index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. </ins> The purpose of the ufrag is to resolve ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is absent, the object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all  <ins> m= sections where the offerer chose to perform ICE restart. </ins> The following options are supported in RTCAnswerOptions.