Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Feb 2017 05:37:54 +0900

Dear TRAMsters,

On Fri, Jan 13, 2017 at 12:59 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> This revision addresses comments from Brandon.
>
> -Tiru
>

How close are we to asking Terry to clear the (last remaining) DISCUSS?

Thanks,

Spencer

>
>
> > -----Original Message-----
> > From: tram [mailto:[email-masked]] On Behalf Of internet-
> > [email-masked]
> > Sent: Friday, January 13, 2017 9:28 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the TURN Revised and Modernized of the IETF.
> >
> >         Title           : TURN Server Auto Discovery
> >         Authors         : Prashanth Patil
> >                           Tirumaleswar Reddy
> >                           Dan Wing
> >       Filename        : draft-ietf-tram-turn-server-discovery-12.txt
> >       Pages           : 16
> >       Date            : 2017-01-12
> >
> > Abstract:
> >    Current Traversal Using Relays around NAT (TURN) server discovery
> >    mechanisms are relatively static and limited to explicit
> >    configuration.  These are usually under the administrative control of
> >    the application or TURN service provider, and not the enterprise,
> >    ISP, or the network in which the client is located.  Enterprises and
> >    ISPs wishing to provide their own TURN servers need auto discovery
> >    mechanisms that a TURN client could use with no or minimal
> >    configuration.  This document describes three such mechanisms for
> >    TURN server discovery.
> >
> >    This draft updates [RFC5766] to relax the requirement for mutual
> >    authentication in certain cases.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-12
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-
> server-discovery-12
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 1 Feb 2017 16:00:37 -0500

Le 2017-02-01 à 15:37, Spencer Dawkins at IETF a écrit :
> Dear TRAMsters,
> 
> On Fri, Jan 13, 2017 at 12:59 PM, Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

Thanks for the reminder.

If my co-chair and the authors have no objection, I think we're ready.

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 2 Feb 2017 06:11:55 +0900

Hi, Simon,

> If my co-chair and the authors have no objection, I think we're ready.

I'll give this 24 hours for people to chime in, but I do want to ping
Terry.

It's a little-appreciated thing, but AD ballot positions go away when ADs
go away; this document has 12 yes/no objections now, and you need 10 for
approval, and three are from ADs who are stepping down in March ;-)

Spencer

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 2 Feb 2017 01:53:36 +0000

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Thursday, February 2, 2017 2:31 AM
> To: Spencer Dawkins at IETF <[email-masked]>; Tirumaleswar
> Reddy (tireddy) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
> 

Yup, draft is ready from our side.

Cheers,
-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Fri, 3 Feb 2017 00:23:41 +0100

The -12 version of the draft does not include major remedies of flaws that were un-addressed long before the DISCUSS, nor the latest regarding the possible use of (D)TLS for auto discovered turn servers provided the local or access network administrator, see

https://www.ietf.org/mail-archive/web/tram/current/msg02216.html 

For the latest discussed, see

https://www.ietf.org/mail-archive/web/tram/current/msg02279.html 

>> However, I think we need agreement on the justification for such a

> change.

> [Karl] Justification is in the (A), (B), (C) and (D) of

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02254.html> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html

> where saying Binding instead Allocate, is necessary to achieve (A) and (B), and improves (C) and (D).

Brandon> It is true that you have provided a justification for the change.

https://www.ietf.org/mail-archive/web/tram/current/msg02296.html 

The (D)TLS mandating was Author's idea to throw into version -10 during the discuss and remains in this version -11, breaking the consensus text since version -7.

https://www.ietf.org/mail-archive/web/tram/current/msg02297.html

STUN dummy authentication instead of (D)TLS as suggested by Oleg Moskalenko

I have inserted my (now edited and adopted to the latest) redlining, removal of blue options etc. into the -12 draft text as attached, for the author to copy from and paste.

Without my red lining, current version -12 is in conflict with RFC7478 (Web Real-Time Communication Use Cases and Requirements)  and does not meet the need of [I-D.ietf-rtcweb-return] (Recursively Encapsulated TURN) (see under redlined 7.2)

and it does not do what was set out in the Charter and “Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs”

Further, the authors have in version -12 (compared to from before DISCUSS)  changed the text “  6.  Discovery using Anycast “ to:

 <https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt

“IP anycast can also be used for TURN service discovery.  A packet

   sent to an anycast address is delivered to the "topologically

   nearest" network interface with the anycast address.  Using the TURN

   anycast address, the only two things that need to be deployed in the

   network for discovery are the two things that actually use TURN.

   When a client requires TURN services, it sends a TURN allocate

   request to the assigned anycast address.  A TURN anycast server

   performs checks 1 to 7 discussed in Section 6.2 of [RFC5766].  If all

   checks pass, the TURN anycast server MUST respond with a 300 (Try

   Alternate) error as described in Section 2.9 of [RFC5766]; The

   response contains the TURN unicast address in the ALTERNATE-SERVER

   attribute.  For subsequent communication with the TURN server, the

   client uses the responding server's unicast address.  This has to be

   done because two packets addressed to an anycast address may reach

   two different anycast servers.  The client, thus, also needs to

   ensure that the initial request fits in a single packet.  An

   implementation may choose to send out every new TURN Allocation

   request to the anycast address to discover the closest and the most

   optimal unicast address for the TURN server.”

The highlighted “A TURN anycast server”  is nothing known nor described (in fact there would have to be TWO TURN servers, one deployed at the anycast address and another TURN server deployed at the unicast address, reacting differently to the Allocation request) for this to work as clarified in WG discussions with Simon). 

The last sentence “An  implementation may choose to send out every new TURN Allocation request to the anycast address to discover the closest and the most optimal unicast address for the TURN server.” violates security and deployment considerations (see red lined considerations in attached).

Further, the authors have in version -12 (compared to from before DISCUSS)  changed the text “7.2.  Recursively Encapsulated TURN “ to:

 <https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt

“WebRTC endpoints SHOULD treat any TURN server discovered through the

   mechanisms described in this specification as an enterprise/gateway

   or access network server, in accordance with Recursively Encapsulated

   TURN [I-D.ietf-rtcweb-return].”

The text is a contradiction, since the return draft deals with TURN servers provided by the local or access network, not other TURN servers discovered by this draft.

Current -12 draft cannot be considered to be an RFC!

I suggest the redline version of draft -12 attached is chimed into now and quickly merged into a version -13, so we can avoid the "Conflict Resolution and Appeals" process hinted about in

https://www.ietf.org/mail-archive/web/tram/current/msg02202.html, further delaying what is needed for Internet real-time communication and especially for WebRTC.

/Karl 

Från: tram [ <mailto:[email-masked]> mailto:[email-masked]] För Spencer Dawkins at IETF
Skickat: den 1 februari 2017 22:12
Till: Simon Perreault
Kopia:  <mailto:[email-masked]> [email-masked]; Tirumaleswar Reddy (tireddy)
Ämne: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

Hi, Simon,

On Thu, Feb 2, 2017 at 6:00 AM, Simon Perreault < <mailto:[email-masked]> [email-masked]> wrote:

Le 2017-02-01 à 15:37, Spencer Dawkins at IETF a écrit :
> < <mailto:[email-masked]> [email-masked] <mailto: <mailto:[email-masked]> [email-masked]>> wrote:
>

Thanks for the reminder.

I'll give this 24 hours for people to chime in, but I do want to ping Terry. 

It's a little-appreciated thing, but AD ballot positions go away when ADs go away; this document has 12 yes/no objections now, and you need 10 for approval, and three are from ADs who are stepping down in March ;-)

Spencer

---

From: Simon Perreault <[email-masked]>
Date: Fri, 3 Feb 2017 08:42:31 -0500

Karl,

There is no consensus in the working group behind this new anycast
mechanism. Therefore it can not be added to the draft, and the mechanism
defined in RFC 5766 remains.

Thanks,
Simon

