Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id B6AED12B04B
 for <rtcweb@ietfa.amsl.com>; Tue, 21 Jun 2016 07:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9lyUC__cJMwd for <rtcweb@ietfa.amsl.com>;
 Tue, 21 Jun 2016 07:24:09 -0700 (PDT)
Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com
 [173.203.187.65])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 0AFBA12B046
 for <rtcweb@ietf.org>; Tue, 21 Jun 2016 07:24:08 -0700 (PDT)
Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain
 [127.0.0.1])
 by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 254003804C6;
 Tue, 21 Jun 2016 10:24:03 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender:
 fluffy-AT-iii.ca) with ESMTPSA id 3849138042C; 
 Tue, 21 Jun 2016 10:24:02 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.169])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA)
 by 0.0.0.0:465 (trex/5.5.4); Tue, 21 Jun 2016 10:24:03 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF261485CC@MCHP04MSX.global-ad.net>
Date: Tue, 21 Jun 2016 08:24:01 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA35D2CF-8257-42FC-8B08-774EE3591CF9@iii.ca>
References: <D746D31A-B9C3-4CAE-AA57-6047ADCD84EE@iii.ca>
 <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net>
 <CA+9kkMDhVt-11cCYtgrN0fzxmVVNkcpgVfs=1oeuvo78ySjqhg@mail.gmail.com>
 <9F33F40F6F2CD847824537F3C4E37DDF261485CC@MCHP04MSX.global-ad.net>
To: "Hutton, Andrew" <andrew.hutton@unify.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/7fXqkxAwnI57zG1cLlWxpjGTavw>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list
 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>,
 <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>,
 <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2016 14:24:11 -0000


I don't think we had consensus on MUST do RETURN. It is very clear that =
browser are not forbidden from doing RETURN so saying MAY implement some =
RFC does not seem very controversial as long as it does not extend the =
list of normative dependencies.=20


> On Jun 21, 2016, at 2:35 AM, Hutton, Andrew <andrew.hutton@unify.com> =
wrote:
>=20
> Hi Ted / All,
> =20
> Thanks for suggesting some text but your text is I believe not correct =
in that section 6.2 of draft-ietf-rtcweb-return only covers the conflict =
between auto-discovered and configured TURN servers not the conflict =
between configured/auto-discovered and application provided TURN =
servers. I therefore suggest the following text:
> =E2=80=9CWebRTC 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]=E2=80=9D=
.
>=20
> Personally I think it would be better to make RETURN a =E2=80=9CMUST=E2=80=
=9D level requirement as getting consistency in the browser =
implementations here is I think important but I understand that this =
might be too much for many people and there are no implementations out =
there at the moment.
> =20
> Regards
> Andy
> =20
> =20
> =20
> =20
> From: Ted Hardie [mailto:ted.ietf@gmail.com]=20
> Sent: 20 June 2016 18:44
> To: Hutton, Andrew
> Cc: Cullen Jennings; RTCWeb IETF
> Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - =
return.
> =20
> Hi Andrew,
>=20
> Thanks for re-reading the draft for last call.
>=20
> If the following: "WebRTC browsers MUST support configuration of STUN =
and TURN servers, both from browser configuration and from an =
application."  were modified to "WebRTC browsers MUST support =
configuration of STUN and TURN servers, both from browser configuration =
and from an application.  If a WebRTC browser implements RETURN =
[draft-ietf-rtcweb-return] to permit the use of TURN proxies, it should =
resolve conflicts among discovered or configured proxies as set out in =
section 6.2 of [draft-ietf-rtcweb-return]." would that resolve the issue =
for you?
>=20
> regards,
>=20
> Ted =20
> =20
> On Mon, Jun 20, 2016 at 3:11 AM, Hutton, Andrew =
<andrew.hutton@unify.com> wrote:
> =
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-14#section-3.4 =
states "WebRTC browsers MUST support configuration of STUN and TURN =
servers, both from browser configuration and from an application".
>=20
> The return draft (draft-ietf-rtcweb-return) explains how to deal with =
the situation when both are available and actually this also covers the =
case when a TURN server is auto-discovered as well as being provided by =
the application.  So should the text be expanded to say that =
"configuration" also included auto-discovery and include a reference to =
-rtcweb-return?
>=20
> Sorry for the last minute comment I have read this so many times =
before.
>=20
> Regards
> Andy
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen
> > Jennings
> > Sent: 09 June 2016 18:36
> > To: RTCWeb IETF
> > Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports
> >
> > This is the working group last call for =
draft-ietf-rtcweb-transports-14
> >
> > Please send any comments to this list by June 22, 2016.
> >
> > Thanks,
> > Cullen, Ted, and Sean
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

