Subject: [rtcweb] Please review: Fixes to RTCWEB review comments

From: Harald Alvestrand <[email-masked]>
Date: Tue, 2 Aug 2016 13:48:59 +0200

I believe I now have PRs covering all the issues raised during and after
Last Call that were not fixed in -15.

These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly
editorial.

Please review the PRs at
https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there are
no objections, I hope to merge them early Wednesday morning CET (that's
late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can
use as basis for balloting on Thursday (August 4).

Harald

---

From: Andy Hutton <[email-masked]>
Date: Tue, 2 Aug 2016 14:40:52 +0100

There is still the issue of what to say in section 3.4 about auto-discovery
of TURN servers and the conflicts between application provided, auto
discovered, and configured TURN servers.

Section 3.4 currently includes the statement "WebRTC browsers MUST support
configuration of STUN and TURN servers, both from browser configuration and
from an application".

Previously I suggested the text:

"WebRTC browsers MUST support configuration of STUN and TURN servers, both
from browser configuration and from an application. WebRTC browsers MAY
also discover TURN servers using TURN Auto-Discovery
[draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TURN
servers provided by configuration, auto-discovery, and the application
WebRTC browsers MAY implement the procedures specified in Recursively
Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]”.

This suggestion was based on the fact that the -return- draft is I believe
the only place where there is a statement about what to do about the
conflict between application provided and locally configured TURN servers.

Regards
Andy

On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand <[email-masked]>
wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Michael Davey <[email-masked]>
Date: Wed, 3 Aug 2016 15:19:44 +0100

...And I have previously proposed that the second instance of MAY from
Andy's text be upgraded to "SHOULD .." or "are RECOMMENDED to ...".

On 2 August 2016 at 14:40, Andy Hutton <[email-masked]> wrote:

> There is still the issue of what to say in section 3.4 about
> auto-discovery of TURN servers and the conflicts between application
> provided, auto discovered, and configured TURN servers.
>
> Section 3.4 currently includes the statement "WebRTC browsers MUST
> support configuration of STUN and TURN servers, both from browser
> configuration and from an application".
>
> "WebRTC browsers MUST support configuration of STUN and TURN servers,
> both from browser configuration and from an application. WebRTC browsers
> MAY also discover TURN servers using TURN Auto-Discovery

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Aug 2016 22:02:25 +0200

My problem with adding this is that it's new text after WG Last Call,
and I don't recall a consensus to add the text - my memory is that the
discussions at IETFs were inconclusive, and that no declaration of
consensus to add has been made by the chairs.

New technical content added the day before IESG telechat treatment is
likely to make the IESG nervous about document stability.

I'll take instruction from the chairs on this issue, but won't add this
text to -15.

On 08/03/2016 04:19 PM, Michael Davey wrote:
> On 2 August 2016 at 14:40, Andy Hutton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     auto-discovery of TURN servers and the conflicts between
>     application provided, auto discovered, and configured TURN servers.
>
>     "WebRTC browsers MUST support configuration of STUN and TURN
>     servers, both from browser configuration and from an application.
>     WebRTC browsers MAY also discover TURN servers using TURN
>     Auto-Discovery [draft-ietf-tram-turn-server-discovery]. To resolve
>     conflicts between TURN servers provided by configuration,
>     auto-discovery, and the application WebRTC browsers MAY implement
>     the procedures specified in Recursively Encapsulated TURN (RETURN)
>     [draft-ietf-rtcweb-return]”.
>
>     This suggestion was based on the fact that the -return- draft is I
>     believe the only place where there is a statement about what to do
>     about the conflict between application provided and locally
>     configured TURN servers.
>
>     Regards
>     Andy
>
>
>
>     On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: Andy Hutton <[email-masked]>
Date: Thu, 4 Aug 2016 07:27:12 +0100

I believe the comment was made during WGLC but Ii cannot check that right
now.

Do you believe there is anything controversial in the text?

My thinking was it was just referring to other drafts to clarify the case
when there are conflicts.

Andy

On Wednesday, 3 August 2016, Harald Alvestrand <[email-masked]> wrote:

> My problem with adding this is that it's new text after WG Last Call, and
> I don't recall a consensus to add the text - my memory is that the
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> believe the only place where there is a statement about what to do about
>> the conflict between application provided and locally configured TURN
>> servers.
>>
>> Regards
>> Andy
>>
>>
>>
>> On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> >
>> > [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Michael Davey <[email-masked]>
Date: Thu, 4 Aug 2016 11:05:00 +0100

Yes it was.  The email subject line was: "WGLC comment on
draft-ietf-rtcweb-transports - return", discussion 20th-22nd June.

I agree its just a reminder that TURN servers may be auto-discovered as
discussed elsewhere in the spec. and what to do in the case of conflicts.

-- 
Michael

On 4 August 2016 at 07:27, Andy Hutton <[email-masked]> wrote:

>>> [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between
>>> TURN servers provided by configuration, auto-discovery, and the application