Change:
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> <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 <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> <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;

Discussion:
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