Draft: draft-ietf-rtcweb-jsep

Commentary: Is there any other action to be taken for the issues mentioned in ? 
 I concluded no . 
 Grouping these as one bug . Section 4.1.7.1 - the term " inactive " final answer is introduced without a defintion . Need to either define " inactive " or use another term . Section 4.1.7.2 Rollback - " and possibly the answerer as well " is wishy - washy . Suggest " and the answerer if it has done set - remote - description " . Section 4.1.7.2 This is the first mention of " pending local / remote description " . Suggest link to definition . Section 4.1.7.2 " RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed " . The term " removed " is undefined . Deleted , discarded , destroyed or detached from the PeerConnection ? Suggestion : " stopped and removed from the PeerConnection " . ( if the JS app still has a reference to them , it may still inspect the object ) . 
 LG % nit
Paragraph (version A):
A rollback discards any proposed changes to the session, returning
the state machine to the stable state, and setting the pending local
and/or remote description back to null.  Any resources or candidates
that were allocated by the abandoned local description are discarded;
any media that is received will be processed according to the
previous local and remote descriptions.  Rollback can only be used to
cancel proposed changes; there is no support for rolling back from a
stable state to a previous stable state.  Note that this implies that
once the answerer has performed setLocalDescription with his answer,
this cannot be rolled back.
Paragraph (version B):
A rollback discards any proposed changes to the session, returning
the state machine to the stable state, and setting the pending local
and/or remote description (see sec.pendinglocaldescription and
sec.pendingremotedescription) to null.  Any resources or candidates
that were allocated by the abandoned local description are discarded;
any media that is received will be processed according to the
previous local and remote descriptions.  Rollback can only be used to
cancel proposed changes; there is no support for rolling back from a
stable state to a previous stable state.  Note that this implies that
once the answerer has performed setLocalDescription with his answer,
this cannot be rolled back.
Paragraph (version A):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid property MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if a track was attached to the
RtpTransceiver via the addTrack method.  This is so that an
application may call addTrack, then call setRemoteDescription with an
offer, then roll back that offer, then call createOffer and have a m=
section for the added track appear in the generated offer.
Paragraph (version B):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid property MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be stopped and removed from
the PeerConnection.  However, a RtpTransceiver MUST NOT be removed if
a track was attached to the RtpTransceiver via the addTrack method.
This is so that an application may call addTrack, then call
setRemoteDescription with an offer, then roll back that offer, then
call createOffer and have a m= section for the added track appear in
the generated offer.