Subject: [tram] TURN Server Discovery - WG feedback

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 9 Mar 2015 02:19:54 +0000

Hi Folks,
Based on some of the comments on the mailing list for https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01, we'd like feedback from the WG on the following:

  1.  Reverse PTR lookup on the client’s public IP address to determine the domain-name (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies on STUN server discovery, which is a concern. Given this, we’re considering removing sections pertaining to resolution using IP address (Sections 4.1.2 & 4.2.1).
  2.  DNS Service Discovery - Is there interest in the WG to include this mechanism in the draft?

-Prashanth

---

From: Justin Uberti <[email-masked]>
Date: Sun, 8 Mar 2015 20:46:45 -0700

On Sun, Mar 8, 2015 at 7:19 PM, Prashanth Patil (praspati) <
[email-masked]> wrote:

>  Hi Folks,
> Based on some of the comments on the mailing list for
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01,
> we'd like feedback from the WG on the following:
>
>    1. Reverse PTR lookup on the client’s public IP address to determine
>    the domain-name (
>    https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#section-4.1.2)
>    - Using RFC7216 to achieve this has dependencies on STUN server discovery,
>    which is a concern. Given this, we’re considering removing sections
>    pertaining to resolution using IP address (Sections 4.1.2 & 4.2.1).
>
> I think this would be a good simplification.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Mar 2015 04:54:33 +0000

+1 to support DNS-SD; I am okay with removing [1] or make it optional to implement.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Prashanth Patil (praspati)
Sent: Monday, March 09, 2015 7:50 AM
To: [email-masked]
Subject: [tram] TURN Server Discovery - WG feedback

Hi Folks,

  1.  Reverse PTR lookup on the client's public IP address to determine the domain-name (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies on STUN server discovery, which is a concern. Given this, we're considering removing sections pertaining to resolution using IP address (Sections 4.1.2 & 4.2.1).
  2.  DNS Service Discovery - Is there interest in the WG to include this mechanism in the draft?
-Prashanth

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Mar 2015 08:44:18 -0400

Le 2015-03-08 22:19, Prashanth Patil (praspati) a écrit :
>     the domain-name
>     (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#section-4.1.2)
>     - Using RFC7216 to achieve this has dependencies on STUN server
>     discovery, which is a concern. Given this, we’re considering
>     removing sections pertaining to resolution using IP address
>     (Sections 4.1.2 & 4.2.1).

I'm OK with removing this based on Adam's comments, but I truly don't 
understand the rationale above.

>  2. DNS Service Discovery - Is there interest in the WG to include this

I say if Adam thinks this can work, let's give it a shot.

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 13 Mar 2015 23:24:08 +0000

Hi Simon,

On 3/9/15, 5:44 AM, "Simon Perreault" <[email-masked]> wrote:

>>  1. Reverse PTR lookup on the client¹s public IP address to determine
>>     the domain-name
>>     
>>     discovery, which is a concern. Given this, we¹re considering

The draft suggests that one of the discovery mechanisms be Service
Resolution, as per RFC 5928 - an NAPTR lookup for RELAY application
service within the given 'domain¹. We¹ve explained 3 possible means a
client could use to retrieve domain names. One of the means is to derive
the domain name from the client¹s IP address i.e. reverse PTR lookup. To
discover a TURN server provided by the ISP, given that a client is almost
certainly going to be behind a NAT, the client would have to determine
it¹s public IP address. As Adam has rightly points out, the client would
have to use a STUN server to do this. This would mean the client has to
discover a STUN server, which has the same problems as TURN discovery.
Given these problems, we were considering removing sections that describe
domain lookup using IP address.

-Prashanth

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Mar 2015 08:14:15 -0400

Le 2015-03-13 19:24, Prashanth Patil (praspati) a écrit :
> it¹s public IP address.

No. If I'm on a private network, I want to fetch the PTR record
corresponding to my private IP address. That's the one the network
administrator would use to configure the TURN server's location.

This relies on a split-view DNS server populated with PTR records for
the network's private address range. That is common practice in
enterprise networks.

Simon

> As Adam has rightly points out, the client would

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Mar 2015 13:13:42 -0500

On 3/16/15 07:14, Simon Perreault wrote:
> If I'm on a private network, I want to fetch the PTR record 
> administrator would use to configure the TURN server's location. This 
> relies on a split-view DNS server populated with PTR records for the 
> network's private address range. That is common practice in enterprise 
> networks.

That seems downright Rube Goldberg-esque compared to the more direct 
approach of asking for the address of the TURN server via mDNS.

/a

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Mar 2015 14:17:31 -0400

> approach of asking for the address of the TURN server via mDNS.

Agreed. I'm not suggesting that it's better than mDNS. I'm just pointing
out that the "recursive discovery" rationale for rejecting the PTR
method doesn't make sense.

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 16 Mar 2015 20:08:00 +0000

>method doesn't make sense.

If we¹re fine with recommending the PTR method to the private network, we
can retain some of the text. But if included DNS-SD, the PTR method may
not be necessary.

-Prashanth

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