jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-jsep

Commentary: Justin , what are you looking for me to do here ? 
 ? This is ancient . 
 it seems this was dealt with long ago . I have no idea why it says I assigned it to EKR and hour ago ? 
 12 ) [ rfced ] Section 4.1.8.1 : We had trouble with this sentence . If neither suggestion below is correct , please clarify . Original : While this could also be done with a " sendonly " pranswer , followed by a " sendrecv " answer , the initial pranswer leaves the offer - answer exchange open , which means that the caller can not send an updated offer during this time . Suggestion : While this could also be done with a " sendonly " pranswer , if followed by a " sendrecv " answer the initial pranswer leaves the offer / answer exchange open , which means that the caller can not send an updated offer during this time . Suggestion : While this could also be done with a " sendonly " pranswer followed by a " sendrecv " answer , the initial pranswer leaves the offer / answer exchange open , which means that the caller can not send an updated offer during this time . 
 suggestion seems right 
 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 A):
Note that when BUNDLE is used, any additional attributes that are
added MUST follow the advice in I-D.nandakumar-mmusic-sdp-mux-
attributes on how those attributes interact with BUNDLE.
Paragraph (version B):
Note that when BUNDLE is used, any additional attributes that are
added MUST follow the advice in I-D.ietf-mmusic-sdp-mux-attributes on
how those attributes interact with BUNDLE.