Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-15: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 30 April 2015 07:47 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E761ACED0; Thu, 30 Apr 2015 00:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 jXnSUf8b_rcw; Thu, 30 Apr 2015 00:47:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46BE1ACECF; Thu, 30 Apr 2015 00:47:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1B6D6BDD8; Thu, 30 Apr 2015 08:47:04 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDkSu39RUocE; Thu, 30 Apr 2015 08:47:03 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.22]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DC6D9BDCC; Thu, 30 Apr 2015 08:47:02 +0100 (IST)
Message-ID: <5541DDF6.7000205@cs.tcd.ie>
Date: Thu, 30 Apr 2015 08:47:02 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Oleg Moskalenko <mom040267@gmail.com>
References: <20150428212204.9453.5930.idtracker@ietfa.amsl.com> <D1667313.5436C%praspati@cisco.com> <554142C5.6030505@cs.tcd.ie> <CALDtMrJFBJKL-chgCF48N2vP9uM3s07zST2kLT_yUrXRFiJoJg@mail.gmail.com>
In-Reply-To: <CALDtMrJFBJKL-chgCF48N2vP9uM3s07zST2kLT_yUrXRFiJoJg@mail.gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/t4Gf_rXn7aJNsldfBw3uGNJobUA>
Cc: "Prashanth Patil (praspati)" <praspati@cisco.com>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "draft-ietf-tram-turn-third-party-authz@ietf.org" <draft-ietf-tram-turn-third-party-authz@ietf.org>, "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>, "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" <draft-ietf-tram-turn-third-party-authz.ad@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" <draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org>
Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-15: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2015 07:47:31 -0000


On 30/04/15 02:02, Oleg Moskalenko wrote:
> 
> different implementations of what ? TURN Servers do not have to
> interact with each other. The interactions are between WebRTC server
> and TURN servers. 

Clearly.

> I see it as perfectly OK if different TURN servers
> access different WebRTC servers in a different manner. 

That is not the same as picking a mandatory to implement method,
which is what I'm arguing for.

> This WG is
> about STUN and TURN; I do not think that we have to deal with WebRTC
> servers standardization. I believe that the document addresses the
> TURN server operations standard in a proper way, and leaves the
> question of WebRTC to their WG.
> 
> How the TURN server stores the credentials, amd how those credentials
> are getting filled in the database, is not the topic of this WG, I
> believe.

We disagree then. ISTM that either everyone will implement 4.1.1 or
else this specification will produce interop failures or go unused
when the probability that a WebRTC server and TURN server share a key
is not sufficiently high for people to bother turning this on. (And
yes, that's as fallible prediction as most people's:-)

S.