Message-ID: <51ED9318.6000003@nostrum.com>
Date: Mon, 22 Jul 2013 15:16:24 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Rajmohan Banavi <rajmohanbanavi@gmail.com>
References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com>
 <CALe60zBA_unaQekMkKwKwKNRPbJjECAtJ9bAV=fv6V6Mdfon6Q@mail.gmail.com>
 <CAOJ7v-2WGi_fD9mVx+dtZBo+X4-sXxXZFek9mt2cAmrqFCyYMg@mail.gmail.com>
 <CAJWm+fGBDec_66WMBVhsv5TD8hVzDoOtd5CGs7xAHZqkYtDGBg@mail.gmail.com>
 <51E70106.8060100@goodadvice.pages.de>
 <CAJWm+fGUEH43bgR1j56qea3+uSVQ63myr1tZkrdYRGEmBw=zew@mail.gmail.com>
 <CAOJ7v-2wzEQXSMPM4bnGW5_0ciDf9VuY1nb2xp=Wbqe0Rq5yZA@mail.gmail.com>
 <CAJWm+fE1G2r0TcUAcZUVCP0WRSC35JFBdZ-oMqJfAykhNExqyA@mail.gmail.com>
In-Reply-To: <CAJWm+fE1G2r0TcUAcZUVCP0WRSC35JFBdZ-oMqJfAykhNExqyA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070307020801070707040107"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a
 trusted mechanism)
Cc: behave <behave@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for
 draft-uberti-behave-turn-rest-00.txt
Precedence: list

This is a multi-part message in MIME format.
--------------070307020801070707040107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 7/18/13 07:28, Rajmohan Banavi wrote:
> Hi  Justin, comments inline with additional comments at the end.
>
>     Correct, but that is a significant advantage, especially when the
>     web and TURN servers are separate entities.
>
>
> IMHO, the standard spec should not be based on any specific 
> implementation method. Now I agree that the TURN server validation 
> becomes easier using this method because it does not have to do some 
> sort of lookup. However, some another TURN server implementer can 
> achieve the same functionality by providing REST API but using 
> randomly generated pasword (rather than use HMAC) and using some sort 
> of lookup for TURN username when TURN ALLOCATE request is received.

I think the value here -- the value in defining a common scheme for 
password generation -- is that I could get an off-the-shelf TURN server 
from arbitrary vendor A, and run an off-the-shelf credential server from 
abitrary vendor B, and it would all work together. What you propose 
requires collusion between the TURN server provider and the credential 
server provider, using a not-yet-defined (and, if I read your proposal, 
never-publicly-defined) protocol to share credential information via a 
back-channel.

What Justin proposes gets us this inter-vendor interop cheaply and 
easily. What you're counterproposing forces people into a single-vendor 
(or, at least, partnered) solution, which kinda defeats the purpose of 
defining this in an SDO in the first place.

/a

--------------070307020801070707040107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 7/18/13 07:28, Rajmohan Banavi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJWm+fE1G2r0TcUAcZUVCP0WRSC35JFBdZ-oMqJfAykhNExqyA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi &nbsp;Justin, comments inline with additional
        comments at the end.
        <div class="gmail_extra"><br>
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">
                    <div>Correct, but that is a significant advantage,
                      especially when the web and TURN servers are
                      separate entities.&nbsp;</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div>
              <br>
            </div>
            <div>IMHO, the standard spec should not be based on any
              specific implementation method. Now I agree that the TURN
              server validation becomes easier using this method because
              it does not have to do some sort of lookup. However, some
              another TURN server implementer can achieve the same
              functionality by providing REST API but using randomly
              generated pasword (rather than use HMAC) and using some
              sort of lookup for TURN username when TURN ALLOCATE
              request is received.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I think the value here -- the value in defining a common scheme for
    password generation -- is that I could get an off-the-shelf TURN
    server from arbitrary vendor A, and run an off-the-shelf credential
    server from abitrary vendor B, and it would all work together. What
    you propose requires collusion between the TURN server provider and
    the credential server provider, using a not-yet-defined (and, if I
    read your proposal, never-publicly-defined) protocol to share
    credential information via a back-channel.<br>
    <br>
    What Justin proposes gets us this inter-vendor interop cheaply and
    easily. What you're counterproposing forces people into a
    single-vendor (or, at least, partnered) solution, which kinda
    defeats the purpose of defining this in an SDO in the first place.<br>
    <br>
    /a<br>
  </body>
</html>

--------------070307020801070707040107--