Le 2017-02-02 à 18:23, Karl Stahl a écrit :
> The -12 version of the draft does not include major remedies of flaws
> that were un-addressed long before the DISCUSS, nor the latest regarding
> the possible use of (D)TLS for auto discovered turn servers provided the
> local or access network administrator, see
> 
>> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
> 
> The (D)TLS mandating was Author's idea to throw into version -10 during
> the discuss and remains in this version -11, breaking the consensus text
> since version -7.
> 
>  
> 
> I have inserted my (now edited and adopted to the latest) redlining,
> removal of blue options etc. into the -12 draft text as attached, for
> the author to copy from and paste.
> 
>  
> 
> Without my red lining, current version -12 is in conflict with RFC7478
> (Web Real-Time Communication Use Cases and Requirements)  and does not
> meet the need of [I-D.ietf-rtcweb-return] (Recursively Encapsulated
> TURN) (see under redlined 7.2)
> 
> and it does not do what was set out in the Charter and “Milestone 3:
> TURN server auto-discovery mechanism for enterprise and ISPs”
> 
>  
> 
> Further, the authors have in version -12 (compared to from before
> DISCUSS)  changed the text “  6.  Discovery using Anycast “ to:
> 
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
> 
> The highlighted “A TURN anycast server”  isnothing known nor described
> (in fact there would have to be TWO TURN servers, one deployed at the
> anycast address and another TURN server deployed at the unicast address,
> reacting differently to the Allocation request) for this to work as
> clarified in WG discussions with Simon).
> 
>  
> 
> The last sentence “An  implementation may choose to send out every new
> TURN Allocation request to the anycast address to discover the closest
> and the most optimal unicast address for the TURN server.” violates
> security and deployment considerations (see red lined considerations in
> attached).
> 
>  
> 
> Further, the authors have in version -12 (compared to from before
> DISCUSS)  changed the text “7.2.  Recursively Encapsulated TURN “ to:
> 
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
> 
> The text is a contradiction, since the return draft deals with TURN
> servers provided by the local or access network, not other TURN servers
> discovered by this draft.
> 
>  
> 
> *Current -12 draft cannot be considered to be an RFC!*
> 
>  
> 
> I suggest the redline version of draft -12 attached is chimed into now
> and quickly merged into a version -13, so we can avoid the "Conflict
> Resolution and Appeals"process hinted about in
> 
> https://www.ietf.org/mail-archive/web/tram/current/msg02202.html,
> further delaying what is needed for Internet real-time communication and
> especially for WebRTC.
> 
>  
> 
> /Karl
> 
>  
> 
> *Från:*tram [mailto:[email-masked]] *För *Spencer Dawkins at IETF
> *Skickat:* den 1 februari 2017 22:12
> *Till:* Simon Perreault
> *Kopia:* [email-masked] <mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)
> *Ämne:* Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
> 
>  
> 
> Hi, Simon,
> 
>  
> 
> On Thu, Feb 2, 2017 at 6:00 AM, Simon Perreault <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>>
> It's a little-appreciated thing, but AD ballot positions go away when
> ADs go away; this document has 12 yes/no objections now, and you need 10
> for approval, and three are from ADs who are stepping down in March ;-)
> 
>  
> 
> Spencer 
> 
> 
>

---

From: Karl Stahl <[email-masked]>
Date: Mon, 6 Feb 2017 11:10:19 +0100

Simon,

There is no consensus yet whatsoever regarding any anycast mechanism, but we
have a chance getting consensus of a working anycast mechanism, that works
for all cases, which no one has disputed as working and that is technically
superior. 

Further, it does not exist such "mechanism defined in RFC 5766" and what is
in current version -12 text is still undefined and interpreted radically
different by participating WG individuals.

Only Tiru, during the DISCUSS, after version -10 (
<https://www.ietf.org/mail-archive/web/tram/current/msg02219.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02219.html) 

referenced  <https://tools.ietf.org/html/rfc5766#section-2.9>
https://tools.ietf.org/html/rfc5766#section-2.9, which says:

"This version of TURN has been designed to *permit the future specification
of a method* of doing anycast discovery of a TURN server over UDP.

Previous to my redlined "say Binding instead of Allocate to
discover"-method, I questioned version -08 of the draft (before the DISCUSS)
(in August,
<https://www.ietf.org/mail-archive/web/tram/current/msg02081.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02081.html) but that
was not responded to by the authors (only Branded responded, but from an
authentication point of view, as if the method meant a mixture of discovery
and usage, which was confusing). 

During the DISCUSS, in response to my request to fix, Prashanth only said:
We intend to add the following to explain server behavior a little better:

“A TURN anycast server performs checks 1 to 7 discussed in Section 6.2 of
RFC5766. If all checks pass, the TURN anycast server MUST respond with a 300
(Try Alternate) error as described in [RFC5766]”

[Karl] That must be an update of RFC5766. Or does “TURN anycast server”
imply that there ALSO is a “TURN unicast server” at the same interface
accepting the Allocate request?  

That was never responded to and in your discussion with me:

https://www.ietf.org/mail-archive/web/tram/current/msg02239.html 

[Karl]> (I think Brandon assumes a TURN server listening to TWO IP addresses
that

> can respond error 300 or make an allocation, distinguished by whether the

> request was received on its anycast address or its unicast address,

[Simon] Correct.

[Karl]> and I

> think Prashanth using the term "TURN anycast server" means we really have

> TWO TURN servers to play with,

[Simon] That would be an equally valid deployment scenario.

[Karl]> and I think others interpret the draft -10

> text as if the FIRST Allocate is responded to with error 300 and
SUBSEQUENT

> Allocates actually are making allocations.

[Simon] No, that would be wrong.

NOW, reverse engineering the current -12 text to understand what may be in
the author’s mind (which they strangely enough never have spelled out), it
is NOT the “TWO LAN IP TURN servers” but the “No, that would be
wrong.”-method that is intended, see these highlights in the -12 text!

IP anycast can also be used for TURN service discovery. A packet sent to an
anycast address is delivered to the "topologically nearest" network
interface [Karl: Nearest cannot be two] with the anycast address. Using the
TURN anycast address, the only two things that need to be deployed in the
network for discovery are the two things that actually use TURN.

When a client requires TURN services, it sends a TURN allocate request to
the assigned anycast address. A TURN anycast server performs checks 1 to 7
discussed in Section 6.2 of [RFC5766]
<https://tools.ietf.org/id/draft-ietf-tram-turn-server-discovery-12.html#RFC
5766> . If all checks pass, the TURN anycast server MUST respond with a 300
(Try Alternate) error as described in Section 2.9 of [RFC5766]
<https://tools.ietf.org/id/draft-ietf-tram-turn-server-discovery-12.html#RFC
5766> ; The response contains the TURN unicast address in the
ALTERNATE-SERVER attribute. For subsequent communication with the TURN
server, the client uses the responding server's unicast address. This has to
be done because two packets addressed to an anycast address may reach two
different anycast servers. The client, thus, also needs to ensure that the
initial request fits in a single packet. An implementation may choose to
send out every new TURN Allocation request to the anycast address to
discover the closest and the most optimal unicast address for the TURN
server.

I think other participants in the discussion, also interpret the -12 text as
the “that would be wrong”-variant, or even worse, a mixture of discovery and
usage authentication (where (D)TLS might come in
(https://www.ietf.org/mail-archive/web/tram/current/msg02297.html )). 

So, current version -12 meaning of text is probably not only “wrong”, but
does not work (in addition to being undefined). Version -12 can have no
consensus, nor can that be brought into an RFC.

In order to NOW ease to get consensus for a defined and working anycast
mechanism (my redlining of the -12 text), that works for all cases (which no
one has disputed), I have just made an IPR declaration “in Alan Johnston /
Avaya style (compare https://datatracker.ietf.org/ipr/2555)” where any party
can use the proposed anycast method (for which patent was provisionally
applied for October 21, 2013) free of royalty as long as not asserting a
patent right of its owns against us. My IPR Declaration related to this I-D
should appear in day (said when submitting).

/Karl

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 3 februari 2017 14:43
Till: Karl Stahl; 'Spencer Dawkins at IETF'
Kopia: [email-masked]; 'Tirumaleswar Reddy (tireddy)'
Ämne: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
draft-ietf-tram-turn-server-discovery-12.txt

Karl,

Thanks,

Simon

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02216.html>

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02279.html>

>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02254.html>

>> where saying Binding instead Allocate, is necessary to achieve (A) and

> (B), and improves (C) and (D).

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02296.html>

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02297.html>

<https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-0
9.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt>
https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09
.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt

<https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-0
9.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt>
https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discovery-09
.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02202.html>

> *Från:*tram [ <mailto:[email-masked]> mailto:[email-masked]]
*För *Spencer Dawkins at IETF

> *Kopia:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]>
mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)

> *Ämne:* Re: [tram] I-D Action:
draft-ietf-tram-turn-server-discovery-12.txt

> < <mailto:[email-masked]> mailto:[email-masked]>> wrote:

>> < <mailto:[email-masked]%20%3cmailto:[email-masked]>
[email-masked] <mailto:[email-masked]><mailto:[email-masked]

> < <mailto:[email-masked]> mailto:[email-masked]>>> wrote:

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/tram>

 

-- 

Simon Perreault

 <https://jive.com> https://jive.com | +1 418 478 0989 ext. 1241 |
<mailto:[email-masked]> [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 7 Feb 2017 06:18:28 +0000

> Sent: Friday, February 3, 2017 7:13 PM
> To: Karl Stahl <[email-masked]>; 'Spencer Dawkins at IETF'
> <[email-masked]>
> Cc: [email-masked]; Tirumaleswar Reddy (tireddy) <[email-masked]>
> Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

Yup, https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar mechanism.
I don't see the need for a new anycast mechanism.

-Tiru

> > that were un-addressed long before the DISCUSS, nor the latest
> > regarding the possible use of (D)TLS for auto discovered turn servers
> > provided the local or access network administrator, see
> >
> > The (D)TLS mandating was Author's idea to throw into version -10
> > during the discuss and remains in this version -11, breaking the
> > consensus text since version -7.
> >
> >
> >
> > and it does not do what was set out in the Charter and "Milestone 3:
> > TURN server auto-discovery mechanism for enterprise and ISPs"
> >
> >
> >
> > DISCUSS)  changed the text "  6.  Discovery using Anycast " to:
> >
> > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discov
> > ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
> >
> > "IP anycast can also be used for TURN service discovery.  A packet
> >
> >    optimal unicast address for the TURN server."
> >
> >
> >
> > The highlighted "A TURN anycast server"  isnothing known nor described
> > anycast address and another TURN server deployed at the unicast
> > address, reacting differently to the Allocation request) for this to
> > work as clarified in WG discussions with Simon).
> >
> >
> >
> > The last sentence "An  implementation may choose to send out every new
> > and the most optimal unicast address for the TURN server." violates
> > security and deployment considerations (see red lined considerations
> > in attached).
> >
> >
> >
> > DISCUSS)  changed the text "7.2.  Recursively Encapsulated TURN " to:
> >
> > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-discov
> > ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
> >
> > "WebRTC endpoints SHOULD treat any TURN server discovered through
> the
> >
> >    TURN [I-D.ietf-rtcweb-return]."
> >
> >
> >
> > servers provided by the local or access network, not other TURN
> > servers discovered by this draft.
> >
> >
> >
> > further delaying what is needed for Internet real-time communication
> > and especially for WebRTC.
> >
> >
> >
> > /Karl
> >
> >
> >
> >> <[email-masked]
> >> <mailto:[email-masked]><mailto:[email-masked]
> > ADs go away; this document has 12 yes/no objections now, and you need
> > 10 for approval, and three are from ADs who are stepping down in March
> > ;-)
> >
> >
> >
> > Spencer
> >
> >
> >

