Original text:
triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration.  When a new gathering phase starts, the ICE Agent will notify the application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply parameters are changed: Any changes to the STUN/TURN servers to use affect the next <del> gathering phase.  If gathering has already occurred, this will cause the next call to createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used. If the ICE candidate pool has a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del>  Any changes to the ICE candidate policy also affect the next <del> gathering phase, in similar fashion to the server changes described above.  Note though that changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del>  Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;

Reviewer comments:
From EMAIL: Question 1: Should this be interpreted literally, to mean "the next call, and only the next call to createOffer will generate new ICE credentials"? If so, there are various situations wherein one could encounter unexpected behavior. For example: Before createOffer is called, a remote offer is received that triggers an ICE restart. Should the next call to createOffer trigger another, superfluous ICE restart? createOffer is called twice, without setting the local description (and kicking off a new gathering phase). Should the second call generate new credentials, or only the first? I would propose a slight change, such as: "this will cause subsequent calls to createOffer to generate new ICE credentials, until a new gathering phase has started." This would more clearly represent the intent of the original rule, in my opinion. Question 2: The next paragraph states "Any changes to the ICE candidate policy also affect the next gathering phase, in similar fashion to the server changes described above." Does this mean that changes to the candidate policy will also cause an ICE restart, according to the same rules? I assume so, but figure it's worth asking.
On , any changes should set a needs-ice-restart bit, which is only cleared by setLD with new ICE credentials (although, possibly only by setLD + setRD, since the setLD could be rolled back) On , if the ICE policy is being made more restrictive, no ICE restart is needed. Obviously if less restrictive, then the needs-ice-restart bit will be set.
Both you proposed resolutions look good to me

Revised text:
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 set, calls to the createOffer API will generate new ICE credentials. This bit is cleared by a call to the setLocalDescription API with new ICE credentials from either an offer or an answer, i.e., from either a local- or remote-initiated ICE restart. </ins> When a new gathering phase starts, the ICE Agent will notify the application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply parameters are changed: Any changes to the STUN/TURN servers to use affect the next  <ins> gathering phase.  With the exception of the initial state where ICE gathering has not yet occurred, the 'needs-ice-restart' bit mentioned in sec.ice-gather-overview will be set.  This will cause the next call to createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any changes to the ICE candidate policy also affect the next  <ins> gathering phase.  If the policy is being made more liberal (i.e., more permitted candidates), the 'needs-ice-restart' bit will be set.  If the policy is being made more strict, no ICE restart is needed, and the bit will not be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;