Original text:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the <del> initiating side creates an offer by calling a createOffer() API.  The </del>  application then uses that offer to set up its local config via the <del> setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del>  To complete the offer/answer exchange, the remote party uses the <del> createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the </del>  initiator over the signaling channel.  When the initiator gets that <del> answer, it installs it using the setRemoteDescription() API, and </del>  initial setup is complete.  This process can be repeated for additional offer/answer exchanges.

Reviewer comments:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

Revised text:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the  <ins> initiating side creates an offer by calling a createOffer API.  The </ins> application then uses that offer to set up its local config via the  <ins> setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </ins> To complete the offer/answer exchange, the remote party uses the  <ins> createAnswer API to generate an appropriate answer, applies it using the setLocalDescription API, and sends the answer back to the </ins> initiator over the signaling channel.  When the initiator gets that  <ins> answer, it installs it using the setRemoteDescription API, and </ins> initial setup is complete.  This process can be repeated for additional offer/answer exchanges.