---

From: Karl Stahl <[email-masked]>
Date: Tue, 7 Feb 2017 11:31:57 +0100

Tiru,

That does not make the version -12 text in the draft any clearer about 
what the draft's anycast method actually is. I am asking you the same 
question as I asked Simon before (and only he answered):

Does the draft assume: 

(A) a TURN server listening to TWO IP addresses (that are at different 
subnets) that can respond error 300 or make an allocation, distinguished 
by whether the request was received on its anycast address or 
its unicast address, OR

(B) we really have TWO TURN servers to play with (the one at the anycast 
address being configured to respond with the error 300, OR 

(C) the FIRST Allocate is responded to with error 300 and SUBSEQUENT
Allocates actually are making TURN allocations. 

We cannot have an RFC, not even being clear about the method specified.

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 7 februari 2017 07:18
Till: Simon Perreault; Karl Stahl; 'Spencer Dawkins at IETF'
Kopia: [email-masked]
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

> defined in RFC 5766 remains.

Yup, https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar
mechanism.
I don't see the need for a new anycast mechanism.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 7 Feb 2017 11:01:54 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
> Sent: Tuesday, February 7, 2017 4:02 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Simon Perreault'
> <[email-masked]>; 'Spencer Dawkins at IETF'
> That does not make the version -12 text in the draft any clearer about what
> the draft's anycast method actually is. I am asking you the same question as I
> asked Simon before (and only he answered):

I agree with the responses Simon has already provided to all the below questions. Further, I also don't see the need to discuss the below questions in the draft because they are only operational considerations (and have no impact on the actual protocol).

-Tiru

> subnets) that can respond error 300 or make an allocation, distinguished by
> whether the request was received on its anycast address or its unicast
> address, OR
> 
> > mechanism. Therefore it can not be added to the draft, and the
> > mechanism defined in RFC 5766 remains.
> 
> > > The -12 version of the draft does not include major remedies of
> > > flaws that were un-addressed long before the DISCUSS, nor the latest
> > > regarding the possible use of (D)TLS for auto discovered turn
> > > servers provided the local or access network administrator, see
> > >
> > > removal of blue options etc. into the -12 draft text as attached,
> > > for the author to copy from and paste.
> > >
> > >
> > >
> > > Without my red lining, current version -12 is in conflict with
> > > RFC7478 (Web Real-Time Communication Use Cases and Requirements)
> > > and does
> > not
> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
> > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
> > >
> > > The highlighted "A TURN anycast server"  isnothing known nor
> > > described (in fact there would have to be TWO TURN servers, one
> > > deployed at the anycast address and another TURN server deployed at
> > > the unicast address, reacting differently to the Allocation request)
> > > for this to work as clarified in WG discussions with Simon).
> > >
> > >
> > >
> > > The last sentence "An  implementation may choose to send out every
> > > new TURN Allocation request to the anycast address to discover the
> > > closest and the most optimal unicast address for the TURN server."
> > > violates security and deployment considerations (see red lined
> > > considerations in attached).
> > >
> > >
> > >
> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
> > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
> > >
> > > I suggest the redline version of draft -12 attached is chimed into
> > > now and quickly merged into a version -13, so we can avoid the
> > > "Conflict Resolution and Appeals"process hinted about in
> > >
> > > It's a little-appreciated thing, but AD ballot positions go away
> > > when ADs go away; this document has 12 yes/no objections now, and
> > > you need

---

From: Karl Stahl <[email-masked]>
Date: Wed, 8 Feb 2017 07:58:05 +0100

1) The A)+B) method (that Simon and I discussed) is not specified in the
draft -12 text and further referencing: 

[Tiru below]> " <https://tools.ietf.org/html/rfc7094#section-3.4>
https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar
mechanism" does not help:

- It rather states issues coming from not knowing whether a server reached
by anycast addressing, actually is at a unicast address or really is
deployed at a anycast address (which I believe is rare).

2) Further, there are no deployment considerations for the A)+B) method in
the –12 draft (compare the redlined version)

It does not even discuss or list  RFC7478 (Web Real-Time Communication Use
Cases and Requirements) that it is supposed to meet, but which the A)+B)
method is in conflict with. 

 <https://www.ietf.org/mail-archive/web/tram/current/msg02314.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02314.html and
https://www.ietf.org/mail-archive/web/tram/current/msg02254.html. 

3) And if the (more complex) A)+B) method would be properly defined and
described in some future revision, then remains (from
https://www.ietf.org/mail-archive/web/tram/current/msg02254.html):

“(trying to) exemplify/clarify the high level (important) points why we

need/want anycast discovery by saying Binding instead of Allocate. These

points are:

(A) We need an anycast discovery method for auto-discovering "a TURN server"

(not some special TURN server or arrangement of TURN servers "invented" for

being discoverable by a certain method)

(B) We need an anycast discovery method for a TURN server that is

setup/installed/configured for its USAGE (which is relaying traffic) - not

requiring a special network configuration just for being discoverable. (And

more widely, it must be the goal of this specification to provide at least

one discovery method that works for ALL network types and configurations,

where a network provided TURN server may be useful - I see only anycast

using Binding for querying *the TURN server's* unicast address fulfilling

this.)  

(C) Robust (tolerant) deployment is highly preferable.

(D) Ease of deployment is highly preferable.

Saying Binding instead Allocate, is necessary to achieve (A) and (B), and

improves (C) and (D).”

4) The (D)TLS text in version -12 does not have consensus either. 

https://www.ietf.org/mail-archive/web/tram/current/msg02296.html and 

Against my red lined (D)TLS changes, I have heard no objections (just as
with the red lined anycast method).

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

> From: tram [ <mailto:[email-masked]> mailto:[email-masked]]
On Behalf Of Karl Stahl

> To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]>
[email-masked]>; 'Simon Perreault'

> < <mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins at
IETF'

> < <mailto:[email-masked]> [email-masked]>

> Cc:  <mailto:[email-masked]> [email-masked]

> That does not make the version -12 text in the draft any clearer about
what

> asked Simon before (and only he answered):

I agree with the responses Simon has already provided to all the below
questions. Further, I also don't see the need to discuss the below questions
in the draft because they are only operational considerations (and have no
impact on the actual protocol).

-Tiru

> subnets) that can respond error 300 or make an allocation, distinguished
by

> Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]>
mailto:[email-masked]]

> Kopia:  <mailto:[email-masked]> [email-masked]

> > From: Simon Perreault [ <mailto:[email-masked]>
mailto:[email-masked]]

> > To: Karl Stahl < <mailto:[email-masked]> [email-masked]>;
'Spencer Dawkins at IETF'

> > < <mailto:[email-masked]> [email-masked]>

> > Cc:  <mailto:[email-masked]> [email-masked]; Tirumaleswar Reddy (tireddy)
< <mailto:[email-masked]> [email-masked]>

> > Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D

> Action:

> Yup,  <https://tools.ietf.org/html/rfc7094#section-3.4>
https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar

> > >> where saying Binding instead Allocate, is necessary to achieve (A)

> > >> and

> > > Brandon> It is true that you have provided a justification for the

> > > STUN dummy authentication instead of (D)TLS as suggested by Oleg

> > > Moskalenko

<https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc>
https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc

> > >    nearest" network interface with the anycast address.  Using the

> > > TURN

> > >    anycast address, the only two things that need to be deployed in

> > >    performs checks 1 to 7 discussed in Section 6.2 of [RFC5766].  If

> > > all

> > >    response contains the TURN unicast address in the

> > > ALTERNATE-SERVER

> > >    attribute.  For subsequent communication with the TURN server,

> > >    client uses the responding server's unicast address.  This has to

> > > be

> > >    done because two packets addressed to an anycast address may

> > > reach

> > >    request to the anycast address to discover the closest and the

> > > most

<https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc>
https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc

> > >    mechanisms described in this specification as an

> > > enterprise/gateway

> > >    or access network server, in accordance with Recursively

> > > Encapsulated

> > > *Från:*tram [ <mailto:[email-masked]>
mailto:[email-masked]] *För *Spencer Dawkins at

> > > IETF

> > > *Kopia:*  <mailto:[email-masked]> [email-masked] <
<mailto:[email-masked]> mailto:[email-masked]>; Tirumaleswar Reddy

> > > (tireddy)

