Original text:
However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP and be serialized out to SDP.  If future <del> specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. </del>  As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls <del> as opaque blobs; that is, the application will not need to read or change them. </del>  3.4. In order to give the application control over various common session parameters, JSEP provides control surfaces that tell the JSEP <del> implementation how to generate session descriptions.  This avoids the need for JavaScript to modify session descriptions in most cases. </del>  Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/createAnswer calls. MUST be used for identification; otherwise, the "m=" section index is used instead. <del> Implementations MUST be prepared to receive objects with some fields missing, as mentioned above. </del>  3.5.3. implemented by some implementations according to an earlier, pre- standard definition (in which, for example, no "m=" sections were marked as bundle-only).  As a result, "max-bundle" is considered <del> deprecated, and new applications should use the "must-bundle" policy instead. </del>  The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a "stable" state and the previous local/remote description.  To support <del> this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the "stable" state.  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. </del>  4.1.11. untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious <del> ones.  This is particularly relevant when we consider the SDP that is passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or </del>  createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead.

Reviewer comments:
Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout

Revised text:
However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP and be serialized out to SDP.  If future  <ins> specifications agree on a JSON format for session descriptions, this object could be enhanced to generate and consume that JSON. </ins> As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls  <ins> as opaque blobs; that is, the application will not need to parse or understand them. </ins> 3.4. In order to give the application control over various common session parameters, JSEP provides control surfaces that tell the JSEP  <ins> implementation how to generate session descriptions.  In most cases, this removes the need for applications to modify session descriptions after they are created. </ins> Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/createAnswer calls. MUST be used for identification; otherwise, the "m=" section index is used instead.  <ins> Other than the "m=" section index, all IceCandidate fields are optional, and implementations MUST NOT reject a candidate simply because an optional field is missing. </ins> 3.5.3. implemented by some implementations according to an earlier, pre- standard definition (in which, for example, no "m=" sections were marked as bundle-only).  As a result, "max-bundle" is considered  <ins> deprecated, and implementations compliant with this specification SHOULD ignore attempts by the application to select this bundle policy (although some phase-out period may be necessary to avoid application breakage). </ins> The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a "stable" state and the previous local/remote description.  To support  <ins> this, this specification introduces the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the "stable" state.  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. </ins> 4.1.11. untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious  <ins> ones.  This is particularly relevant when one considers the SDP that is passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or </ins> createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead.