Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports

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. 

> On Jun 21, 2016, at 2:35 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
> 
> Hi Ted / All,
>  
> 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:
> “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]”.
> 
> Personally I think it would be better to make RETURN a “MUST” 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.
>  
> Regards
> Andy
>  
>  
>  
>  
> From: Ted Hardie [mailto:ted.ietf@gmail.com] 
> 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.
>  
> Hi Andrew,
> 
> Thanks for re-reading the draft for last call.
> 
> 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?
> 
> regards,
> 
> Ted  
>  
> 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".
> 
> 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?
> 
> Sorry for the last minute comment I have read this so many times before.
> 
> Regards
> Andy
> 
> 
> 
> 
> 
> > -----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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb