Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
Karl Stahl <karl.stahl@ingate.com> Wed, 15 February 2017 07:42 UTC
Return-Path: <karl@ingate.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A04128B37 for <tram@ietfa.amsl.com>; Tue, 14 Feb 2017 23:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.009
X-Spam-Level:
X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ingate.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8bV-4f3ooUG for <tram@ietfa.amsl.com>; Tue, 14 Feb 2017 23:42:45 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30071.outbound.protection.outlook.com [40.107.3.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA34128AC9 for <tram@ietf.org>; Tue, 14 Feb 2017 23:42:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingate.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eW8GtS7MaHZeY+X9E3X/qKY4LobG2vUFheclGHuBCIY=; b=Pb6izMGQobgMgG+WF3Dvn2diikIX1w/o2R4i/03re7QH+c28/H3SCq/tvKIJCyJmGAEM8/qRmVs5gUJgWN1rSCkD9YjGJ/96jD7HLGndOISMd8r6RYoefXUF4l1Io7NHOcnbbCsnCT+clElpKJtisdOaZ8/3cWQz4adCtIkX8wY=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=karl@ingate.com;
Received: from Kallei7 (90.227.80.227) by VI1PR01MB1840.eurprd01.prod.exchangelabs.com (10.166.40.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 07:42:39 +0000
From: Karl Stahl <karl.stahl@ingate.com>
To: 'Simon Perreault' <sperreault@jive.com>, 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>, tram@ietf.org, "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>, "'Prashanth Patil (praspati)'" <praspati@cisco.com>, dwing-ietf@fuggles.com
References: <148427986357.3020.7793783112924549744.idtracker@ietfa.amsl.com> <a4aaffdefb794fb0a1b96f0252b862a9@XCH-RCD-017.cisco.com> <CAKKJt-fUzJJS9SXvbG2=T7PDz6nvHnhBqvHRtm-41BoGJsJC6Q@mail.gmail.com> <b139c913-a052-9397-c5df-7cd7c884cf71@jive.com> <CAKKJt-eh8ZZ=5J0KoY9zUpOhj=r9+ATSOk_hEF=G7qTt78_4-Q@mail.gmail.com> <5893bf99.0699370a.55c1f.0964SMTPIN_ADDED_BROKEN@mx.google.com> <bfd3ab0f-dbd5-2f95-1830-fc869a29d7c6@jive.com> <018401d28061$3a85dc80$af919580$@stahl@ingate.com> <ac9ada11-b54f-d15e-dc6c-12ef944db821@akamai.com> <075501d28632$cc7aeaa0$6570bfe0$@stahl@ingate.com>
In-Reply-To: <075501d28632$cc7aeaa0$6570bfe0$@stahl@ingate.com>
Date: Wed, 15 Feb 2017 08:42:31 +0100
Message-ID: <08ea01d2875f$13060450$39120cf0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08EB_01D28767.74CA6C50"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdKFSu0nu/D9yYB5RA+9ioRZTQzuuQA11wKgACdJkyA=
Content-Language: sv
X-Originating-IP: [90.227.80.227]
X-ClientProxiedBy: DB6PR1001CA0006.EURPRD10.PROD.OUTLOOK.COM (10.171.79.16) To VI1PR01MB1840.eurprd01.prod.exchangelabs.com (10.166.40.26)
X-MS-Office365-Filtering-Correlation-Id: 5f5e02b7-c32c-4797-274e-08d455763816
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR01MB1840;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1840; 3:J/quTpwfUXhFY0XAvO03FkALBZBmzP1VjYCqiGfbRSDXoxa/aG8LIgoEsDRLUMTR352YNnejQyw8NdKpqqh/66HMRpeeRc41EwCvdIoId0DdtfvLZfRrZjRHg0+dyWz4O0l0RrXVg28ydN/D+ORX0cIiLyc6sbh9rwxcM/qrugy1pRqdfSeXzKMG1seDY1EF59ZH+/AlpuyDnT/+tQ2MKJL7vsyS2jouiMcb/6TP4KrrpFr5u3g6/QKEU3/vJYpCdUaNRFop9EPnue8wrUrrNw==; 25:sDhGpluEaEmaNhJKtSDjL1S22vH1NF4zlyYHwbcg0eV9XxuprCc7s0NciHSIYWcjJHUMoPaXn38+l+34rOo77ntW/jLQDI2jA4ME85pYceun/ujgz/qcSUzmjIh7PD1XCX/HnzjFywcs83vvoDGU7hJC9KPRx/6KCOVmmnb95B4dXicpmd/99WlGMEQqU9up0v5lnT0ZAyKNpJefdw54AfYlER5Q0mVVlYwQDtYgdW3UTTk1/SsdZXbx2PE2+JRLTou2jlXKC7Jf9EIDlBqgrHI+2xVJ2/8VBn2FI2yCo9STHWmDTXeGTG3I4SnMbotFzsqGzDxWvmW4MaE9wGJ/t0Z8YZ4UYivV9/NkKsKny+JHx2BJDlgwtiRK1bfbzZSyHUlpFu1qpwpKqcSTqo4F5ulV+XGVQ7YFdLTcmTLX1UIFUIXfpiHymh6IdBEZrTO4zqjVgu/h2lzXgf4evZAWIw==
X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1840; 31:HQ4GZNf0L8FID2tBuaUdsRkcsIm5yy7W2+z8HBjx+h1qSPWfRrI4LoPusc3Gcm2SFlXlVspkJ3gRydkhZxX5GnGJBqPAYKQetlRp8OKFHtpiBLQ2cUEuZhAfJhypzNRSa6Zfh1K1XUDP5XOseWuGbA2vFav6KvnqlzOyObAxwH57NSf5lJW+UTdeRqM2EnbK7YurmqQhTMJ+IOWAfSL3oeFD6c8r81Shonuz7O99Ap9qdAe1S+4Y+6vqfnTcRaNRt1f4P54wVyv9ICKVxAUqvQ==
X-Microsoft-Antispam-PRVS: <VI1PR01MB184067561CA5BA9A3B233467B15B0@VI1PR01MB1840.eurprd01.prod.exchangelabs.com>
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(278428928389397)(120809045254105)(192374486261705)(100405760836317)(95692535739014)(21748063052155)(10436049006162);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123562025)(2016111802025)(20161123560025)(20161123564025)(20161123555025)(6072148)(6043046); SRVR:VI1PR01MB1840; BCL:0; PCL:0; RULEID:; SRVR:VI1PR01MB1840;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1840; 4:y0dilqEREg/L7qGGTb0iksSq97R1TrJtv0EGYJ/CF2kI573Ux5B3WYGJJWcrFjMVWghZfKyDXpXpmLjxdTT4VRnuMRgj3sBBc6VtvfTXUcdV8drjWzpk+QGZfUm6Ws2YsDqwIlwJqxnXAemwGTpl8/9O6BHb6CFGg6dx7yz/ttY3eRxn7zS8mfZe5Hv+WLj9cshPMbC/e0hAFYjUcrjAzdQl9vAsz7nIbYLiCpKFdOjIueIcMOYIrhaBVSVTKaf3hUlOQ2klnpTW07zp8UyBF1U8Z/5YzwJMLq7Rt5JoX0AHcmx8m84Qe9CN0n10GzY4s3nEgemxxbi4dPOzPX30BRFjaAaHY26yEpLL9796K+0to0Kd9pn8zXx5CbKPr8v0HA8wgSN6K9SxxXkU4h02ZQm9qWGqxjjLM+M+df05dkD2lNlj8rAygc+JBguX6Vgq+mI1AEdZFqQyrmPJV6fbDJB7iO2iSRx0tf7/3BURFYEdkIYOVX2JF870A04EbmlLZDXJfwmSVhfrEk+3EvaoDYcou+2HLwwRZiWRPuqUOUOzFBmDzgkajdcVu/YtbR7XIQaDEU5ozI1iFlR48vNTJR0TBsX2WsWrteFLMVnXvqEmUmQ+G4UHon3Kdlf076nyO/FU+at13Jyk9acasNsNIoAWR/N2LEFg5C7uD6jjfaKw0IJFdlhtnj+qe8NTwts0R013/WPyLclE3rhUMPmrn/GgAIuuI3Z5CQDX7zMyBZTVk0tSVpJTKTl6w1bblBbK2TP3i2iDUt06lu+Y2XGqzmfJIb44stjZYPK5LHbahTN87kURFPlDvLYWv3fzxJTdibX5ZqKSUQwqQT0neciEalIHrhBMiQ0slrgBw6ehpN+vzMBKZLyXvdNIRMMPriE4wrHfcMB1YG8xEPYDTOzwJo8AvqNSrd/T1GR06HReYY726InhJEQ0VSrVh8UOtqR5
X-Forefront-PRVS: 021975AE46
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(979002)(7916002)(39830400002)(39450400003)(39410400002)(377424004)(377454003)(199003)(24454002)(38534002)(51914003)(189002)(101416001)(14726001)(7736002)(2906002)(33646002)(76176999)(38730400002)(96836002)(50986999)(3846002)(790700001)(7826002)(54896002)(102836003)(6116002)(7906003)(53546003)(66066001)(97736004)(6306002)(2950100002)(189998001)(6666003)(53946003)(36756003)(512934002)(18717965001)(5660300001)(81166006)(9686003)(8676002)(53936002)(84116002)(61296003)(61793004)(93886004)(106356001)(25786008)(236005)(6486002)(5890100001)(81156014)(606005)(44736005)(50226002)(16200700003)(92566002)(230783001)(575784001)(71636004)(68736007)(1420700001)(84326002)(42186005)(105586002)(6496005)(389900002)(959014)(579004)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR01MB1840; H:Kallei7; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: ingate.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1840; 23:KEXczK4zF+pi6cDVUsi0sBXYZPJAGRvba0RbUXBx3/X4orNIb+PhMKrwX9ZNhF5vPJ7KPzqRzuuKVosY6FPV1VXj3L/P1en9AsAboq+MHTp0LjRDiiLbB85VB2oJVOTRy0I7cWjLbFDP1a6tX99B062s9aYWgvgdHKt2cCmu33suNUUUIaWUcI9mubU/cHx4szSv0PZnuFO8LXqamMFSoZMHTqXjb+GUmAtPT4VQND4IQeU4LSo6S2BZAAFLt+LZWD2/V5rw80IBtDkkcQn77NBPW2kRyQHNVSqeOfUY/RjJGzqNGO3y3qozHl1HBUjl+pPmjzB/+y0zFFp+8EeJMqwQMJ9nE6IssWzxgUqXNTfddlKral7/hOrHoDf0cYnbZg+OrnzQp9oYfgyJ5KXNncpiwz+zMsRi7+28bi8MfGdbKSY5u4AMzAjnsXNTGdO9tk9mjBbu8b04iQgN8n4d/DRcSG6GUOd4/iGuPTHcDyMw92a3S9zaJZv3hWU8hCEJX5SJm1SB9v42P3+rGT4s42o5fo89uj7udG9UaYz6Vp6t+2bjiyp02KhO57UXXFYTHLh/E2sqLm5iL/NIwK4CaVyS/Kgqo0qYatTXvDn2XijRg3fJ1CmAfulR0q5fL9v71FwC9IPOELE6PXQ+2frHo1ohQ5Z43GICs0xYkpRtWp1FwAMxHZVgmBOea/PYHpNHHieV9UbraZU6MzxXSKFnuu3tCJ95hA5m+CBBmKB+w4UzEXYO15y7ql37hZ1+2FRyz+ZBt/6TDwY2ryPiTTMIgnk4y/Lts1C9hTUkkGu3QZ6GCLKzso+KqTM8Do0m4ogK1BUsBqlcatGQhxYLPV8iwM+GRxq91nN3qeDlKagwJL+ePM6PIN0Ynbqob5ZBRncOg5ryvmq9mU7RJR1FHzhkO6b85Py6YJ17s7P6FXdm8eM1Y9qRLrQ6vuWuYwcJCx9sNka8Wc5U9+UpzcChA2ECV5p+zSeUHBZeEmKH0xNLj/qhk4yHsr4xru3gDVh40hLAbbYOQY2DZbqeezm1m9LxcgX9ErxZcbMikJ9jScycG/2dEi5g3Y1eusu+8hZJsmUE5bQ/yHmSqfUiKpkiVLhcy0NWiJNTC2Q9YUh4x2gGLhgftXHgpAVSGd6bLmn/MghYDryrZy8X8wnSVAcDji43DZEyWmwH4s0JH06H2JpRmcIt2LTRDZZDDRY6Ff6TIJ34Hg33RW9DuL5kgs9MwDXXIBfKvttZEyXuy0ayQyTNn3VDEY/uHPa9f+FB4jhBUspHdB1XDJDBgFQDXn44OBqscqB5KiWW2gNkx8tF/Cbfv+QZ5tlLpmXV3hSRzhN+tJnr0bdpGnFLefXOlFTGM2+RGRC72viFswi5MLoH50ruTlSGvH8fM8XzSVVpIZFF2frL+nORiAKUHLCoFkkW8se8sS9PfLECbWizYplJUFtivrfE6H/bek+xDK4klEat+SC265jgFnhG5fF9NBZ8xHaS976+c2jFTWHbBLVTHnm6zuVcv8VIFsEWFM8I+/VnFLI0xGfSMn7QwaRMwpdzH6jAu5yYBYua3H3RJzHCa6EXhAP/3xIKmA0tq3YZ0235o9JpZmnKm81cpJIPYK2zOWeIMn98sklUQZLbLJY6Uv80tGCFIkCWhsNpd6pyWL81QjteNIDcvwoW7Pz3hBtq7h+W2LxQ+zwIndGkE9/1B3GyYrs=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1840; 6:SZtd7KIAKzfW5uwFmt0Qb6NYxqRmOFZbeXG7ZzMrjghN2/X4YD4ZUCAmDU4N1rr64qQTEWf2VibXQCHg3/KyBzNW2Jc5RwLs/ZuQosJ/kxo/O6XfKSDRhTAm6yR5cs1XXDxLVYpIXXALwi05vDt2wGeJmIROW26hOaP2qxPVa03A+QnQ738Rsaxxi1qStJwWgybkRSciILEPBpjkFbZTp7U1ogBgtm1bRDY1j7CwYakCSAFEY2FI7rqQ5kj17nA9NARI51Yy1HOqEObyW2GqpJikjSetwT1yZaamlpnLYLzXVPU1fDQ3Xx2otTlrYMiVES56wWuNjDPYqLaQFKiXOyE0n5BBHPSBDjCRcm2a1QGeDLe/kTWjwteY9C2Vddr7OCDusl6nNCuMdXtVWgXwbw==; 5:PhRRl5jrMHx70zfC87PjYrHf36zqF3moBO3snDvA918V8xVMwOMj60VargS/ANUWASeK3TOsktDqr9DMaem3iggP0JHfn1Qu7h6CPbvvIDLWb+xDXFNevi7cIBI/dT0DyOAJ3+rCGElGRHkTAi8+lw==; 24:2EIbP8cPpPyhTJV0SREhTDYOYXj5yFaOjpcqshDbh/ZZgdJMux6JtYpGRVMD6N0IRdOrnZ6LBn/E6uyqzkwFCJnIZK83exKeq5bSIlWO6Ek=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; VI1PR01MB1840; 7:jTc/5zvOy2T8ntTRndPU/SWX7FVlJZQlI+oGnVIUoTZLadE9tSyEMur6iexZ3I3quPxvKtNe+Qh4xArZWabBXVxFAAcPnx4dUGFGyHJAkl0CrDNS4aHVG+DK7f65Jl+6UZTnC24SBORPzq2im2JBQKLPvDwPt1nw5LkC8C4lXQco7cMigBEZU4qlp/8Idih9g3dLRhMimWzPxz1YILqGcLMnHVgeROBunG1cdc+L0rhnkDel9XekIEOZ7kNIckbOgGm/hFJaGAVqEhKnXT7gNjUwruIsr7XGQZXsaSsbIsesJsWvYr3oG11pmMr3Fj0sDuedrfbSANS1jg5sIFdIqv+rLRl4nZx4oTNr58AkredmgfgvtQFaQGu3hGbknJ3I+mbFeEq7E9Z5zJjeJJaMWcabwWs9f7YKRln+WCn7UD/tIRkG1tFrM6ATsISA1O9swt2KQFUoaZkEFYHuAtpZsEqiYTffoDzsxdSwgPb6IVg/27cK43RpKQ1/py4Z7OEjR/4uJYgohc0d8A2La6KKRQ==
X-OriginatorOrg: ingate.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2017 07:42:39.2762 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB1840
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/AzDoS4gVl41TDTrFm1RjMObTifg>
Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 07:42:51 -0000
Authors: Tiru, Prashpanth, Dan (still there?), Reading the below (not mentioning TWO TURN servers, saying TURN anycast server) and Tirus 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 servers unicast address). Seeing/Understanding this, isnt that an opening so authors can adjust the version -12 text and we can move forward? /Karl Från: tram [ <mailto:tram-bounces@ietf.org> mailto:tram-bounces@ietf.org] För Karl Stahl Skickat: den 13 februari 2017 20:53 Till: 'Brandon Williams'; 'Simon Perreault'; 'Spencer Dawkins at IETF'; <mailto:tram@ietf.org> tram@ietf.org 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: 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 When a client requires TURN services, it sends a TURN allocate 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 When a client requires TURN services, it sends a TURN allocate 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 Authors 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:brandon.williams@akamai.com> mailto:brandon.williams@akamai.com] Skickat: den 12 februari 2017 17:13 Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'; <mailto:tram@ietf.org> tram@ietf.org 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 (resending to the list from the correct address; apologies to those who receive multiple copies) -- 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://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=>, > 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 > < <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=>) > 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> 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=> > > > [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 authors 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_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=>. > 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_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=>; > 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://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=> > )). > > > > 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> 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=>) > 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:sperreault@jive.com> mailto:sperreault@jive.com] > Skickat: den 3 februari 2017 14:43 > Till: Karl Stahl; 'Spencer Dawkins at IETF' > Kopia: <mailto:tram@ietf.org> tram@ietf.org; '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, > > > > 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/msg02216.html> 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=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=> > >> > >> > >> > >> For the latest discussed, see > >> > >> > >> > >> <https://www.ietf.org/mail-archive/web/tram/current/msg02279.html> 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=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=> > >> > >>>> 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 > < <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=> > >> > >>> 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> 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=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=> > >> > >> 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> 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=> > >> > >> 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-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://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=> > >> > >> 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 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-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://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=> > >> > >> 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> 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=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=>, > >> further delaying what is needed for Internet real-time communication and > >> especially for WebRTC. > >> > >> > >> > >> /Karl > >> > >> > >> > >> *Från:*tram [ <mailto:tram-bounces@ietf.org> mailto:tram-bounces@ietf.org] *För *Spencer Dawkins at IETF > >> *Skickat:* den 1 februari 2017 22:12 > >> *Till:* Simon Perreault > >> *Kopia:* <mailto:tram@ietf.org> tram@ietf.org < <mailto:tram@ietf.org> mailto:tram@ietf.org> < <mailto:tram@ietf.org> mailto:tram@ietf.org>; > 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 <sperreault@jive.com > >> < <mailto:sperreault@jive.com> mailto:sperreault@jive.com>> wrote: > >> > >> 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) > >>> <tireddy@cisco.com <mailto:tireddy@cisco.com > < <mailto:tireddy@cisco.com%20%3cmailto:tireddy@cisco.com> mailto:tireddy@cisco.com%20%3cmailto:tireddy@cisco.com>><mailto:tireddy@cisc o.com > >> < <mailto:tireddy@cisco.com> mailto:tireddy@cisco.com>>> wrote: > >>> > >>> This revision addresses comments from Brandon. > >>> > >>> -Tiru > >>> > >>> > >>> How close are we to asking Terry to clear the (last remaining) DISCUSS? > >> > >> Thanks for the reminder. > >> > >> 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 > >> > >> > >> > >> _______________________________________________ > >> tram mailing list > >> <mailto:tram@ietf.org> tram@ietf.org < <mailto:tram@ietf.org> mailto:tram@ietf.org> > >> <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram > < <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=> > >> > > > > > > -- > > Simon Perreault > > Director of Engineering, Platform | Jive Communications, Inc. > > <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:sperreault@jive.com> sperreault@jive.com > < <mailto:sperreault@jive.com> mailto:sperreault@jive.com> > > > > _______________________________________________ > tram mailing list > <mailto:tram@ietf.org> tram@ietf.org > <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc.
- [tram] I-D Action: draft-ietf-tram-turn-server-di… internet-drafts
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Tirumaleswar Reddy (tireddy)
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Spencer Dawkins at IETF
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Simon Perreault
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Spencer Dawkins at IETF
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Tirumaleswar Reddy (tireddy)
- [tram] Chime in on attched redlined version-12 WA… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Simon Perreault
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Tirumaleswar Reddy (tireddy)
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] I-D Action: draft-ietf-tram-turn-serve… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Brandon Williams
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl
- Re: [tram] Chime in on attched redlined version-1… Karl Stahl