> > >> < <mailto:[email-masked]>
mailto:[email-masked]><mailto:[email-masked]

> > > I'll give this 24 hours for people to chime in, but I do want to

> > > ping Terry.

> > > 10 for approval, and three are from ADs who are stepping down in

> > > March

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Feb 2017 08:51:08 +0000

Hi Karl,

We have gone over the same points over and over again and I don't see a need to document the discussion b/w you and Simon, they are only operational considerations and have no impact on the protocol.

Secondly, there is no consensus on your proposed new anycast mechanism and WG members have opposed your new anycast mechanism.

Regarding (D)TLS, the draft is updated in 12 version to say that (D)TLS is not mandatory to use if the network infrastructure can defend against the attacks discussed in RFC5766. This update addresses comments received from Brandon.

-Tiru

From: Karl Stahl [mailto:[email-masked]]
Sent: Wednesday, February 8, 2017 12:28 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Simon Perreault' <[email-masked]>; 'Spencer Dawkins at IETF' <[email-masked]>
Cc: [email-masked]
Subject: SV: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

1) The A)+B) method (that Simon and I discussed) is not specified in the draft -12 text and further referencing:

[Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar mechanism" does not help:

- It rather states issues coming from not knowing whether a server reached by anycast addressing, actually is at a unicast address or really is deployed at a anycast address (which I believe is rare).

2) Further, there are no deployment considerations for the A)+B) method in the -12 draft (compare the redlined version)

It does not even discuss or list  RFC7478 (Web Real-Time Communication Use Cases and Requirements) that it is supposed to meet, but which the A)+B) method is in conflict with.

https://www.ietf.org/mail-archive/web/tram/current/msg02314.html and https://www.ietf.org/mail-archive/web/tram/current/msg02254.html.

3) And if the (more complex) A)+B) method would be properly defined and described in some future revision, then remains (from https://www.ietf.org/mail-archive/web/tram/current/msg02254.html):
"(trying to) exemplify/clarify the high level (important) points why we
need/want anycast discovery by saying Binding instead of Allocate. These
points are:

improves (C) and (D)."

4) The (D)TLS text in version -12 does not have consensus either.
https://www.ietf.org/mail-archive/web/tram/current/msg02296.html and
https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
Against my red lined (D)TLS changes, I have heard no objections (just as with the red lined anycast method).

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]<mailto:[email-masked]>
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

> To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Simon Perreault'

> <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF'

> <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>

-Tiru

> Kopia: [email-masked]<mailto:[email-masked]>

> > To: Karl Stahl <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF'

> > <[email-masked]<mailto:[email-masked]>>

> > Cc: [email-masked]<mailto:[email-masked]>; Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>

> > > *Från:*tram [mailto:[email-masked]] *För *Spencer Dawkins at

> > > *Kopia:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Tirumaleswar Reddy

> > > [email-masked]<mailto:[email-masked]>

> > https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Karl Stahl <[email-masked]>
Date: Thu, 9 Feb 2017 13:52:15 +0100

Tiru,

Each of your three sentences are incorrect.

And,

> updated in 12 version to say that (D)TLS is not mandatory to use if the
network infrastructure can defend against the attacks discussed in RFC5766. 

--- And in addition It breaks the version -07 consensus text regarding
(D)TLS usage in this situation, by introducing “MUST” for (D)TLS usage under
9: 

...and therefore MUST NOT be used for privacy sensitive communication.

...but MUST NOT fall back without explicit administrator choice.  

...but MUST NOT fall back without explicit administrator choice.  

and my question how the “explicit administrator choice”  is supposed to
happen in an enterprise environment or at an internet café is not answered.

- I don’t think Brandon or anyone asked for such impossibilities (which
again seem to be created to make this specification unusable for its
purpose).

Please note that to my knowledge, (D)TLS usage is not mandated  for any
usage of TURN servers anywhere, and (again) this draft – that should specify
DISCOVERY – cannot MANDATE USAGE. None of the discovery methods do (and
cannot)  use (D)TLS (that discussion is for USAGE, AFTER the DISCOVERY).

The read lined -12 version is cleared from these and other flaws or
mistakes.

We should focus on whether the red lined version anything but improvements
and adds no drawbacks over version -12 of the draft.

/Karl

PS: Regarding the non working anycast method, *since I highlighted in August
8, 2016, all from the Author’s at the WG list is*:

October 18, 2016 (from Prashanth to me and others during the discuss):  We
intend to add the following to explain server behavior a little better:

“A TURN anycast server performs checks 1 to 7 discussed in Section 6.2 of
RFC5766. If all checks pass, the TURN anycast server MUST respond with a 300
(Try Alternate) error as described in [RFC5766];”

November 15, 2016  (to something from Brandon): Agreed. -Tiru 

November 18, 2016 (to something from Brandon): +1, don't see a need for
alternate mechanism. -Tiru

December 22, 2016 Hi Karl, I don’t understand why the mechanism where TURN
server has both anycast and unicast address for re-direction won’t work ?
Cheers, -Tiru

Now February 7, 8, 2016 See below

Skickat: den 8 februari 2017 09:51

Hi Karl,

We have gone over the same points over and over again and I don’t see a need
to document the discussion b/w you and Simon, they are only operational
considerations and have no impact on the protocol.

Secondly, there is no consensus on your proposed new anycast mechanism and
WG members have opposed your new anycast mechanism. 

Regarding (D)TLS, the draft is updated in 12 version to say that (D)TLS is
not mandatory to use if the network infrastructure can defend against the
attacks discussed in RFC5766. This update addresses comments received from
Brandon.

-Tiru

Subject: SV: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

[Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4 also
discusses similar mechanism" does not help:

 

points are:

this.)  

improves (C) and (D).”

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

On Behalf Of Karl Stahl

IETF'

what

-Tiru

by

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 9 Feb 2017 14:33:55 +0000

Hi Karl,

Please see inline

From: Karl Stahl [mailto:[email-masked]]
Sent: Thursday, February 9, 2017 6:22 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Simon Perreault' <[email-masked]>; 'Spencer Dawkins at IETF' <[email-masked]>
Cc: [email-masked]
Subject: SV: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

Tiru,

And,
> updated in 12 version to say that (D)TLS is not mandatory to use if the network infrastructure can defend against the attacks discussed in RFC5766.

--- And in addition It breaks the version -07 consensus text regarding (D)TLS usage in this situation, by introducing "MUST" for (D)TLS usage under 9:
...and therefore MUST NOT be used for privacy sensitive communication.
...but MUST NOT fall back without explicit administrator choice.
...but MUST NOT fall back without explicit administrator choice.
and my question how the "explicit administrator choice"  is supposed to happen in an enterprise environment or at an internet café is not answered.

[TR] Explicit administrator choice means the user is notified about the failure and fallback happens only after consent from the user (i.e. the user needs to know that fallback happens to a less secure mechanism).

- I don't think Brandon or anyone asked for such impossibilities (which again seem to be created to make this specification unusable for its purpose).

Please note that to my knowledge, (D)TLS usage is not mandated  for any usage of TURN servers anywhere, and (again) this draft - that should specify DISCOVERY - cannot MANDATE USAGE. None of the discovery methods do (and cannot)  use (D)TLS (that discussion is for USAGE, AFTER the DISCOVERY).

[TR] No, (D)TLS is only mandated if the network infrastructure cannot defend against the attacks discussed in RFC5766.

-Tiru

The read lined -12 version is cleared from these and other flaws or mistakes.

We should focus on whether the red lined version anything but improvements and adds no drawbacks over version -12 of the draft.

/Karl

PS: Regarding the non working anycast method, *since I highlighted in August 8, 2016, all from the Author's at the WG list is*:
October 18, 2016 (from Prashanth to me and others during the discuss):  We intend to add the following to explain server behavior a little better:
"A TURN anycast server performs checks 1 to 7 discussed in Section 6.2 of RFC5766. If all checks pass, the TURN anycast server MUST respond with a 300 (Try Alternate) error as described in [RFC5766];"
November 15, 2016  (to something from Brandon): Agreed. -Tiru

November 18, 2016 (to something from Brandon): +1, don't see a need for alternate mechanism. -Tiru
December 22, 2016 Hi Karl, I don't understand why the mechanism where TURN server has both anycast and unicast address for re-direction won't work ? Cheers, -Tiru
Now February 7, 8, 2016 See below

Hi Karl,

-Tiru

To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Simon Perreault' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]<mailto:[email-masked]>
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Fri, 10 Feb 2017 02:22:32 +0100

Hi Tiru, please see [Karl] inlines after your inlines.

Skickat: den 9 februari 2017 15:34

Hi Karl,

Please see inline

Tiru,

And,

[TR] Explicit administrator choice means the user is notified about the
failure and fallback happens only after consent from the user (i.e. the user
needs to know that fallback happens to a less secure mechanism).

[Karl] I suggest “administrator” is then changed to “user” so it is not
interpreted as the network administrator, in a version -13 of the draft.

[TR] No, (D)TLS is only mandated if the network infrastructure cannot defend
against the attacks discussed in RFC5766. 

[Karl] That is already clear in the -12 version. My comment remains (In
addition to being wrong, I meant it is also strange (and unnecessary,
considering that dummy authentication can achieve it better) if this
DISCOVERY draft would mandates (D)TLS for TURN server usage in a certain
situation, when no other draft mandates (D)TLS for usage of TURN servers.)

