Draft: draft-ietf-rtcweb-jsep

Commentary: for approval 
 Approved . ( If I need to say this someplace else , let me know . ) 
 39 ) [ rfced ] Section 5.3.1 : Should " must be followed : " here be " MUST be followed : " ? ( We ask because ( 1 ) we see " For the m= line itself , the following rules MUST be followed : " in Section 5.2.1 and ( 2 ) all of the rules listed below this sentence include a " MUST . " ) Original : For the m= line itself , the following rules must be followed : 
 yes , should be MUST . 
 Normative text change , please review 
 I hit this one in , closing it out accordingly . 
 I am fine with theses changes . I did not review any of the ones that you did not change . The new normative text is tagged correctly . Final approval resides with the AD . Thanks !
Paragraph (version A):
"offer" indicates that a description should be parsed as an offer;
said description may include many possible media configurations.  A
description used as an "offer" may be applied any time the
PeerConnection is in a "stable" state or applied as an update to a
previously supplied but unanswered "offer".
Paragraph (version A):
"pranswer" indicates that a description should be parsed as an
answer, but not a final answer, and so should not result in the
freeing of allocated resources.  It may result in the start of media
transmission, if the answer does not specify an inactive media
direction.  A description used as a "pranswer" may be applied as a
response to an "offer" or as an update to a previously sent
"pranswer".
Paragraph (version A):
"answer" indicates that a description should be parsed as an answer,
the offer/answer exchange should be considered complete, and any
resources (decoders, candidates) that are no longer needed can be
released.  A description used as an "answer" may be applied as a
response to an "offer" or as an update to a previously sent
"pranswer".
Paragraph (version B):
"offer" indicates that a description MUST be parsed as an offer; said
description may include many possible media configurations.  A
description used as an "offer" may be applied any time the
PeerConnection is in a "stable" state or applied as an update to a
previously supplied but unanswered "offer".
Paragraph (version B):
"pranswer" indicates that a description MUST be parsed as an answer,
but not a final answer, and so MUST NOT result in the freeing of
allocated resources.  It may result in the start of media
transmission, if the answer does not specify an inactive media
direction.  A description used as a "pranswer" may be applied as a
response to an "offer" or as an update to a previously sent
"pranswer".
Paragraph (version B):
"answer" indicates that a description MUST be parsed as an answer,
the offer/answer exchange MUST be considered complete, and any
resources (decoders, candidates) that are no longer needed SHOULD be
released.  A description used as an "answer" may be applied as a
response to an "offer" or as an update to a previously sent
"pranswer".
Paragraph (version A):
"rollback" is a special session description type implying that the
state machine should be rolled back to the previous "stable" state,
as described in sec.rollback.  The contents MUST be empty.
Paragraph (version B):
"rollback" is a special session description type indicating that the
state machine MUST be rolled back to the previous "stable" state, as
described in sec.rollback.  The contents MUST be empty.
Paragraph (version A):
If "a=group" attributes with semantics of "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as
specified in RFC5888.  These attributes MUST have semantics "BUNDLE"
and MUST include all mid identifiers from the offered bundle groups
that have not been rejected.  Note that regardless of the presence of
"a=bundle-only" in the offer, no "m=" sections in the answer should
have an "a=bundle-only" line.
Paragraph (version B):
If "a=group" attributes with semantics of "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as
specified in RFC5888.  These attributes MUST have semantics "BUNDLE"
and MUST include all mid identifiers from the offered bundle groups
that have not been rejected.  Note that regardless of the presence of
"a=bundle-only" in the offer, all "m=" sections in the answer MUST
NOT have an "a=bundle-only" line.
Paragraph (version A):
Silence suppression in the answer is handled as described in
sec.voiceactivitydetection1, with one exception: if support for
silence suppression was not indicated in the offer, the
VoiceActivityDetection parameter has no effect, and the answer should
be generated as if VoiceActivityDetection was set to "false".  This
is done on a per-codec basis (e.g., if the offerer somehow offered
support for CN but set "usedtx=0" for Opus, setting
VoiceActivityDetection to "true" would result in an answer with CN
codecs and "usedtx=0").  The impact of this rule is that an answerer
will not try to use silence suppression with any endpoint that does
not offer it, making silence suppression support bilateral even with
non-JSEP endpoints.
Paragraph (version B):
Silence suppression in the answer is handled as described in
sec.voiceactivitydetection1, with one exception: if support for
silence suppression was not indicated in the offer, the
VoiceActivityDetection parameter has no effect, and the answer MUST
be generated as if VoiceActivityDetection was set to "false".  This
is done on a per-codec basis (e.g., if the offerer somehow offered
support for CN but set "usedtx=0" for Opus, setting
VoiceActivityDetection to "true" would result in an answer with CN
codecs and "usedtx=0").  The impact of this rule is that an answerer
will not try to use silence suppression with any endpoint that does
not offer it, making silence suppression support bilateral even with
non-JSEP endpoints.
Paragraph (version A):
address should instead configure the ICE agent to use only relay
candidates.
Paragraph (version B):
address MUST instead configure the ICE agent to use only relay
candidates.