Draft: draft-ietf-rtcweb-jsep

Commentary: From 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
Paragraph (version B):
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.
Paragraph (version A):
Any changes to the STUN/TURN servers to use affect the next
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.
Paragraph (version A):
Any changes to the ICE candidate policy also affect the next
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.
Paragraph (version B):
Any changes to the STUN/TURN servers to use affect the next
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.
Paragraph (version B):
Any changes to the ICE candidate policy also affect the next
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.