[Karl] While producing the above suggested -13 of the draft, I also suggest
you also include all the redlining I proposed (and no one has objected
against) and I think we will have a draft that can be accepted to become an
RFC.

Thanks,

Karl 

-Tiru

We should focus on whether the red lined version is anything but
improvements and adds no drawbacks over version -12 of the draft.

/Karl

 

Hi Karl,

-Tiru

 

points are:

this.)  

improves (C) and (D).”

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

On Behalf Of Karl Stahl

IETF'

what

-Tiru

by

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 10 Feb 2017 04:56:43 +0000

Hi Karl,

Please see inline [TR2]

From: Karl Stahl [mailto:[email-masked]]
Sent: Friday, February 10, 2017 6:53 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Simon Perreault' <[email-masked]>; 'Spencer Dawkins at IETF' <[email-masked]>
Cc: [email-masked]
Subject: SV: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

Hi Karl,

Please see inline

Tiru,

And,

[TR] Explicit administrator choice means the user is notified about the failure and fallback happens only after consent from the user (i.e. the user needs to know that fallback happens to a less secure mechanism).
[Karl] I suggest "administrator" is then changed to "user" so it is not interpreted as the network administrator, in a version -13 of the draft.

[TR2] Sure, I can update draft.

[TR2] Other drafts do not mandate (D)TLS because RFC5766 mandates STUN authentication, this draft updates RFC5766 by saying STUN authentication is not mandatory hence it is mandating (D)TLS.

[TR] No, (D)TLS is only mandated if the network infrastructure cannot defend against the attacks discussed in RFC5766.
[Karl] That is already clear in the -12 version. My comment remains (In addition to being wrong, I meant it is also strange (and unnecessary, considering that dummy authentication can achieve it better) if this DISCOVERY draft would mandates (D)TLS for TURN server usage in a certain situation, when no other draft mandates (D)TLS for usage of TURN servers.)

[TR2] I don't agree with your comments and don't plan to make any changes to (D)TLS related text in the draft unless I hear otherwise from other WG members and chairs.

[Karl] While producing the above suggested -13 of the draft, I also suggest you also include all the redlining I proposed (and no one has objected against) and I think we will have a draft that can be accepted to become an RFC.

[TR2] I reject your all your other proposed changes including anycast, don't see any merit in your arguments and will let the WG chairs decide how to proceed with the draft.

-Tiru

Thanks,
Karl

-Tiru

We should focus on whether the red lined version is anything but improvements and adds no drawbacks over version -12 of the draft.

/Karl

Hi Karl,

-Tiru

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]<mailto:[email-masked]>
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Fri, 10 Feb 2017 14:20:27 +0100

Hi Tiru, below again

Skickat: den 10 februari 2017 05:57

Hi Karl,

Please see inline [TR2]

Hi Karl,

Please see inline

Tiru,

And,

[Karl2] But please notice, that this only clarifies the draft, it is still a
nuisance for a user and a general webRTC browser (that will be used under
such conditions) and that was not what Brandon or anyone else asked for.
Recommending the STUN dummy authentication instead, resolves the (D)TLS
break of consensus of the version -07 text, including the performance
concerns raised by Pal-Erik and others, as well as other objections.

[TR2] Other drafts do not mandate (D)TLS because RFC5766 mandates STUN
authentication, this draft updates RFC5766 by saying STUN authentication is
not mandatory hence it is mandating (D)TLS. 

[Karl2] Yes, we agree. It is only this draft, version -10 to -12 draft that
suggests to mandate usage of (D)TLS (Please free us from that)

[TR2] I don’t agree with your comments and don’t plan to make any changes to
(D)TLS related text in the draft unless I hear otherwise from other WG
members and chairs.

[TR2] I reject your all your other proposed changes including anycast, don’t
see any merit in your arguments 

[Karl2] … and ignoring Brandon’s: 

> It is true that you have provided a justification for the change. 

> My  point is that the small set of people… 

As responded to: 

>> [Karl Justification is in the (A), (B), (C) and (D) of 

and will let the WG chairs decide how to proceed with the draft.

[Karl2] Well, we need a specification that is defined and fulfill its
purpose and thus can be made an RFC. 

Can you specify what and explain why any of the red lined suggestions to the
version -12 text would go against this (or is there nothing)?

(As a guidance to those you ask for “decide how to proceed with the draft.”)

/Karl

-Tiru

Thanks,

Karl 

-Tiru

/Karl

 

Hi Karl,

-Tiru

 

points are:

this.)  

improves (C) and (D).”

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 7 februari 2017 12:02
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
Kopia: [email-masked]
Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:

On Behalf Of Karl Stahl

IETF'

what

-Tiru

by

---

From: Brandon Williams <[email-masked]>
Date: Sun, 12 Feb 2017 10:05:05 -0500

Just so it's clear on the list ...

The new text in this draft does indeed represent the compromise position 
re: (D)TLS that I had previously proposed on the list, and I agree with 
Tiru and the chairs that it should clear the remaining DISCUSS. [I know 
I'm a little late to chime in on that last point, but later discussion 
on the list suggests that a supportive comment might still be useful.]

--Brandon

On 01/12/2017 10:59 PM, Tirumaleswar Reddy (tireddy) wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-12
>>
>>
>> Please note that it may take a couple of minutes from the time of submission

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Brandon Williams <[email-masked]>
Date: Sun, 12 Feb 2017 10:21:19 -0500

Karl,

I haven't read the redlined version and am only responding to your use 
of a quote from me. In the mail that you quote from, my full comment was:

"It is true that you have provided a justification for the change. My 
point is that the small set of people who have engaged in list 
discussion do not appear to agree with your justification."

In other words, there is no consensus on the list about your 
justification. I and others are unwilling to consider changing the 
current draft until we have first agreed that a change is necessary.

--Brandon

On 02/02/2017 06:23 PM, Karl Stahl wrote:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=VZTOoZcdO5h3WpTcdR7MoDXvGYjtW3ztekCV7nsVdz0&e=>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02279.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=yOujmfvFc-3OmTGH6eJo3Bl5HaAfRCZ3dr7D3n5qNzU&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=MhwVvzEav-8SarwQa9ttpmwv6gcj_pX2GomLzQdJLQg&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02296.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=4yIVNcGZlYcu6y4zNGV8eAW0yMHzSxuFOQ9MJqrJtdc&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=jvMmpY2IuOzVdqZ5BzBkHwCHkXc8qgsQVUd_7YZW1h8&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=YqLbQir1UBA1SRkI7JipPPP5OE2JM4BetfHOQsbp9LA&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=YqLbQir1UBA1SRkI7JipPPP5OE2JM4BetfHOQsbp9LA&e=>
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02202.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02202.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=mtrWKocQ1ct2kXvrYTErFIMZCNEUhb9362LtpbH9Ias&s=Zsb91h9LfPnp06OgDG4FLg31ubnCGPxwmUFdfn7Hnyw&e=>,

---

From: Brandon Williams <[email-masked]>
Date: Sun, 12 Feb 2017 11:09:59 -0500

Karl,

My sense of the discussion is that there is in fact consensus on the 
anycast mechanism as described in the draft, and there has been for 
quite some time. That is why the draft was submitted for publishing in 
the first place. One vocal dissent does not mean that the WG failed to 
follow IETF process for reaching consensus.

Since we already have rough consensus on the mechanism and we clearly do 
not have even rough consensus that the mechanism requires changes, I 
support the chairs' decision to move forward.

--Brandon

On 02/06/2017 05:10 AM, Karl Stahl wrote:
> Simon,
>
>
>
> There is no consensus yet whatsoever regarding any anycast mechanism,
> but we have a chance getting consensus of a working anycast mechanism,
> that works for all cases, which no one has disputed as working and that
> is technically superior.
>
>
>
> Further, it does not exist such "mechanism defined in RFC 5766" and what
> is in current version -12 text is still undefined and interpreted
> radically different by participating WG individuals.
>
>
>
> Only Tiru, during the DISCUSS, after version -10
> (https://www.ietf.org/mail-archive/web/tram/current/msg02219.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02219.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=9Vinivwpl57Ies6e-yU0dUlpAl4fU82P3tUUttRw6To&e=>)
>
>
> referenced https://tools.ietf.org/html/rfc5766#section-2.9
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D2.9&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=7l8YhEhODU-mAOOge_PGkmBRe3izR5ccHjCt00fIMKg&e=>,
> which says:
>
> "This version of TURN has been designed to **permit the future
> specification of a method** of doing anycast discovery of a TURN server
> over UDP.
>
>
>
> discover"-method, I questioned version -08 of the draft (before the
> DISCUSS) (in August,
> https://www.ietf.org/mail-archive/web/tram/current/msg02081.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02081.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=Ky60LXSnuUbd3V9g_U7OQeygIMsDBSIhzoR3CJnhudc&e=>)
> but that was not responded to by the authors (only Branded responded,
> but from an authentication point of view, as if the method meant a
> mixture of discovery and usage, which was confusing).
>
>
>
> During the DISCUSS, in response to my request to fix, Prashanth only
> said:  We intend to add the following to explain server behavior a
> little better:
>
> “A TURN anycast server performs checks 1 to 7 discussed in Section 6.2
> of RFC5766. If all checks pass, the TURN anycast server MUST respond
> with a 300 (Try Alternate) error as described in [RFC5766]”
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02239.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=lF-ED0y_3a0PpIV86fSvOqTSZ35xA0rHRPSWIT_zg40&e=>
>
>
> [Karl]> (I think Brandon assumes a TURN server listening to TWO IP
> addresses that
>
>> text as if the FIRST Allocate is responded to with error 300 and SUBSEQUENT
>
> NOW, reverse engineering the current -12 text to understand what may be
> in the author’s mind (which they strangely enough never have spelled
> out), it is NOT the “TWO LAN IP TURN servers” but *the “**No, that would
> be wrong.**”-method that is intended*, see these highlights in the -12 text!
>
> IP anycast can also be used for TURN service discovery. A packet sent to
> an anycast address is delivered to the "topologically nearest" network
> interface [Karl: Nearest cannot be two] with the anycast address. Using
> the TURN anycast address, the only two things that need to be deployed
> in the network for discovery are the two things that actually use TURN.
>
> When a client requires TURN services, it sends a TURN allocate request
> to the assigned anycast address. A TURN anycast serverperforms checks 1
> to 7 discussed in Section 6.2 of [RFC5766]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.html-23RFC5766&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=NjtWzkAK2zeIDoPlbPXBtnWym-ieDQliiEuKwilZ8-w&e=>.
> If all checks pass, the TURN anycast server MUST respond with a 300 (Try
> Alternate) error as described in Section 2.9 of [RFC5766]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.html-23RFC5766&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=NjtWzkAK2zeIDoPlbPXBtnWym-ieDQliiEuKwilZ8-w&e=>;
> The response contains the TURN unicast address in the ALTERNATE-SERVER
> attribute. For *subsequent*communication with *the*TURN server, the
> client uses theresponding server's unicast address. This has to be done
> because two packets addressed to an anycast address may reach two
> different anycast servers. The client, thus, also needs to ensure that
> the initial request fits in a single packet. An implementation may
> choose to send out every new TURN Allocation request to the anycast
> address to discover the closest and the most optimal unicast address for
> the TURN server.
>
> I think other participants in the discussion, also interpret the -12
> text as the “that would be wrong”-variant, or even worse, a mixture of
> discovery and usage authentication (where (D)TLS might come
> in(https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=ckHAyWA3lSkWuR_x23jKoarxwQ5p83eHWlRLRR0-WGU&e=>
> )).
>
>
>
> So, current version -12 meaning of text is probably not only “wrong”,
> but does not work (in addition to being undefined). Version -12 can have
> no consensus, nor can that be brought into an RFC.
>
>
>
>
>
> mechanism (my redlining of the -12 text), that works for all cases
> (which no one has disputed), I have just made an IPR declaration “in
> Alan Johnston / Avaya style (compare
> https://datatracker.ietf.org/ipr/2555
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2555&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=-3GAqbhshjLGlqn1rJTvvZYBX8hUMnoE9klSH8jcetE&e=>)”
> where any party can use the proposed anycast method (for which patent
> was provisionally applied for October 21, 2013) free of royalty as long
> as not asserting a patent right of its owns against us.My IPR
> Declaration related to this I-D should appear in day (said when submitting).
>
>
>
> /Karl
>
>
>
> Ämne: Re: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Karl,
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=bBFj_GASKSsY_HNdIBjjv0y8sjPtr6zzgj4BQ3oMrdU&e=>
>
>>
>
>>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=J8IfAGYsotvUD3BZ34GaL2PMdA8VgM4YrjsBZYsWTJU&e=>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=88hP4v4Z4-R6Uabxb4H3ZiBhM0Qd5RJVPrV20Xqhdrk&e=>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=3RTX5rmvnTz6_hFMiKyI82eEcI3D2Wq3NRGBGG-g7HQ&e=>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=ckHAyWA3lSkWuR_x23jKoarxwQ5p83eHWlRLRR0-WGU&e=>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=p9f6UjD__Fo0xiUk6DaYgSTI26yAZyz0VNDbpfZLpgA&e=>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=p9f6UjD__Fo0xiUk6DaYgSTI26yAZyz0VNDbpfZLpgA&e=>
>
>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=xJqnJA5Recy-zn0mjGAwmioTMfhnHGcUQiW8HvTcUAY&e=>,
>
>> *Kopia:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>;
> Tirumaleswar Reddy (tireddy)
>
>>> <[email-masked] <mailto:[email-masked]
> <mailto:[email-masked]%20%3cmailto:[email-masked]>><mailto:[email-masked]
>
>> [email-masked] <mailto:[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=bfMg0C2AcGncycaAxmFKGxYyCDivv_QxmIJUrJgAIHA&e=>
>
>>
>
>
>
>
>
> --
>
> Simon Perreault
>
> https://jive.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=-0naNOVsq-b3TnBmNWKQhhf-TF_BR_JdB-AIEp4Azag&e=>
> | +1 418 478 0989 ext. 1241 | [email-masked]
> <mailto:[email-masked]>
>
>
>

---

From: Brandon Williams <[email-masked]>
Date: Sun, 12 Feb 2017 11:13:15 -0500

(resending to the list from the correct address; apologies to those who 
receive multiple copies)

--

Karl,

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Sun, 12 Feb 2017 11:19:28 -0500

Hi Karl,

I see that you have continued to provide partial quotes from me to 
justify your position, which suggests that I was not direct enough in 
some of my earlier responses. Please let me clarify.

I do not agree that you have identified any problems with the -12 draft 
that need to be addressed, aside from a minor clarification that Tiru 
has agreed to make.

Furthermore, I agree with Tiru and the rest of the authors on the 
importance of the (D)TLS discussion. The draft updates existing TURN 
requirements regarding authentication that have a significant impact on 
the security model, which requires the draft to provide clear guidance 
about the use of (D)TLS within the new security model. I think that the 
-12 draft represents a reasonable middle-ground between your position 
(no mandate) and the position that I share with the authors (mandate in 
all cases where STUN auth is not used).

--Brandon

PS: The e-mail is simply a clarification of my position. I'll send a 
separate note about where I want to add to another part of the discussion.

On 02/10/2017 08:20 AM, Karl Stahl wrote:
> Hi Tiru, below again
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 10 februari 2017 05:57
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [email-masked]
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> *From:*Karl Stahl [mailto:[email-masked]]
> *Sent:* Friday, February 10, 2017 6:53 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Simon Perreault' <[email-masked]
> <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 9 februari 2017 15:34
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [email-masked] <mailto:[email-masked]>
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> *From:*Karl Stahl [mailto:[email-masked]]
> *Sent:* Thursday, February 9, 2017 6:22 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Simon Perreault' <[email-masked]
> <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> (D)TLS usage in this situation, by introducing “MUST” for (D)TLS usage
> under 9:
>
> failure and fallback happens only after consent from the user (i.e. the
> user needs to know that fallback happens to a less secure mechanism).
>
> [Karl2] But please notice, that this only clarifies the draft, it is
> still a nuisance for a user and a general webRTC browser (that will be
> used under such conditions) and that was not what Brandon or anyone else
> asked for. Recommending the STUN dummy authentication instead, resolves
> the (D)TLS break of consensus of the version -07 text, including the
> performance concerns raised by Pal-Erik and others, as well as other
> objections.
>
>
>
> usage of TURN servers anywhere, and (again) this draft – that should
> specify DISCOVERY – cannot MANDATE USAGE. None of the discovery methods
> do (and cannot)  use (D)TLS (that discussion is for USAGE, AFTER the
> DISCOVERY).
>
>
>
> authentication, this draft updates RFC5766 by saying STUN authentication
> is not mandatory hence it is mandating (D)TLS.
>
> [Karl2] Yes, we agree. It is only this draft, version -10 to -12 draft
> that suggests to mandate usage of (D)TLS (Please free us from that)
>
>
>
> [TR] No, (D)TLS is only mandated if the network infrastructure cannot
> defend against the attacks discussed in RFC5766.
>
> [TR2] I don’t agree with your comments and don’t plan to make any
> changes to (D)TLS related text in the draft unless I hear otherwise from
> other WG members and chairs.
>
>
>
> [Karl] While producing the above suggested -13 of the draft, I also
> suggest you also include all the redlining I proposed (and no one has
> objected against) and I think we will have a draft that can be accepted
> to become an RFC.
>
>
>
> [TR2] I reject your all your other proposed changes including anycast,
> don’t see any merit in your arguments
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>
>
> Can you specify what and explain why any of the red lined suggestions to
> the version -12 text would go against this (or is there nothing)?
>
> PS: Regarding the non working anycast method, **since I highlighted in
> August 8, 2016, all from the Author’s at the WG list is**:
>
> October 18, 2016 (from Prashanth to me and others during the discuss):
> with a 300 (Try Alternate) error as described in [RFC5766];”
>
> December 22, 2016 Hi Karl, I don’t understand why the mechanism where
> TURN server has both anycast and unicast address for re-direction won’t
> work ? Cheers, -Tiru
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 8 februari 2017 09:51
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [email-masked] <mailto:[email-masked]>
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> We have gone over the same points over and over again and I don’t see a
> need to document the discussion b/w you and Simon, they are only
> operational considerations and have no impact on the protocol.
>
>
>
> Secondly, there is no consensus on your proposed new anycast mechanism
> and WG members have opposed your new anycast mechanism.
>
>
>
> Regarding (D)TLS, the draft is updated in 12 version to say that (D)TLS
> is not mandatory to use if the network infrastructure can defend against
> the attacks discussed in RFC5766. This update addresses comments
> received from Brandon.
>
>
>
> -Tiru
>
>
>
> *From:*Karl Stahl [mailto:[email-masked]]
> *Sent:* Wednesday, February 8, 2017 12:28 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Simon Perreault' <[email-masked]
> <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> [Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LEhCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> also discusses similar mechanism" does not help:
>
> - It rather states issues coming from not knowing whether a server
> reached by anycast addressing, actually is at a unicast address or
> really is deployed at a anycast address (which I believe is rare).
>
>
>
> 2) Further, there are no deployment considerations for the A)+B) method
> in the –12 draft (compare the redlined version)
>
> It does not even discuss or list  RFC7478 (Web Real-Time Communication
> Use Cases and Requirements) that it is supposed to meet, but which the
> A)+B) method is in conflict with.
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02314.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02314.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=JUvi1vp2Im171VnwziFnhFyKRHdWeOyx5urNi9JOG9w&e=>
> and https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>.
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>):
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
> and
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>
>
> Kopia: [email-masked] <mailto:[email-masked]>
> Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D
>> To: Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>>; 'Simon Perreault'
>
>> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
>
>> <[email-masked] <mailto:[email-masked]>>
>
>> Cc: [email-masked] <mailto:[email-masked]>
>
> questions. Further, I also don't see the need to discuss the below
> questions in the draft because they are only operational considerations
> (and have no impact on the actual protocol).
>
>
>
> -Tiru
>
>
>
>>
>
>> Does the draft assume:
>
>>
>
>> Kopia: [email-masked] <mailto:[email-masked]>
>
>> > To: Karl Stahl <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins
> at IETF'
>
>> > <[email-masked] <mailto:[email-masked]>>
>
>> > Cc: [email-masked] <mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>>
>
>> Yup, https://tools.ietf.org/html/rfc7094#section-3.4
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LEhCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> also discusses similar
>
>> mechanism.
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=OR288fay15EdJ063J_GCuNOt-SScDC5CylZsleLjXbU&e=>
>
>> > >
>
>> > >
>
>> > >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=B9ST_TVehqEC-PVjUMsDQsxLBNgTStctSmVvmqi39zo&e=>
>
>> > >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>
>> > >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
>
>> > >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>
>> > >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=d3MIEALshSLyuVc0Tp0U_RBYISTdX2sF-YW4oVWzUk4&e=>,
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
>
>> > >
>
>> >
>
>> >
>
>> > --
>
>> > Simon Perreault
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6xMRYWWn81v-P_m3BZY8GMOvpo0ygL0wYykEsxKd66Q&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
>
>
>

---

From: Brandon Williams <[email-masked]>
Date: Sun, 12 Feb 2017 11:24:41 -0500

Hi Karl,

Regarding the "explicit administrator choice" part of the text, I think 
the point is not that an application MUST NOT blindly fall back to 
cleartext, but instead MUST give the admin and/or user some control. 
There are a variety of ways this could be accomplished. Tiru's 
suggestion in the earlier e-mail is just one of those. I don't think the 
draft needs to describe a specific method; it's up to the application 
developer to choose a method that best meets user needs.

--Brandon

---

From: Karl Stahl <[email-masked]>
Date: Mon, 13 Feb 2017 20:52:50 +0100

Regarding (D)TLS: 

Brandon, the "explicit administrator choice" text in version -12 is the only
thing I have attributed to you as "I don’t think Brandon or anyone asked for
such impossibilities" and I think what you say below is just that. Let's not
make too much about that.

The real things about the STUN Authentication (in addition to introducing
this (D)TLS "impossibility use case" ) are:

1) (D)TLS mandate was thrown in during the DISCUSS and broke the -07 text
consensus, where STUN Authentication was not required for network provided
TURN servers in the local or access network (no (D)TLS was suggested - that
is for validation, not for authentication) 

2) The STUN Authentication downgrade was (correctly) declared first during
discuss (although it happened with version -07), and the "IP Authentication"
(that automatically the users belonging to the local or access network have,
was (correctly) spelled out during the discuss as "A TURN server in such
cases must be configured to only process STUN
   requests from the trusted local network or subscribers of the access
   network.  Operational measures must be taken in order protect the
   TURN server; some of these measures include, but not limited to,
   access control by means of access-lists, firewalls, subscriber quota
   limits, ingress filtering etc."
  
3) The (D)TLS mandate thrown in during the discuss does other things than
compensate for the STUN Authentication, and was later (by Authors) reduced
to fixing vulnerability for spoofing (-12 text), and the -12 text's
mandating (D)TLS in some situations.

4) However, for eliminating the spoofing vulnerability, introduced (D)TLS is
still not good (CPU hunger, thus DOD/DDOS vulnerable, trust anchor or
certificate seldom available), while Oleg's Dummy Authentication does the
job and has none of the drawbacks. 

This is introduced in the red-lined version -12 and is a way bring back
consensus if agreed upon.

/Karl

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 12 februari 2017 17:25
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Simon Perreault';

Hi Karl,

--Brandon

>>> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
> [Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rf
c7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuad
q6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LE
hCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> https://www.ietf.org/mail-archive/web/tram/current/msg02314.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02314.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=JUvi1vp2Im171VnwziFnhFyKRHdWeOyx5urNi9JOG9w&e=>
> and https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>.
> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
> https://www.ietf.org/mail-archive/web/tram/current/msg02296.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
> https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>> To: Tirumaleswar Reddy (tireddy) <[email-masked]
<mailto:[email-masked]>>; 'Simon Perreault'
what
by
>> Yup, https://tools.ietf.org/html/rfc7094#section-3.4
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rf
c7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuad
q6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LE
hCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=OR288fay15EdJ063J_GCuNOt-SScDC5CylZsleLjXbU&e=>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02279.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=B9ST_TVehqEC-PVjUMsDQsxLBNgTStctSmVvmqi39zo&e=>
>> > >> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02296.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff
-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w
0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4
f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff
-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w
0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4
f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02202.html
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=d3MIEALshSLyuVc0Tp0U_RBYISTdX2sF-YW4oVWzUk4&e=>,
>> > > 10 for approval, and three are from ADs who are stepping down in
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgw
bBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler
_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96
ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW
-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6xMRYWWn81v-P_m3BZY8GMOvpo0ygL0wYykEs
xKd66Q&e=>
> <mailto:[email-masked]>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgw
bBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler
_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>

---

From: Karl Stahl <[email-masked]>
Date: Mon, 13 Feb 2017 20:53:03 +0100

Regarding Anycast:

Brandon, previous email > I haven't read the redlined version 

--- The anycast related redlining of version -12 is the same as I did in
version -10 that you read and discussed/commented with one thing that I
addressed. Let's not make too much of that, since there is no common
understanding of what the Author's anycast method actually is. 

Reality is: 

- Tiru says he agrees with other (Simon, but that discussion was based
around the "Two LAN IP TURN server(s)" method assumption) but Tiru gave a
pointer in another direction.

- Prashpanth extra text during discuss (in version -12 now) rather points at
another interpretation, using only one TURN server, that answers
differently, depending on when accessed.

- And Brandon seems to point to Tiru

- Dissident me highlighted the flaws already in version -08 (when reading
the “not all TURN servers may support anycast.” statement) but Author's did
not respond

Checking History:

https://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-00 

   request to the assigned anycast address.  The responding TURN anycast

   server puts its own unicast address as the source address in the

   reply message.  For subsequent

https://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 

   request to the assigned anycast address.  The TURN anycast server

   responds with a 300 (Try Alternate) error as described in [RFC5766];

   The response contains the TURN unicast address in the ALTERNATE-

   SERVER attribute.  For subsequent

The “not all TURN servers may support anycast.” statement appeared later in 

https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-02 

Nothing of this indicates that the Authors mean the "Two LAN IP TURN
server(s)" method Simon and I discussed and the continued silence from the
Author’s just confirms that -12 lacks an anycast specification that can be
implemented and used. Further, version -12 lacks deployment considerations.

The red-lined version -12 defines the “say Binding instead of Allocate”
anycast method (working with one TURN server and in all situations), it
includes deployment considerations, and is a way to get consensus of
something defined.

/Karl

 

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 12 februari 2017 17:13
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF';
[email-masked]
Kopia: 'Tirumaleswar Reddy (tireddy)'
Ämne: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
draft-ietf-tram-turn-server-discovery-12.txt

receive multiple copies)

--

Karl,

--Brandon

> ( <https://www.ietf.org/mail-archive/web/tram/current/msg02219.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02219.html

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02219.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=9Vinivwpl57Ies6e-yU0dUlpAl4fU82P3tUUttRw6To&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02219.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=9Vinivwpl57Ies6e-yU0dUlpAl4fU82P3tUUttRw6To&e=>)

> referenced  <https://tools.ietf.org/html/rfc5766#section-2.9>
https://tools.ietf.org/html/rfc5766#section-2.9

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rf
c5766-23section-2D2.9&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuad
q6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=7l
8YhEhODU-mAOOge_PGkmBRe3izR5ccHjCt00fIMKg&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc
5766-23section-2D2.9&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq
6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=7l8
YhEhODU-mAOOge_PGkmBRe3izR5ccHjCt00fIMKg&e=>,

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02081.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=Ky60LXSnuUbd3V9g_U7OQeygIMsDBSIhzoR3CJnhudc&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02081.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=Ky60LXSnuUbd3V9g_U7OQeygIMsDBSIhzoR3CJnhudc&e=>)

