Draft: draft-ietf-rtcweb-jsep

Commentary: Editorial suggestions , if helpful use , if not just close the PR . 
 fine with me to merge this 
 LGTM
Paragraph (version A):
In addition, various RFCs put different conditions on the format of
offers versus answers.  For example, a offer may propose an arbitrary
number of media streams (i.e. m= sections), but an answer must
contain the exact same number as the offer.
Paragraph (version B):
In addition, various RFCs put different conditions on the format of
offers versus answers.  For example, an offer may propose an
arbitrary number of media streams (i.e. m= sections), but an answer
must contain the exact same number as the offer.
Paragraph (version A):
When a new gathering phase starts, the ICE Agent will notify the
application that gathering is occurring through a callback.  Then,
when each new ICE candidate becomes available, the ICE Agent will
supply it to the application via an additional callback; these
candidates will also automatically be added to the local session
description.  Finally, when all candidates have been gathered, a
callback will be dispatched to signal that the gathering process is
complete.
Paragraph (version B):
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
it to the application via an additional event; these candidates will
also automatically be added to the local session description.
Finally, when all candidates have been gathered, an event will be
dispatched to signal that the gathering process is complete.
Paragraph (version A):
When setLocalDescription is eventually called, and the browser goes
to gather the needed ICE candidates, it SHOULD start by checking if
any candidates are available in the pool.  If there are candidates in
the pool, they SHOULD be handed to the application immediately via
the ICE candidate callback.  If the pool becomes depleted, either
because a larger-than-expected number of ICE components is used, or
because the pool has not had enough time to gather candidates, the
remaining candidates are gathered as usual.
Paragraph (version B):
When setLocalDescription is eventually called, and the browser goes
to gather the needed ICE candidates, it SHOULD start by checking if
any candidates are available in the pool.  If there are candidates in
the pool, they SHOULD be handed to the application immediately via
the ICE candidate event.  If the pool becomes depleted, either
because a larger-than-expected number of ICE components is used, or
because the pool has not had enough time to gather candidates, the
remaining candidates are gathered as usual.
Paragraph (version A):
The createOffer method takes as a parameter an RTCAnswerOptions
object.  Special processing is performed when generating a SDP
description if the following constraints are present.
Paragraph (version B):
The createAnswer method takes as a parameter an RTCAnswerOptions
object.  Special processing is performed when generating a SDP
description if the following constraints are present.
Paragraph (version B):
The DTLS fingerprint(s) (a=fingerprint).