Original text:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use <del> their existing candidates. </del>  3.4.2. supply them to its ICE Agent.  This triggers the ICE Agent to start using the new remote candidates for connectivity checks. <del> When BUNDLE is in use, candidates (both in-SDP and trickle) are only exchanged for and associated with the m= section referenced by the sender's BUNDLE-tag, as described in I-D.ietf-mmusic-sdp-bundle- negotiation </del> 3.4.2.1. As with session descriptions, the syntax of the IceCandidate object Each "a=mid" line MUST stay the same. <del> If the m= section is not bundled into another m= section (i.e., it is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless </del>  the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= <del> section is bundled into another m= section, it MUST NOT have any ICE credentials. </del>  If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering values MUST be used, as described in the initial answer section above. <del> If the m= section is not bundled into another m= section (i.e., it is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= section is bundled into another m= section, it MUST NOT contain any ICE credentials. </del>  If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering

Reviewer comments:
Change position of initial paragraph on handling of bundled m= sections; simplify some text; remove discussion of ICE restart option in answers.
NAME FYI

Revised text:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use  <ins> 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. </ins> 3.4.2. supply them to its ICE Agent.  This triggers the ICE Agent to start using the new remote candidates for connectivity checks.  3.4.2.1. As with session descriptions, the syntax of the IceCandidate object Each "a=mid" line MUST stay the same.  <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless </ins> the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m=  <ins> section is bundled into another m= section, it still MUST NOT contain any ICE credentials. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering values MUST be used, as described in the initial answer section above.  <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering