Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 6 Feb 2015 10:18:48 +0000

Inline [TR]

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, February 06, 2015 6:21 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Benjamin Schwartz; Simon Perreault; [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

I agree with Simon and Ben in being skeptical about this proposal.

The client is the only party which knows exactly what 'privacy' means, and there is no trivial way to serialize this into a single attribute for the TURN server.

[TR] We are evaluating how the client can covey its ‘privacy’ needs in this new attribute to the TURN server so that it can take appropriate action and the server responds if the client ‘privacy’ requirement can be met fully or partially.

-Tiru

As such, I think this decision should be left entirely to the client.

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address.

[TR3] The difference this draft brings in is that it helps the TURN server (offered by a global or cloud service) to determine that the client wants privacy and level of privacy required conveyed in the new STUN attribute, the TURN server determines suitable alternate TURN server that can offer the required level of privacy.

-Tiru

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Benjamin Schwartz <[email-masked]>
Date: Fri, 6 Feb 2015 11:19:20 -0500

I appreciate the goal of this work.  Maybe a slightly different strategy
would be more easily accepted in the working group.  What if the client
could query the server for a list of alternate TURN servers?  Then the
client could have the option of selecting a server based on geolocation,
but the client would not have to convey its privacy goals to the server
explicitly.

Inline [TR]

*From:* Justin Uberti [mailto:[email-masked]]
*Sent:* Friday, February 06, 2015 6:21 AM
*To:* Tirumaleswar Reddy (tireddy)
*Cc:* Benjamin Schwartz; Simon Perreault; [email-masked]
*Subject:* Re: [tram] FW: New Version Notification for
draft-reddy-tram-turn-ipaddress-privacy-00.txt

The client is the only party which knows exactly what 'privacy' means, and
there is no trivial way to serialize this into a single attribute for the
TURN server.

[TR] We are evaluating how the client can covey its ‘privacy’ needs in this
new attribute to the TURN server so that it can take appropriate action and
the server responds if the client ‘privacy’ requirement can be met fully or
partially.

-Tiru

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

I agree that the client can do equally well itself, by sending a STUN
Binding Request and comparing the response to the TURN server's own IP
address.

[TR3] The difference this draft brings in is that it helps the TURN server
(offered by a global or cloud service) to determine that the client wants
privacy and level of privacy required conveyed in the new STUN attribute,
the TURN server determines suitable alternate TURN server that can offer
the required level of privacy.

-Tiru

[email-masked]