>  <https://www.ietf.org/mail-archive/web/tram/current/msg02239.html>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02239.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=lF-ED0y_3a0PpIV86fSvOqTSZ35xA0rHRPSWIT_zg40&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02239.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=lF-ED0y_3a0PpIV86fSvOqTSZ35xA0rHRPSWIT_zg40&e=>

SUBSEQUENT

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draf
t-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.html-23RFC5766&d=DwMFAw&c=9
6ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6j
k02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=NjtWzkAK2zeIDoPlbPXBtnWym-ieDQliiEuK
wilZ8-w&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft
-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.html-23RFC5766&d=DwMFAw&c=96
ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk
02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=NjtWzkAK2zeIDoPlbPXBtnWym-ieDQliiEuKw
ilZ8-w&e=>.

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draf
t-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.html-23RFC5766&d=DwMFAw&c=9
6ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6j
k02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=NjtWzkAK2zeIDoPlbPXBtnWym-ieDQliiEuK
wilZ8-w&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft
-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.html-23RFC5766&d=DwMFAw&c=96
ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk
02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=NjtWzkAK2zeIDoPlbPXBtnWym-ieDQliiEuKw
ilZ8-w&e=>;

> in( <https://www.ietf.org/mail-archive/web/tram/current/msg02297.html>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=ckHAyWA3lSkWuR_x23jKoarxwQ5p83eHWlRLRR0-WGU&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=ckHAyWA3lSkWuR_x23jKoarxwQ5p83eHWlRLRR0-WGU&e=>

>  <https://datatracker.ietf.org/ipr/2555>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_i
pr_2555&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJ
a4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=-3GAqbhshjLGlqn1
rJTvvZYBX8hUMnoE9klSH8jcetE&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ip
r_2555&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa
4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=-3GAqbhshjLGlqn1r
JTvvZYBX8hUMnoE9klSH8jcetE&e=>)”

> Från: Simon Perreault [ <mailto:[email-masked]>

> Kopia:  <mailto:[email-masked]> [email-masked]; 'Tirumaleswar Reddy
(tireddy)'

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=bBFj_GASKSsY_HNdIBjjv0y8sjPtr6zzgj4BQ3oMrdU&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=bBFj_GASKSsY_HNdIBjjv0y8sjPtr6zzgj4BQ3oMrdU&e=>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=J8IfAGYsotvUD3BZ34GaL2PMdA8VgM4YrjsBZYsWTJU&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=J8IfAGYsotvUD3BZ34GaL2PMdA8VgM4YrjsBZYsWTJU&e=>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=88hP4v4Z4-R6Uabxb4H3ZiBhM0Qd5RJVPrV20Xqhdrk&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=88hP4v4Z4-R6Uabxb4H3ZiBhM0Qd5RJVPrV20Xqhdrk&e=>

change.

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=3RTX5rmvnTz6_hFMiKyI82eEcI3D2Wq3NRGBGG-g7HQ&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=3RTX5rmvnTz6_hFMiKyI82eEcI3D2Wq3NRGBGG-g7HQ&e=>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=ckHAyWA3lSkWuR_x23jKoarxwQ5p83eHWlRLRR0-WGU&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=ckHAyWA3lSkWuR_x23jKoarxwQ5p83eHWlRLRR0-WGU&e=>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff
-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3D
draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFAw&c=96ZbZZca
MF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblM
wTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=p9f6UjD__Fo0xiUk6DaYgSTI26yAZyz0VNDbpfZLpgA
&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-
3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3Dd
raft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFAw&c=96ZbZZcaM
F4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMw
TNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=p9f6UjD__Fo0xiUk6DaYgSTI26yAZyz0VNDbpfZLpgA&
e=>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff
-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3D
draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFAw&c=96ZbZZca
MF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblM
wTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=p9f6UjD__Fo0xiUk6DaYgSTI26yAZyz0VNDbpfZLpgA
&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-
3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D09.txt-26url2-3Dd
raft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D12.txt&d=DwMFAw&c=96ZbZZcaM
F4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMw
TNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=p9f6UjD__Fo0xiUk6DaYgSTI26yAZyz0VNDbpfZLpgA&
e=>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8g
kiIfZ2CAYQ&s=xJqnJA5Recy-zn0mjGAwmioTMfhnHGcUQiW8HvTcUAY&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darc
hive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gk
iIfZ2CAYQ&s=xJqnJA5Recy-zn0mjGAwmioTMfhnHGcUQiW8HvTcUAY&e=>,

>> *Från:*tram [ <mailto:[email-masked]>
mailto:[email-masked]] *För *Spencer Dawkins at IETF

>> *Kopia:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]>
mailto:[email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>;

> < <mailto:[email-masked]%20%3cmailto:[email-masked]>
mailto:[email-masked]%20%3cmailto:[email-masked]>><mailto:tireddy@cisc
o.com

>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]>
mailto:[email-masked]>

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgw
bBVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=bfMg0C2AcGn
cycaAxmFKGxYyCDivv_QxmIJUrJgAIHA&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_li
stinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwb
BVUJa4mZfmEIBXg&m=LlHl6jk02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=bfMg0C2AcGnc
ycaAxmFKGxYyCDivv_QxmIJUrJgAIHA&e=>

>  <https://jive.com> https://jive.com

> <
<https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96
ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk
02cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=-0naNOVsq-b3TnBmNWKQhhf-TF_BR_JdB-AIE
p4Azag&e=>
https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96Z
bZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LlHl6jk0
2cblMwTNHwaYXp02Cfy8lHe8gkiIfZ2CAYQ&s=-0naNOVsq-b3TnBmNWKQhhf-TF_BR_JdB-AIEp
4Azag&e=>

> | +1 418 478 0989 ext. 1241 |  <mailto:[email-masked]>
[email-masked]

> < <mailto:[email-masked]> mailto:[email-masked]>

-- 

--

---

From: Karl Stahl <[email-masked]>
Date: Wed, 15 Feb 2017 08:42:31 +0100

Authors: Tiru, Prashpanth, Dan (still there?),

Reading the below (not mentioning TWO TURN servers, saying “TURN anycast
server”) and Tiru’s 7th of February pointer to       

“ <https://tools.ietf.org/html/rfc7094#section-3.4>
https://tools.ietf.org/html/rfc7094#section-3.4 also discusses similar
mechanism.”:

 <https://tools.ietf.org/html/rfc7094#section-3.4> 3.4.  Service Discovery

   Applications able to tolerate an extra round-trip time (RTT) to learn

   a unicast destination address for multipacket exchanges might safely

   use anycast destination addresses for service instance discovery.

   For example, "instance discovery" messages are sent to an anycast

   destination address, and a reply is subsequently sent from the unique

   unicast source address of the interface that received the discovery

   message, or a reply is sent from the anycast source address of the

   interface that received the message, containing the unicast address

   to be used to invoke the service.  Only the latter of these will

   avoid potential NAT binding and stateful firewall issues.

I think the current “pointing at each other in circles” comes from that we
have not realized how Anycast routing is done: 

An server is installed at a an IP address. We call it anycast server because
it is reachable by an anycast address. The forwarder (router/firewall) that
knows where the anycast server is located *exchanges the destination address
in the packet* (if the server is at a unicast address) to make it arrive at
the server and therefore the server cannot know how it originally was
addressed (by an anycast address or by its unicast address).

So it is a ROUTING ISSUE, not a TURN server issue (“not all TURN servers may
support anycast.” As the text under “3. Discovery Procedure” says is
confusing), that the TURN server cannot know whether it is in the discovery
phase (and shall respond with the error 300) or in the usage phase (and
actually shall make an Allocation).

I think seeing this as a TURN server issue has made us confused. By sending
a Binding (instead of Allocate) during the discovery phase, the TURN server
knows it is in discovery phase and can respond with the error 300
(containing the TURN server’s unicast address). 

Seeing/Understanding this, isn’t that an opening so authors can adjust the
version -12 text and we can move forward?

/Karl

Från: tram [ <mailto:[email-masked]> mailto:[email-masked]]
För Karl Stahl
Skickat: den 13 februari 2017 20:53
Till: 'Brandon Williams'; 'Simon Perreault'; 'Spencer Dawkins at IETF';
<mailto:[email-masked]> [email-masked]
Kopia: 'Tirumaleswar Reddy (tireddy)'
Ämne: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
draft-ietf-tram-turn-server-discovery-12.txt

Regarding Anycast:

 

Reality is: 

Checking History:

/Karl

 

-----Ursprungligt meddelande-----
Från: Brandon Williams [ <mailto:[email-masked]>
mailto:[email-masked]] 
Skickat: den 12 februari 2017 17:13
Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF';
<mailto:[email-masked]> [email-masked]
Kopia: 'Tirumaleswar Reddy (tireddy)'
Ämne: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
draft-ietf-tram-turn-server-discovery-12.txt

receive multiple copies)

--

Karl,

--Brandon

SUBSEQUENT

(tireddy)'

change.

mailto:[email-masked]>

[email-masked]

-- 

--