Draft: draft-ietf-rtcweb-jsep

Commentary: Is n't actpass always offered ? Not sure I understand the context here . 
 My understanding is the JSEP compliant implementations are suppose to always use ' actpass ' in offers . But you may interop with something which will only present it 's current role in a subsequent offer . 
 If that 's the intent , I think that rationale should be spelled out in the text here . 
 LGTM 
 OK , so this took a bit of research to get clear on . First , let me state what I believe the rules are : endpoints MUST always send actpass in offers . This is defined in http://rtcweb- and never modified in 5.2.2 initial answers , JSEP endpoints ( a ) MUST send active or passive . ( b ) if the other side sent something other than actpass , MUST send the complement ( c ) if the other side sent actpass , SHOULD send active . http://rtcweb- subsquent answers , JSEP endpoints : ( a ) MUST send active or passive . ( b ) MUST send something consistent with the current state  The text we are working on here is the initial answer text , therefore , I think that rule 3(b ) does not apply , which , I believe , makes the current text correct . 
 The explanation from EKR above looks right to me 
 Actually , 5763 requires it to always be actpass , so we can remove the non - JSEP section . Ugh , but the revision does not require it : 
 I think we have two options here : dtls - sdp modified ( the offending text is in )  handle this condition , as above . Does anyone know why we changed the rules in dtls - sdp ? ^^ ? 
 I would have to check the archives in order to find out why we relaxed the must - use - actpass - in - initial - offer rule . Most likely people did n't see a need for not allowing other values . Having said that ,  can always mandate sending " actpass " in initial offers . A JSEP implementation must of course still be prepared to receive something else . 
 That 's probably fine , as long as dtls - sdp ensures that everyone has to handle actpass in offers . I do n't want people trying to avoid implementing part of the spec by only supporting passive mode or some such . 
 If you think there is some text indicating that support of " actpass " is optional , that should be corrected . 
 OK , after all that discussion , I think we need to keep the text that says only JSEP endpoints are guaranteed to do this , but they wwill always do so , which means , I believe that the current text is right , modulo the repeated " the " which the new commit fixes . 
 Page 52 , bullet starting " An ' a = setup ' line " : add the words " when allowed " to the end of the bullet . 
 Text is An " a = setup " line , as specified in [ RFC4145 ] , Section 4 , and clarified for use in DTLS - SRTP scenarios in [ RFC5763 ] , Section 5 . The role value in the answer MUST be " active " or " passive " ; the " active " role is RECOMMENDED . Fix per adam .
Paragraph (version B):
An "a=setup" line, as specified in RFC4145, Section 4, and
clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
The role value in the answer MUST be "active" or "passive".  When
the offer contains the "actpass" value, as will always be the case
with JSEP endpoints, the answerer SHOULD use the "active" role.
Offers from non-JSEP endpoints MAY send other values for
"a=setup", in which case the answer MUST use a value consistent
with the value in the offer.