From nobody Sat Jan 3 16:42:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289F21AC3B3 for ; Sat, 3 Jan 2015 16:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lgFI7wldSicO for ; Sat, 3 Jan 2015 16:42:23 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 375811AC3AE for ; Sat, 3 Jan 2015 16:42:22 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BbdwF0d6hU37x4AA==.55179S4; Sun, 04 Jan 2015 07:13:11 +0800 (CST) From: "Aijun Wang" To: "'Varun Singh'" , "'Tirumaleswar Reddy \(tireddy\)'" References: <913383AAA69FF945B8F946018B75898A3552591A@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Sun, 4 Jan 2015 08:41:49 +0800 Message-ID: <004401d027b7$42c3efe0$c84bcfa0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAk53fR7KaCZukAQuKZW0ejc7E0CgCzbSqQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06BbdwF0d6hU37x4AA==.55179S4 X-Coremail-Antispam: 1U3129KBjvJXoWxAw4kJF4DJFWrCF17ZFyrJFb_yoW5GF4DpF WS9rW8Kr1kJr9rC3sFkw1xJa4YvrWrJr43Jrn8Gr1xC345KFy0g3W8t3yFyFZ8CF1rtws0 v3yjv39rua1jvrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUAVWUtjIFyTuYvjfUOiSdDUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oMfSH3Z4WXPSJdyA_IHJvfpQF_A Cc: 'Simon Perreault' , tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 00:42:27 -0000 Hi, Singh, Reddy and Simon: I admitted that the path characteristic can be one factor to be = considered and can be used to assist the endpoints to select the = appropriate path. The main point of this value that different from other = criteria defined in RFC5245 is that this value will be changed = dynamically and is not determined.=20 Consider the ICE connectivity check will be only done once for one = communication session, is it appropriate for it to rely on one = unreliable value to make the decision? What would you do if it select = one idle pair at first but it become congest later? I think the dynamic path selection should be left to and be considered = by the application layer itself, such as RTCP protocol etc. Best Regards. > -----Original Message----- > From: Varun Singh [mailto:vsingh.ietf@gmail.com] > Sent: Wednesday, December 31, 2014 7:50 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Simon Perreault; Brandon Williams; tram@ietf.org; Aijun Wang > Subject: Re: [tram] FW: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt >=20 > On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy) > wrote: > > Inline [TR] > > On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams > > wrote: > > > > You are correct that the currently published RFC makes the path > > quality information harder to use in a meaningful way. However, = there > > is ongoing work in both tram and mmusic focused on allowing more > > dynamic path selection that can use performance metrics rather than > > the currently defined static priorities. This draft is just one = piece of that > bigger picture. > > > > > > You're right, of course, but if there's no way to make practical use > > of this draft with regular ICE, then that's useful information that > > needs to go into the draft. Ideally with pointers to the bigger = picture you > mentioned. > > > > > > > > [TR] we will update the introduction section to make it clear. This > > draft can be used with regular ICE when there is no noticeable = impact > > in setting up the media session. It depends on the number of = candidate > > pairs, time interval (Ta) for pacing ICE connectivity checks and RTO = values. > > >=20 > True. Path characteristics can be used in addition to the proprietary = criteria the > endpoint currently implements. i.e., if the endpoints wants to stop = checking > because it met its defined criteria and was using the path = characteristics as > part of the STUN messages, it could still use the path characteristics = for those > candidates to make further decisions. >=20 >=20 >=20 > -- > http://www.netlab.tkk.fi/~varun/ From nobody Sun Jan 4 23:27:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B2B1A1E0F for ; Sun, 4 Jan 2015 23:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 X5wnP-2RCn04 for ; Sun, 4 Jan 2015 23:27:35 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5570D1A1E0E for ; Sun, 4 Jan 2015 23:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4145; q=dns/txt; s=iport; t=1420442856; x=1421652456; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=kHel2W3aS9OjY9atdwsYOLnKdvaHaxQzLHweMlJCXRU=; b=SsjCb34ZoJ4DYLIUq9sB9/RfyNTiSbp1w6g5XwaXMRsGNYraXnL57Vsh uusUZ9bIMGqZ12b8fbZkSdfSoha+p/Cr919cv5R6eYcjsCRLnuyjsfOAL YgJJMWmYRMa+0PSm4+gNdCXrftmefzRsULLpDu3PK2KCBNmEBRus6QaP2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAFg8qlStJA2N/2dsb2JhbABcFoJwUlgEw3SCGwyFbwKBBBYBAQEBAX2EDAEBAQMBAQEBNzQJAgUHBgEIEQQBAQEKFAkoBgsUCAEJAQQBDQUIiBADCQgNt0QNhAsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXig2DQIF5MQ2DEIETBY4Vgz+DcIJRMIoCOgOFVCKCMoE8bwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208";a="381232499" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jan 2015 07:27:35 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t057RYPC011675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 07:27:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 01:27:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Aijun Wang , "'Varun Singh'" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAouQ6uDpQby5+uRoW/5l0W5fKUiQ== Date: Mon, 5 Jan 2015 07:27:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/aa-mbyKZbERegTp9LrDr_cSEiOg Cc: 'Simon Perreault' , "tram@ietf.org" , 'Brandon Williams' Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 07:27:38 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang > Sent: Sunday, January 04, 2015 6:12 AM > To: 'Varun Singh'; Tirumaleswar Reddy (tireddy) > Cc: 'Simon Perreault'; tram@ietf.org; 'Brandon Williams' > Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stu= n- > path-data-00.txt >=20 > Hi, Singh, Reddy and Simon: >=20 > I admitted that the path characteristic can be one factor to be considere= d > and can be used to assist the endpoints to select the appropriate path. T= he > main point of this value that different from other criteria defined in RF= C5245 > is that this value will be changed dynamically and is not determined. > Consider the ICE connectivity check will be only done once for one > communication session, is it appropriate for it to rely on one unreliable= value > to make the decision?=20 No, consent freshness and ICE continuous nomination explain that ICE connec= tivity checks happen even after candidates are nominated for the media sess= ion. An interface can be picked based on the current path characteristics, = continue with ICE checks on other interfaces or new interfaces discovered l= ater and switch-over when a better candidate pair is available. For more i= nformation refer to the discussion in mmusic WG (http://juberti.github.io/d= raughts/nombis/draft-uberti-mmusic-nombis.html) > What would you do if it select one idle pair at first but > it become congest later? >=20 > I think the dynamic path selection should be left to and be considered by= the > application layer itself, such as RTCP protocol etc. In case of MPRTP, Path characteristics discovered using ICE will be used f= or picking the interface for the primary sub-flow and interfaces for subseq= uent sub-flows and MPRTP RTCP report can be used later for load balancing.= =20 -Tiru >=20 > Best Regards. >=20 > > -----Original Message----- > > From: Varun Singh [mailto:vsingh.ietf@gmail.com] > > Sent: Wednesday, December 31, 2014 7:50 PM > > To: Tirumaleswar Reddy (tireddy) > > Cc: Simon Perreault; Brandon Williams; tram@ietf.org; Aijun Wang > > Subject: Re: [tram] FW: New Version Notification for > > draft-reddy-tram-stun-path-data-00.txt > > > > On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > > Inline [TR] > > > On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams > > > wrote: > > > > > > You are correct that the currently published RFC makes the path > > > quality information harder to use in a meaningful way. However, > > > there is ongoing work in both tram and mmusic focused on allowing > > > more dynamic path selection that can use performance metrics rather > > > than the currently defined static priorities. This draft is just one > > > piece of that > > bigger picture. > > > > > > > > > You're right, of course, but if there's no way to make practical use > > > of this draft with regular ICE, then that's useful information that > > > needs to go into the draft. Ideally with pointers to the bigger > > > picture you > > mentioned. > > > > > > > > > > > > [TR] we will update the introduction section to make it clear. This > > > draft can be used with regular ICE when there is no noticeable > > > impact in setting up the media session. It depends on the number of > > > candidate pairs, time interval (Ta) for pacing ICE connectivity check= s and > RTO values. > > > > > > > True. Path characteristics can be used in addition to the proprietary > > criteria the endpoint currently implements. i.e., if the endpoints > > wants to stop checking because it met its defined criteria and was > > using the path characteristics as part of the STUN messages, it could > > still use the path characteristics for those candidates to make further > decisions. > > > > > > > > -- > > http://www.netlab.tkk.fi/~varun/ >=20 >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Jan 5 01:01:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6EF1A1BEE for ; Mon, 5 Jan 2015 01:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2ln148bnA0Ve for ; Mon, 5 Jan 2015 01:01:36 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577801A0178 for ; Mon, 5 Jan 2015 01:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19354; q=dns/txt; s=iport; t=1420448497; x=1421658097; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jUmePU/2NXDTxMjoXPHiTxJmMvgqePQxOGUo5BYp7Uw=; b=Ef45FJtNeens7SG9l5DFRcqdRDCmiuh3f2zBlq/FkY1RPoteILFY31f2 4WNS7AySqHCeApTBJGuvd/5v2fkb3AQ+Fds1LiybgyPA39UMjPlixbBYq cGu0XvrrCbrRryPptVUM6W6cmU9BAq6peGFhFqG9cA5GlzF7Sp3N/oA0t M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooGAGFSqlStJV2T/2dsb2JhbABcFoJwUk0LBIMBwTGBXwELhW8CHGkWAQEBAQF9hAwBAQEEAQEBIEsJAgwEAgEIEQQBASgDAgICHwYLFAkIAgQOBYgYAxENqHOPIA2ECwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKDYNAgggiBwaCYi6BEwWMPoFXgz+DcIFEgQ0whGiFGjoDhVQig25vAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208,217";a="384350996" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 05 Jan 2015 09:01:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0591ZRK019586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 09:01:35 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 03:01:35 -0600 From: "Pal Martinsen (palmarti)" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQKMY08iA5OjqfHEuWn8QMJzakSQ== Date: Mon, 5 Jan 2015 09:01:34 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.89.230] Content-Type: multipart/alternative; boundary="_000_E563EB09DC4D49A995971631C33BCD57ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wshEnWODGAJQT1rje5VmL0ZHZIM Cc: Simon Perreault , "tram@ietf.org" , Aijun Wang , Brandon Williams , Varun Singh Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 09:01:40 -0000 --_000_E563EB09DC4D49A995971631C33BCD57ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwNSBKYW4gMjAxNSwgYXQgMDg6MjcsIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkg PHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFpanVuIFdhbmcNClNlbnQ6IFN1bmRheSwgSmFudWFy eSAwNCwgMjAxNSA2OjEyIEFNDQpUbzogJ1ZhcnVuIFNpbmdoJzsgVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KQ0KQ2M6ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPjsgJ0JyYW5kb24gV2lsbGlhbXMnDQpTdWJqZWN0OiBSZTogW3RyYW1dIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi0NCnBh dGgtZGF0YS0wMC50eHQNCg0KSGksIFNpbmdoLCBSZWRkeSBhbmQgU2ltb246DQoNCkkgYWRtaXR0 ZWQgdGhhdCB0aGUgcGF0aCBjaGFyYWN0ZXJpc3RpYyBjYW4gYmUgb25lIGZhY3RvciB0byBiZSBj b25zaWRlcmVkDQphbmQgY2FuIGJlIHVzZWQgdG8gYXNzaXN0IHRoZSBlbmRwb2ludHMgdG8gc2Vs ZWN0IHRoZSBhcHByb3ByaWF0ZSBwYXRoLiBUaGUNCm1haW4gcG9pbnQgb2YgdGhpcyB2YWx1ZSB0 aGF0IGRpZmZlcmVudCBmcm9tIG90aGVyIGNyaXRlcmlhIGRlZmluZWQgaW4gUkZDNTI0NQ0KaXMg dGhhdCB0aGlzIHZhbHVlIHdpbGwgYmUgY2hhbmdlZCBkeW5hbWljYWxseSBhbmQgaXMgbm90IGRl dGVybWluZWQuDQpDb25zaWRlciB0aGUgSUNFIGNvbm5lY3Rpdml0eSBjaGVjayB3aWxsIGJlIG9u bHkgZG9uZSBvbmNlIGZvciBvbmUNCmNvbW11bmljYXRpb24gc2Vzc2lvbiwgaXMgaXQgYXBwcm9w cmlhdGUgZm9yIGl0IHRvIHJlbHkgb24gb25lIHVucmVsaWFibGUgdmFsdWUNCnRvIG1ha2UgdGhl IGRlY2lzaW9uPw0KDQpObywgY29uc2VudCBmcmVzaG5lc3MgYW5kIElDRSBjb250aW51b3VzIG5v bWluYXRpb24gZXhwbGFpbiB0aGF0IElDRSBjb25uZWN0aXZpdHkgY2hlY2tzIGhhcHBlbiBldmVu IGFmdGVyIGNhbmRpZGF0ZXMgYXJlIG5vbWluYXRlZCBmb3IgdGhlIG1lZGlhIHNlc3Npb24uIEFu IGludGVyZmFjZSBjYW4gYmUgcGlja2VkIGJhc2VkIG9uIHRoZSBjdXJyZW50IHBhdGggY2hhcmFj dGVyaXN0aWNzLCBjb250aW51ZSB3aXRoIElDRSBjaGVja3Mgb24gb3RoZXIgaW50ZXJmYWNlcyBv ciBuZXcgaW50ZXJmYWNlcyBkaXNjb3ZlcmVkIGxhdGVyIGFuZCBzd2l0Y2gtb3ZlciB3aGVuIGEg YmV0dGVyIGNhbmRpZGF0ZSBwYWlyIGlzIGF2YWlsYWJsZS4gIEZvciBtb3JlIGluZm9ybWF0aW9u IHJlZmVyIHRvIHRoZSBkaXNjdXNzaW9uIGluIG1tdXNpYyBXRyAoaHR0cDovL2p1YmVydGkuZ2l0 aHViLmlvL2RyYXVnaHRzL25vbWJpcy9kcmFmdC11YmVydGktbW11c2ljLW5vbWJpcy5odG1sKQ0K DQpJIGRvIGFncmVlIHdpdGggQWlqdW5zIHBvaW50IHRoYXQgUkZDNTI0NSBsaW1pdHMgdGhlIHVz YWJpbGl0eSBvZiB0aGlzIGRyYWZ0LiBCdXQgYXMgeW91IHBvaW50IG91dCB0aGVyZSBpcyBhIGxv dCBvZiBkaXNjdXNzaW9ucyBnb2luZyBvbiByZWdhcmRpbmcgaG93IHdlIGNhbiBpbXByb3ZlIElD RSwgbm90IGFsbCBvZiB0aG9zZSBkaXNjdXNzaW9ucyBhcmUgd2VsbCBrbm93bi4gVG8gY2F0Y2gg dXAsIHJlYWRpbmcgdGhlIE1NVVNJQyBtYWlsaW5nLWxpc3QgaXMgcHJvYmFibHkgYSBnb29kIGlk ZWEuDQoNClRvIG1ha2UgaXQgZWFzaWVyIHRvIHJlYWQgdGhlIGRyYWZ0IEkgd291bGQgcHJvcG9z ZSB0byBkbyB0aGUgZm9sbG93aW5nIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCi0gUmVuYW1lIGRy YWZ0IHRvIOKAnFJUVCBhbmQgbG9zcyBtZWFzdXJlbWVudHMgb2YgU1RVTiBUcmFuc2FjdGlvbnPi gJ0uIFBhdGggY2hhcmFjdGVyaXN0aWNzIHNlZW1zIHRvIGhpbnQgdGhhdCBvdGhlciB0aGluZ3Mg bGlrZSBiYW5kd2lkdGggYW5kIHNvIG9uIGlzIGFsc28gaW5jbHVkZWQuDQotIERvd24gcGxheSBJ Q0UgdXNhZ2UuIEZvY3VzIG9uIHdoYXQgYSBUUkFNIGRyYWZ0cyBzaG91bGQgZm9jdXMgb24uIChJ biB0aGlzIGNhc2UgcHJvdmlkZSBSVFQgYW5kIGxvc3MgaW5mb3JtYXRpb24pDQoNCg0KVGhlIERJ U0NVU1MgZHJhZnQgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1tYXJ0aW5zZW4tdHJh bS1kaXNjdXNzLTAxLnR4dCkgYWxzbyBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb3ZpZGUgdXNlZnVs IGluZm9ybWF0aW9uLCBidXQgaXQgcmVxdWlyZXMgc3VwcG9ydCBmcm9tIHRoZSBuZXR3b3JrIHRv IGFjaGlldmUgdGhpcy4NCg0KDQoNCldoYXQgd291bGQgeW91IGRvIGlmIGl0IHNlbGVjdCBvbmUg aWRsZSBwYWlyIGF0IGZpcnN0IGJ1dA0KaXQgYmVjb21lIGNvbmdlc3QgbGF0ZXI/DQoNCkkgdGhp bmsgdGhlIGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24gc2hvdWxkIGJlIGxlZnQgdG8gYW5kIGJlIGNv bnNpZGVyZWQgYnkgdGhlDQphcHBsaWNhdGlvbiBsYXllciBpdHNlbGYsIHN1Y2ggYXMgUlRDUCBw cm90b2NvbCBldGMuDQoNCkluIGNhc2Ugb2YgTVBSVFAsICBQYXRoIGNoYXJhY3RlcmlzdGljcyBk aXNjb3ZlcmVkIHVzaW5nIElDRSB3aWxsIGJlIHVzZWQgZm9yIHBpY2tpbmcgdGhlIGludGVyZmFj ZSBmb3IgdGhlIHByaW1hcnkgc3ViLWZsb3cgYW5kIGludGVyZmFjZXMgZm9yIHN1YnNlcXVlbnQg c3ViLWZsb3dzIGFuZCBNUFJUUCBSVENQIHJlcG9ydCBjYW4gYmUgdXNlZCBsYXRlciBmb3IgbG9h ZCBiYWxhbmNpbmcuDQoNCg0KQSBzaG9ydCBzdW1tYXJ5IG9mIG15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIE1NVVNJQyBJQ0UgZGlzY3Vzc2lvbnMgaXM6DQotIFVzZSBJQ0UgdG8gYnVpbGQgYSB2YWxp ZCBsaXN0DQotIFJlZGVmaW5lZCBob3cgd2UgdXNlIHRoYXQgdmFsaWQgbGlzdC4gKEtlZXBpbmcg cGFpcnMgd2FybSBzbyB3ZSBjYW4gc3dpdGNoIHRvIHRoZW0gZmFzdCArKykNCi0gUmVkZWZpbmUg d2hlbiBhbmQgaG93IHdlIGNob3NlIGFuIGFjdGl2ZSBjYW5kaWRhdGUgcGFpciB0byBzZW5kIG1l ZGlhIG9uLg0KDQouLS4NClDDpWwtRXJpaw0KDQotVGlydQ0KDQoNCkJlc3QgUmVnYXJkcy4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFZhcnVuIFNpbmdoIFttYWlsdG86dnNp bmdoLmlldGZAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAzMSwgMjAxNCA3 OjUwIFBNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IFNpbW9uIFBlcnJl YXVsdDsgQnJhbmRvbiBXaWxsaWFtczsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9y Zz47IEFpanVuIFdhbmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCmRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0DQoNCk9u IFdlZCwgRGVjIDMxLCAyMDE0IGF0IDg6MTkgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSkNCjx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToN CklubGluZSBbVFJdDQpPbiBUdWUsIERlYyAzMCwgMjAxNCBhdCA5OjMxIEFNLCBCcmFuZG9uIFdp bGxpYW1zDQo8YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tPG1haWx0bzpicmFuZG9uLndpbGxp YW1zQGFrYW1haS5jb20+PiB3cm90ZToNCg0KWW91IGFyZSBjb3JyZWN0IHRoYXQgdGhlIGN1cnJl bnRseSBwdWJsaXNoZWQgUkZDIG1ha2VzIHRoZSBwYXRoDQpxdWFsaXR5IGluZm9ybWF0aW9uIGhh cmRlciB0byB1c2UgaW4gYSBtZWFuaW5nZnVsIHdheS4gSG93ZXZlciwNCnRoZXJlIGlzIG9uZ29p bmcgd29yayBpbiBib3RoIHRyYW0gYW5kIG1tdXNpYyBmb2N1c2VkIG9uIGFsbG93aW5nDQptb3Jl IGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24gdGhhdCBjYW4gdXNlIHBlcmZvcm1hbmNlIG1ldHJpY3Mg cmF0aGVyDQp0aGFuIHRoZSBjdXJyZW50bHkgZGVmaW5lZCBzdGF0aWMgcHJpb3JpdGllcy4gVGhp cyBkcmFmdCBpcyBqdXN0IG9uZQ0KcGllY2Ugb2YgdGhhdA0KYmlnZ2VyIHBpY3R1cmUuDQoNCg0K WW91J3JlIHJpZ2h0LCBvZiBjb3Vyc2UsIGJ1dCBpZiB0aGVyZSdzIG5vIHdheSB0byBtYWtlIHBy YWN0aWNhbCB1c2UNCm9mIHRoaXMgZHJhZnQgd2l0aCByZWd1bGFyIElDRSwgdGhlbiB0aGF0J3Mg dXNlZnVsIGluZm9ybWF0aW9uIHRoYXQNCm5lZWRzIHRvIGdvIGludG8gdGhlIGRyYWZ0LiBJZGVh bGx5IHdpdGggcG9pbnRlcnMgdG8gdGhlIGJpZ2dlcg0KcGljdHVyZSB5b3UNCm1lbnRpb25lZC4N Cg0KDQoNCltUUl0gd2Ugd2lsbCB1cGRhdGUgdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uIHRvIG1h a2UgaXQgY2xlYXIuICBUaGlzDQpkcmFmdCBjYW4gYmUgdXNlZCB3aXRoIHJlZ3VsYXIgSUNFIHdo ZW4gdGhlcmUgaXMgbm8gbm90aWNlYWJsZQ0KaW1wYWN0IGluIHNldHRpbmcgdXAgdGhlIG1lZGlh IHNlc3Npb24uIEl0IGRlcGVuZHMgb24gdGhlIG51bWJlciBvZg0KY2FuZGlkYXRlIHBhaXJzLCB0 aW1lIGludGVydmFsIChUYSkgZm9yIHBhY2luZyBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBhbmQN ClJUTyB2YWx1ZXMuDQoNCg0KVHJ1ZS4gUGF0aCBjaGFyYWN0ZXJpc3RpY3MgY2FuIGJlIHVzZWQg aW4gYWRkaXRpb24gdG8gdGhlIHByb3ByaWV0YXJ5DQpjcml0ZXJpYSB0aGUgZW5kcG9pbnQgY3Vy cmVudGx5IGltcGxlbWVudHMuIGkuZS4sIGlmIHRoZSBlbmRwb2ludHMNCndhbnRzIHRvIHN0b3Ag Y2hlY2tpbmcgYmVjYXVzZSBpdCBtZXQgaXRzIGRlZmluZWQgY3JpdGVyaWEgYW5kIHdhcw0KdXNp bmcgdGhlIHBhdGggY2hhcmFjdGVyaXN0aWNzIGFzIHBhcnQgb2YgdGhlIFNUVU4gbWVzc2FnZXMs IGl0IGNvdWxkDQpzdGlsbCB1c2UgdGhlIHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aG9zZSBj YW5kaWRhdGVzIHRvIG1ha2UgZnVydGhlcg0KZGVjaXNpb25zLg0KDQoNCg0KLS0NCmh0dHA6Ly93 d3cubmV0bGFiLnRray5maS9+dmFydW4vDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8 bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== --_000_E563EB09DC4D49A995971631C33BCD57ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3CAF70C502086A4BB3E8B505238FB6C9@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwNSBK YW4gMjAxNSwgYXQgMDg6MjcsIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhy ZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgY2xhc3M9IiI+dGlyZWRkeUBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiB0cmFtIFs8YSBocmVm PSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEFpanVuIFdhbmc8YnIgY2xhc3M9IiI+DQpT ZW50OiBTdW5kYXksIEphbnVhcnkgMDQsIDIwMTUgNjoxMiBBTTxiciBjbGFzcz0iIj4NClRvOiAn VmFydW4gU2luZ2gnOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyIGNsYXNzPSIiPg0K Q2M6ICdTaW1vbiBQZXJyZWF1bHQnOyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xh c3M9IiI+dHJhbUBpZXRmLm9yZzwvYT47ICdCcmFuZG9uIFdpbGxpYW1zJzxiciBjbGFzcz0iIj4N ClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtcmVkZHktdHJhbS1zdHVuLTxiciBjbGFzcz0iIj4NCnBhdGgtZGF0YS0wMC50eHQ8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSwgU2luZ2gsIFJlZGR5IGFuZCBTaW1vbjo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFkbWl0dGVkIHRoYXQgdGhlIHBhdGggY2hhcmFjdGVy aXN0aWMgY2FuIGJlIG9uZSBmYWN0b3IgdG8gYmUgY29uc2lkZXJlZDxiciBjbGFzcz0iIj4NCmFu ZCBjYW4gYmUgdXNlZCB0byBhc3Npc3QgdGhlIGVuZHBvaW50cyB0byBzZWxlY3QgdGhlIGFwcHJv cHJpYXRlIHBhdGguIFRoZTxiciBjbGFzcz0iIj4NCm1haW4gcG9pbnQgb2YgdGhpcyB2YWx1ZSB0 aGF0IGRpZmZlcmVudCBmcm9tIG90aGVyIGNyaXRlcmlhIGRlZmluZWQgaW4gUkZDNTI0NTxiciBj bGFzcz0iIj4NCmlzIHRoYXQgdGhpcyB2YWx1ZSB3aWxsIGJlIGNoYW5nZWQgZHluYW1pY2FsbHkg YW5kIGlzIG5vdCBkZXRlcm1pbmVkLjxiciBjbGFzcz0iIj4NCkNvbnNpZGVyIHRoZSBJQ0UgY29u bmVjdGl2aXR5IGNoZWNrIHdpbGwgYmUgb25seSBkb25lIG9uY2UgZm9yIG9uZTxiciBjbGFzcz0i Ij4NCmNvbW11bmljYXRpb24gc2Vzc2lvbiwgaXMgaXQgYXBwcm9wcmlhdGUgZm9yIGl0IHRvIHJl bHkgb24gb25lIHVucmVsaWFibGUgdmFsdWU8YnIgY2xhc3M9IiI+DQp0byBtYWtlIHRoZSBkZWNp c2lvbj8gPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KTm8sIGNv bnNlbnQgZnJlc2huZXNzIGFuZCBJQ0UgY29udGludW91cyBub21pbmF0aW9uIGV4cGxhaW4gdGhh dCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBoYXBwZW4gZXZlbiBhZnRlciBjYW5kaWRhdGVzIGFy ZSBub21pbmF0ZWQgZm9yIHRoZSBtZWRpYSBzZXNzaW9uLiBBbiBpbnRlcmZhY2UgY2FuIGJlIHBp Y2tlZCBiYXNlZCBvbiB0aGUgY3VycmVudCBwYXRoIGNoYXJhY3RlcmlzdGljcywgY29udGludWUg d2l0aCBJQ0UgY2hlY2tzIG9uIG90aGVyDQogaW50ZXJmYWNlcyBvciBuZXcgaW50ZXJmYWNlcyBk aXNjb3ZlcmVkIGxhdGVyIGFuZCBzd2l0Y2gtb3ZlciB3aGVuIGEgYmV0dGVyIGNhbmRpZGF0ZSBw YWlyIGlzIGF2YWlsYWJsZS4gJm5ic3A7Rm9yIG1vcmUgaW5mb3JtYXRpb24gcmVmZXIgdG8gdGhl IGRpc2N1c3Npb24gaW4gbW11c2ljIFdHICg8YSBocmVmPSJodHRwOi8vanViZXJ0aS5naXRodWIu aW8vZHJhdWdodHMvbm9tYmlzL2RyYWZ0LXViZXJ0aS1tbXVzaWMtbm9tYmlzLmh0bWwiIGNsYXNz PSIiPmh0dHA6Ly9qdWJlcnRpLmdpdGh1Yi5pby9kcmF1Z2h0cy9ub21iaXMvZHJhZnQtdWJlcnRp LW1tdXNpYy1ub21iaXMuaHRtbDwvYT4pPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIGRvIGFncmVlIHdpdGggQWlq dW5zIHBvaW50IHRoYXQgUkZDNTI0NSBsaW1pdHMgdGhlIHVzYWJpbGl0eSBvZiB0aGlzIGRyYWZ0 LiBCdXQgYXMgeW91IHBvaW50IG91dCB0aGVyZSBpcyBhIGxvdCBvZiBkaXNjdXNzaW9ucyBnb2lu ZyBvbiByZWdhcmRpbmcgaG93IHdlIGNhbiBpbXByb3ZlIElDRSwgbm90IGFsbCBvZiB0aG9zZSBk aXNjdXNzaW9ucyBhcmUgd2VsbCBrbm93bi4gVG8gY2F0Y2ggdXAsIHJlYWRpbmcgdGhlIE1NVVNJ QyBtYWlsaW5nLWxpc3QNCiBpcyBwcm9iYWJseSBhIGdvb2QgaWRlYS48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRvIG1ha2UgaXQgZWFzaWVyIHRvIHJlYWQgdGhlIGRy YWZ0IEkgd291bGQgcHJvcG9zZSB0byBkbyB0aGUgZm9sbG93aW5nIGluIHRoZSBuZXh0IHZlcnNp b24uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4tIFJlbmFtZSBkcmFm dCB0byDigJxSVFQgYW5kIGxvc3MgbWVhc3VyZW1lbnRzIG9mIFNUVU4gVHJhbnNhY3Rpb25z4oCd LiBQYXRoIGNoYXJhY3RlcmlzdGljcyBzZWVtcyB0byBoaW50IHRoYXQgb3RoZXIgdGhpbmdzIGxp a2UgYmFuZHdpZHRoIGFuZCBzbyBvbiBpcyBhbHNvIGluY2x1ZGVkLjwvZGl2Pg0KPGRpdj4tIERv d24gcGxheSBJQ0UgdXNhZ2UuIEZvY3VzIG9uIHdoYXQgYSBUUkFNIGRyYWZ0cyBzaG91bGQgZm9j dXMgb24uIChJbiB0aGlzIGNhc2UgcHJvdmlkZSBSVFQgYW5kIGxvc3MgaW5mb3JtYXRpb24pPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+VGhlIERJU0NVU1MgZHJhZnQgKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1kaXNjdXNzLTAxLnR4dCIgY2xhc3M9IiI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDEudHh0PC9h PikgYWxzbyBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb3ZpZGUgdXNlZnVsIGluZm9ybWF0aW9uLCBi dXQgaXQgcmVxdWlyZXMgc3VwcG9ydCBmcm9tIHRoZSBuZXR3b3JrDQogdG8gYWNoaWV2ZSB0aGlz LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+V2hh dCB3b3VsZCB5b3UgZG8gaWYgaXQgc2VsZWN0IG9uZSBpZGxlIHBhaXIgYXQgZmlyc3QgYnV0PGJy IGNsYXNzPSIiPg0KaXQgYmVjb21lIGNvbmdlc3QgbGF0ZXI/PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSSB0aGluayB0aGUgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiBzaG91bGQgYmUgbGVm dCB0byBhbmQgYmUgY29uc2lkZXJlZCBieSB0aGU8YnIgY2xhc3M9IiI+DQphcHBsaWNhdGlvbiBs YXllciBpdHNlbGYsIHN1Y2ggYXMgUlRDUCBwcm90b2NvbCBldGMuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSW4gY2FzZSBvZiBNUFJUUCwgJm5ic3A7UGF0aCBj aGFyYWN0ZXJpc3RpY3MgZGlzY292ZXJlZCB1c2luZyBJQ0Ugd2lsbCBiZSB1c2VkIGZvciBwaWNr aW5nIHRoZSBpbnRlcmZhY2UgZm9yIHRoZSBwcmltYXJ5IHN1Yi1mbG93IGFuZCBpbnRlcmZhY2Vz IGZvciBzdWJzZXF1ZW50IHN1Yi1mbG93cyBhbmQgTVBSVFAgUlRDUCByZXBvcnQgY2FuIGJlIHVz ZWQgbGF0ZXIgZm9yIGxvYWQgYmFsYW5jaW5nLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5BIHNob3J0IHN1bW1hcnkgb2YgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgTU1VU0lDIElDRSBk aXNjdXNzaW9ucyBpczo8L2Rpdj4NCjxkaXY+LSBVc2UgSUNFIHRvIGJ1aWxkIGEgdmFsaWQgbGlz dDwvZGl2Pg0KPGRpdj4tIFJlZGVmaW5lZCBob3cgd2UgdXNlIHRoYXQgdmFsaWQgbGlzdC4gKEtl ZXBpbmcgcGFpcnMgd2FybSBzbyB3ZSBjYW4gc3dpdGNoIHRvIHRoZW0gZmFzdCAmIzQzOyYjNDM7 KTwvZGl2Pg0KPGRpdj4tIFJlZGVmaW5lIHdoZW4gYW5kIGhvdyB3ZSBjaG9zZSBhbiBhY3RpdmUg Y2FuZGlkYXRlIHBhaXIgdG8gc2VuZCBtZWRpYSBvbi48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2Pi4tLjwvZGl2Pg0KPGRpdj5Qw6VsLUVyaWs8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4t VGlydTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkJlc3QgUmVnYXJkcy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IFZhcnVuIFNpbmdoIFs8YSBocmVmPSJt YWlsdG86dnNpbmdoLmlldGZAZ21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86dnNpbmdoLmlldGZA Z21haWwuY29tPC9hPl08YnIgY2xhc3M9IiI+DQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDMx LCAyMDE0IDc6NTAgUE08YnIgY2xhc3M9IiI+DQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KTxiciBjbGFzcz0iIj4NCkNjOiBTaW1vbiBQZXJyZWF1bHQ7IEJyYW5kb24gV2lsbGlhbXM7 IDxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9h PjsgQWlqdW4gV2FuZzxiciBjbGFzcz0iIj4NClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnIgY2xhc3M9IiI+DQpkcmFmdC1yZWRkeS10cmFtLXN0 dW4tcGF0aC1kYXRhLTAwLnR4dDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIFdlZCwg RGVjIDMxLCAyMDE0IGF0IDg6MTkgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnIg Y2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiBjbGFzcz0i Ij50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPklubGluZSBbVFJdPGJyIGNsYXNzPSIiPg0KT24gVHVl LCBEZWMgMzAsIDIwMTQgYXQgOTozMSBBTSwgQnJhbmRvbiBXaWxsaWFtczxiciBjbGFzcz0iIj4N CiZsdDs8YSBocmVmPSJtYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tIiBjbGFzcz0i Ij5icmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudGx5IHB1Ymxp c2hlZCBSRkMgbWFrZXMgdGhlIHBhdGg8YnIgY2xhc3M9IiI+DQpxdWFsaXR5IGluZm9ybWF0aW9u IGhhcmRlciB0byB1c2UgaW4gYSBtZWFuaW5nZnVsIHdheS4gSG93ZXZlciw8YnIgY2xhc3M9IiI+ DQp0aGVyZSBpcyBvbmdvaW5nIHdvcmsgaW4gYm90aCB0cmFtIGFuZCBtbXVzaWMgZm9jdXNlZCBv biBhbGxvd2luZzxiciBjbGFzcz0iIj4NCm1vcmUgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiB0aGF0 IGNhbiB1c2UgcGVyZm9ybWFuY2UgbWV0cmljcyByYXRoZXI8YnIgY2xhc3M9IiI+DQp0aGFuIHRo ZSBjdXJyZW50bHkgZGVmaW5lZCBzdGF0aWMgcHJpb3JpdGllcy4gVGhpcyBkcmFmdCBpcyBqdXN0 IG9uZTxiciBjbGFzcz0iIj4NCnBpZWNlIG9mIHRoYXQ8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQpiaWdnZXIgcGljdHVyZS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3UncmUgcmlnaHQsIG9m IGNvdXJzZSwgYnV0IGlmIHRoZXJlJ3Mgbm8gd2F5IHRvIG1ha2UgcHJhY3RpY2FsIHVzZTxiciBj bGFzcz0iIj4NCm9mIHRoaXMgZHJhZnQgd2l0aCByZWd1bGFyIElDRSwgdGhlbiB0aGF0J3MgdXNl ZnVsIGluZm9ybWF0aW9uIHRoYXQ8YnIgY2xhc3M9IiI+DQpuZWVkcyB0byBnbyBpbnRvIHRoZSBk cmFmdC4gSWRlYWxseSB3aXRoIHBvaW50ZXJzIHRvIHRoZSBiaWdnZXI8YnIgY2xhc3M9IiI+DQpw aWN0dXJlIHlvdTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCm1lbnRpb25lZC48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpbVFJdIHdlIHdpbGwgdXBkYXRlIHRoZSBpbnRy b2R1Y3Rpb24gc2VjdGlvbiB0byBtYWtlIGl0IGNsZWFyLiAmbmJzcDtUaGlzPGJyIGNsYXNzPSIi Pg0KZHJhZnQgY2FuIGJlIHVzZWQgd2l0aCByZWd1bGFyIElDRSB3aGVuIHRoZXJlIGlzIG5vIG5v dGljZWFibGU8YnIgY2xhc3M9IiI+DQppbXBhY3QgaW4gc2V0dGluZyB1cCB0aGUgbWVkaWEgc2Vz c2lvbi4gSXQgZGVwZW5kcyBvbiB0aGUgbnVtYmVyIG9mPGJyIGNsYXNzPSIiPg0KY2FuZGlkYXRl IHBhaXJzLCB0aW1lIGludGVydmFsIChUYSkgZm9yIHBhY2luZyBJQ0UgY29ubmVjdGl2aXR5IGNo ZWNrcyBhbmQ8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQpSVE8g dmFsdWVzLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KVHJ1ZS4gUGF0aCBjaGFyYWN0ZXJpc3RpY3MgY2FuIGJlIHVz ZWQgaW4gYWRkaXRpb24gdG8gdGhlIHByb3ByaWV0YXJ5PGJyIGNsYXNzPSIiPg0KY3JpdGVyaWEg dGhlIGVuZHBvaW50IGN1cnJlbnRseSBpbXBsZW1lbnRzLiBpLmUuLCBpZiB0aGUgZW5kcG9pbnRz PGJyIGNsYXNzPSIiPg0Kd2FudHMgdG8gc3RvcCBjaGVja2luZyBiZWNhdXNlIGl0IG1ldCBpdHMg ZGVmaW5lZCBjcml0ZXJpYSBhbmQgd2FzPGJyIGNsYXNzPSIiPg0KdXNpbmcgdGhlIHBhdGggY2hh cmFjdGVyaXN0aWNzIGFzIHBhcnQgb2YgdGhlIFNUVU4gbWVzc2FnZXMsIGl0IGNvdWxkPGJyIGNs YXNzPSIiPg0Kc3RpbGwgdXNlIHRoZSBwYXRoIGNoYXJhY3RlcmlzdGljcyBmb3IgdGhvc2UgY2Fu ZGlkYXRlcyB0byBtYWtlIGZ1cnRoZXI8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpkZWNp c2lvbnMuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJodHRwOi8vd3d3Lm5ldGxhYi50a2suZmkvfnZhcnVuLyIgY2xhc3M9IiI+aHR0 cDovL3d3dy5uZXRsYWIudGtrLmZpL352YXJ1bi88L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQp0 cmFtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYu b3JnIiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E563EB09DC4D49A995971631C33BCD57ciscocom_-- From nobody Mon Jan 5 05:12:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E451A7006 for ; Mon, 5 Jan 2015 05:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 WA74K7HxqnV1 for ; Mon, 5 Jan 2015 05:12:12 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 790111A6FCB for ; Mon, 5 Jan 2015 05:12:12 -0800 (PST) Received: from [IPv6:2001:470:40b8:0:70bd:ccd8:860b:4125] (unknown [IPv6:2001:470:40b8:0:70bd:ccd8:860b:4125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3ABDC20202; Mon, 5 Jan 2015 14:12:09 +0100 (CET) Message-ID: <54AA8DA7.4060307@acm.org> Date: Mon, 05 Jan 2015 06:12:07 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <1A180643-8AEA-4258-ACFE-9E46B5F0F969@vidyo.com> <868A4DD6-060C-4FBD-A114-F794A4B34C00@cisco.com> In-Reply-To: <868A4DD6-060C-4FBD-A114-F794A4B34C00@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/F_pQ_KbrqKQErG4DetFoH4Aq9v4 Cc: "tram@ietf.org" , Tirumaleswar Reddy Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:12:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/23/2014 09:11 AM, 🔓Dan Wing wrote: > > On Dec 23, 2014, at 7:58 AM, Jonathan Lennox wrote: > >> >> On Dec 23, 2014, at 10:29 AM, Tirumaleswar Reddy (tireddy) wrote: >> >>> This draft describes a mechanism for an endpoint to discover the path characteristics using STUN. >>> Comments and suggestions are welcome. >> >> One other path characteristic that it would be useful to be able to learn is Path MTU. >> >> The natural way to do this would be to support the ICE attribute PADDING (0x0026) (from RFC 5780) in the ICE connectivity/consent STUN usages, though for backward compatibility we may need to resurrect the optional flavor of PADDING (0x8026) from draft-ietf-behave-nat-behavior-discovery-00. >> >> This doesn’t necessarily need to be specified in this same draft, of course, but it seems related. > > Yes, we should determine the path's MTU. Marc wrote http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud but it expired in 2009. > Thanks Dan. As it seems that there is some renewed interest in this draft, I published a new version few minutes ago. This is the same text that was published back in 2009, just refreshed for new publication. I'll publish a more complete version at the end of the week. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUqo2nAAoJECnERZXWan7E+g8QAI1Ldoi2dLI7cMq53ZLrTnjS HkarRkGOCP+QrlcQtO8sSVDkULd71E2h9Aq81KggNsNIoxeCV02TmFfFMh7w6sg4 WvQsUyCh1MCpBrS5HxeT5Wj6T8ig3Oev3/SGaPZc0+P4kZVc+KiyOzcJii9fnfVB Z6YYkwlZixLEiwUW/pl3YOnAHgIIH8W5O4jKJEgqtgPnjudoLnp7ngp+pGBCLP3k XUU/+SiddK9hE4YyfuloiR1XLM3/ccQJK/n0elPDuvuHSSZw54LhrprbkMzrWIiA Vp7fbwyFBnaSPR237sJrY7331SVP9eHukGYgWIyEmwABHjRaiRXA5JQDlJCVKG2t vs2LGxMMQJpUJ5F6mJ0hGaMv41nXqvGbe0GMQG0+9v4hYcoclgVtn9i3yWt7JRNS 7BxIlg3u8UEid26Sk+e398ooslUZ10UOwHlfuWXcRKN8xoa9TLmtQiCRJ9hOfcKZ dsCYyPg8D4kQiIdasfrHlbjdeIARHx7yfGkxeB13nxCNK4vkXJyT5lx4pdWB0Npn nWYArDFX2S7uEg3LlrjOcLNdR7DLfoOqmDBCSVhJtOfMIlFKlkK/+0kqh5E4S8c3 +TOkaxccYIMxwUAXsYZAOtFmW0ybAmsJN2x+LC91oF/5W1t47lDrToRiBkfYeZfh p2hGr3rH8GEXQaDXa+li =ZteH -----END PGP SIGNATURE----- From nobody Mon Jan 5 15:10:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBB41A9071 for ; Mon, 5 Jan 2015 15:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pgOMoouzDfAO for ; Mon, 5 Jan 2015 15:10:26 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4054D1A0266 for ; Mon, 5 Jan 2015 15:10:26 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CBF95284F6 for ; Mon, 5 Jan 2015 23:10:25 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id B9963284F4 for ; Mon, 5 Jan 2015 23:10:25 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B54922026 for ; Mon, 5 Jan 2015 23:10:25 +0000 (GMT) Message-ID: <54AB19E1.1010207@akamai.com> Date: Mon, 05 Jan 2015 18:10:25 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0kZq1HhSCRv-iQK1SCPn7vGHoUk Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 23:10:31 -0000 Hi Pål-Erik, You wrote: Down play ICE usage. Focus on what a TRAM drafts should focus on. (In this case provide RTT and loss information) I'm not certain exactly what you're looking for in the text. I don't really see a meaningful use case for the RTT and loss stats outside of the end-to-end context of the ICE use case, since using partial path stats for decision making will often generate bad results. Do you see a use case other than ICE? Or are you simply suggesting that the draft should avoid referencing a specific use case altogether? Thanks, --Brandon On 01/05/2015 04:01 AM, Pal Martinsen (palmarti) wrote: > >> On 05 Jan 2015, at 08:27, Tirumaleswar Reddy (tireddy) >> > wrote: >> >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang >>> Sent: Sunday, January 04, 2015 6:12 AM >>> To: 'Varun Singh'; Tirumaleswar Reddy (tireddy) >>> Cc: 'Simon Perreault'; tram@ietf.org ; 'Brandon >>> Williams' >>> Subject: Re: [tram] FW: New Version Notification for >>> draft-reddy-tram-stun- >>> path-data-00.txt >>> >>> Hi, Singh, Reddy and Simon: >>> >>> I admitted that the path characteristic can be one factor to be >>> considered >>> and can be used to assist the endpoints to select the appropriate >>> path. The >>> main point of this value that different from other criteria defined >>> in RFC5245 >>> is that this value will be changed dynamically and is not determined. >>> Consider the ICE connectivity check will be only done once for one >>> communication session, is it appropriate for it to rely on one >>> unreliable value >>> to make the decision? >> >> No, consent freshness and ICE continuous nomination explain that ICE >> connectivity checks happen even after candidates are nominated for the >> media session. An interface can be picked based on the current path >> characteristics, continue with ICE checks on other interfaces or new >> interfaces discovered later and switch-over when a better candidate >> pair is available. For more information refer to the discussion in >> mmusic WG >> (http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html) > > I do agree with Aijuns point that RFC5245 limits the usability of this > draft. But as you point out there is a lot of discussions going on > regarding how we can improve ICE, not all of those discussions are well > known. To catch up, reading the MMUSIC mailing-list is probably a good idea. > > To make it easier to read the draft I would propose to do the following > in the next version. > > - Rename draft to “RTT and loss measurements of STUN Transactions”. Path > characteristics seems to hint that other things like bandwidth and so on > is also included. > - Down play ICE usage. Focus on what a TRAM drafts should focus on. (In > this case provide RTT and loss information) > > > The DISCUSS draft > (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt) also have > the ability to provide useful information, but it requires support from > the network to achieve this. > > >> >>> What would you do if it select one idle pair at first but >>> it become congest later? >>> >>> I think the dynamic path selection should be left to and be >>> considered by the >>> application layer itself, such as RTCP protocol etc. >> >> In case of MPRTP, Path characteristics discovered using ICE will be >> used for picking the interface for the primary sub-flow and interfaces >> for subsequent sub-flows and MPRTP RTCP report can be used later for >> load balancing. >> > > A short summary of my understanding of the MMUSIC ICE discussions is: > - Use ICE to build a valid list > - Redefined how we use that valid list. (Keeping pairs warm so we can > switch to them fast ++) > - Redefine when and how we chose an active candidate pair to send media on. > > .-. > Pål-Erik > >> -Tiru >> >>> >>> Best Regards. >>> >>>> -----Original Message----- >>>> From: Varun Singh [mailto:vsingh.ietf@gmail.com] >>>> Sent: Wednesday, December 31, 2014 7:50 PM >>>> To: Tirumaleswar Reddy (tireddy) >>>> Cc: Simon Perreault; Brandon Williams; tram@ietf.org >>>> ; Aijun Wang >>>> Subject: Re: [tram] FW: New Version Notification for >>>> draft-reddy-tram-stun-path-data-00.txt >>>> >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy) >>>> > wrote: >>>>> Inline [TR] >>>>> On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams >>>>> > >>>>> wrote: >>>>> >>>>> You are correct that the currently published RFC makes the path >>>>> quality information harder to use in a meaningful way. However, >>>>> there is ongoing work in both tram and mmusic focused on allowing >>>>> more dynamic path selection that can use performance metrics rather >>>>> than the currently defined static priorities. This draft is just one >>>>> piece of that >>>> bigger picture. >>>>> >>>>> >>>>> You're right, of course, but if there's no way to make practical use >>>>> of this draft with regular ICE, then that's useful information that >>>>> needs to go into the draft. Ideally with pointers to the bigger >>>>> picture you >>>> mentioned. >>>>> >>>>> >>>>> >>>>> [TR] we will update the introduction section to make it clear. This >>>>> draft can be used with regular ICE when there is no noticeable >>>>> impact in setting up the media session. It depends on the number of >>>>> candidate pairs, time interval (Ta) for pacing ICE connectivity >>>>> checks and >>> RTO values. >>>>> >>>> >>>> True. Path characteristics can be used in addition to the proprietary >>>> criteria the endpoint currently implements. i.e., if the endpoints >>>> wants to stop checking because it met its defined criteria and was >>>> using the path characteristics as part of the STUN messages, it could >>>> still use the path characteristics for those candidates to make further >>> decisions. >>>> >>>> >>>> >>>> -- >>>> http://www.netlab.tkk.fi/~varun/ >>> >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Jan 5 19:43:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6AB1A07BC for ; Mon, 5 Jan 2015 19:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 n9w11kqUcIRC for ; Mon, 5 Jan 2015 19:43:15 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFA21A026E for ; Mon, 5 Jan 2015 19:43:13 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CLTQC4RKtUhMOPAA==.31441S4; Tue, 06 Jan 2015 10:13:30 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , "'Pal Martinsen \(palmarti\)'" , "'Tirumaleswar Reddy \(tireddy\)'" References: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> <54AB1995.60306@akamai.com> In-Reply-To: <54AB1995.60306@akamai.com> Date: Tue, 6 Jan 2015 11:42:38 +0800 Message-ID: <003001d02962$da0997e0$8e1cc7a0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdApMStHuqe8CvtnR3qqJzfv1sj5XgAL92gQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06CLTQC4RKtUhMOPAA==.31441S4 X-Coremail-Antispam: 1U3129KBjvJXoWxtFyfAw4xAw18tFW8CF4fGrg_yoW3Cw4rpF W3tayjkF4kJr13AwnFyw18AF1Yv3s5trWUXr15tryUCas8KFyFgF1Utw4ruFWDCr45Jw4j vrWj9347u3WjvrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUAVWUtjIFyTuYvjfUOiSdDUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7y5uODMNm2aGOjkuz08npaHkWs8 Cc: 'Simon Perreault' , tram@ietf.org, 'Varun Singh' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:43:18 -0000 Hi, All: The draft that given by Reddy illustrating some drawback of the current = ICE solution(RFC5245), and actually provided another possible solution = to improve it. I agree also that it is necessary for ICE to check = connectivity continuously, but still hesitate to agree add more = additional function to its role(such as RTT, loss rate, pathmtu etc.). The better solution may be to check the connectivity continuously, = especially for the newly up interface, but only limited to the = connectivity characteristic. The application layer should balance among = these available interfaces that given by ICE, using their own RTT, loss = rate detection and path-mtu finding solution. This can also reduce the = latency of interface switching of the endpoint. Best Regards. Aijun Wang. > -----Original Message----- > From: Brandon Williams [mailto:bowill@akamai.com] > Sent: Tuesday, January 06, 2015 7:09 AM > To: Pal Martinsen (palmarti); Tirumaleswar Reddy (tireddy) > Cc: Aijun Wang; Varun Singh; Simon Perreault; tram@ietf.org > Subject: Re: [tram] New Version Notification for > draft-reddy-tram-stun-path-data-00.txt >=20 > Hi P=C3=A5l-Erik, >=20 > You wrote: Down play ICE usage. Focus on what a TRAM drafts should = focus on. > (In this case provide RTT and loss information) >=20 > I'm not certain exactly what you're looking for in the text. I don't = really see a > meaningful use case for the RTT and loss stats outside of the = end-to-end > context of the ICE use case, since using partial path stats for = decision making > will often generate bad results. Do you see a use case other than ICE? = Or are > you simply suggesting that the draft should avoid referencing a = specific use > case altogether? >=20 > Thanks, > --Brandon >=20 >=20 > On 01/05/2015 04:01 AM, Pal Martinsen (palmarti) wrote: > > > >> On 05 Jan 2015, at 08:27, Tirumaleswar Reddy (tireddy) > >> > wrote: > >> > >>> -----Original Message----- > >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang > >>> Sent: Sunday, January 04, 2015 6:12 AM > >>> To: 'Varun Singh'; Tirumaleswar Reddy (tireddy) > >>> Cc: 'Simon Perreault'; tram@ietf.org ; > >>> 'Brandon Williams' > >>> Subject: Re: [tram] FW: New Version Notification for > >>> draft-reddy-tram-stun- > >>> path-data-00.txt > >>> > >>> Hi, Singh, Reddy and Simon: > >>> > >>> I admitted that the path characteristic can be one factor to be > >>> considered and can be used to assist the endpoints to select the > >>> appropriate path. The main point of this value that different from > >>> other criteria defined in RFC5245 is that this value will be = changed > >>> dynamically and is not determined. > >>> Consider the ICE connectivity check will be only done once for one > >>> communication session, is it appropriate for it to rely on one > >>> unreliable value to make the decision? > >> > >> No, consent freshness and ICE continuous nomination explain that = ICE > >> connectivity checks happen even after candidates are nominated for > >> the media session. An interface can be picked based on the current > >> path characteristics, continue with ICE checks on other interfaces = or > >> new interfaces discovered later and switch-over when a better > >> candidate pair is available. For more information refer to the > >> discussion in mmusic WG > >> = (http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis. > >> html) > > > > I do agree with Aijuns point that RFC5245 limits the usability of = this > > draft. But as you point out there is a lot of discussions going on > > regarding how we can improve ICE, not all of those discussions are > > well known. To catch up, reading the MMUSIC mailing-list is probably = a good > idea. > > > > To make it easier to read the draft I would propose to do the > > following in the next version. > > > > - Rename draft to =E2=80=9CRTT and loss measurements of STUN = Transactions=E2=80=9D. > > Path characteristics seems to hint that other things like bandwidth > > and so on is also included. > > - Down play ICE usage. Focus on what a TRAM drafts should focus on. > > (In this case provide RTT and loss information) > > > > > > The DISCUSS draft > > (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt) also > > have the ability to provide useful information, but it requires > > support from the network to achieve this. > > > > > >> > >>> What would you do if it select one idle pair at first but it = become > >>> congest later? > >>> > >>> I think the dynamic path selection should be left to and be > >>> considered by the application layer itself, such as RTCP protocol > >>> etc. > >> > >> In case of MPRTP, Path characteristics discovered using ICE will = be > >> used for picking the interface for the primary sub-flow and > >> interfaces for subsequent sub-flows and MPRTP RTCP report can be = used > >> later for load balancing. > >> > > > > A short summary of my understanding of the MMUSIC ICE discussions = is: > > - Use ICE to build a valid list > > - Redefined how we use that valid list. (Keeping pairs warm so we = can > > switch to them fast ++) > > - Redefine when and how we chose an active candidate pair to send = media > on. > > > > .-. > > P=C3=A5l-Erik > > > >> -Tiru > >> > >>> > >>> Best Regards. > >>> > >>>> -----Original Message----- > >>>> From: Varun Singh [mailto:vsingh.ietf@gmail.com] > >>>> Sent: Wednesday, December 31, 2014 7:50 PM > >>>> To: Tirumaleswar Reddy (tireddy) > >>>> Cc: Simon Perreault; Brandon Williams; tram@ietf.org > >>>> ; Aijun Wang > >>>> Subject: Re: [tram] FW: New Version Notification for > >>>> draft-reddy-tram-stun-path-data-00.txt > >>>> > >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy) > >>>> > wrote: > >>>>> Inline [TR] > >>>>> On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams > >>>>> > > >>>>> wrote: > >>>>> > >>>>> You are correct that the currently published RFC makes the path > >>>>> quality information harder to use in a meaningful way. However, > >>>>> there is ongoing work in both tram and mmusic focused on = allowing > >>>>> more dynamic path selection that can use performance metrics > >>>>> rather than the currently defined static priorities. This draft = is > >>>>> just one piece of that > >>>> bigger picture. > >>>>> > >>>>> > >>>>> You're right, of course, but if there's no way to make practical > >>>>> use of this draft with regular ICE, then that's useful = information > >>>>> that needs to go into the draft. Ideally with pointers to the > >>>>> bigger picture you > >>>> mentioned. > >>>>> > >>>>> > >>>>> > >>>>> [TR] we will update the introduction section to make it clear. > >>>>> This draft can be used with regular ICE when there is no > >>>>> noticeable impact in setting up the media session. It depends on > >>>>> the number of candidate pairs, time interval (Ta) for pacing ICE > >>>>> connectivity checks and > >>> RTO values. > >>>>> > >>>> > >>>> True. Path characteristics can be used in addition to the > >>>> proprietary criteria the endpoint currently implements. i.e., if > >>>> the endpoints wants to stop checking because it met its defined > >>>> criteria and was using the path characteristics as part of the = STUN > >>>> messages, it could still use the path characteristics for those > >>>> candidates to make further > >>> decisions. > >>>> > >>>> > >>>> > >>>> -- > >>>> http://www.netlab.tkk.fi/~varun/ > >>> > >>> > >>> > >>> _______________________________________________ > >>> tram mailing list > >>> tram@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tram > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Mon Jan 5 22:15:35 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721A21A90FD for ; Mon, 5 Jan 2015 22:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 MIKi-vmn76Mn for ; Mon, 5 Jan 2015 22:15:29 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id EC5031A90F8 for ; Mon, 5 Jan 2015 22:15:28 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CbWBNpaKtU_rWOAA==.36733S4; Tue, 06 Jan 2015 12:45:47 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> In-Reply-To: <54A1CFC0.6030000@akamai.com> Date: Tue, 6 Jan 2015 14:14:57 +0800 Message-ID: <003401d02978$21689220$6439b660$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAjp1jLJ6NbGcuURiislh4lnqYmEgFzkNVQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06CbWBNpaKtU_rWOAA==.36733S4 X-Coremail-Antispam: 1U3129KBjvJXoWxWw4kGF4kCw4rtr1xArW5Wrg_yoW5uw4rpa yIg3yxGrn5Aw1xG3s3uw1I9F15Z3s3XrW5Zr15tr18Z3s8KF12qr12grWrXFy8Gr15Jryj qF48uF48u3Z5ZrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/o4zVUGEpkcGPdd5fIdUgv2gqHMs Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 06:15:31 -0000 Hi, Brandon. I read your draft just and wants to ask you some question for clarification: 1. Is it possible for two peers to select different Relay Server to communicate? If so, will the communication channel between the Relay Server will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure two peers select the same Relay Server? 2. Is it better for ICE server to determine the appropriate Relay Server for two peers at the beginning of ICE connectivity check? The determination process can be based on information such as the load status of each Relay Server, the link usage of its interfaces and the proximity of two peers(based solely on the reflex-address of each peer). Best Regards. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Tuesday, December 30, 2014 6:04 AM > To: tram@ietf.org > Subject: [tram] Fwd: New Version Notification for > draft-williams-peer-redirect-02.txt > > Hi all, > > I've just updated the peer redirect draft to provide the warning labels that Ted > asked for back in Toronto. I also added brief discussion of a load balancing use > case when adding a new flow to an existing allocation. > > There's some work going on both here and in mmusic related to ICE that can > help provide a framework for making more effective use of this redirection > capability. > > I hope that there might be enough interest in this draft for WG adoption and > would like to hear thoughts on that from the list. > > Thanks, > --Brandon > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-williams-peer-redirect-02.txt > Date: Mon, 29 Dec 2014 16:53:47 -0500 > From: internet-drafts@ietf.org > To: Williams, Brandon , Tirumaleswar Reddy > , Tirumaleswar Reddy , Williams, > Brandon > > > A new version of I-D, draft-williams-peer-redirect-02.txt > has been successfully submitted by Brandon Williams and posted to the IETF > repository. > > Name: draft-williams-peer-redirect > Revision: 02 > Title: Peer-specific Redirection for Traversal Using Relays around NAT > (TURN) > Document date: 2014-12-29 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.txt > Status: > https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ > Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 > > Abstract: > This specification describes a peer-specific redirection method that > allows the TURN server to redirect a client for the purpose of > improving communication with a specific peer without negatively > affecting communication with other peers. > > > > > > 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. > > The IETF Secretariat > > > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jan 6 01:31:56 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5058F1A1EEA for ; Tue, 6 Jan 2015 01:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pgyqU5YH6KSm for ; Tue, 6 Jan 2015 01:31:51 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF781A9122 for ; Tue, 6 Jan 2015 01:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12284; q=dns/txt; s=iport; t=1420536711; x=1421746311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=25FZzTywNUa/Xh+ZA2didJ5aJlEW2uTnwCTrgILa2SY=; b=FadNZ8X9vkZSXEhKF3MyAbuv4RNBQUav4pDS9WjX0N0tlUHlkMuT/NZL R7uY200lBDPQLceJ4U6Mc7kaEgCufaWfa7qlcCxuNEqNu0WOFiuSthsOT 7YPffbOJBx6fcGhPll6r/jxmKuk8bG5BF9eWKZrnXAT4Dvd+dLER1m1Bd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkFAK6qq1StJA2I/2dsb2JhbABcFoJwUlgEgwHDMwyFcQIcchYBAQEBAX2EDAEBAQMBAQEBIBE6CQIFBwQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAgQOBYgYAwkIDa1kkCUNg24BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGIbYNAgg8bBwaCYi6BEwWOIINAg3GBRIENMIRshRw6A4VXIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,706,1413244800"; d="scan'208";a="110661063" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 06 Jan 2015 09:31:50 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t069Vn9b004751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 09:31:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 03:31:49 -0600 From: "Pal Martinsen (palmarti)" To: Brandon Williams Thread-Topic: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQKMY08iA5OjqfHEuWn8QMJzakSZyyjJuAgACtmwA= Date: Tue, 6 Jan 2015 09:31:48 +0000 Message-ID: <04FD1E08-CBA8-44F1-A324-74474E302872@cisco.com> References: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> <54AB19E1.1010207@akamai.com> In-Reply-To: <54AB19E1.1010207@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.77.93] Content-Type: text/plain; charset="utf-8" Content-ID: <456938A8CD447A40B6B2308501EC9677@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4H-fgfpguROVh07GYI9wFoL-V_Y Cc: "tram@ietf.org" Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:31:54 -0000 DQo+IE9uIDA2IEphbiAyMDE1LCBhdCAwMDoxMCwgQnJhbmRvbiBXaWxsaWFtcyA8YnJhbmRvbi53 aWxsaWFtc0Bha2FtYWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIFDDpWwtRXJpaywNCj4gDQo+IFlv dSB3cm90ZTogRG93biBwbGF5IElDRSB1c2FnZS4gRm9jdXMgb24gd2hhdCBhIFRSQU0gZHJhZnRz IHNob3VsZCBmb2N1cyBvbi4gKEluIHRoaXMgY2FzZSBwcm92aWRlIFJUVCBhbmQgbG9zcyBpbmZv cm1hdGlvbikNCj4gDQo+IEknbSBub3QgY2VydGFpbiBleGFjdGx5IHdoYXQgeW91J3JlIGxvb2tp bmcgZm9yIGluIHRoZSB0ZXh0LiBJIGRvbid0IHJlYWxseSBzZWUgYSBtZWFuaW5nZnVsIHVzZSBj YXNlIGZvciB0aGUgUlRUIGFuZCBsb3NzIHN0YXRzIG91dHNpZGUgb2YgdGhlIGVuZC10by1lbmQg Y29udGV4dCBvZiB0aGUgSUNFIHVzZSBjYXNlLCBzaW5jZSB1c2luZyBwYXJ0aWFsIHBhdGggc3Rh dHMgZm9yIGRlY2lzaW9uIG1ha2luZyB3aWxsIG9mdGVuIGdlbmVyYXRlIGJhZCByZXN1bHRzLiBE byB5b3Ugc2VlIGEgdXNlIGNhc2Ugb3RoZXIgdGhhbiBJQ0U/IE9yIGFyZSB5b3Ugc2ltcGx5IHN1 Z2dlc3RpbmcgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGF2b2lkIHJlZmVyZW5jaW5nIGEgc3BlY2lm aWMgdXNlIGNhc2UgYWx0b2dldGhlcj8NCj4gDQoNCldoYXQgSSBoYWQgaW4gbWluZCB3aXRoIGRv d25wbGF5IHdhcyB0byBub3QgdXNlIHNvIG1hbnkgd29yZHMgZGVzY3JpYmluZyBJQ0UgaW4gdGhl IGFic3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24uIFdlIGNhbiBzYWZlbHkgcmVtb3ZlIHRoZSBmaXJz dCBwYXJhZ3JhcGggaW4gYm90aCB0aGUgYWJzdHJhY3QgYW5kIGludHJvZHVjdGlvbi4gV2UgZG8g bm90IHdhbnQgdG8gbWFuZGF0ZSBob3cgSUNFIHNob3VsZCB1c2UgdGhpcywgYnV0IG9ubHkgc2F5 IHRoYXQgdGhpcyBpcyB1c2VmdWwgZm9yIHRoZSBkaWZmZXJlbnQgSUNFIHNjZW5hcmlvcy4gDQoN ClNvIHRoZSBuZXcgYWJzdHJhY3Qgd2lsbCBiZToNCiJUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBo b3cgdG8gZXh0ZW5kIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3INCiAgTkFUIChTVFVO KSB0byBtZWFzdXJlIHRoZSB0cmFuc2FjdGlvbiBSVFQgYW5kIGNvdW50IGxvc3QgdHJhbnNhY3Rp b24NCiAgcGFja2V0cy4gIFRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIHVzZWQgYnkgSW50ZXJhY3Rp dmUgQ29ubmVjdGl2aXR5DQogIEVzdGFibGlzaG1lbnQgKElDRSkgdG8gaW1wcm92ZSB0aGUgYWN0 aXZlIHBhdGggc2VsZWN0aW9uLuKAnQ0KDQpOZXcgSW50cm9kdWN0aW9uOg0KIlRoaXMgZHJhZnQg ZXh0ZW5kcyBTVFVOIFtSRkM1Mzg5XSB0byBkaXN0aW5ndWlzaCBTVFVOIHJlc3BvbnNlcyB0bw0K ICByZS10cmFuc21pdHRlZCByZXF1ZXN0cyBhbmQgYXNzaXN0cyB0aGUgY2xpZW50IGluIGRldGVy bWluaW5nIHRoZQ0KICBwYXRoIGNoYXJhY3RlcmlzdGljcyByb3VuZC10cmlwIHRpbWUgKFJUVCkg YW5kIHBhY2tldCBsb3NzIGluIGVhY2gNCiAgZGlyZWN0aW9uIGJldHdlZW4gZW5kcG9pbnRzLg0K DQogIFdoZW4gbWVhc3VyaW5nIFJUVCBvbiBzdHVuIHJlcXVlc3RzIHJlLXRyYW5zbWl0cyBjYW4g Y2F1c2UgYW4NCiAgb3RoZXJ3aXNlLWdvb2QgcGF0aCB0byBhcHBlYXIgZmxhd2VkLiAgSG93ZXZl ciwgU1RVTidzIHJldHJhbnNtaXNzaW9uDQogIGFsZ29yaXRobSBbUkZDNTM4OV0gY2Fubm90IGRl dGVybWluZSB0aGUgcm91bmQtdHJpcCB0aW1lIGlmIGEgU1RVTg0KICByZXF1ZXN0IHBhY2tldCBp cyByZS10cmFuc21pdHRlZCwgYmVjYXVzZSBlYWNoIHBhY2tldCByZXF1ZXN0IGFuZA0KICByZXRy YW5zbWlzc2lvbiBpcyBpZGVudGljYWwuDQoNCiAgVG8gcmVzb2x2ZSB0aGUgaXNzdWUgb2YgaWRl bnRpY2FsIHJlcXVlc3QgYW5kIHJlc3BvbnNlIHBhY2tldHMgaW4gYQ0KICBTVFVOIHRyYW5zYWN0 aW9uLCB0aGlzIGRvY3VtZW50IGNoYW5nZXMgdGhhdCByZXRyYW5zbWlzc2lvbiBiZWhhdmlvcg0K ICBmb3IgaWRlbXBvdGVudCBwYWNrZXRzLiAgSW4gYWRkaXRpb24gdG8gZGV0ZXJtaW5pbmcgUlRU LCBpdCBpcyBhbHNvDQogIGRlc2lyYWJsZSB0byBkZXRlY3Qgd2hpY2ggcGF0aCBkaXJlY3Rpb24g Y2F1c2VkIHBhY2tldCBsb3NzLA0KICBkZXNjcmliZWQgYXMgImJpLWRpcmVjdGlvbmFsIHBhdGgg Y2hhcmFjdGVyaXN0aWNzLCIgYmVsb3cuICBUaGlzIGlzDQogIGFjaGlldmVkIGJ5IGRlZmluaW5n IGEgbmV3IFNUVU4gYXR0cmlidXRlIGFuZCByZXF1aXJlcyBjb21wbGlhbnQgU1RVTg0KICAoVFVS TiwgSUNFKSBzZXJ2ZXJzIHRvIGNvdW50IHJldHJhbnNtaXR0ZWQgcmVxdWVzdCBwYWNrZXRzLuKA nQ0KDQouLS4NClDDpWwtRXJpaw0KDQoNCg0KDQo+IFRoYW5rcywNCj4gLS1CcmFuZG9uDQo+IA0K PiANCj4gT24gMDEvMDUvMjAxNSAwNDowMSBBTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIHdy b3RlOg0KPj4gDQo+Pj4gT24gMDUgSmFuIDIwMTUsIGF0IDA4OjI3LCBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQo+Pj4gPHRpcmVkZHlAY2lzY28uY29tIDxtYWlsdG86dGlyZWRkeUBjaXNj by5jb20+PiB3cm90ZToNCj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFpanVuIFdhbmcNCj4+Pj4gU2VudDogU3VuZGF5LCBKYW51YXJ5IDA0LCAyMDE1IDY6MTIgQU0N Cj4+Pj4gVG86ICdWYXJ1biBTaW5naCc7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4+ Pj4gQ2M6ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRm Lm9yZz47ICdCcmFuZG9uDQo+Pj4+IFdpbGxpYW1zJw0KPj4+PiBTdWJqZWN0OiBSZTogW3RyYW1d IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4+IGRyYWZ0LXJlZGR5LXRyYW0t c3R1bi0NCj4+Pj4gcGF0aC1kYXRhLTAwLnR4dA0KPj4+PiANCj4+Pj4gSGksIFNpbmdoLCBSZWRk eSBhbmQgU2ltb246DQo+Pj4+IA0KPj4+PiBJIGFkbWl0dGVkIHRoYXQgdGhlIHBhdGggY2hhcmFj dGVyaXN0aWMgY2FuIGJlIG9uZSBmYWN0b3IgdG8gYmUNCj4+Pj4gY29uc2lkZXJlZA0KPj4+PiBh bmQgY2FuIGJlIHVzZWQgdG8gYXNzaXN0IHRoZSBlbmRwb2ludHMgdG8gc2VsZWN0IHRoZSBhcHBy b3ByaWF0ZQ0KPj4+PiBwYXRoLiBUaGUNCj4+Pj4gbWFpbiBwb2ludCBvZiB0aGlzIHZhbHVlIHRo YXQgZGlmZmVyZW50IGZyb20gb3RoZXIgY3JpdGVyaWEgZGVmaW5lZA0KPj4+PiBpbiBSRkM1MjQ1 DQo+Pj4+IGlzIHRoYXQgdGhpcyB2YWx1ZSB3aWxsIGJlIGNoYW5nZWQgZHluYW1pY2FsbHkgYW5k IGlzIG5vdCBkZXRlcm1pbmVkLg0KPj4+PiBDb25zaWRlciB0aGUgSUNFIGNvbm5lY3Rpdml0eSBj aGVjayB3aWxsIGJlIG9ubHkgZG9uZSBvbmNlIGZvciBvbmUNCj4+Pj4gY29tbXVuaWNhdGlvbiBz ZXNzaW9uLCBpcyBpdCBhcHByb3ByaWF0ZSBmb3IgaXQgdG8gcmVseSBvbiBvbmUNCj4+Pj4gdW5y ZWxpYWJsZSB2YWx1ZQ0KPj4+PiB0byBtYWtlIHRoZSBkZWNpc2lvbj8NCj4+PiANCj4+PiBObywg Y29uc2VudCBmcmVzaG5lc3MgYW5kIElDRSBjb250aW51b3VzIG5vbWluYXRpb24gZXhwbGFpbiB0 aGF0IElDRQ0KPj4+IGNvbm5lY3Rpdml0eSBjaGVja3MgaGFwcGVuIGV2ZW4gYWZ0ZXIgY2FuZGlk YXRlcyBhcmUgbm9taW5hdGVkIGZvciB0aGUNCj4+PiBtZWRpYSBzZXNzaW9uLiBBbiBpbnRlcmZh Y2UgY2FuIGJlIHBpY2tlZCBiYXNlZCBvbiB0aGUgY3VycmVudCBwYXRoDQo+Pj4gY2hhcmFjdGVy aXN0aWNzLCBjb250aW51ZSB3aXRoIElDRSBjaGVja3Mgb24gb3RoZXIgaW50ZXJmYWNlcyBvciBu ZXcNCj4+PiBpbnRlcmZhY2VzIGRpc2NvdmVyZWQgbGF0ZXIgYW5kIHN3aXRjaC1vdmVyIHdoZW4g YSBiZXR0ZXIgY2FuZGlkYXRlDQo+Pj4gcGFpciBpcyBhdmFpbGFibGUuICBGb3IgbW9yZSBpbmZv cm1hdGlvbiByZWZlciB0byB0aGUgZGlzY3Vzc2lvbiBpbg0KPj4+IG1tdXNpYyBXRw0KPj4+ICho dHRwOi8vanViZXJ0aS5naXRodWIuaW8vZHJhdWdodHMvbm9tYmlzL2RyYWZ0LXViZXJ0aS1tbXVz aWMtbm9tYmlzLmh0bWwpDQo+PiANCj4+IEkgZG8gYWdyZWUgd2l0aCBBaWp1bnMgcG9pbnQgdGhh dCBSRkM1MjQ1IGxpbWl0cyB0aGUgdXNhYmlsaXR5IG9mIHRoaXMNCj4+IGRyYWZ0LiBCdXQgYXMg eW91IHBvaW50IG91dCB0aGVyZSBpcyBhIGxvdCBvZiBkaXNjdXNzaW9ucyBnb2luZyBvbg0KPj4g cmVnYXJkaW5nIGhvdyB3ZSBjYW4gaW1wcm92ZSBJQ0UsIG5vdCBhbGwgb2YgdGhvc2UgZGlzY3Vz c2lvbnMgYXJlIHdlbGwNCj4+IGtub3duLiBUbyBjYXRjaCB1cCwgcmVhZGluZyB0aGUgTU1VU0lD IG1haWxpbmctbGlzdCBpcyBwcm9iYWJseSBhIGdvb2QgaWRlYS4NCj4+IA0KPj4gVG8gbWFrZSBp dCBlYXNpZXIgdG8gcmVhZCB0aGUgZHJhZnQgSSB3b3VsZCBwcm9wb3NlIHRvIGRvIHRoZSBmb2xs b3dpbmcNCj4+IGluIHRoZSBuZXh0IHZlcnNpb24uDQo+PiANCj4+IC0gUmVuYW1lIGRyYWZ0IHRv IOKAnFJUVCBhbmQgbG9zcyBtZWFzdXJlbWVudHMgb2YgU1RVTiBUcmFuc2FjdGlvbnPigJ0uIFBh dGgNCj4+IGNoYXJhY3RlcmlzdGljcyBzZWVtcyB0byBoaW50IHRoYXQgb3RoZXIgdGhpbmdzIGxp a2UgYmFuZHdpZHRoIGFuZCBzbyBvbg0KPj4gaXMgYWxzbyBpbmNsdWRlZC4NCj4+IC0gRG93biBw bGF5IElDRSB1c2FnZS4gRm9jdXMgb24gd2hhdCBhIFRSQU0gZHJhZnRzIHNob3VsZCBmb2N1cyBv bi4gKEluDQo+PiB0aGlzIGNhc2UgcHJvdmlkZSBSVFQgYW5kIGxvc3MgaW5mb3JtYXRpb24pDQo+ PiANCj4+IA0KPj4gVGhlIERJU0NVU1MgZHJhZnQNCj4+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtbWFydGluc2VuLXRyYW0tZGlzY3Vzcy0wMS50eHQpIGFsc28gaGF2ZQ0KPj4gdGhl IGFiaWxpdHkgdG8gcHJvdmlkZSB1c2VmdWwgaW5mb3JtYXRpb24sIGJ1dCBpdCByZXF1aXJlcyBz dXBwb3J0IGZyb20NCj4+IHRoZSBuZXR3b3JrIHRvIGFjaGlldmUgdGhpcy4NCj4+IA0KPj4gDQo+ Pj4gDQo+Pj4+IFdoYXQgd291bGQgeW91IGRvIGlmIGl0IHNlbGVjdCBvbmUgaWRsZSBwYWlyIGF0 IGZpcnN0IGJ1dA0KPj4+PiBpdCBiZWNvbWUgY29uZ2VzdCBsYXRlcj8NCj4+Pj4gDQo+Pj4+IEkg dGhpbmsgdGhlIGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24gc2hvdWxkIGJlIGxlZnQgdG8gYW5kIGJl DQo+Pj4+IGNvbnNpZGVyZWQgYnkgdGhlDQo+Pj4+IGFwcGxpY2F0aW9uIGxheWVyIGl0c2VsZiwg c3VjaCBhcyBSVENQIHByb3RvY29sIGV0Yy4NCj4+PiANCj4+PiBJbiBjYXNlIG9mIE1QUlRQLCAg UGF0aCBjaGFyYWN0ZXJpc3RpY3MgZGlzY292ZXJlZCB1c2luZyBJQ0Ugd2lsbCBiZQ0KPj4+IHVz ZWQgZm9yIHBpY2tpbmcgdGhlIGludGVyZmFjZSBmb3IgdGhlIHByaW1hcnkgc3ViLWZsb3cgYW5k IGludGVyZmFjZXMNCj4+PiBmb3Igc3Vic2VxdWVudCBzdWItZmxvd3MgYW5kIE1QUlRQIFJUQ1Ag cmVwb3J0IGNhbiBiZSB1c2VkIGxhdGVyIGZvcg0KPj4+IGxvYWQgYmFsYW5jaW5nLg0KPj4+IA0K Pj4gDQo+PiBBIHNob3J0IHN1bW1hcnkgb2YgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgTU1VU0lD IElDRSBkaXNjdXNzaW9ucyBpczoNCj4+IC0gVXNlIElDRSB0byBidWlsZCBhIHZhbGlkIGxpc3QN Cj4+IC0gUmVkZWZpbmVkIGhvdyB3ZSB1c2UgdGhhdCB2YWxpZCBsaXN0LiAoS2VlcGluZyBwYWly cyB3YXJtIHNvIHdlIGNhbg0KPj4gc3dpdGNoIHRvIHRoZW0gZmFzdCArKykNCj4+IC0gUmVkZWZp bmUgd2hlbiBhbmQgaG93IHdlIGNob3NlIGFuIGFjdGl2ZSBjYW5kaWRhdGUgcGFpciB0byBzZW5k IG1lZGlhIG9uLg0KPj4gDQo+PiAuLS4NCj4+IFDDpWwtRXJpaw0KPj4gDQo+Pj4gLVRpcnUNCj4+ PiANCj4+Pj4gDQo+Pj4+IEJlc3QgUmVnYXJkcy4NCj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogVmFydW4gU2luZ2ggW21haWx0bzp2c2luZ2guaWV0 ZkBnbWFpbC5jb21dDQo+Pj4+PiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDMxLCAyMDE0IDc6 NTAgUE0NCj4+Pj4+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+Pj4+PiBDYzog U2ltb24gUGVycmVhdWx0OyBCcmFuZG9uIFdpbGxpYW1zOyB0cmFtQGlldGYub3JnDQo+Pj4+PiA8 bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBBaWp1biBXYW5nDQo+Pj4+PiBTdWJqZWN0OiBSZTogW3Ry YW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4+PiBkcmFmdC1yZWRkeS10 cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KPj4+Pj4gDQo+Pj4+PiBPbiBXZWQsIERlYyAzMSwg MjAxNCBhdCA4OjE5IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+Pj4+PiA8dGly ZWRkeUBjaXNjby5jb20gPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPj4+Pj4+ IElubGluZSBbVFJdDQo+Pj4+Pj4gT24gVHVlLCBEZWMgMzAsIDIwMTQgYXQgOTozMSBBTSwgQnJh bmRvbiBXaWxsaWFtcw0KPj4+Pj4+IDxicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20gPG1haWx0 bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+Pg0KPj4+Pj4+IHdyb3RlOg0KPj4+Pj4+IA0K Pj4+Pj4+IFlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBjdXJyZW50bHkgcHVibGlzaGVkIFJGQyBt YWtlcyB0aGUgcGF0aA0KPj4+Pj4+IHF1YWxpdHkgaW5mb3JtYXRpb24gaGFyZGVyIHRvIHVzZSBp biBhIG1lYW5pbmdmdWwgd2F5LiBIb3dldmVyLA0KPj4+Pj4+IHRoZXJlIGlzIG9uZ29pbmcgd29y ayBpbiBib3RoIHRyYW0gYW5kIG1tdXNpYyBmb2N1c2VkIG9uIGFsbG93aW5nDQo+Pj4+Pj4gbW9y ZSBkeW5hbWljIHBhdGggc2VsZWN0aW9uIHRoYXQgY2FuIHVzZSBwZXJmb3JtYW5jZSBtZXRyaWNz IHJhdGhlcg0KPj4+Pj4+IHRoYW4gdGhlIGN1cnJlbnRseSBkZWZpbmVkIHN0YXRpYyBwcmlvcml0 aWVzLiBUaGlzIGRyYWZ0IGlzIGp1c3Qgb25lDQo+Pj4+Pj4gcGllY2Ugb2YgdGhhdA0KPj4+Pj4g YmlnZ2VyIHBpY3R1cmUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gWW91J3JlIHJpZ2h0LCBv ZiBjb3Vyc2UsIGJ1dCBpZiB0aGVyZSdzIG5vIHdheSB0byBtYWtlIHByYWN0aWNhbCB1c2UNCj4+ Pj4+PiBvZiB0aGlzIGRyYWZ0IHdpdGggcmVndWxhciBJQ0UsIHRoZW4gdGhhdCdzIHVzZWZ1bCBp bmZvcm1hdGlvbiB0aGF0DQo+Pj4+Pj4gbmVlZHMgdG8gZ28gaW50byB0aGUgZHJhZnQuIElkZWFs bHkgd2l0aCBwb2ludGVycyB0byB0aGUgYmlnZ2VyDQo+Pj4+Pj4gcGljdHVyZSB5b3UNCj4+Pj4+ IG1lbnRpb25lZC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBbVFJdIHdlIHdp bGwgdXBkYXRlIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiB0byBtYWtlIGl0IGNsZWFyLiAgVGhp cw0KPj4+Pj4+IGRyYWZ0IGNhbiBiZSB1c2VkIHdpdGggcmVndWxhciBJQ0Ugd2hlbiB0aGVyZSBp cyBubyBub3RpY2VhYmxlDQo+Pj4+Pj4gaW1wYWN0IGluIHNldHRpbmcgdXAgdGhlIG1lZGlhIHNl c3Npb24uIEl0IGRlcGVuZHMgb24gdGhlIG51bWJlciBvZg0KPj4+Pj4+IGNhbmRpZGF0ZSBwYWly cywgdGltZSBpbnRlcnZhbCAoVGEpIGZvciBwYWNpbmcgSUNFIGNvbm5lY3Rpdml0eQ0KPj4+Pj4+ IGNoZWNrcyBhbmQNCj4+Pj4gUlRPIHZhbHVlcy4NCj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gVHJ1 ZS4gUGF0aCBjaGFyYWN0ZXJpc3RpY3MgY2FuIGJlIHVzZWQgaW4gYWRkaXRpb24gdG8gdGhlIHBy b3ByaWV0YXJ5DQo+Pj4+PiBjcml0ZXJpYSB0aGUgZW5kcG9pbnQgY3VycmVudGx5IGltcGxlbWVu dHMuIGkuZS4sIGlmIHRoZSBlbmRwb2ludHMNCj4+Pj4+IHdhbnRzIHRvIHN0b3AgY2hlY2tpbmcg YmVjYXVzZSBpdCBtZXQgaXRzIGRlZmluZWQgY3JpdGVyaWEgYW5kIHdhcw0KPj4+Pj4gdXNpbmcg dGhlIHBhdGggY2hhcmFjdGVyaXN0aWNzIGFzIHBhcnQgb2YgdGhlIFNUVU4gbWVzc2FnZXMsIGl0 IGNvdWxkDQo+Pj4+PiBzdGlsbCB1c2UgdGhlIHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aG9z ZSBjYW5kaWRhdGVzIHRvIG1ha2UgZnVydGhlcg0KPj4+PiBkZWNpc2lvbnMuDQo+Pj4+PiANCj4+ Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtLQ0KPj4+Pj4gaHR0cDovL3d3dy5uZXRsYWIudGtrLmZpL352 YXJ1bi8NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+Pj4gdHJh bUBpZXRmLm9yZyA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+PiB0 cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4+IA0KPiANCj4gLS0gDQo+IEJyYW5kb24gV2ls bGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXINCj4gRW1lcmdpbmcgUHJv ZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPiANCj4gLS0gDQo+ IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXINCj4g RW1lcmdpbmcgUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g dHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0K From nobody Tue Jan 6 01:52:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F0E1A1BB7 for ; Tue, 6 Jan 2015 01:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1vh6khMf0OLD for ; Tue, 6 Jan 2015 01:52:30 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C631A0029 for ; Tue, 6 Jan 2015 01:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13022; q=dns/txt; s=iport; t=1420537949; x=1421747549; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OqmLpRXHUemMux4tQnUQTcbeQJDOYiQco+Bm8OTPuKY=; b=cSawra4zMh2hD06obOdljdPdk5ZSq/LmPNO23jMlhwvQVXHzr/am1C0H PL3rNBu3nd3ZS7dhb6TK+Vzz68hKofSpHv6D0aQB03z0Y29rDYndFGb1v gHZablWnWeMR7YI4JBEAJ/Yw2thwedaWp/FYFNt5yuFzB/pw7WJSnZtpV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkFACOvq1StJA2L/2dsb2JhbABcFoJwUlgEgwHDMwqFcwIcchYBAQEBAX2EDAEBAQMBAQEBCxURMQkJAgUHBAIBCBEEAQEBAgIjAwICAh8GCxQBCAgCBA4FG4d9AwkIDa1okCUNg24BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGIbYNAgUcLJRgbBwaCYi6BEwWOIINAg3GBRIENMIRshRw6A4VXIoNubwGBAkJ+AQEB X-IronPort-AV: E=Sophos;i="5.07,706,1413244800"; d="scan'208";a="110669524" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 06 Jan 2015 09:52:28 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t069qSHx015392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 09:52:28 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 03:52:28 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQKMY08iA5OjqfHEuWn8QMJzakSZyyjEGAgABMaQCAAGdSAA== Date: Tue, 6 Jan 2015 09:52:27 +0000 Message-ID: <8549007E-B474-4059-AEA1-C132EF92B5D2@cisco.com> References: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> <54AB1995.60306@akamai.com> <003001d02962$da0997e0$8e1cc7a0$@org.cn> In-Reply-To: <003001d02962$da0997e0$8e1cc7a0$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.77.93] Content-Type: text/plain; charset="utf-8" Content-ID: <5B4DCA51577AD0498BB2BFE34BB049D4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/q-veLypPzsvqnYv2GJQE_2gGrMw Cc: Simon Perreault , Varun Singh , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:52:33 -0000 DQo+IE9uIDA2IEphbiAyMDE1LCBhdCAwNDo0MiwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4gd3JvdGU6DQo+IA0KPiBIaSwgQWxsOg0KPiANCj4gVGhlIGRyYWZ0IHRoYXQg Z2l2ZW4gYnkgUmVkZHkgaWxsdXN0cmF0aW5nIHNvbWUgZHJhd2JhY2sgb2YgdGhlIGN1cnJlbnQg SUNFIHNvbHV0aW9uKFJGQzUyNDUpLCBhbmQgYWN0dWFsbHkgcHJvdmlkZWQgYW5vdGhlciBwb3Nz aWJsZSBzb2x1dGlvbiB0byBpbXByb3ZlIGl0LiAgSSBhZ3JlZSBhbHNvIHRoYXQgaXQgaXMgbmVj ZXNzYXJ5IGZvciBJQ0UgdG8gY2hlY2sgY29ubmVjdGl2aXR5IGNvbnRpbnVvdXNseSwgYnV0IHN0 aWxsIGhlc2l0YXRlIHRvIGFncmVlIGFkZCBtb3JlIGFkZGl0aW9uYWwgZnVuY3Rpb24gdG8gaXRz IHJvbGUoc3VjaCBhcyBSVFQsIGxvc3MgcmF0ZSwgcGF0aG10dSBldGMuKS4NCj4gDQpUaGUgZHJh ZnQgaWRlbnRpZmllcyBwcm9ibGVtcyBtZWFzdXJpbmcgZW5kIHRvIGVuZCBSVFQgYW5kIHBhY2tl dCBsb3NzIHdpdGggdGhlIGN1cnJlbnQgZGVmaW5lZCBTVFVOIHRyYW5zYWN0aW9uIHNvbHV0aW9u LiBJZiB0aGF0IGlzIHNvbHZlZCBpdCBjYW4gcHJvdmlkZSB1c2VmdWwgaW5mb3JtYXRpb24gdG8g dGhlIG5leHQgZ2VuZXJhdGlvbiBvZiBJQ0Ugc3BlY3MuIFdlIGNhbiBmaXggU1RVTiBwcm9ibGVt cyBoZXJlIGluIFRSQU0sIG5ldyBJQ0Ugc29sdXRpb25zIHNob3VsZCBpZGVhbGx5IGJlIGRpc2N1 c3NlZCBpbiBNTVVTSUMuIEJ1dCBzb21lIGNyb3Nzb3ZlciBpcyB1bmF2b2lkYWJsZS4gDQoNCkkg d291bGQgYWxzbyBsaWtlIHRvIHBvaW50IG91dCB0aGF0IGF0IGxlYXN0IHNvbWUgd2ViUlRDIElD RSBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBhIGRpZmZlcmVudCBzb2x1dGlvbiB0byB0aGlzIHByb2Js ZW0uIEFzIHRoZXkgb25seSBjYW4gc2VuZCBhIFNUVU4gcGFja2V0IGV2ZXJ5IDUwbXMoPyksIHRo ZXkgY2hvc2UgdG8gc2ltcGxpZnkgdGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgYnkgaWdub3Jpbmcg dGhlIFNUVU4gVHJhbnNhY3Rpb24gcGFydC4gVGhleSB3aWxsIGZpcmUgb2ZmIGEgbmV3IFNUVU4g cGFja2V0IGV2ZXJ5IHggbXMsIGFuZCBpZiBpdCBoYXBwZW4gdG8gYmUgYSByZXRyYW5zbWl0IGl0 IHdpbGwgZ2V0IGEgbmV3IFRyYW5zYWN0aW9uIElELiAgVGhpcyBhcHByb2FjaCBtYWtlcyBpdCB0 cml2aWFsIHRvIG1lYXN1cmUgUlRULiANCg0KDQo+IFRoZSBiZXR0ZXIgc29sdXRpb24gbWF5IGJl IHRvIGNoZWNrIHRoZSBjb25uZWN0aXZpdHkgY29udGludW91c2x5LCBlc3BlY2lhbGx5IGZvciB0 aGUgbmV3bHkgdXAgaW50ZXJmYWNlLCBidXQgb25seSBsaW1pdGVkIHRvIHRoZSBjb25uZWN0aXZp dHkgY2hhcmFjdGVyaXN0aWMuIFRoZSBhcHBsaWNhdGlvbiBsYXllciBzaG91bGQgYmFsYW5jZSBh bW9uZyB0aGVzZSBhdmFpbGFibGUgaW50ZXJmYWNlcyB0aGF0IGdpdmVuIGJ5IElDRSwgdXNpbmcg dGhlaXIgb3duIFJUVCwgbG9zcyByYXRlIGRldGVjdGlvbiBhbmQgcGF0aC1tdHUgZmluZGluZyBz b2x1dGlvbi4gVGhpcyBjYW4gYWxzbyByZWR1Y2UgdGhlIGxhdGVuY3kgb2YgaW50ZXJmYWNlIHN3 aXRjaGluZyBvZiB0aGUgZW5kcG9pbnQuDQo+IA0KTXVjaCBvZiB0aGlzIGNhbiBiZSBkZWNpZGVk IGF0IHRoZSBhcHBsaWNhdGlvbiBsZXZlbCBpZiB3ZSBwcm92aWRlIHRoZSByaWdodCBidWlsZGlu ZyBibG9ja3Mgb24gdGhlIGxvd2VyIGxheWVycy4gSSBhZ3JlZSB0aGF0IG1ha2luZyBJQ0UgdG8g c21hcnQgd2l0aG91dCBsZXR0aW5nIHRoZSBhcHBsaWNhdGlvbiBkZWNpZGUgdml0YWwgcGFydHMg aXMgYSBzbGlwcGVyeSBzbG9wZS4gDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KPiBCZXN0IFJlZ2Fy ZHMuDQo+IEFpanVuIFdhbmcuDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IEJyYW5kb24gV2lsbGlhbXMgW21haWx0bzpib3dpbGxAYWthbWFpLmNvbV0NCj4+IFNl bnQ6IFR1ZXNkYXksIEphbnVhcnkgMDYsIDIwMTUgNzowOSBBTQ0KPj4gVG86IFBhbCBNYXJ0aW5z ZW4gKHBhbG1hcnRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPj4gQ2M6IEFpanVu IFdhbmc7IFZhcnVuIFNpbmdoOyBTaW1vbiBQZXJyZWF1bHQ7IHRyYW1AaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4gZHJhZnQt cmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCj4+IA0KPj4gSGkgUMOlbC1FcmlrLA0K Pj4gDQo+PiBZb3Ugd3JvdGU6IERvd24gcGxheSBJQ0UgdXNhZ2UuIEZvY3VzIG9uIHdoYXQgYSBU UkFNIGRyYWZ0cyBzaG91bGQgZm9jdXMgb24uDQo+PiAoSW4gdGhpcyBjYXNlIHByb3ZpZGUgUlRU IGFuZCBsb3NzIGluZm9ybWF0aW9uKQ0KPj4gDQo+PiBJJ20gbm90IGNlcnRhaW4gZXhhY3RseSB3 aGF0IHlvdSdyZSBsb29raW5nIGZvciBpbiB0aGUgdGV4dC4gSSBkb24ndCByZWFsbHkgc2VlIGEN Cj4+IG1lYW5pbmdmdWwgdXNlIGNhc2UgZm9yIHRoZSBSVFQgYW5kIGxvc3Mgc3RhdHMgb3V0c2lk ZSBvZiB0aGUgZW5kLXRvLWVuZA0KPj4gY29udGV4dCBvZiB0aGUgSUNFIHVzZSBjYXNlLCBzaW5j ZSB1c2luZyBwYXJ0aWFsIHBhdGggc3RhdHMgZm9yIGRlY2lzaW9uIG1ha2luZw0KPj4gd2lsbCBv ZnRlbiBnZW5lcmF0ZSBiYWQgcmVzdWx0cy4gRG8geW91IHNlZSBhIHVzZSBjYXNlIG90aGVyIHRo YW4gSUNFPyBPciBhcmUNCj4+IHlvdSBzaW1wbHkgc3VnZ2VzdGluZyB0aGF0IHRoZSBkcmFmdCBz aG91bGQgYXZvaWQgcmVmZXJlbmNpbmcgYSBzcGVjaWZpYyB1c2UNCj4+IGNhc2UgYWx0b2dldGhl cj8NCj4+IA0KPj4gVGhhbmtzLA0KPj4gLS1CcmFuZG9uDQo+PiANCj4+IA0KPj4gT24gMDEvMDUv MjAxNSAwNDowMSBBTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIHdyb3RlOg0KPj4+IA0KPj4+ PiBPbiAwNSBKYW4gMjAxNSwgYXQgMDg6MjcsIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkN Cj4+Pj4gPHRpcmVkZHlAY2lzY28uY29tIDxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90 ZToNCj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTog dHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFpanVuIFdh bmcNCj4+Pj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAwNCwgMjAxNSA2OjEyIEFNDQo+Pj4+PiBU bzogJ1ZhcnVuIFNpbmdoJzsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPj4+Pj4gQ2M6 ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz47 DQo+Pj4+PiAnQnJhbmRvbiBXaWxsaWFtcycNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+Pj4+IGRyYWZ0LXJlZGR5LXRyYW0tc3R1 bi0NCj4+Pj4+IHBhdGgtZGF0YS0wMC50eHQNCj4+Pj4+IA0KPj4+Pj4gSGksIFNpbmdoLCBSZWRk eSBhbmQgU2ltb246DQo+Pj4+PiANCj4+Pj4+IEkgYWRtaXR0ZWQgdGhhdCB0aGUgcGF0aCBjaGFy YWN0ZXJpc3RpYyBjYW4gYmUgb25lIGZhY3RvciB0byBiZQ0KPj4+Pj4gY29uc2lkZXJlZCBhbmQg Y2FuIGJlIHVzZWQgdG8gYXNzaXN0IHRoZSBlbmRwb2ludHMgdG8gc2VsZWN0IHRoZQ0KPj4+Pj4g YXBwcm9wcmlhdGUgcGF0aC4gVGhlIG1haW4gcG9pbnQgb2YgdGhpcyB2YWx1ZSB0aGF0IGRpZmZl cmVudCBmcm9tDQo+Pj4+PiBvdGhlciBjcml0ZXJpYSBkZWZpbmVkIGluIFJGQzUyNDUgaXMgdGhh dCB0aGlzIHZhbHVlIHdpbGwgYmUgY2hhbmdlZA0KPj4+Pj4gZHluYW1pY2FsbHkgYW5kIGlzIG5v dCBkZXRlcm1pbmVkLg0KPj4+Pj4gQ29uc2lkZXIgdGhlIElDRSBjb25uZWN0aXZpdHkgY2hlY2sg d2lsbCBiZSBvbmx5IGRvbmUgb25jZSBmb3Igb25lDQo+Pj4+PiBjb21tdW5pY2F0aW9uIHNlc3Np b24sIGlzIGl0IGFwcHJvcHJpYXRlIGZvciBpdCB0byByZWx5IG9uIG9uZQ0KPj4+Pj4gdW5yZWxp YWJsZSB2YWx1ZSB0byBtYWtlIHRoZSBkZWNpc2lvbj8NCj4+Pj4gDQo+Pj4+IE5vLCBjb25zZW50 IGZyZXNobmVzcyBhbmQgSUNFIGNvbnRpbnVvdXMgbm9taW5hdGlvbiBleHBsYWluIHRoYXQgSUNF DQo+Pj4+IGNvbm5lY3Rpdml0eSBjaGVja3MgaGFwcGVuIGV2ZW4gYWZ0ZXIgY2FuZGlkYXRlcyBh cmUgbm9taW5hdGVkIGZvcg0KPj4+PiB0aGUgbWVkaWEgc2Vzc2lvbi4gQW4gaW50ZXJmYWNlIGNh biBiZSBwaWNrZWQgYmFzZWQgb24gdGhlIGN1cnJlbnQNCj4+Pj4gcGF0aCBjaGFyYWN0ZXJpc3Rp Y3MsIGNvbnRpbnVlIHdpdGggSUNFIGNoZWNrcyBvbiBvdGhlciBpbnRlcmZhY2VzIG9yDQo+Pj4+ IG5ldyBpbnRlcmZhY2VzIGRpc2NvdmVyZWQgbGF0ZXIgYW5kIHN3aXRjaC1vdmVyIHdoZW4gYSBi ZXR0ZXINCj4+Pj4gY2FuZGlkYXRlIHBhaXIgaXMgYXZhaWxhYmxlLiAgRm9yIG1vcmUgaW5mb3Jt YXRpb24gcmVmZXIgdG8gdGhlDQo+Pj4+IGRpc2N1c3Npb24gaW4gbW11c2ljIFdHDQo+Pj4+ICho dHRwOi8vanViZXJ0aS5naXRodWIuaW8vZHJhdWdodHMvbm9tYmlzL2RyYWZ0LXViZXJ0aS1tbXVz aWMtbm9tYmlzLg0KPj4+PiBodG1sKQ0KPj4+IA0KPj4+IEkgZG8gYWdyZWUgd2l0aCBBaWp1bnMg cG9pbnQgdGhhdCBSRkM1MjQ1IGxpbWl0cyB0aGUgdXNhYmlsaXR5IG9mIHRoaXMNCj4+PiBkcmFm dC4gQnV0IGFzIHlvdSBwb2ludCBvdXQgdGhlcmUgaXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbnMgZ29p bmcgb24NCj4+PiByZWdhcmRpbmcgaG93IHdlIGNhbiBpbXByb3ZlIElDRSwgbm90IGFsbCBvZiB0 aG9zZSBkaXNjdXNzaW9ucyBhcmUNCj4+PiB3ZWxsIGtub3duLiBUbyBjYXRjaCB1cCwgcmVhZGlu ZyB0aGUgTU1VU0lDIG1haWxpbmctbGlzdCBpcyBwcm9iYWJseSBhIGdvb2QNCj4+IGlkZWEuDQo+ Pj4gDQo+Pj4gVG8gbWFrZSBpdCBlYXNpZXIgdG8gcmVhZCB0aGUgZHJhZnQgSSB3b3VsZCBwcm9w b3NlIHRvIGRvIHRoZQ0KPj4+IGZvbGxvd2luZyBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPj4+IA0K Pj4+IC0gUmVuYW1lIGRyYWZ0IHRvIOKAnFJUVCBhbmQgbG9zcyBtZWFzdXJlbWVudHMgb2YgU1RV TiBUcmFuc2FjdGlvbnPigJ0uDQo+Pj4gUGF0aCBjaGFyYWN0ZXJpc3RpY3Mgc2VlbXMgdG8gaGlu dCB0aGF0IG90aGVyIHRoaW5ncyBsaWtlIGJhbmR3aWR0aA0KPj4+IGFuZCBzbyBvbiBpcyBhbHNv IGluY2x1ZGVkLg0KPj4+IC0gRG93biBwbGF5IElDRSB1c2FnZS4gRm9jdXMgb24gd2hhdCBhIFRS QU0gZHJhZnRzIHNob3VsZCBmb2N1cyBvbi4NCj4+PiAoSW4gdGhpcyBjYXNlIHByb3ZpZGUgUlRU IGFuZCBsb3NzIGluZm9ybWF0aW9uKQ0KPj4+IA0KPj4+IA0KPj4+IFRoZSBESVNDVVNTIGRyYWZ0 DQo+Pj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1kaXNj dXNzLTAxLnR4dCkgYWxzbw0KPj4+IGhhdmUgdGhlIGFiaWxpdHkgdG8gcHJvdmlkZSB1c2VmdWwg aW5mb3JtYXRpb24sIGJ1dCBpdCByZXF1aXJlcw0KPj4+IHN1cHBvcnQgZnJvbSB0aGUgbmV0d29y ayB0byBhY2hpZXZlIHRoaXMuDQo+Pj4gDQo+Pj4gDQo+Pj4+IA0KPj4+Pj4gV2hhdCB3b3VsZCB5 b3UgZG8gaWYgaXQgc2VsZWN0IG9uZSBpZGxlIHBhaXIgYXQgZmlyc3QgYnV0IGl0IGJlY29tZQ0K Pj4+Pj4gY29uZ2VzdCBsYXRlcj8NCj4+Pj4+IA0KPj4+Pj4gSSB0aGluayB0aGUgZHluYW1pYyBw YXRoIHNlbGVjdGlvbiBzaG91bGQgYmUgbGVmdCB0byBhbmQgYmUNCj4+Pj4+IGNvbnNpZGVyZWQg YnkgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGl0c2VsZiwgc3VjaCBhcyBSVENQIHByb3RvY29sDQo+ Pj4+PiBldGMuDQo+Pj4+IA0KPj4+PiBJbiBjYXNlIG9mIE1QUlRQLCAgUGF0aCBjaGFyYWN0ZXJp c3RpY3MgZGlzY292ZXJlZCB1c2luZyBJQ0Ugd2lsbCBiZQ0KPj4+PiB1c2VkIGZvciBwaWNraW5n IHRoZSBpbnRlcmZhY2UgZm9yIHRoZSBwcmltYXJ5IHN1Yi1mbG93IGFuZA0KPj4+PiBpbnRlcmZh Y2VzIGZvciBzdWJzZXF1ZW50IHN1Yi1mbG93cyBhbmQgTVBSVFAgUlRDUCByZXBvcnQgY2FuIGJl IHVzZWQNCj4+Pj4gbGF0ZXIgZm9yIGxvYWQgYmFsYW5jaW5nLg0KPj4+PiANCj4+PiANCj4+PiBB IHNob3J0IHN1bW1hcnkgb2YgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgTU1VU0lDIElDRSBkaXNj dXNzaW9ucyBpczoNCj4+PiAtIFVzZSBJQ0UgdG8gYnVpbGQgYSB2YWxpZCBsaXN0DQo+Pj4gLSBS ZWRlZmluZWQgaG93IHdlIHVzZSB0aGF0IHZhbGlkIGxpc3QuIChLZWVwaW5nIHBhaXJzIHdhcm0g c28gd2UgY2FuDQo+Pj4gc3dpdGNoIHRvIHRoZW0gZmFzdCArKykNCj4+PiAtIFJlZGVmaW5lIHdo ZW4gYW5kIGhvdyB3ZSBjaG9zZSBhbiBhY3RpdmUgY2FuZGlkYXRlIHBhaXIgdG8gc2VuZCBtZWRp YQ0KPj4gb24uDQo+Pj4gDQo+Pj4gLi0uDQo+Pj4gUMOlbC1FcmlrDQo+Pj4gDQo+Pj4+IC1UaXJ1 DQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBCZXN0IFJlZ2FyZHMuDQo+Pj4+PiANCj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IFZhcnVuIFNpbmdoIFttYWlsdG86 dnNpbmdoLmlldGZAZ21haWwuY29tXQ0KPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIg MzEsIDIwMTQgNzo1MCBQTQ0KPj4+Pj4+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp DQo+Pj4+Pj4gQ2M6IFNpbW9uIFBlcnJlYXVsdDsgQnJhbmRvbiBXaWxsaWFtczsgdHJhbUBpZXRm Lm9yZw0KPj4+Pj4+IDxtYWlsdG86dHJhbUBpZXRmLm9yZz47IEFpanVuIFdhbmcNCj4+Pj4+PiBT dWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4+ Pj4gZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCj4+Pj4+PiANCj4+Pj4+ PiBPbiBXZWQsIERlYyAzMSwgMjAxNCBhdCA4OjE5IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpDQo+Pj4+Pj4gPHRpcmVkZHlAY2lzY28uY29tIDxtYWlsdG86dGlyZWRkeUBjaXNjby5j b20+PiB3cm90ZToNCj4+Pj4+Pj4gSW5saW5lIFtUUl0NCj4+Pj4+Pj4gT24gVHVlLCBEZWMgMzAs IDIwMTQgYXQgOTozMSBBTSwgQnJhbmRvbiBXaWxsaWFtcw0KPj4+Pj4+PiA8YnJhbmRvbi53aWxs aWFtc0Bha2FtYWkuY29tDQo+PiA8bWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbT4+ DQo+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+PiANCj4+Pj4+Pj4gWW91IGFyZSBjb3JyZWN0IHRoYXQg dGhlIGN1cnJlbnRseSBwdWJsaXNoZWQgUkZDIG1ha2VzIHRoZSBwYXRoDQo+Pj4+Pj4+IHF1YWxp dHkgaW5mb3JtYXRpb24gaGFyZGVyIHRvIHVzZSBpbiBhIG1lYW5pbmdmdWwgd2F5LiBIb3dldmVy LA0KPj4+Pj4+PiB0aGVyZSBpcyBvbmdvaW5nIHdvcmsgaW4gYm90aCB0cmFtIGFuZCBtbXVzaWMg Zm9jdXNlZCBvbiBhbGxvd2luZw0KPj4+Pj4+PiBtb3JlIGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24g dGhhdCBjYW4gdXNlIHBlcmZvcm1hbmNlIG1ldHJpY3MNCj4+Pj4+Pj4gcmF0aGVyIHRoYW4gdGhl IGN1cnJlbnRseSBkZWZpbmVkIHN0YXRpYyBwcmlvcml0aWVzLiBUaGlzIGRyYWZ0IGlzDQo+Pj4+ Pj4+IGp1c3Qgb25lIHBpZWNlIG9mIHRoYXQNCj4+Pj4+PiBiaWdnZXIgcGljdHVyZS4NCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBZb3UncmUgcmlnaHQsIG9mIGNvdXJzZSwgYnV0IGlmIHRo ZXJlJ3Mgbm8gd2F5IHRvIG1ha2UgcHJhY3RpY2FsDQo+Pj4+Pj4+IHVzZSBvZiB0aGlzIGRyYWZ0 IHdpdGggcmVndWxhciBJQ0UsIHRoZW4gdGhhdCdzIHVzZWZ1bCBpbmZvcm1hdGlvbg0KPj4+Pj4+ PiB0aGF0IG5lZWRzIHRvIGdvIGludG8gdGhlIGRyYWZ0LiBJZGVhbGx5IHdpdGggcG9pbnRlcnMg dG8gdGhlDQo+Pj4+Pj4+IGJpZ2dlciBwaWN0dXJlIHlvdQ0KPj4+Pj4+IG1lbnRpb25lZC4NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gW1RSXSB3ZSB3aWxsIHVwZGF0ZSB0 aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gdG8gbWFrZSBpdCBjbGVhci4NCj4+Pj4+Pj4gVGhpcyBk cmFmdCBjYW4gYmUgdXNlZCB3aXRoIHJlZ3VsYXIgSUNFIHdoZW4gdGhlcmUgaXMgbm8NCj4+Pj4+ Pj4gbm90aWNlYWJsZSBpbXBhY3QgaW4gc2V0dGluZyB1cCB0aGUgbWVkaWEgc2Vzc2lvbi4gSXQg ZGVwZW5kcyBvbg0KPj4+Pj4+PiB0aGUgbnVtYmVyIG9mIGNhbmRpZGF0ZSBwYWlycywgdGltZSBp bnRlcnZhbCAoVGEpIGZvciBwYWNpbmcgSUNFDQo+Pj4+Pj4+IGNvbm5lY3Rpdml0eSBjaGVja3Mg YW5kDQo+Pj4+PiBSVE8gdmFsdWVzLg0KPj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBUcnVlLiBQ YXRoIGNoYXJhY3RlcmlzdGljcyBjYW4gYmUgdXNlZCBpbiBhZGRpdGlvbiB0byB0aGUNCj4+Pj4+ PiBwcm9wcmlldGFyeSBjcml0ZXJpYSB0aGUgZW5kcG9pbnQgY3VycmVudGx5IGltcGxlbWVudHMu IGkuZS4sIGlmDQo+Pj4+Pj4gdGhlIGVuZHBvaW50cyB3YW50cyB0byBzdG9wIGNoZWNraW5nIGJl Y2F1c2UgaXQgbWV0IGl0cyBkZWZpbmVkDQo+Pj4+Pj4gY3JpdGVyaWEgYW5kIHdhcyB1c2luZyB0 aGUgcGF0aCBjaGFyYWN0ZXJpc3RpY3MgYXMgcGFydCBvZiB0aGUgU1RVTg0KPj4+Pj4+IG1lc3Nh Z2VzLCBpdCBjb3VsZCBzdGlsbCB1c2UgdGhlIHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aG9z ZQ0KPj4+Pj4+IGNhbmRpZGF0ZXMgdG8gbWFrZSBmdXJ0aGVyDQo+Pj4+PiBkZWNpc2lvbnMuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0NCj4+Pj4+PiBodHRwOi8vd3d3Lm5l dGxhYi50a2suZmkvfnZhcnVuLw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHRyYW0gbWFp bGluZyBsaXN0DQo+Pj4+PiB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4+PiANCj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4g dHJhbSBtYWlsaW5nIGxpc3QNCj4+Pj4gdHJhbUBpZXRmLm9yZyA8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4+ IA0KPj4gDQo+PiAtLQ0KPj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0 d2FyZSBFbmdpbmVlciBFbWVyZ2luZyBQcm9kdWN0cw0KPj4gRW5naW5lZXJpbmc7IEFrYW1haSBU ZWNobm9sb2dpZXMgSW5jLg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= From nobody Tue Jan 6 04:19:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA381AC42B for ; Tue, 6 Jan 2015 04:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ezHtEFtZ3Zph for ; Tue, 6 Jan 2015 04:19:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1EF1ACC82 for ; Tue, 6 Jan 2015 04:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13728; q=dns/txt; s=iport; t=1420546784; x=1421756384; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=Z9Ief7/IPfZ/aOIzxrGd1blXHmbpcMQUdDbXXdZGNi0=; b=ga78YUo6zjX8MzVHdSV1963tqIsqGcu6MA3jyfFGHWMS+jfVdZ7/B5Qb UmInQilwKferVc2aNDkj/FoPBR1lbkQMVOj9wZkLHg4id5ZBvLtpZh5sg O/KAHQ4/pbHvPZi+NamgBNJIeEMjYAN3LU3IgiQ+IBLLHtm7HhStIvzyX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAEXSq1StJV2b/2dsb2JhbABcFoJwUlgEgwHBGoIbDIVxAhxzFgEBAQEBfYQMAQEBAwEBAQELFRExCQkCBQcGAQgRBAEBAQICBh0DAgQfBgsUAQgJAQQBDQUIE4d9AwkIDa0hkBwNg24BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGIbYNAgUcLJxYbDYJiLoETBY4gg0CDcYJRMIRshRw6A4VXIoNubwEBgQFCfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,707,1413244800"; d="scan'208";a="110690078" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 06 Jan 2015 12:19:43 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t06CJhVU008366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 12:19:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 06:19:43 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Aijun Wang , "'Brandon Williams'" , "Pal Martinsen (palmarti)" Thread-Topic: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdApqwiDucdBfXFpQw+g1WxST3B2JQ== Date: Tue, 6 Jan 2015 12:19:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552705C@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.12.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3Ly204W0Pvqt9pgfMOU6ccsn_tA Cc: 'Simon Perreault' , "tram@ietf.org" , 'Varun Singh' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 12:19:49 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiBTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDA2LCAyMDE1IDk6MTMgQU0NCj4gVG86ICdCcmFuZG9uIFdpbGxpYW1zJzsgUGFs IE1hcnRpbnNlbiAocGFsbWFydGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gKHRpcmVkZHkpDQo+ IENjOiAnU2ltb24gUGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgJ1ZhcnVuIFNpbmdoJw0KPiBT dWJqZWN0OiBSZTogW3RyYW1dIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVk ZHktdHJhbS1zdHVuLXBhdGgtDQo+IGRhdGEtMDAudHh0DQo+IA0KPiBIaSwgQWxsOg0KPiANCj4g VGhlIGRyYWZ0IHRoYXQgZ2l2ZW4gYnkgUmVkZHkgaWxsdXN0cmF0aW5nIHNvbWUgZHJhd2JhY2sg b2YgdGhlIGN1cnJlbnQgSUNFDQo+IHNvbHV0aW9uKFJGQzUyNDUpLCBhbmQgYWN0dWFsbHkgcHJv dmlkZWQgYW5vdGhlciBwb3NzaWJsZSBzb2x1dGlvbiB0bw0KPiBpbXByb3ZlIGl0LiAgDQoNCklD RSByZWd1bGFyIGFuZCBhZ2dyZXNzaXZlIG5vbWluYXRpb24gaGF2ZSBjZXJ0YWluIGRyYXdiYWNr cyB3aGljaCB3aWxsIGJlIGRlYWx0IGFzIHBhcnQgb2YgSUNFIGNvbnRpbnVvdXMgbm9taW5hdGlv biB3b3JrIGluIG1tdXNpYyBXRywgSUNFIGFsZ29yaXRobSBjaGFuZ2VzIHdpbGwgbm90IGJlIGNv dmVyZWQgaW4gdGhpcyBkcmFmdC4gTm90ZSB0aGF0IHRoaXMgZHJhZnQgY2FuIGFsc28gYmUgdXNl ZCB3aXRoIHJlZ3VsYXIgSUNFIHdoZW4gdGhlcmUgaXMgbm8gbm90aWNlYWJsZSBpbXBhY3QgaW4g c2V0dGluZyB1cCB0aGUgbWVkaWEgc2Vzc2lvbiwgIEl0IGRlcGVuZHMgb24gdGhlIG51bWJlciBv ZiBjYW5kaWRhdGUgcGFpcnMsIHRpbWUgaW50ZXJ2YWwgZm9yIHBhY2luZyBJQ0UgY29ubmVjdGl2 aXR5IGNoZWNrcyBhbmQgUlRPIHZhbHVlcy4NCg0KPiBJIGFncmVlIGFsc28gdGhhdCBpdCBpcyBu ZWNlc3NhcnkgZm9yIElDRSB0byBjaGVjayBjb25uZWN0aXZpdHkNCj4gY29udGludW91c2x5LCBi dXQgc3RpbGwgaGVzaXRhdGUgdG8gYWdyZWUgYWRkIG1vcmUgYWRkaXRpb25hbCBmdW5jdGlvbiB0 byBpdHMNCj4gcm9sZShzdWNoIGFzIFJUVCwgbG9zcyByYXRlLCBwYXRobXR1IGV0Yy4pLg0KDQpX aHkgPw0KUGVyaW9kaWMgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgZm9yIG1lZGlhIHN0cmVhbXMg Zm9yIGNvbnNlbnQgZnJlc2huZXNzIGlzIGFscmVhZHkgY292ZXJlZCBpbiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEx IA0KDQo+IA0KPiBUaGUgYmV0dGVyIHNvbHV0aW9uIG1heSBiZSB0byBjaGVjayB0aGUgY29ubmVj dGl2aXR5IGNvbnRpbnVvdXNseSwgZXNwZWNpYWxseQ0KPiBmb3IgdGhlIG5ld2x5IHVwIGludGVy ZmFjZSwgYnV0IG9ubHkgbGltaXRlZCB0byB0aGUgY29ubmVjdGl2aXR5IGNoYXJhY3RlcmlzdGlj Lg0KPiBUaGUgYXBwbGljYXRpb24gbGF5ZXIgc2hvdWxkIGJhbGFuY2UgYW1vbmcgdGhlc2UgYXZh aWxhYmxlIGludGVyZmFjZXMgdGhhdA0KPiBnaXZlbiBieSBJQ0UsIHVzaW5nIHRoZWlyIG93biBS VFQsIGxvc3MgcmF0ZSBkZXRlY3Rpb24gYW5kIHBhdGgtbXR1IGZpbmRpbmcNCj4gc29sdXRpb24u IFRoaXMgY2FuIGFsc28gcmVkdWNlIHRoZSBsYXRlbmN5IG9mIGludGVyZmFjZSBzd2l0Y2hpbmcg b2YgdGhlDQo+IGVuZHBvaW50Lg0KDQpJQ0UgY29udGludW91cyBub21pbmF0aW9uIGFsbG93cyBj aGVja3Mgb24gbmV3IGludGVyZmFjZXMgYW5kIHRoZSBwYXRoIGNoYXJhY3RlcmlzdGljcyBkaXNj b3ZlcmVkIHVzaW5nIElDRSBjYW4gYmUgdXNlZCB0byBzd2l0Y2gtb3ZlciB0aGUgbWVkaWEgc3Ry ZWFtIHRvIGEgbmV3IGludGVyZmFjZS4gSXQgaXMgZGlzY3Vzc2VkIGluIGh0dHA6Ly9qdWJlcnRp LmdpdGh1Yi5pby9kcmF1Z2h0cy9ub21iaXMvZHJhZnQtdWJlcnRpLW1tdXNpYy1ub21iaXMuaHRt bCNzZWN0aW9uLTMuMSANCg0KLVRpcnUNCg0KPiANCj4gQmVzdCBSZWdhcmRzLg0KPiBBaWp1biBX YW5nLg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJyYW5k b24gV2lsbGlhbXMgW21haWx0bzpib3dpbGxAYWthbWFpLmNvbV0NCj4gPiBTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDA2LCAyMDE1IDc6MDkgQU0NCj4gPiBUbzogUGFsIE1hcnRpbnNlbiAocGFsbWFy dGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gQ2M6IEFpanVuIFdhbmc7IFZh cnVuIFNpbmdoOyBTaW1vbiBQZXJyZWF1bHQ7IHRyYW1AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW3RyYW1dIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1yZWRkeS10 cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KPiA+DQo+ID4gSGkgUMOlbC1FcmlrLA0KPiA+DQo+ ID4gWW91IHdyb3RlOiBEb3duIHBsYXkgSUNFIHVzYWdlLiBGb2N1cyBvbiB3aGF0IGEgVFJBTSBk cmFmdHMgc2hvdWxkDQo+IGZvY3VzIG9uLg0KPiA+IChJbiB0aGlzIGNhc2UgcHJvdmlkZSBSVFQg YW5kIGxvc3MgaW5mb3JtYXRpb24pDQo+ID4NCj4gPiBJJ20gbm90IGNlcnRhaW4gZXhhY3RseSB3 aGF0IHlvdSdyZSBsb29raW5nIGZvciBpbiB0aGUgdGV4dC4gSSBkb24ndA0KPiA+IHJlYWxseSBz ZWUgYSBtZWFuaW5nZnVsIHVzZSBjYXNlIGZvciB0aGUgUlRUIGFuZCBsb3NzIHN0YXRzIG91dHNp ZGUgb2YNCj4gPiB0aGUgZW5kLXRvLWVuZCBjb250ZXh0IG9mIHRoZSBJQ0UgdXNlIGNhc2UsIHNp bmNlIHVzaW5nIHBhcnRpYWwgcGF0aA0KPiA+IHN0YXRzIGZvciBkZWNpc2lvbiBtYWtpbmcgd2ls bCBvZnRlbiBnZW5lcmF0ZSBiYWQgcmVzdWx0cy4gRG8geW91IHNlZQ0KPiA+IGEgdXNlIGNhc2Ug b3RoZXIgdGhhbiBJQ0U/IE9yIGFyZSB5b3Ugc2ltcGx5IHN1Z2dlc3RpbmcgdGhhdCB0aGUgZHJh ZnQNCj4gPiBzaG91bGQgYXZvaWQgcmVmZXJlbmNpbmcgYSBzcGVjaWZpYyB1c2UgY2FzZSBhbHRv Z2V0aGVyPw0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IC0tQnJhbmRvbg0KPiA+DQo+ID4NCj4gPiBP biAwMS8wNS8yMDE1IDA0OjAxIEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgd3JvdGU6DQo+ ID4gPg0KPiA+ID4+IE9uIDA1IEphbiAyMDE1LCBhdCAwODoyNywgVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KQ0KPiA+ID4+IDx0aXJlZGR5QGNpc2NvLmNvbSA8bWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tPj4gd3JvdGU6DQo+ID4gPj4NCj4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+Pj4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFpanVuIFdhbmcNCj4gPiA+Pj4gU2VudDogU3VuZGF5LCBKYW51YXJ5IDA0LCAy MDE1IDY6MTIgQU0NCj4gPiA+Pj4gVG86ICdWYXJ1biBTaW5naCc7IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCj4gPiA+Pj4gQ2M6ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3Jn IDxtYWlsdG86dHJhbUBpZXRmLm9yZz47DQo+ID4gPj4+ICdCcmFuZG9uIFdpbGxpYW1zJw0KPiA+ ID4+PiBTdWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y DQo+ID4gPj4+IGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi0NCj4gPiA+Pj4gcGF0aC1kYXRhLTAwLnR4 dA0KPiA+ID4+Pg0KPiA+ID4+PiBIaSwgU2luZ2gsIFJlZGR5IGFuZCBTaW1vbjoNCj4gPiA+Pj4N Cj4gPiA+Pj4gSSBhZG1pdHRlZCB0aGF0IHRoZSBwYXRoIGNoYXJhY3RlcmlzdGljIGNhbiBiZSBv bmUgZmFjdG9yIHRvIGJlDQo+ID4gPj4+IGNvbnNpZGVyZWQgYW5kIGNhbiBiZSB1c2VkIHRvIGFz c2lzdCB0aGUgZW5kcG9pbnRzIHRvIHNlbGVjdCB0aGUNCj4gPiA+Pj4gYXBwcm9wcmlhdGUgcGF0 aC4gVGhlIG1haW4gcG9pbnQgb2YgdGhpcyB2YWx1ZSB0aGF0IGRpZmZlcmVudCBmcm9tDQo+ID4g Pj4+IG90aGVyIGNyaXRlcmlhIGRlZmluZWQgaW4gUkZDNTI0NSBpcyB0aGF0IHRoaXMgdmFsdWUg d2lsbCBiZQ0KPiA+ID4+PiBjaGFuZ2VkIGR5bmFtaWNhbGx5IGFuZCBpcyBub3QgZGV0ZXJtaW5l ZC4NCj4gPiA+Pj4gQ29uc2lkZXIgdGhlIElDRSBjb25uZWN0aXZpdHkgY2hlY2sgd2lsbCBiZSBv bmx5IGRvbmUgb25jZSBmb3Igb25lDQo+ID4gPj4+IGNvbW11bmljYXRpb24gc2Vzc2lvbiwgaXMg aXQgYXBwcm9wcmlhdGUgZm9yIGl0IHRvIHJlbHkgb24gb25lDQo+ID4gPj4+IHVucmVsaWFibGUg dmFsdWUgdG8gbWFrZSB0aGUgZGVjaXNpb24/DQo+ID4gPj4NCj4gPiA+PiBObywgY29uc2VudCBm cmVzaG5lc3MgYW5kIElDRSBjb250aW51b3VzIG5vbWluYXRpb24gZXhwbGFpbiB0aGF0DQo+ID4g Pj4gSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgaGFwcGVuIGV2ZW4gYWZ0ZXIgY2FuZGlkYXRlcyBh cmUgbm9taW5hdGVkDQo+ID4gPj4gZm9yIHRoZSBtZWRpYSBzZXNzaW9uLiBBbiBpbnRlcmZhY2Ug Y2FuIGJlIHBpY2tlZCBiYXNlZCBvbiB0aGUNCj4gPiA+PiBjdXJyZW50IHBhdGggY2hhcmFjdGVy aXN0aWNzLCBjb250aW51ZSB3aXRoIElDRSBjaGVja3Mgb24gb3RoZXINCj4gPiA+PiBpbnRlcmZh Y2VzIG9yIG5ldyBpbnRlcmZhY2VzIGRpc2NvdmVyZWQgbGF0ZXIgYW5kIHN3aXRjaC1vdmVyIHdo ZW4NCj4gPiA+PiBhIGJldHRlciBjYW5kaWRhdGUgcGFpciBpcyBhdmFpbGFibGUuICBGb3IgbW9y ZSBpbmZvcm1hdGlvbiByZWZlcg0KPiA+ID4+IHRvIHRoZSBkaXNjdXNzaW9uIGluIG1tdXNpYyBX Rw0KPiA+ID4+IChodHRwOi8vanViZXJ0aS5naXRodWIuaW8vZHJhdWdodHMvbm9tYmlzL2RyYWZ0 LXViZXJ0aS1tbXVzaWMtbm9tYmlzLg0KPiA+ID4+IGh0bWwpDQo+ID4gPg0KPiA+ID4gSSBkbyBh Z3JlZSB3aXRoIEFpanVucyBwb2ludCB0aGF0IFJGQzUyNDUgbGltaXRzIHRoZSB1c2FiaWxpdHkg b2YNCj4gPiA+IHRoaXMgZHJhZnQuIEJ1dCBhcyB5b3UgcG9pbnQgb3V0IHRoZXJlIGlzIGEgbG90 IG9mIGRpc2N1c3Npb25zIGdvaW5nDQo+ID4gPiBvbiByZWdhcmRpbmcgaG93IHdlIGNhbiBpbXBy b3ZlIElDRSwgbm90IGFsbCBvZiB0aG9zZSBkaXNjdXNzaW9ucw0KPiA+ID4gYXJlIHdlbGwga25v d24uIFRvIGNhdGNoIHVwLCByZWFkaW5nIHRoZSBNTVVTSUMgbWFpbGluZy1saXN0IGlzDQo+ID4g PiBwcm9iYWJseSBhIGdvb2QNCj4gPiBpZGVhLg0KPiA+ID4NCj4gPiA+IFRvIG1ha2UgaXQgZWFz aWVyIHRvIHJlYWQgdGhlIGRyYWZ0IEkgd291bGQgcHJvcG9zZSB0byBkbyB0aGUNCj4gPiA+IGZv bGxvd2luZyBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPiA+ID4NCj4gPiA+IC0gUmVuYW1lIGRyYWZ0 IHRvIOKAnFJUVCBhbmQgbG9zcyBtZWFzdXJlbWVudHMgb2YgU1RVTiBUcmFuc2FjdGlvbnPigJ0u DQo+ID4gPiBQYXRoIGNoYXJhY3RlcmlzdGljcyBzZWVtcyB0byBoaW50IHRoYXQgb3RoZXIgdGhp bmdzIGxpa2UgYmFuZHdpZHRoDQo+ID4gPiBhbmQgc28gb24gaXMgYWxzbyBpbmNsdWRlZC4NCj4g PiA+IC0gRG93biBwbGF5IElDRSB1c2FnZS4gRm9jdXMgb24gd2hhdCBhIFRSQU0gZHJhZnRzIHNo b3VsZCBmb2N1cyBvbi4NCj4gPiA+IChJbiB0aGlzIGNhc2UgcHJvdmlkZSBSVFQgYW5kIGxvc3Mg aW5mb3JtYXRpb24pDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBESVNDVVNTIGRyYWZ0DQo+ID4g PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3Mt MDEudHh0KSBhbHNvDQo+ID4gPiBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb3ZpZGUgdXNlZnVsIGlu Zm9ybWF0aW9uLCBidXQgaXQgcmVxdWlyZXMNCj4gPiA+IHN1cHBvcnQgZnJvbSB0aGUgbmV0d29y ayB0byBhY2hpZXZlIHRoaXMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+Pg0KPiA+ID4+PiBXaGF0IHdv dWxkIHlvdSBkbyBpZiBpdCBzZWxlY3Qgb25lIGlkbGUgcGFpciBhdCBmaXJzdCBidXQgaXQNCj4g PiA+Pj4gYmVjb21lIGNvbmdlc3QgbGF0ZXI/DQo+ID4gPj4+DQo+ID4gPj4+IEkgdGhpbmsgdGhl IGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24gc2hvdWxkIGJlIGxlZnQgdG8gYW5kIGJlDQo+ID4gPj4+ IGNvbnNpZGVyZWQgYnkgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGl0c2VsZiwgc3VjaCBhcyBSVENQ IHByb3RvY29sDQo+ID4gPj4+IGV0Yy4NCj4gPiA+Pg0KPiA+ID4+IEluIGNhc2Ugb2YgTVBSVFAs ICBQYXRoIGNoYXJhY3RlcmlzdGljcyBkaXNjb3ZlcmVkIHVzaW5nIElDRSB3aWxsDQo+ID4gPj4g YmUgdXNlZCBmb3IgcGlja2luZyB0aGUgaW50ZXJmYWNlIGZvciB0aGUgcHJpbWFyeSBzdWItZmxv dyBhbmQNCj4gPiA+PiBpbnRlcmZhY2VzIGZvciBzdWJzZXF1ZW50IHN1Yi1mbG93cyBhbmQgTVBS VFAgUlRDUCByZXBvcnQgY2FuIGJlDQo+ID4gPj4gdXNlZCBsYXRlciBmb3IgbG9hZCBiYWxhbmNp bmcuDQo+ID4gPj4NCj4gPiA+DQo+ID4gPiBBIHNob3J0IHN1bW1hcnkgb2YgbXkgdW5kZXJzdGFu ZGluZyBvZiB0aGUgTU1VU0lDIElDRSBkaXNjdXNzaW9ucyBpczoNCj4gPiA+IC0gVXNlIElDRSB0 byBidWlsZCBhIHZhbGlkIGxpc3QNCj4gPiA+IC0gUmVkZWZpbmVkIGhvdyB3ZSB1c2UgdGhhdCB2 YWxpZCBsaXN0LiAoS2VlcGluZyBwYWlycyB3YXJtIHNvIHdlDQo+ID4gPiBjYW4gc3dpdGNoIHRv IHRoZW0gZmFzdCArKykNCj4gPiA+IC0gUmVkZWZpbmUgd2hlbiBhbmQgaG93IHdlIGNob3NlIGFu IGFjdGl2ZSBjYW5kaWRhdGUgcGFpciB0byBzZW5kDQo+ID4gPiBtZWRpYQ0KPiA+IG9uLg0KPiA+ ID4NCj4gPiA+IC4tLg0KPiA+ID4gUMOlbC1FcmlrDQo+ID4gPg0KPiA+ID4+IC1UaXJ1DQo+ID4g Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gQmVzdCBSZWdhcmRzLg0KPiA+ID4+Pg0KPiA+ID4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4+IEZyb206IFZhcnVuIFNpbmdoIFttYWls dG86dnNpbmdoLmlldGZAZ21haWwuY29tXQ0KPiA+ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNl bWJlciAzMSwgMjAxNCA3OjUwIFBNDQo+ID4gPj4+PiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KQ0KPiA+ID4+Pj4gQ2M6IFNpbW9uIFBlcnJlYXVsdDsgQnJhbmRvbiBXaWxsaWFtczsg dHJhbUBpZXRmLm9yZw0KPiA+ID4+Pj4gPG1haWx0bzp0cmFtQGlldGYub3JnPjsgQWlqdW4gV2Fu Zw0KPiA+ID4+Pj4gU3ViamVjdDogUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiA+ID4+Pj4gZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQN Cj4gPiA+Pj4+DQo+ID4gPj4+PiBPbiBXZWQsIERlYyAzMSwgMjAxNCBhdCA4OjE5IEFNLCBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gPj4+PiA8dGlyZWRkeUBjaXNjby5jb20gPG1h aWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+ID4+Pj4+IElubGluZSBbVFJdDQo+ ID4gPj4+Pj4gT24gVHVlLCBEZWMgMzAsIDIwMTQgYXQgOTozMSBBTSwgQnJhbmRvbiBXaWxsaWFt cw0KPiA+ID4+Pj4+IDxicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4gPiA8bWFpbHRvOmJy YW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbT4+DQo+ID4gPj4+Pj4gd3JvdGU6DQo+ID4gPj4+Pj4N Cj4gPiA+Pj4+PiBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudGx5IHB1Ymxpc2hlZCBS RkMgbWFrZXMgdGhlIHBhdGgNCj4gPiA+Pj4+PiBxdWFsaXR5IGluZm9ybWF0aW9uIGhhcmRlciB0 byB1c2UgaW4gYSBtZWFuaW5nZnVsIHdheS4gSG93ZXZlciwNCj4gPiA+Pj4+PiB0aGVyZSBpcyBv bmdvaW5nIHdvcmsgaW4gYm90aCB0cmFtIGFuZCBtbXVzaWMgZm9jdXNlZCBvbg0KPiA+ID4+Pj4+ IGFsbG93aW5nIG1vcmUgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiB0aGF0IGNhbiB1c2UgcGVyZm9y bWFuY2UNCj4gPiA+Pj4+PiBtZXRyaWNzIHJhdGhlciB0aGFuIHRoZSBjdXJyZW50bHkgZGVmaW5l ZCBzdGF0aWMgcHJpb3JpdGllcy4NCj4gPiA+Pj4+PiBUaGlzIGRyYWZ0IGlzIGp1c3Qgb25lIHBp ZWNlIG9mIHRoYXQNCj4gPiA+Pj4+IGJpZ2dlciBwaWN0dXJlLg0KPiA+ID4+Pj4+DQo+ID4gPj4+ Pj4NCj4gPiA+Pj4+PiBZb3UncmUgcmlnaHQsIG9mIGNvdXJzZSwgYnV0IGlmIHRoZXJlJ3Mgbm8g d2F5IHRvIG1ha2UgcHJhY3RpY2FsDQo+ID4gPj4+Pj4gdXNlIG9mIHRoaXMgZHJhZnQgd2l0aCBy ZWd1bGFyIElDRSwgdGhlbiB0aGF0J3MgdXNlZnVsDQo+ID4gPj4+Pj4gaW5mb3JtYXRpb24gdGhh dCBuZWVkcyB0byBnbyBpbnRvIHRoZSBkcmFmdC4gSWRlYWxseSB3aXRoDQo+ID4gPj4+Pj4gcG9p bnRlcnMgdG8gdGhlIGJpZ2dlciBwaWN0dXJlIHlvdQ0KPiA+ID4+Pj4gbWVudGlvbmVkLg0KPiA+ ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IFtUUl0gd2Ugd2lsbCB1cGRh dGUgdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uIHRvIG1ha2UgaXQgY2xlYXIuDQo+ID4gPj4+Pj4g VGhpcyBkcmFmdCBjYW4gYmUgdXNlZCB3aXRoIHJlZ3VsYXIgSUNFIHdoZW4gdGhlcmUgaXMgbm8N Cj4gPiA+Pj4+PiBub3RpY2VhYmxlIGltcGFjdCBpbiBzZXR0aW5nIHVwIHRoZSBtZWRpYSBzZXNz aW9uLiBJdCBkZXBlbmRzIG9uDQo+ID4gPj4+Pj4gdGhlIG51bWJlciBvZiBjYW5kaWRhdGUgcGFp cnMsIHRpbWUgaW50ZXJ2YWwgKFRhKSBmb3IgcGFjaW5nIElDRQ0KPiA+ID4+Pj4+IGNvbm5lY3Rp dml0eSBjaGVja3MgYW5kDQo+ID4gPj4+IFJUTyB2YWx1ZXMuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+ DQo+ID4gPj4+PiBUcnVlLiBQYXRoIGNoYXJhY3RlcmlzdGljcyBjYW4gYmUgdXNlZCBpbiBhZGRp dGlvbiB0byB0aGUNCj4gPiA+Pj4+IHByb3ByaWV0YXJ5IGNyaXRlcmlhIHRoZSBlbmRwb2ludCBj dXJyZW50bHkgaW1wbGVtZW50cy4gaS5lLiwgaWYNCj4gPiA+Pj4+IHRoZSBlbmRwb2ludHMgd2Fu dHMgdG8gc3RvcCBjaGVja2luZyBiZWNhdXNlIGl0IG1ldCBpdHMgZGVmaW5lZA0KPiA+ID4+Pj4g Y3JpdGVyaWEgYW5kIHdhcyB1c2luZyB0aGUgcGF0aCBjaGFyYWN0ZXJpc3RpY3MgYXMgcGFydCBv ZiB0aGUNCj4gPiA+Pj4+IFNUVU4gbWVzc2FnZXMsIGl0IGNvdWxkIHN0aWxsIHVzZSB0aGUgcGF0 aCBjaGFyYWN0ZXJpc3RpY3MgZm9yDQo+ID4gPj4+PiB0aG9zZSBjYW5kaWRhdGVzIHRvIG1ha2Ug ZnVydGhlcg0KPiA+ID4+PiBkZWNpc2lvbnMuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ DQo+ID4gPj4+PiAtLQ0KPiA+ID4+Pj4gaHR0cDovL3d3dy5uZXRsYWIudGtrLmZpL352YXJ1bi8N Cj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4g PiA+Pj4gdHJhbUBpZXRmLm9yZyA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQo+ID4gPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+ID4+DQo+ID4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiB0cmFt IG1haWxpbmcgbGlzdA0KPiA+ID4+IHRyYW1AaWV0Zi5vcmcgPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+ ID4NCj4gPg0KPiA+IC0tDQo+ID4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBT b2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZyBQcm9kdWN0cw0KPiA+IEVuZ2luZWVyaW5nOyBBa2Ft YWkgVGVjaG5vbG9naWVzIEluYy4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Tue Jan 6 07:36:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E731A6F3A for ; Tue, 6 Jan 2015 07:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Nd6cyu5wpv-J for ; Tue, 6 Jan 2015 07:36:29 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB861A6F32 for ; Tue, 6 Jan 2015 07:36:29 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so11738816lbi.31 for ; Tue, 06 Jan 2015 07:36:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ci9GhFEYyy8IcqOfrplGaAtE4/ebspbSWVvzKWS7c1Y=; b=OV/SsevtKSL90vdL+d2GIR5bzW1ZeIhzcYIcWz78Tkrzxfohwy5LcSg2LnXuv+fiRc fhX61s3PbXONDRwYkpNXQgvEcdxO3LmYXcEIM7T6ihmhzXFRSLB/WB0ijRhDkvjROw3y xWeF+dtZq5iaIiELLgXI6g+p2TAf5r4h6zKelq5Em/5YcdSB3HyQ6jSIwvkNd3NvfsuD /VrmnAGEkFC/+i/19Nb2k5AP2q4H99ld31b4it9W3vHkqZMKnbaQh/CLwk7PmMmUrEID G/Ckd6+5EfB7k3UpgXSq7MJVFp42RN4Yb2A/KZbNbSejLVqQingMI6vJBQGsYSwnBaSa esrw== X-Gm-Message-State: ALoCoQnz/18cxjNOgRBe3GYQQ72IfJgVY7FdJdOEy0yLEHK1zp84CuWkDwj3feB6xKym+2YVHXWT MIME-Version: 1.0 X-Received: by 10.112.91.43 with SMTP id cb11mr99910928lbb.63.1420558587771; Tue, 06 Jan 2015 07:36:27 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 6 Jan 2015 07:36:27 -0800 (PST) In-Reply-To: <003401d02978$21689220$6439b660$@org.cn> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> Date: Tue, 6 Jan 2015 10:36:27 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=001a11348fd601d5e3050bfd922b Archived-At: http://mailarchive.ietf.org/arch/msg/tram/MzWwxYjcv_F4ZcVL_vDIpVtKC_0 Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:36:32 -0000 --001a11348fd601d5e3050bfd922b Content-Type: text/plain; charset=UTF-8 On Tue, Jan 6, 2015 at 1:14 AM, Aijun Wang wrote: > 1. Is it possible for two peers to select different Relay Server to > communicate? > It's already possible with today's ICE, without this draft. Or do you mean something else? > If so, will the communication channel between the Relay Server > will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure two > peers select the same Relay Server? > Why would it be necessary that the two peers select the same server? Simon --001a11348fd601d5e3050bfd922b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jan 6, 2015 at 1:14 AM, Aijun Wang <wangaijun@tsinghua.org= .cn> wrote:
1. Is it possible for two peers t= o select different Relay Server to
communicate?

It's already possibl= e with today's ICE, without this draft. Or do you mean something else?<= /div>
=C2=A0
If so, will the communication channel b= etween the Relay Server
will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure two=
peers select the same Relay Server?

Why would it be necessary that the two peers select the same server?

Simon
--001a11348fd601d5e3050bfd922b-- From nobody Tue Jan 6 21:39:46 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8B1A1A33 for ; Tue, 6 Jan 2015 21:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 gW0JmV5sbbfx for ; Tue, 6 Jan 2015 21:39:40 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id C197D1A1A27 for ; Tue, 6 Jan 2015 21:39:37 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CrowNqsaxUVvGiAA==.7218S4; Wed, 07 Jan 2015 12:09:32 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Brandon Williams'" , "'Pal Martinsen \(palmarti\)'" References: <913383AAA69FF945B8F946018B75898A3552705C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552705C@xmb-rcd-x10.cisco.com> Date: Wed, 7 Jan 2015 13:38:55 +0800 Message-ID: <00a401d02a3c$44661710$cd324530$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdApqwiDucdBfXFpQw+g1WxST3B2JQAjrEQA Content-Language: zh-cn X-CM-TRANSID: Z0GX06CrowNqsaxUVvGiAA==.7218S4 X-Coremail-Antispam: 1U3129KBjvJXoW3Cw4xWFW8uw47CrWrtF47urg_yoWkCr4UpF W3JayUKF4kJr17Aw1Dtr18JF1Yv348tryUXrn8JryUC3s8KFyFqr4Utw1ruFWDCr15Jw4j vrWj9347u3W5ZrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUAVWUtjIFyTuYvjfUOiSdDUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dAa0nHf7XemNb46MsPlwFhvwfsc Cc: 'Simon Perreault' , tram@ietf.org, 'Varun Singh' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 05:39:42 -0000 Hi, Reddy, Please see the reply inline. Best Regards. > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Tuesday, January 06, 2015 8:20 PM > To: Aijun Wang; 'Brandon Williams'; Pal Martinsen (palmarti) > Cc: 'Simon Perreault'; tram@ietf.org; 'Varun Singh' > Subject: RE: [tram] New Version Notification for > draft-reddy-tram-stun-path-data-00.txt >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang > > Sent: Tuesday, January 06, 2015 9:13 AM > > To: 'Brandon Williams'; Pal Martinsen (palmarti); Tirumaleswar Reddy > > (tireddy) > > Cc: 'Simon Perreault'; tram@ietf.org; 'Varun Singh' > > Subject: Re: [tram] New Version Notification for > > draft-reddy-tram-stun-path- data-00.txt > > > > Hi, All: > > > > The draft that given by Reddy illustrating some drawback of the > > current ICE solution(RFC5245), and actually provided another = possible > > solution to improve it. >=20 > ICE regular and aggressive nomination have certain drawbacks which = will be > dealt as part of ICE continuous nomination work in mmusic WG, ICE = algorithm > changes will not be covered in this draft. Note that this draft can = also be used > with regular ICE when there is no noticeable impact in setting up the = media > session, It depends on the number of candidate pairs, time interval = for pacing > ICE connectivity checks and RTO values. >=20 > > I agree also that it is necessary for ICE to check connectivity > > continuously, but still hesitate to agree add more additional = function > > to its role(such as RTT, loss rate, pathmtu etc.). >=20 > Why ? The functions for detecting RTT, loss rate etc. are useful but not = reliable and deterministic. Can you assure the applications that relied = on them will be more efficiency and reliable? I prefer to putting all = usable interfaces into a pool(via ICE continuously checking proposal) = and give more flexibility to the application. More detections and = decision can be made by the upper layer, not the ICE itself. There are other large questions for the connectivity, for example, the = NAT punching for the BEHAVE-compliant NAT devices and non = BEHAVE-compliant NAT devices, the selection of appropriate TURN server = when the TURN server are distributed deployed, the communication between = IPv4 endpoint, IPv4/IPv6 endpoint and IPv6 endpoint etc. I think ICE = should focus more on the solution of these challenges. > Periodic ICE connectivity checks for media streams for consent = freshness is > already covered in > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11 >=20 I was also curious that how this problem that mentioned in this draft is = raised. If the corresponding endpoint doesn't want to receive the data = from other endpoint, it need just close the TCP/UDP session that built = by ICE process, why should we use the consent freshness check? > > > > The better solution may be to check the connectivity continuously, > > especially for the newly up interface, but only limited to the = connectivity > characteristic. > > The application layer should balance among these available = interfaces > > that given by ICE, using their own RTT, loss rate detection and > > path-mtu finding solution. This can also reduce the latency of > > interface switching of the endpoint. >=20 > ICE continuous nomination allows checks on new interfaces and the path > characteristics discovered using ICE can be used to switch-over the = media > stream to a new interface. It is discussed in > = http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html#= se > ction-3.1 >=20 > -Tiru >=20 > > > > Best Regards. > > Aijun Wang. > > > > > -----Original Message----- > > > From: Brandon Williams [mailto:bowill@akamai.com] > > > Sent: Tuesday, January 06, 2015 7:09 AM > > > To: Pal Martinsen (palmarti); Tirumaleswar Reddy (tireddy) > > > Cc: Aijun Wang; Varun Singh; Simon Perreault; tram@ietf.org > > > Subject: Re: [tram] New Version Notification for > > > draft-reddy-tram-stun-path-data-00.txt > > > > > > Hi P=C3=A5l-Erik, > > > > > > You wrote: Down play ICE usage. Focus on what a TRAM drafts should > > focus on. > > > (In this case provide RTT and loss information) > > > > > > I'm not certain exactly what you're looking for in the text. I = don't > > > really see a meaningful use case for the RTT and loss stats = outside > > > of the end-to-end context of the ICE use case, since using partial > > > path stats for decision making will often generate bad results. Do > > > you see a use case other than ICE? Or are you simply suggesting = that > > > the draft should avoid referencing a specific use case altogether? > > > > > > Thanks, > > > --Brandon > > > > > > > > > On 01/05/2015 04:01 AM, Pal Martinsen (palmarti) wrote: > > > > > > > >> On 05 Jan 2015, at 08:27, Tirumaleswar Reddy (tireddy) > > > >> > wrote: > > > >> > > > >>> -----Original Message----- > > > >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun > > > >>> Wang > > > >>> Sent: Sunday, January 04, 2015 6:12 AM > > > >>> To: 'Varun Singh'; Tirumaleswar Reddy (tireddy) > > > >>> Cc: 'Simon Perreault'; tram@ietf.org ; > > > >>> 'Brandon Williams' > > > >>> Subject: Re: [tram] FW: New Version Notification for > > > >>> draft-reddy-tram-stun- > > > >>> path-data-00.txt > > > >>> > > > >>> Hi, Singh, Reddy and Simon: > > > >>> > > > >>> I admitted that the path characteristic can be one factor to = be > > > >>> considered and can be used to assist the endpoints to select = the > > > >>> appropriate path. The main point of this value that different > > > >>> from other criteria defined in RFC5245 is that this value will > > > >>> be changed dynamically and is not determined. > > > >>> Consider the ICE connectivity check will be only done once for > > > >>> one communication session, is it appropriate for it to rely on > > > >>> one unreliable value to make the decision? > > > >> > > > >> No, consent freshness and ICE continuous nomination explain = that > > > >> ICE connectivity checks happen even after candidates are > > > >> nominated for the media session. An interface can be picked = based > > > >> on the current path characteristics, continue with ICE checks = on > > > >> other interfaces or new interfaces discovered later and > > > >> switch-over when a better candidate pair is available. For = more > > > >> information refer to the discussion in mmusic WG > > > >> = (http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis. > > > >> html) > > > > > > > > I do agree with Aijuns point that RFC5245 limits the usability = of > > > > this draft. But as you point out there is a lot of discussions > > > > going on regarding how we can improve ICE, not all of those > > > > discussions are well known. To catch up, reading the MMUSIC > > > > mailing-list is probably a good > > > idea. > > > > > > > > To make it easier to read the draft I would propose to do the > > > > following in the next version. > > > > > > > > - Rename draft to =E2=80=9CRTT and loss measurements of STUN = Transactions=E2=80=9D. > > > > Path characteristics seems to hint that other things like > > > > bandwidth and so on is also included. > > > > - Down play ICE usage. Focus on what a TRAM drafts should focus = on. > > > > (In this case provide RTT and loss information) > > > > > > > > > > > > The DISCUSS draft > > > > (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt) > > > > also have the ability to provide useful information, but it > > > > requires support from the network to achieve this. > > > > > > > > > > > >> > > > >>> What would you do if it select one idle pair at first but it > > > >>> become congest later? > > > >>> > > > >>> I think the dynamic path selection should be left to and be > > > >>> considered by the application layer itself, such as RTCP > > > >>> protocol etc. > > > >> > > > >> In case of MPRTP, Path characteristics discovered using ICE = will > > > >> be used for picking the interface for the primary sub-flow and > > > >> interfaces for subsequent sub-flows and MPRTP RTCP report can = be > > > >> used later for load balancing. > > > >> > > > > > > > > A short summary of my understanding of the MMUSIC ICE = discussions is: > > > > - Use ICE to build a valid list > > > > - Redefined how we use that valid list. (Keeping pairs warm so = we > > > > can switch to them fast ++) > > > > - Redefine when and how we chose an active candidate pair to = send > > > > media > > > on. > > > > > > > > .-. > > > > P=C3=A5l-Erik > > > > > > > >> -Tiru > > > >> > > > >>> > > > >>> Best Regards. > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Varun Singh [mailto:vsingh.ietf@gmail.com] > > > >>>> Sent: Wednesday, December 31, 2014 7:50 PM > > > >>>> To: Tirumaleswar Reddy (tireddy) > > > >>>> Cc: Simon Perreault; Brandon Williams; tram@ietf.org > > > >>>> ; Aijun Wang > > > >>>> Subject: Re: [tram] FW: New Version Notification for > > > >>>> draft-reddy-tram-stun-path-data-00.txt > > > >>>> > > > >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy) > > > >>>> > wrote: > > > >>>>> Inline [TR] > > > >>>>> On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams > > > >>>>> > > > > > > >>>>> wrote: > > > >>>>> > > > >>>>> You are correct that the currently published RFC makes the > > > >>>>> path quality information harder to use in a meaningful way. > > > >>>>> However, there is ongoing work in both tram and mmusic = focused > > > >>>>> on allowing more dynamic path selection that can use > > > >>>>> performance metrics rather than the currently defined static > priorities. > > > >>>>> This draft is just one piece of that > > > >>>> bigger picture. > > > >>>>> > > > >>>>> > > > >>>>> You're right, of course, but if there's no way to make > > > >>>>> practical use of this draft with regular ICE, then that's > > > >>>>> useful information that needs to go into the draft. Ideally > > > >>>>> with pointers to the bigger picture you > > > >>>> mentioned. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> [TR] we will update the introduction section to make it = clear. > > > >>>>> This draft can be used with regular ICE when there is no > > > >>>>> noticeable impact in setting up the media session. It = depends > > > >>>>> on the number of candidate pairs, time interval (Ta) for > > > >>>>> pacing ICE connectivity checks and > > > >>> RTO values. > > > >>>>> > > > >>>> > > > >>>> True. Path characteristics can be used in addition to the > > > >>>> proprietary criteria the endpoint currently implements. i.e., > > > >>>> if the endpoints wants to stop checking because it met its > > > >>>> defined criteria and was using the path characteristics as = part > > > >>>> of the STUN messages, it could still use the path > > > >>>> characteristics for those candidates to make further > > > >>> decisions. > > > >>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> http://www.netlab.tkk.fi/~varun/ > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> tram mailing list > > > >>> tram@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/tram > > > >> > > > >> _______________________________________________ > > > >> tram mailing list > > > >> tram@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > -- > > > Brandon Williams; Senior Principal Software Engineer Emerging > > > Products Engineering; Akamai Technologies Inc. > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jan 6 21:57:51 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466EE1A895B for ; Tue, 6 Jan 2015 21:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7] autolearn=no 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 jfOOWuPMlewp for ; Tue, 6 Jan 2015 21:57:48 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id F3C6E1A895A for ; Tue, 6 Jan 2015 21:57:45 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BrLQK6taxUAzObAA==.7584S4; Wed, 07 Jan 2015 12:27:57 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> In-Reply-To: Date: Wed, 7 Jan 2015 13:57:22 +0800 Message-ID: <00a501d02a3e$d7bcd4c0$87367e40$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01D02A81.E5E014C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdApukh0IsZeNDPZRpquLp/LhDWKTQAgf4rw Content-Language: zh-cn X-CM-TRANSID: Z0GX06BrLQK6taxUAzObAA==.7584S4 X-Coremail-Antispam: 1U3129KBjvJXoW7CF4UGF45uw45Jw1fCF45Jrb_yoW8GF1rpa y5uay5AF93XrWxJr15uw47uF1F9r95Wry3JrnxKw4UuanIyF1Iqr9Igw1F9ry8Grn5Aay2 qr45t3ZrZa13Z3DanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjlmb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r17MIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI 0_Jr0_GrUI43ZEXa7VU1RuWJUUUUU== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/uZUnycFp4S3g2_xFJJINxIoOCHo Cc: tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 05:57:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A6_01D02A81.E5E014C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Simon: =20 Please see the reply inline.=20 =20 Best Regards. Aijun =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Tuesday, January 06, 2015 11:36 PM To: Aijun Wang Cc: Brandon Williams; tram@ietf.org Subject: Re: [tram] Fwd: New Version Notification for = draft-williams-peer-redirect-02.txt =20 =20 On Tue, Jan 6, 2015 at 1:14 AM, Aijun Wang = wrote: 1. Is it possible for two peers to select different Relay Server to communicate? =20 It's already possible with today's ICE, without this draft. Or do you = mean something else? =20 =E3=80=90Aijun=E3=80=91: in = http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/, it described = only the process that the communication endpoints under one same TURN = server. The process for endpoints that under different TURN server is = not mentioned and is complex if we allow it happen. =20 If so, will the communication channel between the Relay Server will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure = two peers select the same Relay Server? =20 Why would it be necessary that the two peers select the same server? =20 =E3=80=90Aijun=E3=80=91: To simplify the realization of TURN process. = Two questions: 1. How do we encapsulate the application data between the TURN servers? = Using the =E2=80=9CChannelData Message=E2=80=9D or using pure UDP = message?=20 2. how about the TCP communication channel between two TURN servers? =20 Simon ------=_NextPart_000_00A6_01D02A81.E5E014C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Simon:

 

Please see the reply inline.

 

Best Regards.

Aijun

 

From:= Simon = Perreault [mailto:sperreault@jive.com]
Sent: Tuesday, January = 06, 2015 11:36 PM
To: Aijun Wang
Cc: Brandon = Williams; tram@ietf.org
Subject: Re: [tram] Fwd: New Version = Notification for = draft-williams-peer-redirect-02.txt

 

 

On Tue, Jan 6, 2015 at 1:14 AM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

1. Is it possible for two peers to select different Relay = Server to
communicate?

 

It's already possible with today's = ICE, without this draft. Or do you mean something = else?

 

=E3=80=90Aijun=E3=80=91: in http://= datatracker.ietf.org/doc/draft-ietf-tram-turnbis/, it described only = the process that the communication endpoints under one same TURN server. = The process for endpoints that under different TURN server is not = mentioned and is complex if we allow it happen.

 

If so, will the communication = channel between the Relay Server
will be changed by the = CHECK-ALTERNATE attribute? If not, how to ensure two
peers select the = same Relay Server?

 

Why would it be necessary that the = two peers select the same server?

 

=E3=80=90Aijun=E3=80=91: To simplify the realization of TURN process. Two = questions:

1. How do we encapsulate the application data between the TURN = servers? Using the =E2=80=9CChannelData Message=E2=80=9D or using pure = UDP message?

2. how about the TCP communication channel between two TURN = servers?

 

Simon

------=_NextPart_000_00A6_01D02A81.E5E014C0-- From nobody Tue Jan 6 22:47:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029D61A895C for ; Tue, 6 Jan 2015 22:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mUFA0n6Tf5Zy for ; Tue, 6 Jan 2015 22:47:42 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16C41A8749 for ; Tue, 6 Jan 2015 22:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18590; q=dns/txt; s=iport; t=1420613262; x=1421822862; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=eIcFC+ITg+Nt0yNMrRtLLnhIekwcPfox2dmvUhWmCho=; b=WhjrcsAGtA2rpbE81q2TyH5nyEizZshhr3mpl1RPQcVjOj4hqwG0WQX1 AuD3iZy+3kn+4dxny4qNW+OXLUs8ada/uvK80nqiIkRR7gXXJAKya6YsA Zr8GvUOpFGfagwpWd7xSlWTLcwQSCapS0TKFLVe+dEIYduPJewkZIKSWw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUFAEnVrFStJV2R/2dsb2JhbABcFoJwUlgEgwHBMYIbCoVzAhxxFgEBAQEBfYQMAQEBAwEBAQELFRExCQkCBQcGAQgRBAEBAQICBh0DAgQfBgsUAQgJAQQBDQUIE4d9AwkIDa9Ej3oNg1oBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGIbYNAgUcLJxYbDYJiLoETBY4lg0GDdIJRMII6gjSFHDoDhVgig25vAYECBT1+AQEB X-IronPort-AV: E=Sophos;i="5.07,713,1413244800"; d="scan'208";a="110972527" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 07 Jan 2015 06:47:40 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t076le7a009506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 06:47:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 00:47:40 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Aijun Wang , "'Brandon Williams'" , "Pal Martinsen (palmarti)" Thread-Topic: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAqRc5JVauEPU4HQy2EODKJPPZIcQ== Date: Wed, 7 Jan 2015 06:47:39 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0AXkH_BI4xzX4kGDSmxWofBQzFg Cc: 'Simon Perreault' , "tram@ietf.org" , 'Varun Singh' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 06:47:46 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiBTZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMDcsIDIwMTUgMTE6MDkgQU0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7ICdCcmFuZG9uIFdpbGxpYW1zJzsgUGFsIE1hcnRpbnNlbg0KPiAocGFsbWFydGkp DQo+IENjOiAnU2ltb24gUGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgJ1ZhcnVuIFNpbmdoJw0K PiBTdWJqZWN0OiBSZTogW3RyYW1dIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt cmVkZHktdHJhbS1zdHVuLXBhdGgtDQo+IGRhdGEtMDAudHh0DQo+IA0KPiBIaSwgUmVkZHksDQo+ IA0KPiBQbGVhc2Ugc2VlIHRoZSByZXBseSBpbmxpbmUuDQo+IA0KPiBCZXN0IFJlZ2FyZHMuDQo+ IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29tXQ0KPiA+IFNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMDYsIDIwMTUgODoyMCBQTQ0KPiA+IFRvOiBBaWp1biBXYW5nOyAnQnJh bmRvbiBXaWxsaWFtcyc7IFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKQ0KPiA+IENjOiAnU2ltb24g UGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgJ1ZhcnVuIFNpbmdoJw0KPiA+IFN1YmplY3Q6IFJF OiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LXJlZGR5LXRy YW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiA+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAwNiwg MjAxNSA5OjEzIEFNDQo+ID4gPiBUbzogJ0JyYW5kb24gV2lsbGlhbXMnOyBQYWwgTWFydGluc2Vu IChwYWxtYXJ0aSk7IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ID4gKHRpcmVkZHkpDQo+ID4gPiBD YzogJ1NpbW9uIFBlcnJlYXVsdCc7IHRyYW1AaWV0Zi5vcmc7ICdWYXJ1biBTaW5naCcNCj4gPiA+ IFN1YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ID4g ZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtIGRhdGEtMDAudHh0DQo+ID4gPg0KPiA+ID4gSGks IEFsbDoNCj4gPiA+DQo+ID4gPiBUaGUgZHJhZnQgdGhhdCBnaXZlbiBieSBSZWRkeSBpbGx1c3Ry YXRpbmcgc29tZSBkcmF3YmFjayBvZiB0aGUNCj4gPiA+IGN1cnJlbnQgSUNFIHNvbHV0aW9uKFJG QzUyNDUpLCBhbmQgYWN0dWFsbHkgcHJvdmlkZWQgYW5vdGhlcg0KPiA+ID4gcG9zc2libGUgc29s dXRpb24gdG8gaW1wcm92ZSBpdC4NCj4gPg0KPiA+IElDRSByZWd1bGFyIGFuZCBhZ2dyZXNzaXZl IG5vbWluYXRpb24gaGF2ZSBjZXJ0YWluIGRyYXdiYWNrcyB3aGljaA0KPiA+IHdpbGwgYmUgZGVh bHQgYXMgcGFydCBvZiBJQ0UgY29udGludW91cyBub21pbmF0aW9uIHdvcmsgaW4gbW11c2ljIFdH LA0KPiA+IElDRSBhbGdvcml0aG0gY2hhbmdlcyB3aWxsIG5vdCBiZSBjb3ZlcmVkIGluIHRoaXMg ZHJhZnQuIE5vdGUgdGhhdA0KPiA+IHRoaXMgZHJhZnQgY2FuIGFsc28gYmUgdXNlZCB3aXRoIHJl Z3VsYXIgSUNFIHdoZW4gdGhlcmUgaXMgbm8NCj4gPiBub3RpY2VhYmxlIGltcGFjdCBpbiBzZXR0 aW5nIHVwIHRoZSBtZWRpYSBzZXNzaW9uLCAgSXQgZGVwZW5kcyBvbiB0aGUNCj4gPiBudW1iZXIg b2YgY2FuZGlkYXRlIHBhaXJzLCB0aW1lIGludGVydmFsIGZvciBwYWNpbmcgSUNFIGNvbm5lY3Rp dml0eSBjaGVja3MNCj4gYW5kIFJUTyB2YWx1ZXMuDQo+ID4NCj4gPiA+IEkgYWdyZWUgYWxzbyB0 aGF0IGl0IGlzIG5lY2Vzc2FyeSBmb3IgSUNFIHRvIGNoZWNrIGNvbm5lY3Rpdml0eQ0KPiA+ID4g Y29udGludW91c2x5LCBidXQgc3RpbGwgaGVzaXRhdGUgdG8gYWdyZWUgYWRkIG1vcmUgYWRkaXRp b25hbA0KPiA+ID4gZnVuY3Rpb24gdG8gaXRzIHJvbGUoc3VjaCBhcyBSVFQsIGxvc3MgcmF0ZSwg cGF0aG10dSBldGMuKS4NCj4gPg0KPiA+IFdoeSA/DQo+IA0KPiBUaGUgZnVuY3Rpb25zIGZvciBk ZXRlY3RpbmcgUlRULCBsb3NzIHJhdGUgZXRjLiBhcmUgdXNlZnVsIGJ1dCBub3QgcmVsaWFibGUg YW5kDQo+IGRldGVybWluaXN0aWMuIA0KDQpJdCBkZXBlbmRzIGlmIHRoZSBjaGVja3MgYXJlIGRv bmUgb25jZSBvciBwZXJpb2RpY2FsbHkuDQogDQo+IENhbiB5b3UgYXNzdXJlIHRoZSBhcHBsaWNh dGlvbnMgdGhhdCByZWxpZWQgb24gdGhlbSB3aWxsIGJlDQo+IG1vcmUgZWZmaWNpZW5jeSBhbmQg cmVsaWFibGU/IEkgcHJlZmVyIHRvIHB1dHRpbmcgYWxsIHVzYWJsZSBpbnRlcmZhY2VzIGludG8g YQ0KPiBwb29sKHZpYSBJQ0UgY29udGludW91c2x5IGNoZWNraW5nIHByb3Bvc2FsKSBhbmQgZ2l2 ZSBtb3JlIGZsZXhpYmlsaXR5IHRvIHRoZQ0KPiBhcHBsaWNhdGlvbi4gTW9yZSBkZXRlY3Rpb25z IGFuZCBkZWNpc2lvbiBjYW4gYmUgbWFkZSBieSB0aGUgdXBwZXIgbGF5ZXIsDQo+IG5vdCB0aGUg SUNFIGl0c2VsZi4NCg0KVGhlIGRlY2lzaW9uIG5lZWQgbm90IGJlIG1hZGUgYnkgSUNFLCBpdCBj YW4gZXhwb3NlIHBhdGggbWV0cmljcyBsaWtlIFJUVCwgcGFja2V0IGxvc3MgdG8gdGhlIHVwcGVy IGxheWVyLg0KDQoNCj4gVGhlcmUgYXJlIG90aGVyIGxhcmdlIHF1ZXN0aW9ucyBmb3IgdGhlIGNv bm5lY3Rpdml0eSwgZm9yIGV4YW1wbGUsIHRoZSBOQVQNCj4gcHVuY2hpbmcgZm9yIHRoZSBCRUhB VkUtY29tcGxpYW50IE5BVCBkZXZpY2VzIGFuZCBub24gQkVIQVZFLWNvbXBsaWFudA0KPiBOQVQg ZGV2aWNlcywgdGhlIHNlbGVjdGlvbiBvZiBhcHByb3ByaWF0ZSBUVVJOIHNlcnZlciB3aGVuIHRo ZSBUVVJOIHNlcnZlcg0KPiBhcmUgZGlzdHJpYnV0ZWQgZGVwbG95ZWQsIHRoZSBjb21tdW5pY2F0 aW9uIGJldHdlZW4gSVB2NCBlbmRwb2ludCwNCj4gSVB2NC9JUHY2IGVuZHBvaW50IGFuZCBJUHY2 IGVuZHBvaW50IGV0Yy4gSSB0aGluayBJQ0Ugc2hvdWxkIGZvY3VzIG1vcmUgb24NCj4gdGhlIHNv bHV0aW9uIG9mIHRoZXNlIGNoYWxsZW5nZXMuDQoNCklDRSBhbHJlYWR5IGFkZHJlc3NlcyBOQVQg YW5kIGNvbm5lY3Rpdml0eSBwcm9ibGVtcyBiL3cgZW5kcG9pbnRzIHdpdGggZGlmZmVyZW50IElQ IGFkZHJlc3MgZmFtaWxpZXMuDQoNCj4gDQo+ID4gUGVyaW9kaWMgSUNFIGNvbm5lY3Rpdml0eSBj aGVja3MgZm9yIG1lZGlhIHN0cmVhbXMgZm9yIGNvbnNlbnQNCj4gPiBmcmVzaG5lc3MgaXMgYWxy ZWFkeSBjb3ZlcmVkIGluDQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMQ0KPiA+DQo+IEkgd2FzIGFsc28gY3Vy aW91cyB0aGF0IGhvdyB0aGlzIHByb2JsZW0gdGhhdCBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdCBp cw0KPiByYWlzZWQuIElmIHRoZSBjb3JyZXNwb25kaW5nIGVuZHBvaW50IGRvZXNuJ3Qgd2FudCB0 byByZWNlaXZlIHRoZSBkYXRhIGZyb20NCj4gb3RoZXIgZW5kcG9pbnQsIGl0IG5lZWQganVzdCBj bG9zZSB0aGUgVENQL1VEUCBzZXNzaW9uIHRoYXQgYnVpbHQgYnkgSUNFDQo+IHByb2Nlc3MsIHdo eSBzaG91bGQgd2UgdXNlIHRoZSBjb25zZW50IGZyZXNobmVzcyBjaGVjaz8NCg0KQ29uc2VudCBm cmVzaG5lc3Mgd2lsbCBoZWxwIHRoZSBlbmRwb2ludCBkZXRlcm1pbmUgaWYgdGhlIHJlbW90ZSBw ZWVyIGlzIGludGVyZXN0ZWQgaW4gcmVjZWl2aW5nIHRoZSB0cmFmZmljIG9yIG5vdC4NCg0KLVRp cnUNCg0KPiANCj4gPiA+DQo+ID4gPiBUaGUgYmV0dGVyIHNvbHV0aW9uIG1heSBiZSB0byBjaGVj ayB0aGUgY29ubmVjdGl2aXR5IGNvbnRpbnVvdXNseSwNCj4gPiA+IGVzcGVjaWFsbHkgZm9yIHRo ZSBuZXdseSB1cCBpbnRlcmZhY2UsIGJ1dCBvbmx5IGxpbWl0ZWQgdG8gdGhlDQo+ID4gPiBjb25u ZWN0aXZpdHkNCj4gPiBjaGFyYWN0ZXJpc3RpYy4NCj4gPiA+IFRoZSBhcHBsaWNhdGlvbiBsYXll ciBzaG91bGQgYmFsYW5jZSBhbW9uZyB0aGVzZSBhdmFpbGFibGUNCj4gPiA+IGludGVyZmFjZXMg dGhhdCBnaXZlbiBieSBJQ0UsIHVzaW5nIHRoZWlyIG93biBSVFQsIGxvc3MgcmF0ZQ0KPiA+ID4g ZGV0ZWN0aW9uIGFuZCBwYXRoLW10dSBmaW5kaW5nIHNvbHV0aW9uLiBUaGlzIGNhbiBhbHNvIHJl ZHVjZSB0aGUNCj4gPiA+IGxhdGVuY3kgb2YgaW50ZXJmYWNlIHN3aXRjaGluZyBvZiB0aGUgZW5k cG9pbnQuDQo+ID4NCj4gPiBJQ0UgY29udGludW91cyBub21pbmF0aW9uIGFsbG93cyBjaGVja3Mg b24gbmV3IGludGVyZmFjZXMgYW5kIHRoZSBwYXRoDQo+ID4gY2hhcmFjdGVyaXN0aWNzIGRpc2Nv dmVyZWQgdXNpbmcgSUNFIGNhbiBiZSB1c2VkIHRvIHN3aXRjaC1vdmVyIHRoZQ0KPiA+IG1lZGlh IHN0cmVhbSB0byBhIG5ldyBpbnRlcmZhY2UuIEl0IGlzIGRpc2N1c3NlZCBpbg0KPiA+IGh0dHA6 Ly9qdWJlcnRpLmdpdGh1Yi5pby9kcmF1Z2h0cy9ub21iaXMvZHJhZnQtdWJlcnRpLW1tdXNpYy1u b21iaXMuaHQNCj4gPiBtbCNzZQ0KPiA+IGN0aW9uLTMuMQ0KPiA+DQo+ID4gLVRpcnUNCj4gPg0K PiA+ID4NCj4gPiA+IEJlc3QgUmVnYXJkcy4NCj4gPiA+IEFpanVuIFdhbmcuDQo+ID4gPg0KPiA+ ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBCcmFuZG9uIFdp bGxpYW1zIFttYWlsdG86Ym93aWxsQGFrYW1haS5jb21dDQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMDYsIDIwMTUgNzowOSBBTQ0KPiA+ID4gPiBUbzogUGFsIE1hcnRpbnNlbiAocGFs bWFydGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gPiA+IENjOiBBaWp1biBX YW5nOyBWYXJ1biBTaW5naDsgU2ltb24gUGVycmVhdWx0OyB0cmFtQGlldGYub3JnDQo+ID4gPiA+ IFN1YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ID4g PiBkcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KPiA+ID4gPg0KPiA+ID4g PiBIaSBQw6VsLUVyaWssDQo+ID4gPiA+DQo+ID4gPiA+IFlvdSB3cm90ZTogRG93biBwbGF5IElD RSB1c2FnZS4gRm9jdXMgb24gd2hhdCBhIFRSQU0gZHJhZnRzIHNob3VsZA0KPiA+ID4gZm9jdXMg b24uDQo+ID4gPiA+IChJbiB0aGlzIGNhc2UgcHJvdmlkZSBSVFQgYW5kIGxvc3MgaW5mb3JtYXRp b24pDQo+ID4gPiA+DQo+ID4gPiA+IEknbSBub3QgY2VydGFpbiBleGFjdGx5IHdoYXQgeW91J3Jl IGxvb2tpbmcgZm9yIGluIHRoZSB0ZXh0LiBJDQo+ID4gPiA+IGRvbid0IHJlYWxseSBzZWUgYSBt ZWFuaW5nZnVsIHVzZSBjYXNlIGZvciB0aGUgUlRUIGFuZCBsb3NzIHN0YXRzDQo+ID4gPiA+IG91 dHNpZGUgb2YgdGhlIGVuZC10by1lbmQgY29udGV4dCBvZiB0aGUgSUNFIHVzZSBjYXNlLCBzaW5j ZSB1c2luZw0KPiA+ID4gPiBwYXJ0aWFsIHBhdGggc3RhdHMgZm9yIGRlY2lzaW9uIG1ha2luZyB3 aWxsIG9mdGVuIGdlbmVyYXRlIGJhZA0KPiA+ID4gPiByZXN1bHRzLiBEbyB5b3Ugc2VlIGEgdXNl IGNhc2Ugb3RoZXIgdGhhbiBJQ0U/IE9yIGFyZSB5b3Ugc2ltcGx5DQo+ID4gPiA+IHN1Z2dlc3Rp bmcgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGF2b2lkIHJlZmVyZW5jaW5nIGEgc3BlY2lmaWMgdXNl IGNhc2UNCj4gYWx0b2dldGhlcj8NCj4gPiA+ID4NCj4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiAt LUJyYW5kb24NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT24gMDEvMDUvMjAxNSAwNDowMSBB TSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIHdyb3RlOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+ IE9uIDA1IEphbiAyMDE1LCBhdCAwODoyNywgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0K PiA+ID4gPiA+PiA8dGlyZWRkeUBjaXNjby5jb20gPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+ IHdyb3RlOg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+ID4gPj4+IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBBaWp1bg0KPiA+ID4gPiA+Pj4gV2FuZw0KPiA+ID4gPiA+Pj4gU2VudDog U3VuZGF5LCBKYW51YXJ5IDA0LCAyMDE1IDY6MTIgQU0NCj4gPiA+ID4gPj4+IFRvOiAnVmFydW4g U2luZ2gnOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gPiA+ID4+PiBDYzogJ1Np bW9uIFBlcnJlYXVsdCc7IHRyYW1AaWV0Zi5vcmcgPG1haWx0bzp0cmFtQGlldGYub3JnPjsNCj4g PiA+ID4gPj4+ICdCcmFuZG9uIFdpbGxpYW1zJw0KPiA+ID4gPiA+Pj4gU3ViamVjdDogUmU6IFt0 cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ID4gPiA+Pj4gZHJhZnQt cmVkZHktdHJhbS1zdHVuLQ0KPiA+ID4gPiA+Pj4gcGF0aC1kYXRhLTAwLnR4dA0KPiA+ID4gPiA+ Pj4NCj4gPiA+ID4gPj4+IEhpLCBTaW5naCwgUmVkZHkgYW5kIFNpbW9uOg0KPiA+ID4gPiA+Pj4N Cj4gPiA+ID4gPj4+IEkgYWRtaXR0ZWQgdGhhdCB0aGUgcGF0aCBjaGFyYWN0ZXJpc3RpYyBjYW4g YmUgb25lIGZhY3RvciB0bw0KPiA+ID4gPiA+Pj4gYmUgY29uc2lkZXJlZCBhbmQgY2FuIGJlIHVz ZWQgdG8gYXNzaXN0IHRoZSBlbmRwb2ludHMgdG8NCj4gPiA+ID4gPj4+IHNlbGVjdCB0aGUgYXBw cm9wcmlhdGUgcGF0aC4gVGhlIG1haW4gcG9pbnQgb2YgdGhpcyB2YWx1ZSB0aGF0DQo+ID4gPiA+ ID4+PiBkaWZmZXJlbnQgZnJvbSBvdGhlciBjcml0ZXJpYSBkZWZpbmVkIGluIFJGQzUyNDUgaXMg dGhhdCB0aGlzDQo+ID4gPiA+ID4+PiB2YWx1ZSB3aWxsIGJlIGNoYW5nZWQgZHluYW1pY2FsbHkg YW5kIGlzIG5vdCBkZXRlcm1pbmVkLg0KPiA+ID4gPiA+Pj4gQ29uc2lkZXIgdGhlIElDRSBjb25u ZWN0aXZpdHkgY2hlY2sgd2lsbCBiZSBvbmx5IGRvbmUgb25jZSBmb3INCj4gPiA+ID4gPj4+IG9u ZSBjb21tdW5pY2F0aW9uIHNlc3Npb24sIGlzIGl0IGFwcHJvcHJpYXRlIGZvciBpdCB0byByZWx5 IG9uDQo+ID4gPiA+ID4+PiBvbmUgdW5yZWxpYWJsZSB2YWx1ZSB0byBtYWtlIHRoZSBkZWNpc2lv bj8NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gTm8sIGNvbnNlbnQgZnJlc2huZXNzIGFuZCBJQ0Ug Y29udGludW91cyBub21pbmF0aW9uIGV4cGxhaW4NCj4gPiA+ID4gPj4gdGhhdCBJQ0UgY29ubmVj dGl2aXR5IGNoZWNrcyBoYXBwZW4gZXZlbiBhZnRlciBjYW5kaWRhdGVzIGFyZQ0KPiA+ID4gPiA+ PiBub21pbmF0ZWQgZm9yIHRoZSBtZWRpYSBzZXNzaW9uLiBBbiBpbnRlcmZhY2UgY2FuIGJlIHBp Y2tlZA0KPiA+ID4gPiA+PiBiYXNlZCBvbiB0aGUgY3VycmVudCBwYXRoIGNoYXJhY3RlcmlzdGlj cywgY29udGludWUgd2l0aCBJQ0UNCj4gPiA+ID4gPj4gY2hlY2tzIG9uIG90aGVyIGludGVyZmFj ZXMgb3IgbmV3IGludGVyZmFjZXMgZGlzY292ZXJlZCBsYXRlcg0KPiA+ID4gPiA+PiBhbmQgc3dp dGNoLW92ZXIgd2hlbiBhIGJldHRlciBjYW5kaWRhdGUgcGFpciBpcyBhdmFpbGFibGUuICBGb3IN Cj4gPiA+ID4gPj4gbW9yZSBpbmZvcm1hdGlvbiByZWZlciB0byB0aGUgZGlzY3Vzc2lvbiBpbiBt bXVzaWMgV0cNCj4gPiA+ID4gPj4gKGh0dHA6Ly9qdWJlcnRpLmdpdGh1Yi5pby9kcmF1Z2h0cy9u b21iaXMvZHJhZnQtdWJlcnRpLW1tdXNpYy0NCj4gbm9tYmlzLg0KPiA+ID4gPiA+PiBodG1sKQ0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBkbyBhZ3JlZSB3aXRoIEFpanVucyBwb2ludCB0aGF0IFJG QzUyNDUgbGltaXRzIHRoZSB1c2FiaWxpdHkNCj4gPiA+ID4gPiBvZiB0aGlzIGRyYWZ0LiBCdXQg YXMgeW91IHBvaW50IG91dCB0aGVyZSBpcyBhIGxvdCBvZg0KPiA+ID4gPiA+IGRpc2N1c3Npb25z IGdvaW5nIG9uIHJlZ2FyZGluZyBob3cgd2UgY2FuIGltcHJvdmUgSUNFLCBub3QgYWxsDQo+ID4g PiA+ID4gb2YgdGhvc2UgZGlzY3Vzc2lvbnMgYXJlIHdlbGwga25vd24uIFRvIGNhdGNoIHVwLCBy ZWFkaW5nIHRoZQ0KPiA+ID4gPiA+IE1NVVNJQyBtYWlsaW5nLWxpc3QgaXMgcHJvYmFibHkgYSBn b29kDQo+ID4gPiA+IGlkZWEuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUbyBtYWtlIGl0IGVhc2ll ciB0byByZWFkIHRoZSBkcmFmdCBJIHdvdWxkIHByb3Bvc2UgdG8gZG8gdGhlDQo+ID4gPiA+ID4g Zm9sbG93aW5nIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtIFJl bmFtZSBkcmFmdCB0byDigJxSVFQgYW5kIGxvc3MgbWVhc3VyZW1lbnRzIG9mIFNUVU4NCj4gVHJh bnNhY3Rpb25z4oCdLg0KPiA+ID4gPiA+IFBhdGggY2hhcmFjdGVyaXN0aWNzIHNlZW1zIHRvIGhp bnQgdGhhdCBvdGhlciB0aGluZ3MgbGlrZQ0KPiA+ID4gPiA+IGJhbmR3aWR0aCBhbmQgc28gb24g aXMgYWxzbyBpbmNsdWRlZC4NCj4gPiA+ID4gPiAtIERvd24gcGxheSBJQ0UgdXNhZ2UuIEZvY3Vz IG9uIHdoYXQgYSBUUkFNIGRyYWZ0cyBzaG91bGQgZm9jdXMgb24uDQo+ID4gPiA+ID4gKEluIHRo aXMgY2FzZSBwcm92aWRlIFJUVCBhbmQgbG9zcyBpbmZvcm1hdGlvbikNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gVGhlIERJU0NVU1MgZHJhZnQNCj4gPiA+ID4gPiAoaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDEudHh0KQ0KPiA+ ID4gPiA+IGFsc28gaGF2ZSB0aGUgYWJpbGl0eSB0byBwcm92aWRlIHVzZWZ1bCBpbmZvcm1hdGlv biwgYnV0IGl0DQo+ID4gPiA+ID4gcmVxdWlyZXMgc3VwcG9ydCBmcm9tIHRoZSBuZXR3b3JrIHRv IGFjaGlldmUgdGhpcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ ID4+PiBXaGF0IHdvdWxkIHlvdSBkbyBpZiBpdCBzZWxlY3Qgb25lIGlkbGUgcGFpciBhdCBmaXJz dCBidXQgaXQNCj4gPiA+ID4gPj4+IGJlY29tZSBjb25nZXN0IGxhdGVyPw0KPiA+ID4gPiA+Pj4N Cj4gPiA+ID4gPj4+IEkgdGhpbmsgdGhlIGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24gc2hvdWxkIGJl IGxlZnQgdG8gYW5kIGJlDQo+ID4gPiA+ID4+PiBjb25zaWRlcmVkIGJ5IHRoZSBhcHBsaWNhdGlv biBsYXllciBpdHNlbGYsIHN1Y2ggYXMgUlRDUA0KPiA+ID4gPiA+Pj4gcHJvdG9jb2wgZXRjLg0K PiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBJbiBjYXNlIG9mIE1QUlRQLCAgUGF0aCBjaGFyYWN0ZXJp c3RpY3MgZGlzY292ZXJlZCB1c2luZyBJQ0UNCj4gPiA+ID4gPj4gd2lsbCBiZSB1c2VkIGZvciBw aWNraW5nIHRoZSBpbnRlcmZhY2UgZm9yIHRoZSBwcmltYXJ5IHN1Yi1mbG93DQo+ID4gPiA+ID4+ IGFuZCBpbnRlcmZhY2VzIGZvciBzdWJzZXF1ZW50IHN1Yi1mbG93cyBhbmQgTVBSVFAgUlRDUCBy ZXBvcnQNCj4gPiA+ID4gPj4gY2FuIGJlIHVzZWQgbGF0ZXIgZm9yIGxvYWQgYmFsYW5jaW5nLg0K PiA+ID4gPiA+Pg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQSBzaG9ydCBzdW1tYXJ5IG9mIG15IHVu ZGVyc3RhbmRpbmcgb2YgdGhlIE1NVVNJQyBJQ0UgZGlzY3Vzc2lvbnMNCj4gaXM6DQo+ID4gPiA+ ID4gLSBVc2UgSUNFIHRvIGJ1aWxkIGEgdmFsaWQgbGlzdA0KPiA+ID4gPiA+IC0gUmVkZWZpbmVk IGhvdyB3ZSB1c2UgdGhhdCB2YWxpZCBsaXN0LiAoS2VlcGluZyBwYWlycyB3YXJtIHNvDQo+ID4g PiA+ID4gd2UgY2FuIHN3aXRjaCB0byB0aGVtIGZhc3QgKyspDQo+ID4gPiA+ID4gLSBSZWRlZmlu ZSB3aGVuIGFuZCBob3cgd2UgY2hvc2UgYW4gYWN0aXZlIGNhbmRpZGF0ZSBwYWlyIHRvDQo+ID4g PiA+ID4gc2VuZCBtZWRpYQ0KPiA+ID4gPiBvbi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC4tLg0K PiA+ID4gPiA+IFDDpWwtRXJpaw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+IC1UaXJ1DQo+ID4gPiA+ ID4+DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gQmVzdCBSZWdhcmRzLg0KPiA+ID4gPiA+Pj4N Cj4gPiA+ID4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+Pj4+IEZy b206IFZhcnVuIFNpbmdoIFttYWlsdG86dnNpbmdoLmlldGZAZ21haWwuY29tXQ0KPiA+ID4gPiA+ Pj4+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMzEsIDIwMTQgNzo1MCBQTQ0KPiA+ID4gPiA+ Pj4+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gPiA+ID4+Pj4gQ2M6IFNp bW9uIFBlcnJlYXVsdDsgQnJhbmRvbiBXaWxsaWFtczsgdHJhbUBpZXRmLm9yZw0KPiA+ID4gPiA+ Pj4+IDxtYWlsdG86dHJhbUBpZXRmLm9yZz47IEFpanVuIFdhbmcNCj4gPiA+ID4gPj4+PiBTdWJq ZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPiA+ ID4+Pj4gZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCj4gPiA+ID4gPj4+ Pg0KPiA+ID4gPiA+Pj4+IE9uIFdlZCwgRGVjIDMxLCAyMDE0IGF0IDg6MTkgQU0sIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPiA+ID4gPj4+PiA8dGlyZWRkeUBjaXNjby5jb20gPG1h aWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+ID4gPiA+Pj4+PiBJbmxpbmUgW1RS XQ0KPiA+ID4gPiA+Pj4+PiBPbiBUdWUsIERlYyAzMCwgMjAxNCBhdCA5OjMxIEFNLCBCcmFuZG9u IFdpbGxpYW1zDQo+ID4gPiA+ID4+Pj4+IDxicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20NCj4g PiA+ID4gPG1haWx0bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+Pg0KPiA+ID4gPiA+Pj4+ PiB3cm90ZToNCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gWW91IGFyZSBjb3JyZWN0IHRo YXQgdGhlIGN1cnJlbnRseSBwdWJsaXNoZWQgUkZDIG1ha2VzIHRoZQ0KPiA+ID4gPiA+Pj4+PiBw YXRoIHF1YWxpdHkgaW5mb3JtYXRpb24gaGFyZGVyIHRvIHVzZSBpbiBhIG1lYW5pbmdmdWwgd2F5 Lg0KPiA+ID4gPiA+Pj4+PiBIb3dldmVyLCB0aGVyZSBpcyBvbmdvaW5nIHdvcmsgaW4gYm90aCB0 cmFtIGFuZCBtbXVzaWMNCj4gPiA+ID4gPj4+Pj4gZm9jdXNlZCBvbiBhbGxvd2luZyBtb3JlIGR5 bmFtaWMgcGF0aCBzZWxlY3Rpb24gdGhhdCBjYW4gdXNlDQo+ID4gPiA+ID4+Pj4+IHBlcmZvcm1h bmNlIG1ldHJpY3MgcmF0aGVyIHRoYW4gdGhlIGN1cnJlbnRseSBkZWZpbmVkIHN0YXRpYw0KPiA+ IHByaW9yaXRpZXMuDQo+ID4gPiA+ID4+Pj4+IFRoaXMgZHJhZnQgaXMganVzdCBvbmUgcGllY2Ug b2YgdGhhdA0KPiA+ID4gPiA+Pj4+IGJpZ2dlciBwaWN0dXJlLg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBZb3UncmUgcmlnaHQsIG9mIGNvdXJzZSwgYnV0IGlm IHRoZXJlJ3Mgbm8gd2F5IHRvIG1ha2UNCj4gPiA+ID4gPj4+Pj4gcHJhY3RpY2FsIHVzZSBvZiB0 aGlzIGRyYWZ0IHdpdGggcmVndWxhciBJQ0UsIHRoZW4gdGhhdCdzDQo+ID4gPiA+ID4+Pj4+IHVz ZWZ1bCBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGdvIGludG8gdGhlIGRyYWZ0LiBJZGVhbGx5 DQo+ID4gPiA+ID4+Pj4+IHdpdGggcG9pbnRlcnMgdG8gdGhlIGJpZ2dlciBwaWN0dXJlIHlvdQ0K PiA+ID4gPiA+Pj4+IG1lbnRpb25lZC4NCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4NCj4g PiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gW1RSXSB3ZSB3aWxsIHVwZGF0ZSB0aGUgaW50cm9k dWN0aW9uIHNlY3Rpb24gdG8gbWFrZSBpdCBjbGVhci4NCj4gPiA+ID4gPj4+Pj4gVGhpcyBkcmFm dCBjYW4gYmUgdXNlZCB3aXRoIHJlZ3VsYXIgSUNFIHdoZW4gdGhlcmUgaXMgbm8NCj4gPiA+ID4g Pj4+Pj4gbm90aWNlYWJsZSBpbXBhY3QgaW4gc2V0dGluZyB1cCB0aGUgbWVkaWEgc2Vzc2lvbi4g SXQNCj4gPiA+ID4gPj4+Pj4gZGVwZW5kcyBvbiB0aGUgbnVtYmVyIG9mIGNhbmRpZGF0ZSBwYWly cywgdGltZSBpbnRlcnZhbCAoVGEpDQo+ID4gPiA+ID4+Pj4+IGZvciBwYWNpbmcgSUNFIGNvbm5l Y3Rpdml0eSBjaGVja3MgYW5kDQo+ID4gPiA+ID4+PiBSVE8gdmFsdWVzLg0KPiA+ID4gPiA+Pj4+ Pg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4gVHJ1ZS4gUGF0aCBjaGFyYWN0ZXJpc3RpY3Mg Y2FuIGJlIHVzZWQgaW4gYWRkaXRpb24gdG8gdGhlDQo+ID4gPiA+ID4+Pj4gcHJvcHJpZXRhcnkg Y3JpdGVyaWEgdGhlIGVuZHBvaW50IGN1cnJlbnRseSBpbXBsZW1lbnRzLiBpLmUuLA0KPiA+ID4g PiA+Pj4+IGlmIHRoZSBlbmRwb2ludHMgd2FudHMgdG8gc3RvcCBjaGVja2luZyBiZWNhdXNlIGl0 IG1ldCBpdHMNCj4gPiA+ID4gPj4+PiBkZWZpbmVkIGNyaXRlcmlhIGFuZCB3YXMgdXNpbmcgdGhl IHBhdGggY2hhcmFjdGVyaXN0aWNzIGFzDQo+ID4gPiA+ID4+Pj4gcGFydCBvZiB0aGUgU1RVTiBt ZXNzYWdlcywgaXQgY291bGQgc3RpbGwgdXNlIHRoZSBwYXRoDQo+ID4gPiA+ID4+Pj4gY2hhcmFj dGVyaXN0aWNzIGZvciB0aG9zZSBjYW5kaWRhdGVzIHRvIG1ha2UgZnVydGhlcg0KPiA+ID4gPiA+ Pj4gZGVjaXNpb25zLg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+Pg0K PiA+ID4gPiA+Pj4+IC0tDQo+ID4gPiA+ID4+Pj4gaHR0cDovL3d3dy5uZXRsYWIudGtrLmZpL352 YXJ1bi8NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ ID4+PiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+Pj4gdHJhbUBpZXRmLm9yZyA8bWFpbHRv OnRyYW1AaWV0Zi5vcmc+DQo+ID4gPiA+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyYW0NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPj4gdHJhbSBtYWlsaW5nIGxp c3QNCj4gPiA+ID4gPj4gdHJhbUBpZXRmLm9yZyA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQo+ID4g PiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+ID4g PiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tDQo+ID4gPiA+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlv ciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4gPiA+ID4gUHJvZHVjdHMg RW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPiA+ID4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiB0cmFtQGlldGYub3JnDQo+ID4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4gDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWls aW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyYW0NCg== From nobody Wed Jan 7 01:37:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CF01A8991 for ; Wed, 7 Jan 2015 01:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 0CNdb0hWPCeD for ; Wed, 7 Jan 2015 01:37:02 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id B84591A898C for ; Wed, 7 Jan 2015 01:36:56 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06B7zAMN6axUS0GjAA==.12059S4; Wed, 07 Jan 2015 16:06:55 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Brandon Williams'" , "'Pal Martinsen \(palmarti\)'" References: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> Date: Wed, 7 Jan 2015 17:36:23 +0800 Message-ID: <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAqRc5JVauEPU4HQy2EODKJPPZIcQAE3Tkw Content-Language: zh-cn X-CM-TRANSID: Z0GX06B7zAMN6axUS0GjAA==.12059S4 X-Coremail-Antispam: 1U3129KBjvAXoW3Cw1kuFy7Wr4xtr48KF4fuFg_yoW8XF4rGo WfAr1xJw48Gr1UAF1qyw1UGr17Xa4rKr15JryUXr1UJFsIqw13Gw18Jw1DWF43tFWUXr1D Ja48J3yDAFWDJFyrn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJaK7 k0a2IF6r1UMc02F40EFcxC0VAKzVAqx4xG6I80ewAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l 1I0E4x80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4ylYx0E74AGY7Cv6cx26r47MI8E67 AF67kF1VAFwI0_JF0_JwUI43ZEXa7VUbpBT5UUUUU== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OyBReVZUJ5P59fl2dpbWelu_eUE Cc: 'Simon Perreault' , tram@ietf.org, 'Varun Singh' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 09:37:06 -0000 Hi, Reddy: Please see the reply inline below. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy > (tireddy) > Sent: Wednesday, January 07, 2015 2:48 PM > To: Aijun Wang; 'Brandon Williams'; Pal Martinsen (palmarti) > Cc: 'Simon Perreault'; tram@ietf.org; 'Varun Singh' > Subject: Re: [tram] New Version Notification for > draft-reddy-tram-stun-path-data-00.txt >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang > > Sent: Wednesday, January 07, 2015 11:09 AM > > To: Tirumaleswar Reddy (tireddy); 'Brandon Williams'; Pal Martinsen > > (palmarti) > > Cc: 'Simon Perreault'; tram@ietf.org; 'Varun Singh' > > Subject: Re: [tram] New Version Notification for > > draft-reddy-tram-stun-path- data-00.txt > > > > Hi, Reddy, > > > > Please see the reply inline. > > > > Best Regards. > > > > > -----Original Message----- > > > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > > > Sent: Tuesday, January 06, 2015 8:20 PM > > > To: Aijun Wang; 'Brandon Williams'; Pal Martinsen (palmarti) > > > Cc: 'Simon Perreault'; tram@ietf.org; 'Varun Singh' > > > Subject: RE: [tram] New Version Notification for > > > draft-reddy-tram-stun-path-data-00.txt > > > > > > > -----Original Message----- > > > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun = Wang > > > > Sent: Tuesday, January 06, 2015 9:13 AM > > > > To: 'Brandon Williams'; Pal Martinsen (palmarti); Tirumaleswar > > > > Reddy > > > > (tireddy) > > > > Cc: 'Simon Perreault'; tram@ietf.org; 'Varun Singh' > > > > Subject: Re: [tram] New Version Notification for > > > > draft-reddy-tram-stun-path- data-00.txt > > > > > > > > Hi, All: > > > > > > > > The draft that given by Reddy illustrating some drawback of the > > > > current ICE solution(RFC5245), and actually provided another > > > > possible solution to improve it. > > > > > > ICE regular and aggressive nomination have certain drawbacks which > > > will be dealt as part of ICE continuous nomination work in mmusic > > > WG, ICE algorithm changes will not be covered in this draft. Note > > > that this draft can also be used with regular ICE when there is no > > > noticeable impact in setting up the media session, It depends on > > > the number of candidate pairs, time interval for pacing ICE > > > connectivity checks > > and RTO values. > > > > > > > I agree also that it is necessary for ICE to check connectivity > > > > continuously, but still hesitate to agree add more additional > > > > function to its role(such as RTT, loss rate, pathmtu etc.). > > > > > > Why ? > > > > The functions for detecting RTT, loss rate etc. are useful but not > > reliable and deterministic. >=20 > It depends if the checks are done once or periodically. =E3=80=90Aijun=E3=80=91: Even the check is periodical, its result will = be influenced by the traffic of the application data itself. I can give = you another example that the path characteristic is valuable in theory = but not used in practice: IGP protocol such as OSPF considers its metric = value from Bandwidth, delay, reliability and loading value, but actually = use only Bandwidth. Will path-characteristic check try this again? >=20 > > Can you assure the applications that relied on them will be more > > efficiency and reliable? I prefer to putting all usable interfaces > > into a pool(via ICE continuously checking proposal) and give more > > flexibility to the application. More detections and decision can be > > made by the upper layer, not the ICE itself. >=20 > The decision need not be made by ICE, it can expose path metrics like = RTT, > packet loss to the upper layer. =E3=80=90Aijun=E3=80=91: The upper layer can get such information via = its data sending and responding naturally in real time. >=20 >=20 > > There are other large questions for the connectivity, for example, = the > > NAT punching for the BEHAVE-compliant NAT devices and non > > BEHAVE-compliant NAT devices, the selection of appropriate TURN = server > > when the TURN server are distributed deployed, the communication > > between IPv4 endpoint, > > IPv4/IPv6 endpoint and IPv6 endpoint etc. I think ICE should focus > > more on the solution of these challenges. >=20 > ICE already addresses NAT and connectivity problems b/w endpoints with > different IP address families. =E3=80=90Aijun=E3=80=91: 1. Does current ICE consider the communication = scenarios that one IPv4-only endpoint wants to talks to one IPv6-only = endpoint?=20 2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT = environment in one determined manner, not the possible success rate via = trying every pair of check list? 3. Does ICE mention how to make sure the relayed packet to pass = through the non-BEHAVE-compliant NAT device? Especially for TCP = protocol? >=20 > > > > > Periodic ICE connectivity checks for media streams for consent > > > freshness is already covered in > > > = http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness- > > > 11 > > > > > I was also curious that how this problem that mentioned in this = draft > > is raised. If the corresponding endpoint doesn't want to receive the > > data from other endpoint, it need just close the TCP/UDP session = that > > built by ICE process, why should we use the consent freshness check? >=20 > Consent freshness will help the endpoint determine if the remote peer = is > interested in receiving the traffic or not. =E3=80=90Aijun=E3=80=91: There is other system to make this decision. = For example, If I want to talk to you via Skype, I should first find you = in my Skype contact list, and make a call to you. If you accept the = call, the ICE process for data transfer then begin. If you drop the = call, the ICE process will be terminated. ICE itself needs not do the = consent check. >=20 > -Tiru >=20 > > > > > > > > > > The better solution may be to check the connectivity = continuously, > > > > especially for the newly up interface, but only limited to the > > > > connectivity > > > characteristic. > > > > The application layer should balance among these available > > > > interfaces that given by ICE, using their own RTT, loss rate > > > > detection and path-mtu finding solution. This can also reduce = the > > > > latency of interface switching of the endpoint. > > > > > > ICE continuous nomination allows checks on new interfaces and the > > > path characteristics discovered using ICE can be used to = switch-over > > > the media stream to a new interface. It is discussed in > > > = http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis. > > > ht > > > ml#se > > > ction-3.1 > > > > > > -Tiru > > > > > > > > > > > Best Regards. > > > > Aijun Wang. > > > > > > > > > -----Original Message----- > > > > > From: Brandon Williams [mailto:bowill@akamai.com] > > > > > Sent: Tuesday, January 06, 2015 7:09 AM > > > > > To: Pal Martinsen (palmarti); Tirumaleswar Reddy (tireddy) > > > > > Cc: Aijun Wang; Varun Singh; Simon Perreault; tram@ietf.org > > > > > Subject: Re: [tram] New Version Notification for > > > > > draft-reddy-tram-stun-path-data-00.txt > > > > > > > > > > Hi P=C3=A5l-Erik, > > > > > > > > > > You wrote: Down play ICE usage. Focus on what a TRAM drafts > > > > > should > > > > focus on. > > > > > (In this case provide RTT and loss information) > > > > > > > > > > I'm not certain exactly what you're looking for in the text. I > > > > > don't really see a meaningful use case for the RTT and loss > > > > > stats outside of the end-to-end context of the ICE use case, > > > > > since using partial path stats for decision making will often > > > > > generate bad results. Do you see a use case other than ICE? Or > > > > > are you simply suggesting that the draft should avoid > > > > > referencing a specific use case > > altogether? > > > > > > > > > > Thanks, > > > > > --Brandon > > > > > > > > > > > > > > > On 01/05/2015 04:01 AM, Pal Martinsen (palmarti) wrote: > > > > > > > > > > > >> On 05 Jan 2015, at 08:27, Tirumaleswar Reddy (tireddy) > > > > > >> > wrote: > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of = Aijun > > > > > >>> Wang > > > > > >>> Sent: Sunday, January 04, 2015 6:12 AM > > > > > >>> To: 'Varun Singh'; Tirumaleswar Reddy (tireddy) > > > > > >>> Cc: 'Simon Perreault'; tram@ietf.org = ; > > > > > >>> 'Brandon Williams' > > > > > >>> Subject: Re: [tram] FW: New Version Notification for > > > > > >>> draft-reddy-tram-stun- > > > > > >>> path-data-00.txt > > > > > >>> > > > > > >>> Hi, Singh, Reddy and Simon: > > > > > >>> > > > > > >>> I admitted that the path characteristic can be one factor = to > > > > > >>> be considered and can be used to assist the endpoints to > > > > > >>> select the appropriate path. The main point of this value > > > > > >>> that different from other criteria defined in RFC5245 is > > > > > >>> that this value will be changed dynamically and is not = determined. > > > > > >>> Consider the ICE connectivity check will be only done once > > > > > >>> for one communication session, is it appropriate for it to > > > > > >>> rely on one unreliable value to make the decision? > > > > > >> > > > > > >> No, consent freshness and ICE continuous nomination explain > > > > > >> that ICE connectivity checks happen even after candidates = are > > > > > >> nominated for the media session. An interface can be picked > > > > > >> based on the current path characteristics, continue with = ICE > > > > > >> checks on other interfaces or new interfaces discovered = later > > > > > >> and switch-over when a better candidate pair is available. > > > > > >> For more information refer to the discussion in mmusic WG > > > > > >> = (http://juberti.github.io/draughts/nombis/draft-uberti-mmusic > > > > > >> - > > nombis. > > > > > >> html) > > > > > > > > > > > > I do agree with Aijuns point that RFC5245 limits the = usability > > > > > > of this draft. But as you point out there is a lot of > > > > > > discussions going on regarding how we can improve ICE, not = all > > > > > > of those discussions are well known. To catch up, reading = the > > > > > > MMUSIC mailing-list is probably a good > > > > > idea. > > > > > > > > > > > > To make it easier to read the draft I would propose to do = the > > > > > > following in the next version. > > > > > > > > > > > > - Rename draft to =E2=80=9CRTT and loss measurements of STUN > > Transactions=E2=80=9D. > > > > > > Path characteristics seems to hint that other things like > > > > > > bandwidth and so on is also included. > > > > > > - Down play ICE usage. Focus on what a TRAM drafts should = focus on. > > > > > > (In this case provide RTT and loss information) > > > > > > > > > > > > > > > > > > The DISCUSS draft > > > > > > = (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt) > > > > > > also have the ability to provide useful information, but it > > > > > > requires support from the network to achieve this. > > > > > > > > > > > > > > > > > >> > > > > > >>> What would you do if it select one idle pair at first but = it > > > > > >>> become congest later? > > > > > >>> > > > > > >>> I think the dynamic path selection should be left to and = be > > > > > >>> considered by the application layer itself, such as RTCP > > > > > >>> protocol etc. > > > > > >> > > > > > >> In case of MPRTP, Path characteristics discovered using = ICE > > > > > >> will be used for picking the interface for the primary > > > > > >> sub-flow and interfaces for subsequent sub-flows and MPRTP > > > > > >> RTCP report can be used later for load balancing. > > > > > >> > > > > > > > > > > > > A short summary of my understanding of the MMUSIC ICE > > > > > > discussions > > is: > > > > > > - Use ICE to build a valid list > > > > > > - Redefined how we use that valid list. (Keeping pairs warm = so > > > > > > we can switch to them fast ++) > > > > > > - Redefine when and how we chose an active candidate pair to > > > > > > send media > > > > > on. > > > > > > > > > > > > .-. > > > > > > P=C3=A5l-Erik > > > > > > > > > > > >> -Tiru > > > > > >> > > > > > >>> > > > > > >>> Best Regards. > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Varun Singh [mailto:vsingh.ietf@gmail.com] > > > > > >>>> Sent: Wednesday, December 31, 2014 7:50 PM > > > > > >>>> To: Tirumaleswar Reddy (tireddy) > > > > > >>>> Cc: Simon Perreault; Brandon Williams; tram@ietf.org > > > > > >>>> ; Aijun Wang > > > > > >>>> Subject: Re: [tram] FW: New Version Notification for > > > > > >>>> draft-reddy-tram-stun-path-data-00.txt > > > > > >>>> > > > > > >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy > > > > > >>>> (tireddy) > > wrote: > > > > > >>>>> Inline [TR] > > > > > >>>>> On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams > > > > > >>>>> > > > > > > > > > > >>>>> wrote: > > > > > >>>>> > > > > > >>>>> You are correct that the currently published RFC makes = the > > > > > >>>>> path quality information harder to use in a meaningful = way. > > > > > >>>>> However, there is ongoing work in both tram and mmusic > > > > > >>>>> focused on allowing more dynamic path selection that can > > > > > >>>>> use performance metrics rather than the currently = defined > > > > > >>>>> static > > > priorities. > > > > > >>>>> This draft is just one piece of that > > > > > >>>> bigger picture. > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> You're right, of course, but if there's no way to make > > > > > >>>>> practical use of this draft with regular ICE, then = that's > > > > > >>>>> useful information that needs to go into the draft. > > > > > >>>>> Ideally with pointers to the bigger picture you > > > > > >>>> mentioned. > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> [TR] we will update the introduction section to make it = clear. > > > > > >>>>> This draft can be used with regular ICE when there is no > > > > > >>>>> noticeable impact in setting up the media session. It > > > > > >>>>> depends on the number of candidate pairs, time interval > > > > > >>>>> (Ta) for pacing ICE connectivity checks and > > > > > >>> RTO values. > > > > > >>>>> > > > > > >>>> > > > > > >>>> True. Path characteristics can be used in addition to the > > > > > >>>> proprietary criteria the endpoint currently implements. > > > > > >>>> i.e., if the endpoints wants to stop checking because it > > > > > >>>> met its defined criteria and was using the path > > > > > >>>> characteristics as part of the STUN messages, it could > > > > > >>>> still use the path characteristics for those candidates = to > > > > > >>>> make further > > > > > >>> decisions. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> -- > > > > > >>>> http://www.netlab.tkk.fi/~varun/ > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> tram mailing list > > > > > >>> tram@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/tram > > > > > >> > > > > > >> _______________________________________________ > > > > > >> tram mailing list > > > > > >> tram@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > > > > > > > -- > > > > > Brandon Williams; Senior Principal Software Engineer Emerging > > > > > Products Engineering; Akamai Technologies Inc. > > > > > > > > > > > > > > > > _______________________________________________ > > > > tram mailing list > > > > tram@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jan 7 03:15:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC461A1F1D for ; Wed, 7 Jan 2015 03:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Wdq8MovuykeG for ; Wed, 7 Jan 2015 03:15:01 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3977B1A0029 for ; Wed, 7 Jan 2015 03:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24436; q=dns/txt; s=iport; t=1420629301; x=1421838901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xpOeoedpvAchKUzIw1VcZE5JxhGgkbd9oYvV0lG2zmM=; b=fjqO+NywWAL5NbIboaYWGlvL1KEMNVBj+lTczbBe7OWi6jAIegIJq0ir y+JX7cYJpoy/z9OfWXntTbx0Ytoa4rOxLSi8f51ZTwcROAR9BpjM//HZo 9ZOWANdg/rFYq0PSWfFFOXP7y3/h10/P2QRNQxBdEmNl3AttS63N3ZdbB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFANoTrVStJA2L/2dsb2JhbABcFoJwUlgEgwLBCoIbCoVzAhxzQwEBAQEBfYQMAQEBBAEBAQsVETEJCQIMBAIBCBEEAQEBAgIGHQMCAgIfBgsUAQgIAQEEAQkEBQgTh30DEQ2ueo9cDYNaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiG2DQIFHCycWGwcGgmIugRMFji6DQ4N5glIwgj6CNIUdOgOFWiKDbm8BgQIFPX4BAQE X-IronPort-AV: E=Sophos;i="5.07,714,1413244800"; d="scan'208";a="111024997" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 07 Jan 2015 11:15:00 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t07BExLW016703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 11:14:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 05:14:59 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Aijun Wang , "'Brandon Williams'" , "Pal Martinsen (palmarti)" Thread-Topic: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAqRc5JVauEPU4HQy2EODKJPPZIcQAE3TkwAAFkNQA= Date: Wed, 7 Jan 2015 11:14:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552783E@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> In-Reply-To: <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4M-OR6gmUillfzf_7fPj4eKMdS0 Cc: 'Simon Perreault' , "tram@ietf.org" , 'Varun Singh' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 11:15:06 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiBTZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMDcsIDIwMTUgMzowNiBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KTsgJ0JyYW5kb24gV2lsbGlhbXMnOyBQYWwgTWFydGluc2VuDQo+IChwYWxtYXJ0aSkN Cj4gQ2M6ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOyAnVmFydW4gU2luZ2gnDQo+ IFN1YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1y ZWRkeS10cmFtLXN0dW4tcGF0aC0NCj4gZGF0YS0wMC50eHQNCj4gDQo+IEhpLCBSZWRkeToNCj4g DQo+IFBsZWFzZSBzZWUgdGhlIHJlcGx5IGlubGluZSBiZWxvdy4NCj4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGlydW1hbGVzd2FyDQo+IFJlZGR5DQo+ID4gKHRpcmVkZHkp DQo+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA3LCAyMDE1IDI6NDggUE0NCj4gPiBUbzog QWlqdW4gV2FuZzsgJ0JyYW5kb24gV2lsbGlhbXMnOyBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkN Cj4gPiBDYzogJ1NpbW9uIFBlcnJlYXVsdCc7IHRyYW1AaWV0Zi5vcmc7ICdWYXJ1biBTaW5naCcN Cj4gPiBTdWJqZWN0OiBSZTogW3RyYW1dIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4g PiBkcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KPiA+DQo+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFpanVuIFdhbmcNCj4gPiA+IFNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAwNywgMjAxNSAxMTowOSBBTQ0KPiA+ID4gVG86IFRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSk7ICdCcmFuZG9uIFdpbGxpYW1zJzsgUGFsIE1hcnRpbnNlbg0KPiA+ID4g KHBhbG1hcnRpKQ0KPiA+ID4gQ2M6ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOyAn VmFydW4gU2luZ2gnDQo+ID4gPiBTdWJqZWN0OiBSZTogW3RyYW1dIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCj4gPiA+IGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLSBkYXRhLTAwLnR4 dA0KPiA+ID4NCj4gPiA+IEhpLCBSZWRkeSwNCj4gPiA+DQo+ID4gPiBQbGVhc2Ugc2VlIHRoZSBy ZXBseSBpbmxpbmUuDQo+ID4gPg0KPiA+ID4gQmVzdCBSZWdhcmRzLg0KPiA+ID4NCj4gPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29tXQ0KPiA+ID4gPiBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDA2LCAyMDE1IDg6MjAgUE0NCj4gPiA+ID4gVG86IEFpanVuIFdhbmc7 ICdCcmFuZG9uIFdpbGxpYW1zJzsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpDQo+ID4gPiA+IENj OiAnU2ltb24gUGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgJ1ZhcnVuIFNpbmdoJw0KPiA+ID4g PiBTdWJqZWN0OiBSRTogW3RyYW1dIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiA+ ID4gZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCj4gPiA+ID4NCj4gPiA+ ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IHRyYW0gW21h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBaWp1biBXYW5nDQo+ID4g PiA+ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAwNiwgMjAxNSA5OjEzIEFNDQo+ID4gPiA+ID4g VG86ICdCcmFuZG9uIFdpbGxpYW1zJzsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBUaXJ1bWFs ZXN3YXINCj4gPiA+ID4gPiBSZWRkeQ0KPiA+ID4gPiA+ICh0aXJlZGR5KQ0KPiA+ID4gPiA+IENj OiAnU2ltb24gUGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgJ1ZhcnVuIFNpbmdoJw0KPiA+ID4g PiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ ID4gPiA+IGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLSBkYXRhLTAwLnR4dA0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gSGksIEFsbDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBkcmFmdCB0aGF0 IGdpdmVuIGJ5IFJlZGR5IGlsbHVzdHJhdGluZyBzb21lIGRyYXdiYWNrIG9mIHRoZQ0KPiA+ID4g PiA+IGN1cnJlbnQgSUNFIHNvbHV0aW9uKFJGQzUyNDUpLCBhbmQgYWN0dWFsbHkgcHJvdmlkZWQg YW5vdGhlcg0KPiA+ID4gPiA+IHBvc3NpYmxlIHNvbHV0aW9uIHRvIGltcHJvdmUgaXQuDQo+ID4g PiA+DQo+ID4gPiA+IElDRSByZWd1bGFyIGFuZCBhZ2dyZXNzaXZlIG5vbWluYXRpb24gaGF2ZSBj ZXJ0YWluIGRyYXdiYWNrcyB3aGljaA0KPiA+ID4gPiB3aWxsIGJlIGRlYWx0IGFzIHBhcnQgb2Yg SUNFIGNvbnRpbnVvdXMgbm9taW5hdGlvbiB3b3JrIGluIG1tdXNpYw0KPiA+ID4gPiBXRywgSUNF IGFsZ29yaXRobSBjaGFuZ2VzIHdpbGwgbm90IGJlIGNvdmVyZWQgaW4gdGhpcyBkcmFmdC4gTm90 ZQ0KPiA+ID4gPiB0aGF0IHRoaXMgZHJhZnQgY2FuIGFsc28gYmUgdXNlZCB3aXRoIHJlZ3VsYXIg SUNFIHdoZW4gdGhlcmUgaXMgbm8NCj4gPiA+ID4gbm90aWNlYWJsZSBpbXBhY3QgaW4gc2V0dGlu ZyB1cCB0aGUgbWVkaWEgc2Vzc2lvbiwgIEl0IGRlcGVuZHMgb24NCj4gPiA+ID4gdGhlIG51bWJl ciBvZiBjYW5kaWRhdGUgcGFpcnMsIHRpbWUgaW50ZXJ2YWwgZm9yIHBhY2luZyBJQ0UNCj4gPiA+ ID4gY29ubmVjdGl2aXR5IGNoZWNrcw0KPiA+ID4gYW5kIFJUTyB2YWx1ZXMuDQo+ID4gPiA+DQo+ ID4gPiA+ID4gSSBhZ3JlZSBhbHNvIHRoYXQgaXQgaXMgbmVjZXNzYXJ5IGZvciBJQ0UgdG8gY2hl Y2sgY29ubmVjdGl2aXR5DQo+ID4gPiA+ID4gY29udGludW91c2x5LCBidXQgc3RpbGwgaGVzaXRh dGUgdG8gYWdyZWUgYWRkIG1vcmUgYWRkaXRpb25hbA0KPiA+ID4gPiA+IGZ1bmN0aW9uIHRvIGl0 cyByb2xlKHN1Y2ggYXMgUlRULCBsb3NzIHJhdGUsIHBhdGhtdHUgZXRjLikuDQo+ID4gPiA+DQo+ ID4gPiA+IFdoeSA/DQo+ID4gPg0KPiA+ID4gVGhlIGZ1bmN0aW9ucyBmb3IgZGV0ZWN0aW5nIFJU VCwgbG9zcyByYXRlIGV0Yy4gYXJlIHVzZWZ1bCBidXQgbm90DQo+ID4gPiByZWxpYWJsZSBhbmQg ZGV0ZXJtaW5pc3RpYy4NCj4gPg0KPiA+IEl0IGRlcGVuZHMgaWYgdGhlIGNoZWNrcyBhcmUgZG9u ZSBvbmNlIG9yIHBlcmlvZGljYWxseS4NCj4g44CQQWlqdW7jgJE6IEV2ZW4gdGhlIGNoZWNrIGlz IHBlcmlvZGljYWwsIGl0cyByZXN1bHQgd2lsbCBiZSBpbmZsdWVuY2VkIGJ5IHRoZQ0KPiB0cmFm ZmljIG9mIHRoZSBhcHBsaWNhdGlvbiBkYXRhIGl0c2VsZi4gIEkgY2FuIGdpdmUgeW91IGFub3Ro ZXIgZXhhbXBsZSB0aGF0IHRoZQ0KPiBwYXRoIGNoYXJhY3RlcmlzdGljIGlzIHZhbHVhYmxlIGlu IHRoZW9yeSBidXQgbm90IHVzZWQgaW4gcHJhY3RpY2U6IElHUCBwcm90b2NvbA0KPiBzdWNoIGFz IE9TUEYgY29uc2lkZXJzIGl0cyBtZXRyaWMgdmFsdWUgZnJvbSBCYW5kd2lkdGgsIGRlbGF5LCBy ZWxpYWJpbGl0eSBhbmQNCj4gbG9hZGluZyB2YWx1ZSwgYnV0IGFjdHVhbGx5IHVzZSBvbmx5IEJh bmR3aWR0aC4gIFdpbGwgcGF0aC1jaGFyYWN0ZXJpc3RpYyBjaGVjaw0KPiB0cnkgdGhpcyBhZ2Fp bj8NCj4gDQo+ID4NCj4gPiA+IENhbiB5b3UgYXNzdXJlIHRoZSBhcHBsaWNhdGlvbnMgdGhhdCBy ZWxpZWQgb24gdGhlbSB3aWxsIGJlIG1vcmUNCj4gPiA+IGVmZmljaWVuY3kgYW5kIHJlbGlhYmxl PyBJIHByZWZlciB0byBwdXR0aW5nIGFsbCB1c2FibGUgaW50ZXJmYWNlcw0KPiA+ID4gaW50byBh IHBvb2wodmlhIElDRSBjb250aW51b3VzbHkgY2hlY2tpbmcgcHJvcG9zYWwpIGFuZCBnaXZlIG1v cmUNCj4gPiA+IGZsZXhpYmlsaXR5IHRvIHRoZSBhcHBsaWNhdGlvbi4gTW9yZSBkZXRlY3Rpb25z IGFuZCBkZWNpc2lvbiBjYW4gYmUNCj4gPiA+IG1hZGUgYnkgdGhlIHVwcGVyIGxheWVyLCBub3Qg dGhlIElDRSBpdHNlbGYuDQo+ID4NCj4gPiBUaGUgZGVjaXNpb24gbmVlZCBub3QgYmUgbWFkZSBi eSBJQ0UsIGl0IGNhbiBleHBvc2UgcGF0aCBtZXRyaWNzIGxpa2UgUlRULA0KPiA+IHBhY2tldCBs b3NzIHRvIHRoZSB1cHBlciBsYXllci4NCj4gDQo+IOOAkEFpanVu44CROiBUaGUgdXBwZXIgbGF5 ZXIgY2FuIGdldCBzdWNoIGluZm9ybWF0aW9uIHZpYSBpdHMgZGF0YSBzZW5kaW5nIGFuZA0KPiBy ZXNwb25kaW5nIG5hdHVyYWxseSBpbiByZWFsIHRpbWUuDQoNCklDRSBjYW4gaGVscHMgZ2V0IG1l dHJpY3MgYmVmb3JlIGRhdGEgaXMgc2VudC4NCg0KPiA+DQo+ID4NCj4gPiA+IFRoZXJlIGFyZSBv dGhlciBsYXJnZSBxdWVzdGlvbnMgZm9yIHRoZSBjb25uZWN0aXZpdHksIGZvciBleGFtcGxlLCB0 aGUNCj4gPiA+IE5BVCBwdW5jaGluZyBmb3IgdGhlIEJFSEFWRS1jb21wbGlhbnQgTkFUIGRldmlj ZXMgYW5kIG5vbg0KPiA+ID4gQkVIQVZFLWNvbXBsaWFudCBOQVQgZGV2aWNlcywgdGhlIHNlbGVj dGlvbiBvZiBhcHByb3ByaWF0ZSBUVVJOIHNlcnZlcg0KPiA+ID4gd2hlbiB0aGUgVFVSTiBzZXJ2 ZXIgYXJlIGRpc3RyaWJ1dGVkIGRlcGxveWVkLCB0aGUgY29tbXVuaWNhdGlvbg0KPiA+ID4gYmV0 d2VlbiBJUHY0IGVuZHBvaW50LA0KPiA+ID4gSVB2NC9JUHY2IGVuZHBvaW50IGFuZCBJUHY2IGVu ZHBvaW50IGV0Yy4gSSB0aGluayBJQ0Ugc2hvdWxkIGZvY3VzDQo+ID4gPiBtb3JlIG9uIHRoZSBz b2x1dGlvbiBvZiB0aGVzZSBjaGFsbGVuZ2VzLg0KPiA+DQo+ID4gSUNFIGFscmVhZHkgYWRkcmVz c2VzIE5BVCBhbmQgY29ubmVjdGl2aXR5IHByb2JsZW1zIGIvdyBlbmRwb2ludHMgd2l0aA0KPiA+ IGRpZmZlcmVudCBJUCBhZGRyZXNzIGZhbWlsaWVzLg0KPiANCj4g44CQQWlqdW7jgJE6IDEuIERv ZXMgY3VycmVudCBJQ0UgY29uc2lkZXIgdGhlIGNvbW11bmljYXRpb24gc2NlbmFyaW9zIHRoYXQN Cj4gb25lIElQdjQtb25seSBlbmRwb2ludCB3YW50cyB0byB0YWxrcyB0byBvbmUgSVB2Ni1vbmx5 IGVuZHBvaW50Pw0KPiAgICAgICAgICAyLiBDYW4gSUNFIHNvbHZlIHRoZSBUQ1AtTkFUIHRyYXZl cnNhbCBpbiBCRUhBVkUtY29tcGxpYW50IE5BVA0KPiBlbnZpcm9ubWVudCBpbiBvbmUgZGV0ZXJt aW5lZCBtYW5uZXIsIG5vdCB0aGUgcG9zc2libGUgc3VjY2VzcyByYXRlIHZpYQ0KPiB0cnlpbmcg ZXZlcnkgcGFpciBvZiBjaGVjayBsaXN0Pw0KPiAgICAgICAgICAzLiBEb2VzIElDRSBtZW50aW9u IGhvdyB0byBtYWtlIHN1cmUgdGhlIHJlbGF5ZWQgcGFja2V0IHRvIHBhc3MNCj4gdGhyb3VnaCB0 aGUgbm9uLUJFSEFWRS1jb21wbGlhbnQgTkFUIGRldmljZT8gRXNwZWNpYWxseSBmb3IgVENQIHBy b3RvY29sPw0KDQpJQ0UgY2FuIGVzdGFibGlzaCBjb21tdW5pY2F0aW9uIGIvdyBwZWVycyBpbiBh bGwgdGhlIGFib3ZlIHNjZW5hcmlvcy4gDQpUQ1AgY2FuZGlkYXRlcyB3aXRoIElDRSBpcyBleHBs YWluZWQgaW4gUkZDIDY1NDQuDQoNCj4gPg0KPiA+ID4NCj4gPiA+ID4gUGVyaW9kaWMgSUNFIGNv bm5lY3Rpdml0eSBjaGVja3MgZm9yIG1lZGlhIHN0cmVhbXMgZm9yIGNvbnNlbnQNCj4gPiA+ID4g ZnJlc2huZXNzIGlzIGFscmVhZHkgY292ZXJlZCBpbg0KPiA+ID4gPiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLQ0KPiA+ ID4gPiAxMQ0KPiA+ID4gPg0KPiA+ID4gSSB3YXMgYWxzbyBjdXJpb3VzIHRoYXQgaG93IHRoaXMg cHJvYmxlbSB0aGF0IG1lbnRpb25lZCBpbiB0aGlzIGRyYWZ0DQo+ID4gPiBpcyByYWlzZWQuIElm IHRoZSBjb3JyZXNwb25kaW5nIGVuZHBvaW50IGRvZXNuJ3Qgd2FudCB0byByZWNlaXZlIHRoZQ0K PiA+ID4gZGF0YSBmcm9tIG90aGVyIGVuZHBvaW50LCBpdCBuZWVkIGp1c3QgY2xvc2UgdGhlIFRD UC9VRFAgc2Vzc2lvbiB0aGF0DQo+ID4gPiBidWlsdCBieSBJQ0UgcHJvY2Vzcywgd2h5IHNob3Vs ZCB3ZSB1c2UgdGhlIGNvbnNlbnQgZnJlc2huZXNzIGNoZWNrPw0KPiA+DQo+ID4gQ29uc2VudCBm cmVzaG5lc3Mgd2lsbCBoZWxwIHRoZSBlbmRwb2ludCBkZXRlcm1pbmUgaWYgdGhlIHJlbW90ZSBw ZWVyIGlzDQo+ID4gaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgdGhlIHRyYWZmaWMgb3Igbm90Lg0K PiANCj4g44CQQWlqdW7jgJE6IFRoZXJlIGlzIG90aGVyIHN5c3RlbSB0byBtYWtlIHRoaXMgZGVj aXNpb24uIEZvciBleGFtcGxlLCBJZiBJIHdhbnQNCj4gdG8gdGFsayB0byB5b3UgdmlhIFNreXBl LCBJIHNob3VsZCBmaXJzdCBmaW5kIHlvdSBpbiBteSBTa3lwZSBjb250YWN0IGxpc3QsIGFuZA0K PiBtYWtlIGEgY2FsbCB0byB5b3UuIElmIHlvdSBhY2NlcHQgdGhlIGNhbGwsIHRoZSBJQ0UgcHJv Y2VzcyBmb3IgZGF0YSB0cmFuc2Zlcg0KPiB0aGVuIGJlZ2luLiBJZiB5b3UgZHJvcCB0aGUgY2Fs bCwgdGhlIElDRSBwcm9jZXNzIHdpbGwgYmUgdGVybWluYXRlZC4gSUNFIGl0c2VsZg0KPiBuZWVk cyBub3QgZG8gdGhlIGNvbnNlbnQgY2hlY2suDQoNCllvdSBtYXkgd2FudCB0byBnbyB0aHJvdWdo IHRoZSBkaXNjdXNzaW9ucyBpbiBydGN3ZWIgV0cgdG8gdW5kZXJzdGFuZCB0aGUgcmVhc29uIGZv ciBjb25zZW50IGZyZXNobmVzcy4NCg0KLVRpcnUNCg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+ ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBiZXR0ZXIgc29sdXRpb24gbWF5IGJlIHRvIGNo ZWNrIHRoZSBjb25uZWN0aXZpdHkgY29udGludW91c2x5LA0KPiA+ID4gPiA+IGVzcGVjaWFsbHkg Zm9yIHRoZSBuZXdseSB1cCBpbnRlcmZhY2UsIGJ1dCBvbmx5IGxpbWl0ZWQgdG8gdGhlDQo+ID4g PiA+ID4gY29ubmVjdGl2aXR5DQo+ID4gPiA+IGNoYXJhY3RlcmlzdGljLg0KPiA+ID4gPiA+IFRo ZSBhcHBsaWNhdGlvbiBsYXllciBzaG91bGQgYmFsYW5jZSBhbW9uZyB0aGVzZSBhdmFpbGFibGUN Cj4gPiA+ID4gPiBpbnRlcmZhY2VzIHRoYXQgZ2l2ZW4gYnkgSUNFLCB1c2luZyB0aGVpciBvd24g UlRULCBsb3NzIHJhdGUNCj4gPiA+ID4gPiBkZXRlY3Rpb24gYW5kIHBhdGgtbXR1IGZpbmRpbmcg c29sdXRpb24uIFRoaXMgY2FuIGFsc28gcmVkdWNlIHRoZQ0KPiA+ID4gPiA+IGxhdGVuY3kgb2Yg aW50ZXJmYWNlIHN3aXRjaGluZyBvZiB0aGUgZW5kcG9pbnQuDQo+ID4gPiA+DQo+ID4gPiA+IElD RSBjb250aW51b3VzIG5vbWluYXRpb24gYWxsb3dzIGNoZWNrcyBvbiBuZXcgaW50ZXJmYWNlcyBh bmQgdGhlDQo+ID4gPiA+IHBhdGggY2hhcmFjdGVyaXN0aWNzIGRpc2NvdmVyZWQgdXNpbmcgSUNF IGNhbiBiZSB1c2VkIHRvIHN3aXRjaC1vdmVyDQo+ID4gPiA+IHRoZSBtZWRpYSBzdHJlYW0gdG8g YSBuZXcgaW50ZXJmYWNlLiBJdCBpcyBkaXNjdXNzZWQgaW4NCj4gPiA+ID4gaHR0cDovL2p1YmVy dGkuZ2l0aHViLmlvL2RyYXVnaHRzL25vbWJpcy9kcmFmdC11YmVydGktbW11c2ljLW5vbWJpcy4N Cj4gPiA+ID4gaHQNCj4gPiA+ID4gbWwjc2UNCj4gPiA+ID4gY3Rpb24tMy4xDQo+ID4gPiA+DQo+ ID4gPiA+IC1UaXJ1DQo+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCZXN0IFJlZ2FyZHMu DQo+ID4gPiA+ID4gQWlqdW4gV2FuZy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IEJyYW5kb24gV2lsbGlhbXMgW21h aWx0bzpib3dpbGxAYWthbWFpLmNvbV0NCj4gPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgMDYsIDIwMTUgNzowOSBBTQ0KPiA+ID4gPiA+ID4gVG86IFBhbCBNYXJ0aW5zZW4gKHBhbG1h cnRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+ID4gPiA+ID4gQ2M6IEFpanVu IFdhbmc7IFZhcnVuIFNpbmdoOyBTaW1vbiBQZXJyZWF1bHQ7IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ ID4gPiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0K PiA+ID4gPiA+ID4gZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBIaSBQw6VsLUVyaWssDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gWW91IHdyb3RlOiBEb3duIHBsYXkgSUNFIHVzYWdlLiBGb2N1cyBvbiB3aGF0IGEgVFJBTSBk cmFmdHMNCj4gPiA+ID4gPiA+IHNob3VsZA0KPiA+ID4gPiA+IGZvY3VzIG9uLg0KPiA+ID4gPiA+ ID4gKEluIHRoaXMgY2FzZSBwcm92aWRlIFJUVCBhbmQgbG9zcyBpbmZvcm1hdGlvbikNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBJJ20gbm90IGNlcnRhaW4gZXhhY3RseSB3aGF0IHlvdSdyZSBs b29raW5nIGZvciBpbiB0aGUgdGV4dC4gSQ0KPiA+ID4gPiA+ID4gZG9uJ3QgcmVhbGx5IHNlZSBh IG1lYW5pbmdmdWwgdXNlIGNhc2UgZm9yIHRoZSBSVFQgYW5kIGxvc3MNCj4gPiA+ID4gPiA+IHN0 YXRzIG91dHNpZGUgb2YgdGhlIGVuZC10by1lbmQgY29udGV4dCBvZiB0aGUgSUNFIHVzZSBjYXNl LA0KPiA+ID4gPiA+ID4gc2luY2UgdXNpbmcgcGFydGlhbCBwYXRoIHN0YXRzIGZvciBkZWNpc2lv biBtYWtpbmcgd2lsbCBvZnRlbg0KPiA+ID4gPiA+ID4gZ2VuZXJhdGUgYmFkIHJlc3VsdHMuIERv IHlvdSBzZWUgYSB1c2UgY2FzZSBvdGhlciB0aGFuIElDRT8gT3INCj4gPiA+ID4gPiA+IGFyZSB5 b3Ugc2ltcGx5IHN1Z2dlc3RpbmcgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGF2b2lkDQo+ID4gPiA+ ID4gPiByZWZlcmVuY2luZyBhIHNwZWNpZmljIHVzZSBjYXNlDQo+ID4gPiBhbHRvZ2V0aGVyPw0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoYW5rcywNCj4gPiA+ID4gPiA+IC0tQnJhbmRvbg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPbiAwMS8wNS8yMDE1IDA0OjAx IEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgd3JvdGU6DQo+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+PiBPbiAwNSBKYW4gMjAxNSwgYXQgMDg6MjcsIFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkNCj4gPiA+ID4gPiA+ID4+IDx0aXJlZGR5QGNpc2NvLmNvbSA8bWFpbHRvOnRpcmVk ZHlAY2lzY28uY29tPj4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+Pj4gRnJvbTogdHJhbSBbbWFp bHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFpanVuDQo+ID4gPiA+ID4g PiA+Pj4gV2FuZw0KPiA+ID4gPiA+ID4gPj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAwNCwgMjAx NSA2OjEyIEFNDQo+ID4gPiA+ID4gPiA+Pj4gVG86ICdWYXJ1biBTaW5naCc7IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkNCj4gPiA+ID4gPiA+ID4+PiBDYzogJ1NpbW9uIFBlcnJlYXVsdCc7 IHRyYW1AaWV0Zi5vcmcgPG1haWx0bzp0cmFtQGlldGYub3JnPjsNCj4gPiA+ID4gPiA+ID4+PiAn QnJhbmRvbiBXaWxsaWFtcycNCj4gPiA+ID4gPiA+ID4+PiBTdWJqZWN0OiBSZTogW3RyYW1dIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPiA+ID4gPiA+Pj4gZHJhZnQtcmVk ZHktdHJhbS1zdHVuLQ0KPiA+ID4gPiA+ID4gPj4+IHBhdGgtZGF0YS0wMC50eHQNCj4gPiA+ID4g PiA+ID4+Pg0KPiA+ID4gPiA+ID4gPj4+IEhpLCBTaW5naCwgUmVkZHkgYW5kIFNpbW9uOg0KPiA+ ID4gPiA+ID4gPj4+DQo+ID4gPiA+ID4gPiA+Pj4gSSBhZG1pdHRlZCB0aGF0IHRoZSBwYXRoIGNo YXJhY3RlcmlzdGljIGNhbiBiZSBvbmUgZmFjdG9yIHRvDQo+ID4gPiA+ID4gPiA+Pj4gYmUgY29u c2lkZXJlZCBhbmQgY2FuIGJlIHVzZWQgdG8gYXNzaXN0IHRoZSBlbmRwb2ludHMgdG8NCj4gPiA+ ID4gPiA+ID4+PiBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIHBhdGguIFRoZSBtYWluIHBvaW50IG9m IHRoaXMgdmFsdWUNCj4gPiA+ID4gPiA+ID4+PiB0aGF0IGRpZmZlcmVudCBmcm9tIG90aGVyIGNy aXRlcmlhIGRlZmluZWQgaW4gUkZDNTI0NSBpcw0KPiA+ID4gPiA+ID4gPj4+IHRoYXQgdGhpcyB2 YWx1ZSB3aWxsIGJlIGNoYW5nZWQgZHluYW1pY2FsbHkgYW5kIGlzIG5vdA0KPiBkZXRlcm1pbmVk Lg0KPiA+ID4gPiA+ID4gPj4+IENvbnNpZGVyIHRoZSBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrIHdp bGwgYmUgb25seSBkb25lIG9uY2UNCj4gPiA+ID4gPiA+ID4+PiBmb3Igb25lIGNvbW11bmljYXRp b24gc2Vzc2lvbiwgaXMgaXQgYXBwcm9wcmlhdGUgZm9yIGl0IHRvDQo+ID4gPiA+ID4gPiA+Pj4g cmVseSBvbiBvbmUgdW5yZWxpYWJsZSB2YWx1ZSB0byBtYWtlIHRoZSBkZWNpc2lvbj8NCj4gPiA+ ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBObywgY29uc2VudCBmcmVzaG5lc3MgYW5kIElDRSBj b250aW51b3VzIG5vbWluYXRpb24gZXhwbGFpbg0KPiA+ID4gPiA+ID4gPj4gdGhhdCBJQ0UgY29u bmVjdGl2aXR5IGNoZWNrcyBoYXBwZW4gZXZlbiBhZnRlciBjYW5kaWRhdGVzIGFyZQ0KPiA+ID4g PiA+ID4gPj4gbm9taW5hdGVkIGZvciB0aGUgbWVkaWEgc2Vzc2lvbi4gQW4gaW50ZXJmYWNlIGNh biBiZSBwaWNrZWQNCj4gPiA+ID4gPiA+ID4+IGJhc2VkIG9uIHRoZSBjdXJyZW50IHBhdGggY2hh cmFjdGVyaXN0aWNzLCBjb250aW51ZSB3aXRoIElDRQ0KPiA+ID4gPiA+ID4gPj4gY2hlY2tzIG9u IG90aGVyIGludGVyZmFjZXMgb3IgbmV3IGludGVyZmFjZXMgZGlzY292ZXJlZCBsYXRlcg0KPiA+ ID4gPiA+ID4gPj4gYW5kIHN3aXRjaC1vdmVyIHdoZW4gYSBiZXR0ZXIgY2FuZGlkYXRlIHBhaXIg aXMgYXZhaWxhYmxlLg0KPiA+ID4gPiA+ID4gPj4gRm9yIG1vcmUgaW5mb3JtYXRpb24gcmVmZXIg dG8gdGhlIGRpc2N1c3Npb24gaW4gbW11c2ljIFdHDQo+ID4gPiA+ID4gPiA+PiAoaHR0cDovL2p1 YmVydGkuZ2l0aHViLmlvL2RyYXVnaHRzL25vbWJpcy9kcmFmdC11YmVydGktbW11c2ljDQo+ID4g PiA+ID4gPiA+PiAtDQo+ID4gPiBub21iaXMuDQo+ID4gPiA+ID4gPiA+PiBodG1sKQ0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJIGRvIGFncmVlIHdpdGggQWlqdW5zIHBvaW50IHRoYXQg UkZDNTI0NSBsaW1pdHMgdGhlIHVzYWJpbGl0eQ0KPiA+ID4gPiA+ID4gPiBvZiB0aGlzIGRyYWZ0 LiBCdXQgYXMgeW91IHBvaW50IG91dCB0aGVyZSBpcyBhIGxvdCBvZg0KPiA+ID4gPiA+ID4gPiBk aXNjdXNzaW9ucyBnb2luZyBvbiByZWdhcmRpbmcgaG93IHdlIGNhbiBpbXByb3ZlIElDRSwgbm90 IGFsbA0KPiA+ID4gPiA+ID4gPiBvZiB0aG9zZSBkaXNjdXNzaW9ucyBhcmUgd2VsbCBrbm93bi4g VG8gY2F0Y2ggdXAsIHJlYWRpbmcgdGhlDQo+ID4gPiA+ID4gPiA+IE1NVVNJQyBtYWlsaW5nLWxp c3QgaXMgcHJvYmFibHkgYSBnb29kDQo+ID4gPiA+ID4gPiBpZGVhLg0KPiA+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gPiBUbyBtYWtlIGl0IGVhc2llciB0byByZWFkIHRoZSBkcmFmdCBJIHdvdWxk IHByb3Bvc2UgdG8gZG8gdGhlDQo+ID4gPiA+ID4gPiA+IGZvbGxvd2luZyBpbiB0aGUgbmV4dCB2 ZXJzaW9uLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtIFJlbmFtZSBkcmFmdCB0byDi gJxSVFQgYW5kIGxvc3MgbWVhc3VyZW1lbnRzIG9mIFNUVU4NCj4gPiA+IFRyYW5zYWN0aW9uc+KA nS4NCj4gPiA+ID4gPiA+ID4gUGF0aCBjaGFyYWN0ZXJpc3RpY3Mgc2VlbXMgdG8gaGludCB0aGF0 IG90aGVyIHRoaW5ncyBsaWtlDQo+ID4gPiA+ID4gPiA+IGJhbmR3aWR0aCBhbmQgc28gb24gaXMg YWxzbyBpbmNsdWRlZC4NCj4gPiA+ID4gPiA+ID4gLSBEb3duIHBsYXkgSUNFIHVzYWdlLiBGb2N1 cyBvbiB3aGF0IGEgVFJBTSBkcmFmdHMgc2hvdWxkIGZvY3VzDQo+IG9uLg0KPiA+ID4gPiA+ID4g PiAoSW4gdGhpcyBjYXNlIHByb3ZpZGUgUlRUIGFuZCBsb3NzIGluZm9ybWF0aW9uKQ0KPiA+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGUgRElTQ1VTUyBkcmFmdA0K PiA+ID4gPiA+ID4gPiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1hcnRpbnNlbi10 cmFtLWRpc2N1c3MtMDEudHh0KQ0KPiA+ID4gPiA+ID4gPiBhbHNvIGhhdmUgdGhlIGFiaWxpdHkg dG8gcHJvdmlkZSB1c2VmdWwgaW5mb3JtYXRpb24sIGJ1dCBpdA0KPiA+ID4gPiA+ID4gPiByZXF1 aXJlcyBzdXBwb3J0IGZyb20gdGhlIG5ldHdvcmsgdG8gYWNoaWV2ZSB0aGlzLg0KPiA+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+PiBXaGF0 IHdvdWxkIHlvdSBkbyBpZiBpdCBzZWxlY3Qgb25lIGlkbGUgcGFpciBhdCBmaXJzdCBidXQgaXQN Cj4gPiA+ID4gPiA+ID4+PiBiZWNvbWUgY29uZ2VzdCBsYXRlcj8NCj4gPiA+ID4gPiA+ID4+Pg0K PiA+ID4gPiA+ID4gPj4+IEkgdGhpbmsgdGhlIGR5bmFtaWMgcGF0aCBzZWxlY3Rpb24gc2hvdWxk IGJlIGxlZnQgdG8gYW5kIGJlDQo+ID4gPiA+ID4gPiA+Pj4gY29uc2lkZXJlZCBieSB0aGUgYXBw bGljYXRpb24gbGF5ZXIgaXRzZWxmLCBzdWNoIGFzIFJUQ1ANCj4gPiA+ID4gPiA+ID4+PiBwcm90 b2NvbCBldGMuDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPj4gSW4gY2FzZSBvZiBNUFJU UCwgIFBhdGggY2hhcmFjdGVyaXN0aWNzIGRpc2NvdmVyZWQgdXNpbmcgSUNFDQo+ID4gPiA+ID4g PiA+PiB3aWxsIGJlIHVzZWQgZm9yIHBpY2tpbmcgdGhlIGludGVyZmFjZSBmb3IgdGhlIHByaW1h cnkNCj4gPiA+ID4gPiA+ID4+IHN1Yi1mbG93IGFuZCBpbnRlcmZhY2VzIGZvciBzdWJzZXF1ZW50 IHN1Yi1mbG93cyBhbmQgTVBSVFANCj4gPiA+ID4gPiA+ID4+IFJUQ1AgcmVwb3J0IGNhbiBiZSB1 c2VkIGxhdGVyIGZvciBsb2FkIGJhbGFuY2luZy4NCj4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+IEEgc2hvcnQgc3VtbWFyeSBvZiBteSB1bmRlcnN0YW5kaW5nIG9m IHRoZSBNTVVTSUMgSUNFDQo+ID4gPiA+ID4gPiA+IGRpc2N1c3Npb25zDQo+ID4gPiBpczoNCj4g PiA+ID4gPiA+ID4gLSBVc2UgSUNFIHRvIGJ1aWxkIGEgdmFsaWQgbGlzdA0KPiA+ID4gPiA+ID4g PiAtIFJlZGVmaW5lZCBob3cgd2UgdXNlIHRoYXQgdmFsaWQgbGlzdC4gKEtlZXBpbmcgcGFpcnMg d2FybSBzbw0KPiA+ID4gPiA+ID4gPiB3ZSBjYW4gc3dpdGNoIHRvIHRoZW0gZmFzdCArKykNCj4g PiA+ID4gPiA+ID4gLSBSZWRlZmluZSB3aGVuIGFuZCBob3cgd2UgY2hvc2UgYW4gYWN0aXZlIGNh bmRpZGF0ZSBwYWlyIHRvDQo+ID4gPiA+ID4gPiA+IHNlbmQgbWVkaWENCj4gPiA+ID4gPiA+IG9u Lg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAuLS4NCj4gPiA+ID4gPiA+ID4gUMOlbC1F cmlrDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+PiAtVGlydQ0KPiA+ID4gPiA+ID4gPj4N Cj4gPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4gPj4+IEJlc3QgUmVnYXJkcy4NCj4gPiA+ID4g PiA+ID4+Pg0KPiA+ID4gPiA+ID4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gPiA+ID4gPj4+PiBGcm9tOiBWYXJ1biBTaW5naCBbbWFpbHRvOnZzaW5naC5pZXRmQGdtYWls LmNvbV0NCj4gPiA+ID4gPiA+ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAzMSwgMjAx NCA3OjUwIFBNDQo+ID4gPiA+ID4gPiA+Pj4+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpDQo+ID4gPiA+ID4gPiA+Pj4+IENjOiBTaW1vbiBQZXJyZWF1bHQ7IEJyYW5kb24gV2lsbGlh bXM7IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ID4+Pj4gPG1haWx0bzp0cmFtQGlldGYub3Jn PjsgQWlqdW4gV2FuZw0KPiA+ID4gPiA+ID4gPj4+PiBTdWJqZWN0OiBSZTogW3RyYW1dIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPiA+ID4gPiA+Pj4+IGRyYWZ0LXJlZGR5 LXRyYW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0DQo+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4g PiA+Pj4+IE9uIFdlZCwgRGVjIDMxLCAyMDE0IGF0IDg6MTkgQU0sIFRpcnVtYWxlc3dhciBSZWRk eQ0KPiA+ID4gPiA+ID4gPj4+PiAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tIDxtYWlsdG86 dGlyZWRkeUBjaXNjby5jb20+Pg0KPiA+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPj4+Pj4gSW5saW5l IFtUUl0NCj4gPiA+ID4gPiA+ID4+Pj4+IE9uIFR1ZSwgRGVjIDMwLCAyMDE0IGF0IDk6MzEgQU0s IEJyYW5kb24gV2lsbGlhbXMNCj4gPiA+ID4gPiA+ID4+Pj4+IDxicmFuZG9uLndpbGxpYW1zQGFr YW1haS5jb20NCj4gPiA+ID4gPiA+IDxtYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29t Pj4NCj4gPiA+ID4gPiA+ID4+Pj4+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4g PiA+ID4+Pj4+IFlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBjdXJyZW50bHkgcHVibGlzaGVkIFJG QyBtYWtlcyB0aGUNCj4gPiA+ID4gPiA+ID4+Pj4+IHBhdGggcXVhbGl0eSBpbmZvcm1hdGlvbiBo YXJkZXIgdG8gdXNlIGluIGEgbWVhbmluZ2Z1bCB3YXkuDQo+ID4gPiA+ID4gPiA+Pj4+PiBIb3dl dmVyLCB0aGVyZSBpcyBvbmdvaW5nIHdvcmsgaW4gYm90aCB0cmFtIGFuZCBtbXVzaWMNCj4gPiA+ ID4gPiA+ID4+Pj4+IGZvY3VzZWQgb24gYWxsb3dpbmcgbW9yZSBkeW5hbWljIHBhdGggc2VsZWN0 aW9uIHRoYXQgY2FuDQo+ID4gPiA+ID4gPiA+Pj4+PiB1c2UgcGVyZm9ybWFuY2UgbWV0cmljcyBy YXRoZXIgdGhhbiB0aGUgY3VycmVudGx5IGRlZmluZWQNCj4gPiA+ID4gPiA+ID4+Pj4+IHN0YXRp Yw0KPiA+ID4gPiBwcmlvcml0aWVzLg0KPiA+ID4gPiA+ID4gPj4+Pj4gVGhpcyBkcmFmdCBpcyBq dXN0IG9uZSBwaWVjZSBvZiB0aGF0DQo+ID4gPiA+ID4gPiA+Pj4+IGJpZ2dlciBwaWN0dXJlLg0K PiA+ID4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+PiBZ b3UncmUgcmlnaHQsIG9mIGNvdXJzZSwgYnV0IGlmIHRoZXJlJ3Mgbm8gd2F5IHRvIG1ha2UNCj4g PiA+ID4gPiA+ID4+Pj4+IHByYWN0aWNhbCB1c2Ugb2YgdGhpcyBkcmFmdCB3aXRoIHJlZ3VsYXIg SUNFLCB0aGVuIHRoYXQncw0KPiA+ID4gPiA+ID4gPj4+Pj4gdXNlZnVsIGluZm9ybWF0aW9uIHRo YXQgbmVlZHMgdG8gZ28gaW50byB0aGUgZHJhZnQuDQo+ID4gPiA+ID4gPiA+Pj4+PiBJZGVhbGx5 IHdpdGggcG9pbnRlcnMgdG8gdGhlIGJpZ2dlciBwaWN0dXJlIHlvdQ0KPiA+ID4gPiA+ID4gPj4+ PiBtZW50aW9uZWQuDQo+ID4gPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+ID4gPj4+Pj4NCj4gPiA+ ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+PiBbVFJdIHdlIHdpbGwgdXBkYXRlIHRoZSBp bnRyb2R1Y3Rpb24gc2VjdGlvbiB0byBtYWtlIGl0IGNsZWFyLg0KPiA+ID4gPiA+ID4gPj4+Pj4g VGhpcyBkcmFmdCBjYW4gYmUgdXNlZCB3aXRoIHJlZ3VsYXIgSUNFIHdoZW4gdGhlcmUgaXMgbm8N Cj4gPiA+ID4gPiA+ID4+Pj4+IG5vdGljZWFibGUgaW1wYWN0IGluIHNldHRpbmcgdXAgdGhlIG1l ZGlhIHNlc3Npb24uIEl0DQo+ID4gPiA+ID4gPiA+Pj4+PiBkZXBlbmRzIG9uIHRoZSBudW1iZXIg b2YgY2FuZGlkYXRlIHBhaXJzLCB0aW1lIGludGVydmFsDQo+ID4gPiA+ID4gPiA+Pj4+PiAoVGEp IGZvciBwYWNpbmcgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5kDQo+ID4gPiA+ID4gPiA+Pj4g UlRPIHZhbHVlcy4NCj4gPiA+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ ID4gPiA+Pj4+IFRydWUuIFBhdGggY2hhcmFjdGVyaXN0aWNzIGNhbiBiZSB1c2VkIGluIGFkZGl0 aW9uIHRvIHRoZQ0KPiA+ID4gPiA+ID4gPj4+PiBwcm9wcmlldGFyeSBjcml0ZXJpYSB0aGUgZW5k cG9pbnQgY3VycmVudGx5IGltcGxlbWVudHMuDQo+ID4gPiA+ID4gPiA+Pj4+IGkuZS4sIGlmIHRo ZSBlbmRwb2ludHMgd2FudHMgdG8gc3RvcCBjaGVja2luZyBiZWNhdXNlIGl0DQo+ID4gPiA+ID4g PiA+Pj4+IG1ldCBpdHMgZGVmaW5lZCBjcml0ZXJpYSBhbmQgd2FzIHVzaW5nIHRoZSBwYXRoDQo+ ID4gPiA+ID4gPiA+Pj4+IGNoYXJhY3RlcmlzdGljcyBhcyBwYXJ0IG9mIHRoZSBTVFVOIG1lc3Nh Z2VzLCBpdCBjb3VsZA0KPiA+ID4gPiA+ID4gPj4+PiBzdGlsbCB1c2UgdGhlIHBhdGggY2hhcmFj dGVyaXN0aWNzIGZvciB0aG9zZSBjYW5kaWRhdGVzIHRvDQo+ID4gPiA+ID4gPiA+Pj4+IG1ha2Ug ZnVydGhlcg0KPiA+ID4gPiA+ID4gPj4+IGRlY2lzaW9ucy4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4g PiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPiA+ID4+Pj4gLS0NCj4g PiA+ID4gPiA+ID4+Pj4gaHR0cDovL3d3dy5uZXRsYWIudGtrLmZpL352YXJ1bi8NCj4gPiA+ID4g PiA+ID4+Pg0KPiA+ID4gPiA+ID4gPj4+DQo+ID4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+ID4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g PiA+ID4gPj4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiA+Pj4gdHJhbUBpZXRmLm9y ZyA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQo+ID4gPiA+ID4gPiA+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ ID4gPiA+ID4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiA+PiB0cmFtQGlldGYub3Jn IDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4gPiA+ID4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4gPiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNp cGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5nDQo+ID4gPiA+ID4gPiBQcm9kdWN0cyBFbmdp bmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+ID4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IHRyYW1A aWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+ID4g dHJhbUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4gDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5n IGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyYW0NCg== From nobody Wed Jan 7 05:56:49 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B050B1A8AF3 for ; Wed, 7 Jan 2015 05:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 6kBzkT-tgPq2 for ; Wed, 7 Jan 2015 05:56:45 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F336D1A8AE3 for ; Wed, 7 Jan 2015 05:56:35 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so3581649lab.1 for ; Wed, 07 Jan 2015 05:56:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7Bcy6orL3yTblnY9rDz9MbrF5JEwhpK2KIfYLMCIqck=; b=Ivy60RcNftSDmIxyjMCVO149wZeQ5W53yo50GMaqc42VAtoh/8fYyJdBsY+dbUk06q ywedNT9UEq0rn2EFtfYF6hxw7cIJ5/QOVGtYtMgxBU8fRBFNOl5+UerjYVKvQxg0vDCD C0ajKAuIIq/XdIzPB56PaW6pKCgd/ullwLwe7ItDP95rQBhmbXxyu1KoYJKODv1NTKVY /OREd9fZEyDlIyMIqhfo5xa7sAkOcWTYpAA6Knr80uMjNCxJUbJm2d5+GBN4EeL5HFbv sjZCB12QNyqFX7NnOrxm4O7Emvj1PTyYmTUtlwO61M21BUB9Vibn7P7G9sIbHccBdgAp ysVA== X-Gm-Message-State: ALoCoQl2BJQyBwU+4MoI6LYyHOUciQMJ0GyCEnvSVJRKMBi9Q4PZzr4iK9jjfq6V27/aPRQwMFYH MIME-Version: 1.0 X-Received: by 10.152.42.169 with SMTP id p9mr4745347lal.94.1420638993927; Wed, 07 Jan 2015 05:56:33 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 7 Jan 2015 05:56:33 -0800 (PST) In-Reply-To: <00a501d02a3e$d7bcd4c0$87367e40$@org.cn> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <00a501d02a3e$d7bcd4c0$87367e40$@org.cn> Date: Wed, 7 Jan 2015 08:56:33 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=001a11c3507c9667ce050c104a83 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lOBVL-fr_Fcu-EE45thxODLkhso Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 13:56:48 -0000 --001a11c3507c9667ce050c104a83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 7, 2015 at 12:57 AM, Aijun Wang wrote: > 1. Is it possible for two peers to select different Relay Server to > communicate? > > > > It's already possible with today's ICE, without this draft. Or do you mea= n > something else? > > > > =E3=80=90Aijun=E3=80=91: in http://datatracker.ietf.org/doc/draft-ietf-tr= am-turnbis/, it > described only the process that the communication endpoints under one sam= e > TURN server. The process for endpoints that under different TURN server i= s > not mentioned and is complex if we allow it happen. > On the contrary, things would be more complex if we tried to disallow it. > If so, will the communication channel between the Relay Server > will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure t= wo > peers select the same Relay Server? > > > > Why would it be necessary that the two peers select the same server? > > > > =E3=80=90Aijun=E3=80=91: To simplify the realization of TURN process. > Sorry, I don't see how enforcing that would simplify anything. It would be nice if it just happened because it would eliminate a leg and the TURN server could apply hairpinning optimization, but from a protocol point of view it would be exactly the same thing. Enforcing that this always happen would actually make the protocol more complex. > Two questions: > > 1. How do we encapsulate the application data between the TURN servers? > Using the =E2=80=9CChannelData Message=E2=80=9D or using pure UDP message= ? > Per the TURN spec it would be pure UDP. Each TURN server would not know it is talking to another TURN server. > 2. how about the TCP communication channel between two TURN servers? > Assuming you mean RFC 6062, it would be pure TCP. Each TURN server would not know it is talking to another TURN server. Simon --001a11c3507c9667ce050c104a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 7, 2015 at 12:57 AM, Aijun Wang <wangaijun@tsinghua.= org.cn> wrote:

1. Is it po= ssible for two peers to select different Relay Server to
communicate?=

=C2=A0

It's already possible with today's ICE, without this d= raft. Or do you mean something else?

<= div>

=C2=A0=

= =E3=80=90Aijun=E3=80=91: in http://datatracker.ietf.org/doc/d= raft-ietf-tram-turnbis/, it described only the process that the communi= cation endpoints under one same TURN server. The process for endpoints that= under different TURN server is not mentioned and is complex if we allow it= happen.


On th= e contrary, things would be more complex if we tried to disallow it.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

If so, will the communication channel between the Relay Server
will b= e changed by the CHECK-ALTERNATE attribute? If not, how to ensure two
pe= ers select the same Relay Server?

=C2=A0

Why would it = be necessary that the two peers select the same server?

=C2=A0

=E3=80=90Aijun=E3=80=91: To simplify the realization of TURN proc= ess.


Sorry, I don't se= e how enforcing that would simplify anything. It would be nice if it just h= appened because it would eliminate a leg and the TURN server could apply ha= irpinning optimization, but from a protocol point of view it would be exact= ly the same thing. Enforcing that this always happen would actually make th= e protocol more complex.
=C2=A0

T= wo questions:

1. How do we encapsulate the application data b= etween the TURN servers? Using the =E2=80=9CChannelData Message=E2=80=9D or= using pure UDP message?


P= er the TURN spec it would be pure UDP. Each TURN server would not know it i= s talking to another TURN server.
=C2=A0

2. how about the TCP communication channel between= two TURN servers?


Assuming you mean= RFC 6062, it would be pure TCP. Each TURN server would not know it is talk= ing to another TURN server.

Simon
--001a11c3507c9667ce050c104a83-- From nobody Wed Jan 7 06:22:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E17C1A9037 for ; Wed, 7 Jan 2015 06:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 aLSunI-er61S for ; Wed, 7 Jan 2015 06:22:05 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F29D1A9031 for ; Wed, 7 Jan 2015 06:22:04 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so3728517lab.1 for ; Wed, 07 Jan 2015 06:22:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RFvBEQfozPWmsK2Qcuz1FExpBZu503oAANg7yKxFHZk=; b=Gf6zevjo3LR1X2fzys+pa2Uofkv6Ksdu8/QJcBuTf+CrJLFVdJ2iWNOfJsThLX2Olu fJMGfFa8dDVTppbsV+15jsLgn24XcWztrIzzm86vvTN6MEdfxTjlhUJJcZhscFXrsoVt KSnrfMITaAmRgs7RB8OdD6cGOGtvlDp0Wx+0zhSmiJymlvD/vKRNBo5ipB05JcUT84gI ondXHS2FlQkkv/9YwAtHg3BEtKCjZ+yHl/Nk1Nix8M4ZrJa4O1JoGRU2enzXKMzMBgrx 7tt0gMRHuwZRYG/L6kvinuyoMC84t1Zk+EGNFqJFHSS7RqzwtkUffETrNCJxZs4cgesS PL2g== X-Gm-Message-State: ALoCoQnefjaVcy6ZZrItVakh9gqKsYXiPsgT6Agf5x0SmOMb52BcUC1PPJU3yN+7Idgc98aGGJvh MIME-Version: 1.0 X-Received: by 10.112.159.136 with SMTP id xc8mr4944178lbb.98.1420640522857; Wed, 07 Jan 2015 06:22:02 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 7 Jan 2015 06:22:02 -0800 (PST) In-Reply-To: <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> References: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> Date: Wed, 7 Jan 2015 09:22:02 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=001a11c3dbacb80b07050c10a5bb Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7FJZxTUlGqGvUdr9RDI8FCizgxw Cc: "Pal Martinsen \(palmarti\)" , Varun Singh , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:22:12 -0000 --001a11c3dbacb80b07050c10a5bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 7, 2015 at 4:36 AM, Aijun Wang wrote: > > > Can you assure the applications that relied on them will be more > > > efficiency and reliable? I prefer to putting all usable interfaces > > > into a pool(via ICE continuously checking proposal) and give more > > > flexibility to the application. More detections and decision can be > > > made by the upper layer, not the ICE itself. > > > > The decision need not be made by ICE, it can expose path metrics like > RTT, > > packet loss to the upper layer. > > =E3=80=90Aijun=E3=80=91: The upper layer can get such information via its= data sending and > responding naturally in real time. > But how would that work? Assuming the upper layer is RTP, and you want to modify it so that it measures path RTTs. Wouldn't that enhanced RTP upper layer then make use of this draft to make its measurements? What alternative are you concretely proposing? > =E3=80=90Aijun=E3=80=91: 1. Does current ICE consider the communication s= cenarios that one > IPv4-only endpoint wants to talks to one IPv6-only endpoint? > Yes. [RFC6156] > 2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT > environment in one determined manner, not the possible success rate via > trying every pair of check list? > I don't understand what you mean. If the NAT is BEHAVE-compliant, then ICE will pick the STUN candidate. What is missing? > 3. Does ICE mention how to make sure the relayed packet to pass > through the non-BEHAVE-compliant NAT device? Especially for TCP protocol? > I don't understand what you mean. Can you be more specific? Perhaps illustrate with an example? > > > > Periodic ICE connectivity checks for media streams for consent > > > > freshness is already covered in > > > > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness= - > > > > 11 > > > > > > > I was also curious that how this problem that mentioned in this draft > > > is raised. If the corresponding endpoint doesn't want to receive the > > > data from other endpoint, it need just close the TCP/UDP session that > > > built by ICE process, why should we use the consent freshness check? > > > > Consent freshness will help the endpoint determine if the remote peer i= s > > interested in receiving the traffic or not. > > =E3=80=90Aijun=E3=80=91: There is other system to make this decision. For= example, If I > want to talk to you via Skype, I should first find you in my Skype contac= t > list, and make a call to you. If you accept the call, the ICE process for > data transfer then begin. If you drop the call, the ICE process will be > terminated. ICE itself needs not do the consent check. Here's a tip... You obviously don't understand why consent checks are needed. Fine. Maybe we're all wrong and consent checks are not needed. But instead of asking questions you try to argue. Not fine. If you ask questions we can try to help you understand, and if we're all wrong our answers will make it obvious to everyone. If instead you try to argue I'm afraid you will just get ignored. Ask more, assert less. Simon --001a11c3dbacb80b07050c10a5bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 7, 2015 at 4:36 AM, Aijun Wang <wangaijun@tsinghua.org= .cn> wrote:
> > Can you assure the applications that relied on them will be mor= e
> > efficiency and reliable? I prefer to putting all usable interface= s
> > into a pool(via ICE continuously checking proposal) and give more=
> > flexibility to the application. More detections and decision can = be
> > made by the upper layer, not the ICE itself.
>
> The decision need not be made by ICE, it can expose path metrics like = RTT,
> packet loss to the upper layer.

=E3=80=90Aijun=E3=80=91: The upper layer can get such information vi= a its data sending and responding naturally in real time.
<= div>
But how would that work? Assuming the upper layer is RTP= , and you want to modify it so that it measures path RTTs. Wouldn't tha= t enhanced RTP upper layer then make use of this draft to make its measurem= ents? What alternative are you concretely proposing?
=C2=A0
=
=E3=80=90Aijun=E3=80=91: 1. Does current ICE= consider the communication scenarios that one IPv4-only endpoint wants to = talks to one IPv6-only endpoint?

Yes. [= RFC6156]
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Can ICE solve the TCP-NAT traversal in= BEHAVE-compliant NAT environment in one determined manner, not the possibl= e success rate via trying every pair of check list?
I don't understand what you mean. If the NAT is BEHAVE-com= pliant, then ICE will pick the STUN candidate. What is missing?
= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Does ICE mention how to make sure the = relayed packet to pass through the non-BEHAVE-compliant NAT device? Especia= lly for TCP protocol?

I don't under= stand what you mean. Can you be more specific? Perhaps illustrate with an e= xample?
=C2=A0
> > > Periodic ICE connectivity checks for media streams for co= nsent
> > > freshness is already covered in
> > > http://tools.ietf.org/html/draft-iet= f-rtcweb-stun-consent-freshness-
> > > 11
> > >
> > I was also curious that how this problem that mentioned in this d= raft
> > is raised. If the corresponding endpoint doesn't want to rece= ive the
> > data from other endpoint, it need just close the TCP/UDP session = that
> > built by ICE process, why should we use the consent freshness che= ck?
>
> Consent freshness will help the endpoint determine if the remote peer = is
> interested in receiving the traffic or not.

=E3=80=90Aijun=E3=80=91: There is other system to make this decision= . For example, If I want to talk to you via Skype, I should first find you = in my Skype contact list, and make a call to you. If you accept the call, t= he ICE process for data transfer then begin. If you drop the call, the ICE = process will be terminated. ICE itself needs not do the consent check.

Here's a tip...

<= /div>
You obviously don't understand why cons= ent checks are needed. Fine. Maybe we're all wrong and consent checks a= re not needed. But instead of asking questions you try to argue. Not fine. = If you ask questions we can try to help you understand, and if we're al= l wrong our answers will make it obvious to everyone. If instead you try to= argue I'm afraid you will just get ignored.

Ask more, assert less.

Simon
--001a11c3dbacb80b07050c10a5bb-- From nobody Wed Jan 7 13:35:22 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E331A6F3D for ; Wed, 7 Jan 2015 13:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IzMIsZXJvaWP for ; Wed, 7 Jan 2015 13:35:18 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1628D1A6EE4 for ; Wed, 7 Jan 2015 13:35:17 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C7C67284EF; Wed, 7 Jan 2015 21:35:16 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A5774284E8; Wed, 7 Jan 2015 21:35:16 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A1A852029; Wed, 7 Jan 2015 21:35:16 +0000 (GMT) Message-ID: <54ADA694.9010300@akamai.com> Date: Wed, 07 Jan 2015 16:35:16 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aijun Wang , "tram@ietf.org" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> In-Reply-To: <003401d02978$21689220$6439b660$@org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9HrGCv7ey3GBPJzClZT1OMdA3AY Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:35:20 -0000 see [bw] inline On 01/06/2015 01:14 AM, Aijun Wang wrote: > Hi, Brandon. > > I read your draft just and wants to ask you some question for clarification: > 1. Is it possible for two peers to select different Relay Server to > communicate? If so, will the communication channel between the Relay Server > will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure two > peers select the same Relay Server? [bw] Yes, they can select different relay servers. The mechanism doesn't add any new restriction in that regard, nor does it changes the communication channel between the servers (there's no need for that). Basically, redirect would end up providing a new relay candidate and there's some ongoing work in mmusic that will help ICE to make more effective use of the new relay candidate. > 2. Is it better for ICE server to determine the appropriate Relay Server for > two peers at the beginning of ICE connectivity check? The determination > process can be based on information such as the load status of each Relay > Server, the link usage of its interfaces and the proximity of two > peers(based solely on the reflex-address of each peer). [bw] I'm not sure what you're getting at here. The 3rd party relay system has the necessary information to determine whether a redirect would be beneficial, so why would it make sense for something else to make that determination? > > Best Regards. > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Tuesday, December 30, 2014 6:04 AM >> To: tram@ietf.org >> Subject: [tram] Fwd: New Version Notification for >> draft-williams-peer-redirect-02.txt >> >> Hi all, >> >> I've just updated the peer redirect draft to provide the warning labels > that Ted >> asked for back in Toronto. I also added brief discussion of a load > balancing use >> case when adding a new flow to an existing allocation. >> >> There's some work going on both here and in mmusic related to ICE that can >> help provide a framework for making more effective use of this redirection >> capability. >> >> I hope that there might be enough interest in this draft for WG adoption > and >> would like to hear thoughts on that from the list. >> >> Thanks, >> --Brandon >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-williams-peer-redirect-02.txt >> Date: Mon, 29 Dec 2014 16:53:47 -0500 >> From: internet-drafts@ietf.org >> To: Williams, Brandon , Tirumaleswar Reddy >> , Tirumaleswar Reddy , Williams, >> Brandon >> >> >> A new version of I-D, draft-williams-peer-redirect-02.txt >> has been successfully submitted by Brandon Williams and posted to the IETF >> repository. >> >> Name: draft-williams-peer-redirect >> Revision: 02 >> Title: Peer-specific Redirection for Traversal Using Relays > around NAT >> (TURN) >> Document date: 2014-12-29 >> Group: Individual Submission >> Pages: 13 >> URL: >> http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ >> Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 >> >> Abstract: >> This specification describes a peer-specific redirection method that >> allows the TURN server to redirect a client for the purpose of >> improving communication with a specific peer without negatively >> affecting communication with other peers. >> >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Jan 7 17:06:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A728D1A87D9 for ; Wed, 7 Jan 2015 17:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 YEhyLlcNxf4M for ; Wed, 7 Jan 2015 17:06:09 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419021A87D5 for ; Wed, 7 Jan 2015 17:06:09 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so204329vcb.11 for ; Wed, 07 Jan 2015 17:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HMQ2ntKdUXdGPcWiAqHKN2wFm2yN5iZvqbtfgk4raq4=; b=MlJ+DZSxwVM7aPMLVbqTMqTgWhKsiLs82VBxVy0qUiFHs6VQyqdKeagHPkl7VNDSSY hv7jB2qfx6YKtgHMLgrYcXo3Md9mi28RlI5gDW1o1e/KSa5Nw7xvjYDqLOvgsmTeQ3NW 43aOYckXjIYPFDvwKhFY2I40Q/jZklp0KPk1/FFBsboWo1E3D0enII8jkvX3OhMQe8L5 1ImOgEoaAgOGBf9fRhg/KJmUgyGdzLFJx7OcgKqUonHmug6BHjvSzssflEdA0dAfNTCl uBHFHq8FbTptT1xTWnMuFJ9SFNtT2dJI5g2weGuhjvJdl6O9wB6Lcb/EmURU5yA4f+8y wG+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HMQ2ntKdUXdGPcWiAqHKN2wFm2yN5iZvqbtfgk4raq4=; b=UfHi1xBJYgsen4BBdD0lBwtkwY9hN8Q95OdYWc7AOsWcn6AOp6zdqT73DYfFEbqilT oPqUDDu8iNyoMSpFa8bqyj3d1ETZg19mqWXyqyUyy+lQmijPxOXh0/qoLg/IMQtYVT2R 7KrIpAZBvvxbitNJRmGlkCJxsO1FDMw3BNdmkzNXnugyMaZe3UxYxZYdFEf8LtIclsJ4 mSn9NyvotOfHy5CJqaO2JqmPIaXwhIFMIlEnGBeP5ZCt77AQiBedr7GG88zDh1CRtAKa 3ixoR4LXWA8u3pOGrMtThgNcdeqKqX31IoFXlRWImHuSy844/c4WJ4b8z7ihrJizjWSj /zeA== X-Gm-Message-State: ALoCoQmEOHRBogaFsIAcYPcSD91kZlnH64ZMazW+9XSAaoEj0uu0WB6kVi9NOhAUV/TWClOGktjv X-Received: by 10.52.190.40 with SMTP id gn8mr4432553vdc.56.1420679168243; Wed, 07 Jan 2015 17:06:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Wed, 7 Jan 2015 17:05:47 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Wed, 7 Jan 2015 17:05:47 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1133f78229e0f8050c19a5d5 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eaBZwnoBoqcqV1VqqfbVAsY-tLg Cc: "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:06:10 -0000 --001a1133f78229e0f8050c19a5d5 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 18, 2014 at 11:12 AM, Simon Perreault wrote: > Ok here's our recap of the discussion, as chairs: > > - Nobody disagrees about the technical merit of TURN over WebSockets > (ToWS). That is, nobody said it won't work, it will break stuff, or won't > actually solve the problem. > > - There is disagreement about what the problem actually is, and whether we > really do need ToWS in the context of WebRTC. > > - Nevertheless, there is an important number of TRAMsters that appear to > be interested in working on ToWS. > > So, unless somebody makes a compelling argument against enabling that > group of interested people to work on ToWS within TRAM, we will propose a > new milestone for this work, and adopt draft-chenxin-behave-turn-websocket > as WG document. > I have a really hard time seeing how the WG could get behind this as long as the problem to solve remains underspecified. A detailed description of the problem to be solved, and an explanation of how the new work will solve said problem, seem like clear prerequisites for any WG-sponsored effort. --001a1133f78229e0f8050c19a5d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 18, 2014 at 11:12 AM, Simon Perreault <= ;sperreault@jive.c= om> wrote:
Ok here's our recap of the discussion, = as chairs:

- Nobody disagrees about the technical merit of TURN over WebSo= ckets (ToWS). That is, nobody said it won't work, it will break stuff, = or won't actually solve the problem.

- There is disagreement about what= the problem actually is, and whether we really do need ToWS in the context= of WebRTC.

- Nevertheless, there is an important number of TRAMsters that = appear to be interested in working on ToWS.

So, unless somebody makes a com= pelling argument against enabling that group of interested people to work o= n ToWS within TRAM, we will propose a new milestone for this work, and adop= t=C2=A0draft-chenxin-behave-turn-websocket as WG document.

I have a really hard time seeing how the WG cou= ld get behind this as long as the problem to solve remains underspecified. = A detailed description of the problem to be solved, and an explanation of h= ow the new work will solve said problem, seem like clear prerequisites for = any WG-sponsored effort.
--001a1133f78229e0f8050c19a5d5-- From nobody Wed Jan 7 17:33:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1541AC3C8 for ; Wed, 7 Jan 2015 17:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 J0U_Ic5Cg98l for ; Wed, 7 Jan 2015 17:33:46 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 989201A87AF for ; Wed, 7 Jan 2015 17:33:45 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BrKQQ_ya1UV3WjAA==.31345S4; Thu, 08 Jan 2015 08:03:28 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> In-Reply-To: <54ADA694.9010300@akamai.com> Date: Thu, 8 Jan 2015 09:33:09 +0800 Message-ID: <005b01d02ae3$17832d80$46898880$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAqtYtnBwPx0O4+Q5qCbFnAD5t6mwAKPUng Content-Language: zh-cn X-CM-TRANSID: Z0GX06BrKQQ_ya1UV3WjAA==.31345S4 X-Coremail-Antispam: 1U3129KBjvJXoW3Jw1Duw4kAFyxAryDJFWDJwb_yoW3XF1fpF W3JFy7Gw1kJr4xCwsFvw1jvF1YvrWkXrW3Xr15tr18Z390kF17tr1Utr4ruryUGr98Gryj qr4Uua17A3W5ArJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hC8uAyfzXE4LqEprf_nEON40L2Q Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:33:49 -0000 Hi, Brandon: Please see the reply inline. Best Regards. Aijun Wang. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Thursday, January 08, 2015 5:35 AM > To: Aijun Wang; tram@ietf.org > Subject: Re: [tram] Fwd: New Version Notification for > draft-williams-peer-redirect-02.txt > > see [bw] inline > > On 01/06/2015 01:14 AM, Aijun Wang wrote: > > Hi, Brandon. > > > > I read your draft just and wants to ask you some question for clarification: > > 1. Is it possible for two peers to select different Relay Server to > > communicate? If so, will the communication channel between the Relay > > Server will be changed by the CHECK-ALTERNATE attribute? If not, how > > to ensure two peers select the same Relay Server? > > [bw] Yes, they can select different relay servers. The mechanism doesn't add > any new restriction in that regard, nor does it changes the communication > channel between the servers (there's no need for that). > Basically, redirect would end up providing a new relay candidate and there's > some ongoing work in mmusic that will help ICE to make more effective use of > the new relay candidate. [Aijun]: section 2.4 and section 10.1&10.2 of the draft http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the process for transferring data via the TURN server(here we select the brief description in section 2.4 for discussion): ---------------------------------------------------------------------------- ---------------------------------------------- When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication. In the reverse direction, UDP datagrams arriving at the relayed transport address on the TURN server are converted into Data indications and sent to the client, with the server-reflexive transport address of the peer included in an XOR-PEER-ADDRESS attribute and the data itself in a DATA attribute. Since the relayed transport address uniquely identified the allocation, the server knows which client should receive the data. ---------------------------------------------------------------------------- --------------------------------------------------- So, from the client to TURN server, the application data is encapsulated in the DATA attribute and also the XOR-PEER-ADDRESS should be included. But from TURN server to the peer, it is one pure UDP datagram, there is no any STUN attribute included, and the application data is directly on the UDP data part. Then it is different for application data transfer between client/server and server/peer pair. If we allow the communication pair connected two different TURN servers, how to transport application data between two TURN servers? Using send indication or use pure UDP datagram? How does the upstream TURN server know the transport address of the downstream TURN Server? > > > 2. Is it better for ICE server to determine the appropriate Relay > > Server for two peers at the beginning of ICE connectivity check? The > > determination process can be based on information such as the load > > status of each Relay Server, the link usage of its interfaces and the > > proximity of two peers(based solely on the reflex-address of each peer). > > [bw] I'm not sure what you're getting at here. The 3rd party relay system has > the necessary information to determine whether a redirect would be beneficial, > so why would it make sense for something else to make that determination? > [Aijun]: My concern at here is same as the above question: how the upstream TURN server knows the transport address of downstream TURN server for one peer? If ICE can determine the appropriate TURN server for the corresponding communication pair, then there is no need the server redirect mechanism. Am I right? > > > > Best Regards. > > > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >> Williams > >> Sent: Tuesday, December 30, 2014 6:04 AM > >> To: tram@ietf.org > >> Subject: [tram] Fwd: New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> > >> Hi all, > >> > >> I've just updated the peer redirect draft to provide the warning > >> labels > > that Ted > >> asked for back in Toronto. I also added brief discussion of a load > > balancing use > >> case when adding a new flow to an existing allocation. > >> > >> There's some work going on both here and in mmusic related to ICE > >> that can help provide a framework for making more effective use of > >> this redirection capability. > >> > >> I hope that there might be enough interest in this draft for WG > >> adoption > > and > >> would like to hear thoughts on that from the list. > >> > >> Thanks, > >> --Brandon > >> > >> -------- Forwarded Message -------- > >> Subject: New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> Date: Mon, 29 Dec 2014 16:53:47 -0500 > >> From: internet-drafts@ietf.org > >> To: Williams, Brandon , Tirumaleswar Reddy > >> , Tirumaleswar Reddy , > >> Williams, Brandon > >> > >> > >> A new version of I-D, draft-williams-peer-redirect-02.txt > >> has been successfully submitted by Brandon Williams and posted to the > >> IETF repository. > >> > >> Name: draft-williams-peer-redirect > >> Revision: 02 > >> Title: Peer-specific Redirection for Traversal Using Relays > > around NAT > >> (TURN) > >> Document date: 2014-12-29 > >> Group: Individual Submission > >> Pages: 13 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.t > >> xt > >> Status: > >> https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ > >> Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-02 > >> Diff: > >> http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 > >> > >> Abstract: > >> This specification describes a peer-specific redirection method that > >> allows the TURN server to redirect a client for the purpose of > >> improving communication with a specific peer without negatively > >> affecting communication with other peers. > >> > >> > >> > >> > >> > >> 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. > >> > >> The IETF Secretariat > >> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > >> > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > > > > > > > > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jan 7 18:02:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2B1A0072 for ; Wed, 7 Jan 2015 18:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 wM8HgC3VWfaC for ; Wed, 7 Jan 2015 18:02:49 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906971A036F for ; Wed, 7 Jan 2015 18:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3477; q=dns/txt; s=iport; t=1420682569; x=1421892169; h=from:to:subject:date:message-id:mime-version; bh=R64TorCSsDcEYbbRjelZbwnCD7KTvI2uZFHSLflIKzo=; b=JomXZTqZxWPH1v9y7R+rjagx2PT4RaducJ3zq0WkHanG67cqOjlt5XRM wlA/9WRcy4CrMU5/1I+xXjtvnNe3LDaY04UzsGe6nwh6lC/4xDkr5aC/q dez2uMkChQU90guycXFSan7pr0Z1Fi21+wo5BpIAhbF6d8rxrhDJdwPEL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABXlrVStJA2M/2dsb2JhbABcgkNDUlzDU4IlhXMCgRFDAQEBAQF9hA4BBC1eAQweViYBBBuIJA2hI6MHAQEBAQEBAQMBAQEBAQEYBI9HLYMhgRMFji6DQ4ZLgm6NaCKDboI0fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,719,1413244800"; d="scan'208,217";a="382084464" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jan 2015 02:02:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0822Sa5017071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Jan 2015 02:02:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 20:02:28 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: SSODA in TURN-bis Thread-Index: AdAq5yRwxEi4Jbc7TpCKn/lLZn1lew== Date: Thu, 8 Jan 2015 02:02:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.119] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35527E46xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xSvIteRlWABlM4fzXu7U-41bdMI Subject: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 02:02:51 -0000 --_000_913383AAA69FF945B8F946018B75898A35527E46xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We are working on incorporating RFC6156 and SSODA into TURN-bis. During IET= F-91 meeting there was discussion if the technique proposed in https://tool= s.ietf.org/html/draft-martinsen-tram-ssoda-01 would break existing TURN ser= ver implementations. Pal had mentioned testing with four implementations a= nd did not face any problem. Please let us know if there are any concerns with the existing proposal of = conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute = values in Allocate request ? Cheers, -Tiru --_000_913383AAA69FF945B8F946018B75898A35527E46xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are working on incorporating RFC6156 and SSODA in= to TURN-bis. During IETF-91 meeting there was discussion if the technique p= roposed in https= ://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break existi= ng TURN server implementations.  Pal had mentioned testing with four i= mplementations and did not face any problem.

 

Please let us know if there are any concerns with th= e existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes wi= th different attribute values in Allocate request ?

 

Cheers,

-Tiru

--_000_913383AAA69FF945B8F946018B75898A35527E46xmbrcdx10ciscoc_-- From nobody Wed Jan 7 20:02:32 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E21A8830 for ; Wed, 7 Jan 2015 20:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 F0tIh5E11V0S for ; Wed, 7 Jan 2015 20:02:29 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004BB1A0404 for ; Wed, 7 Jan 2015 20:02:28 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hy4so391707vcb.1 for ; Wed, 07 Jan 2015 20:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lJFmNjIXyhtdzG/YmgVG9H5WeKg/+O6EHaFCuyVElxQ=; b=fCufRvn/T6IlbFuMoAkqTm+087VQLDQYuNgeFsDyjkYw3m2iLr/T8tyWKo4JzR9xYa VB+INNpbCMvYe3iA3kaIO65PvG+NLK2mRpf2OOrdJooLaEqV0XyCEYBkP1ZNiG4EFOSZ wymWU/yIW4xye4fmZWbN1s9RvcCKYEckp3kR451VS9rIoCSInNzmd2boZJODusTOG6H1 aAvrBoyinLlK0Z7yeJB3afVothO04WVwAkLY7IrT89tiKBrMigKOCXsdUjqdACDcsVEh l1wb60qQfqLPxKvHMEwRkxc6or6NzDLLDKivLwG7UclPET4YglBHVyHDSI1YD/op6FFA Mk/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lJFmNjIXyhtdzG/YmgVG9H5WeKg/+O6EHaFCuyVElxQ=; b=Y35IjejvFb1N709ADB4/yQ5WGzublDtYxHrbqTqzmQmonTC2lyerdwjhBLxtTVewi7 Bvo0pnG8zxNX6Pk11XYD8j0MgGEsuquXV2Gpj1nqy6GrI5QPHTCJnx/xJdj0j4o+th6G hyyTjyQz1P1IKWfh7qVZDDiotz/KGPKFZj7ART8T4WTZUjqNs3CRbPELA/FCGg/pTzEe sr1VFWTq7/J9aI0HS6kMAEU0/uQTDsT80nMqElS9MBLTbdsbw4DHurMs9AnzAXoq0nwx tDVDMj8z1cUc5HxGm+Q1PT2/EXFXbh1W6+F/krjgHHNTazo9zN38Roz+EWHovhnxbQwl PEaQ== X-Gm-Message-State: ALoCoQkAg9RlHou2uutdFZc2mwqcdJv92v6TIwHPcuzcyEtl70osQJq3kDqeYx6SSHnJer6yDJ3v X-Received: by 10.52.97.9 with SMTP id dw9mr4655531vdb.4.1420689747882; Wed, 07 Jan 2015 20:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Wed, 7 Jan 2015 20:02:07 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Wed, 7 Jan 2015 20:02:07 -0800 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=20cf307f3186c25b24050c1c1b54 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/TvQYyKKM_s_SmMILjYmAAbJioPQ Cc: "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 04:02:31 -0000 --20cf307f3186c25b24050c1c1b54 Content-Type: text/plain; charset=UTF-8 I promised I would write up a summary of the current mechanism, and what we could do instead, so here goes: The currently documented mechanism is to send two R-A-F attributes in the request, and get back either a single address (from legacy servers), v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new servers that only support one address family), or an error-code (to indicate complete failure). At the time, there were 2 concerns listed, namely: 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may fail the request completely, or do other weird things. 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; specifically, detailed error information cannot be included. I also thought of a 3rd problem: 3) an old(5766) server may fail the request completely, due to the fact that R-A-F is comprehension-required. Thus an extra roundtrip may be needed in this case, negating one of the benefits of SSODA. I think the ideal solution to #1/#3 is to add a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but comprehension-optional, where multiple values are explicitly supported. Old servers can safely ignore this and will return IPv4 (solving #3), while new servers can process this to return multiple XOR-RELAYED-ADDRESSes in the response. #2 is not a serious issue, but it could easily be solved by defining a new ADDRESS-ERROR-CODE as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Rsvd |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Then a server could return a normal IPv4 address, but a error code for IPv6 with either 440 (unsupported address family) or 508 (insufficient capacity) or some other TBD error. I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and prevents potential interoperability problems with old servers. I could go either way on ADDRESS-ERROR-CODE. On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi all, > > > > We are working on incorporating RFC6156 and SSODA into TURN-bis. During > IETF-91 meeting there was discussion if the technique proposed in > https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break > existing TURN server implementations. Pal had mentioned testing with four > implementations and did not face any problem. > > > > Please let us know if there are any concerns with the existing proposal of > conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute > values in Allocate request ? > > > > Cheers, > > -Tiru > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --20cf307f3186c25b24050c1c1b54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I promised I would write up a summary of the current mecha= nism, and what we could do instead, so here goes:

The cu= rrently documented mechanism is to send two R-A-F attributes in the request= , and get back either a single address (from legacy servers), v4 + v6 addre= sses (from new servers), a single address + a 0= .0.0.0/:: (for new servers that only support one address family), or an= error-code (to indicate complete failure).

At the= time, there were 2 concerns listed, namely:
1) sending multiple = R-A-Fs is undefined behavior; old (6156) servers may fail the request compl= etely, or do other weird things.
2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; specif= ically, detailed error information cannot be included.

=
I also thought of a 3rd problem:
3) an old(5766) server may = fail the request completely, due to the fact that R-A-F is comprehension-re= quired. Thus an extra roundtrip may be needed in this case, negating one of= the benefits of SSODA.

I think the ideal solution= to #1/#3 is to add a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R= -A-F but comprehension-optional, where multiple values are explicitly suppo= rted. Old servers can safely ignore this and will return IPv4 (solving #3),= while new servers can process this to return multiple XOR-RELAYED-ADDRESSe= s in the response.
#2 is not a serious issue, but it could easily= be solved by defining a new ADDRESS-ERROR-CODE as follows:

<= /div>
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+
      |  Address Family                |  Rsvd  |Class|     Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Reason Phrase (variable)                                ..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then a s=
erver could return a normal IPv4 address, but a error code for IPv6 with ei=
ther 440 (unsupported address family) or 508 (insufficient capacity) or som=
e other TBD error.

I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute a=
s it is simple and prevents potential interoperability problems with old se=
rvers. I could go either way on ADDRESS-ERROR-CODE.

=C2=A0

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Hi all,

=C2=A0

We are working on incorporating RFC6156 and SSODA in= to TURN-bis. During IETF-91 meeting there was discussion if the technique p= roposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 = would break existing TURN server implementations.=C2=A0 Pal had mentioned t= esting with four implementations and did not face any problem.

=C2=A0

Please let us know if there are any concerns with th= e existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes wi= th different attribute values in Allocate request ?

=C2=A0

Cheers,

-Tiru


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--20cf307f3186c25b24050c1c1b54-- From nobody Wed Jan 7 20:56:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB31A8852 for ; Wed, 7 Jan 2015 20:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 gP72_YPdQk39 for ; Wed, 7 Jan 2015 20:56:25 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCB61A1A9D for ; Wed, 7 Jan 2015 20:56:25 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id k11so448218wes.3 for ; Wed, 07 Jan 2015 20:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vbjAwCEFlxY0tb2PvizyCCrcs9hYG7s5PzxYbc3GWAg=; b=hjbxeQHRPsbSTDLoZYJRQ0S8tb1F3O2rjvGdbyCsfYyYHXFreKZc+iaH6ApvZ3aDqh pfDbsmyHT5203GT1YDtwZezhgdrMpGw9l192VL2DMra8BvKeiO+wOnn23RP/9n1+UlZA NYvqGSQ8B5BYgEEbzK2JKHQF5eulXz1qlnPioXxbuACl6/g1vn9F6VvMI/jU+FOpkEMG ZQrPzT2D/hHwgYJvnRRGQET6q0svPJ4srBmTBNf/fqKFxLQA62zJX7elFW98jIeg2yDb 17dow/ndM+LZbfQQ2c5qRgm1eP5777l8PRERlSUE4sx5TPwEUV84QWnYfrxVQJmZlIpI UkkA== MIME-Version: 1.0 X-Received: by 10.181.28.165 with SMTP id jp5mr56370727wid.76.1420692984371; Wed, 07 Jan 2015 20:56:24 -0800 (PST) Received: by 10.194.238.132 with HTTP; Wed, 7 Jan 2015 20:56:24 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> Date: Wed, 7 Jan 2015 20:56:24 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1137eac4ab1f66050c1cdc60 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VSSv5KYHqKdcwMAsvDqAyVnMh1s Cc: "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 04:56:27 -0000 --001a1137eac4ab1f66050c1cdc60 Content-Type: text/plain; charset=UTF-8 Hi Tiru I can tell for sure that it will NOT break the rfc5766-turn-server. And this is how SSODA is implemented in CoTURN server. Thanks Oleg On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi all, > > > > We are working on incorporating RFC6156 and SSODA into TURN-bis. During > IETF-91 meeting there was discussion if the technique proposed in > https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break > existing TURN server implementations. Pal had mentioned testing with four > implementations and did not face any problem. > > > > Please let us know if there are any concerns with the existing proposal of > conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute > values in Allocate request ? > > > > Cheers, > > -Tiru > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a1137eac4ab1f66050c1cdc60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tiru

I can tell for sure that it will = NOT break the rfc5766-turn-server.

And this is how SSODA is im= plemented in CoTURN server.

Thanks
Oleg


On Wed, Jan 7, 2015 at = 6:02 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wr= ote:

Hi all,

=C2=A0

We are working on incorporating RFC6156 and SSODA in= to TURN-bis. During IETF-91 meeting there was discussion if the technique p= roposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 = would break existing TURN server implementations.=C2=A0 Pal had mentioned t= esting with four implementations and did not face any problem.

=C2=A0

Please let us know if there are any concerns with th= e existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes wi= th different attribute values in Allocate request ?

=C2=A0

Cheers,

-Tiru


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--001a1137eac4ab1f66050c1cdc60-- From nobody Wed Jan 7 22:15:01 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A381A1A12 for ; Wed, 7 Jan 2015 22:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.712 X-Spam-Level: * X-Spam-Status: No, score=1.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_PSBL=2.7] autolearn=no 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 ObMGWMRe2ZGe for ; Wed, 7 Jan 2015 22:14:53 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CB2751A8868 for ; Wed, 7 Jan 2015 22:14:49 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CLywIaC65Uf3ufAA==.40125S4; Thu, 08 Jan 2015 12:44:27 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> In-Reply-To: Date: Thu, 8 Jan 2015 14:14:10 +0800 Message-ID: <009001d02b0a$59cd52c0$0d67f840$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01D02B4D.67F092C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAqeclGYZ0FCzG/QjaeDEWU9/1aBAAdVB1g Content-Language: zh-cn X-CM-TRANSID: Z0GX06CLywIaC65Uf3ufAA==.40125S4 X-Coremail-Antispam: 1U3129KBjvJXoW3JryrWFy5uw47KFWUJw1DKFg_yoWxXw47pF W5Gryakr4kJr4Iy34qvw4xWF15uaykAFyUJr9Ygr17A398ta4SgrWSk3yjyFW7uFs3Xw42 vr42qayDuw15Z3DanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjHCb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwCY1x0262kK e7AKxVWUAVWUtwC2zVAF1VAY17CE14v26r126r1D0xZFpf9x0JUG1v3UUUUU= Archived-At: http://mailarchive.ietf.org/arch/msg/tram/j4oik7hvfXqOz5ztzXKCKKhTZfs Cc: "'Pal Martinsen \(palmarti\)'" , 'Varun Singh' , tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Brandon Williams' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 06:14:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0091_01D02B4D.67F092C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Wednesday, January 07, 2015 10:22 PM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; Pal Martinsen = (palmarti); tram@ietf.org; Varun Singh Subject: Re: [tram] New Version Notification for = draft-reddy-tram-stun-path-data-00.txt =20 =20 On Wed, Jan 7, 2015 at 4:36 AM, Aijun Wang = wrote: > > Can you assure the applications that relied on them will be more > > efficiency and reliable? I prefer to putting all usable interfaces > > into a pool(via ICE continuously checking proposal) and give more > > flexibility to the application. More detections and decision can be > > made by the upper layer, not the ICE itself. > > The decision need not be made by ICE, it can expose path metrics like = RTT, > packet loss to the upper layer. =E3=80=90Aijun=E3=80=91: The upper layer can get such information via = its data sending and responding naturally in real time. =20 But how would that work? Assuming the upper layer is RTP, and you want = to modify it so that it measures path RTTs. Wouldn't that enhanced RTP = upper layer then make use of this draft to make its measurements? What = alternative are you concretely proposing? =20 [Aiiun] RFC3550 for RTP has the following description: The data transport is augmented by a control protocol (RTCP) to allow = monitoring of the data delivery in a manner scalable to large multicast = networks, and to provide minimal control and identification = functionality. =20 And the Sender Report RTCP Packet and Receiver Report RTCP Packet that = described in section 6.4.1 and 6.4.2 of this RFC illustrate the detail = information that can be gathered by RTCP. Is it sufficient enough for = RTP upper layer? =20 =20 =E3=80=90Aijun=E3=80=91: 1. Does current ICE consider the communication = scenarios that one IPv4-only endpoint wants to talks to one IPv6-only = endpoint? =20 Yes. [RFC6156] =20 [Aijun]: The function that described in RFC6156 for packet translation = is needed for IPv4-Only host to communicate with IPv6-Only host, but the = procedure should be re-clarified. For example, when will the endpoint = send the =E2=80=9CAllocate Request=E2=80=9D that includes = =E2=80=9CREQUSTED-ADDRESS-FAMILY=E2=80=9D attribute to require one relay = address different from its supported address type? =20 There is also other issue for the specific relay address when the = endpoint is behind endpoint-dependent NAT. I will give one example = below. =20 2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT = environment in one determined manner, not the possible success rate via = trying every pair of check list? =20 I don't understand what you mean. If the NAT is BEHAVE-compliant, then = ICE will pick the STUN candidate. What is missing? =20 [Aijun]: http://tools.ietf.org/html/rfc6544#appendix-A = =E2=80=9CLimitations of ICE TCP=E2=80=9D give more detail description = that related to the above two questions. RFC6544 gives only the = simultaneous-open solution for TCP NAT transversal, but its success rate = is not 100%, even under the BEHAVE-compliant environment. =20 3. Does ICE mention how to make sure the relayed packet to pass = through the non-BEHAVE-compliant NAT device? Especially for TCP = protocol? =20 I don't understand what you mean. Can you be more specific? Perhaps = illustrate with an example? =20 [Aijun]: Here is one example: 1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint = Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A = is behind NAT-A, and Host B is behind NAT-B 2. Host A and Host B all send the =E2=80=9CAllocation Request=E2=80=9D = to the TURN server=E2=80=99s well-known address, to get its relayed = address respectively. At the same time, they all punch one TCP hole at = NAT-A and NAT-B, but this TCP hole will only receive the packet from the = TURN server=E2=80=99s well-known transport address, this is the behavior = of EDM type NAT. 3. when Host A send data traffic to Host B, via the TURN server. The = TURN server will change the packet source address to Host A=E2=80=99s = relay address, which is allocated in step 2. Because the = packet=E2=80=99s source address did not match any NAT table item in = NAT-B, this packet will be discard in silence. 4. Did current ICE notice this? This is same as the UDP transport, but = TCP transport maybe more complex.=20 =20 > > > Periodic ICE connectivity checks for media streams for consent > > > freshness is already covered in > > > = http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness- > > > 11 > > > > > I was also curious that how this problem that mentioned in this = draft > > is raised. If the corresponding endpoint doesn't want to receive the > > data from other endpoint, it need just close the TCP/UDP session = that > > built by ICE process, why should we use the consent freshness check? > > Consent freshness will help the endpoint determine if the remote peer = is > interested in receiving the traffic or not. =E3=80=90Aijun=E3=80=91: There is other system to make this decision. = For example, If I want to talk to you via Skype, I should first find you = in my Skype contact list, and make a call to you. If you accept the = call, the ICE process for data transfer then begin. If you drop the = call, the ICE process will be terminated. ICE itself needs not do the = consent check. Here's a tip... =20 You obviously don't understand why consent checks are needed. Fine. = Maybe we're all wrong and consent checks are not needed. But instead of = asking questions you try to argue. Not fine. If you ask questions we can = try to help you understand, and if we're all wrong our answers will make = it obvious to everyone. If instead you try to argue I'm afraid you will = just get ignored. =20 [Aijun]: Ok. I am trying to catch up with all the relevant discussion. = Currently, I read only = http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11 = and there is little background introduction for the consent fresh check. = I personally think the consent check should be controlled also by the = application layer, not the ICE protocol, which is one basic connectivity = check protocol, and may be used by various application, even for that = does not require the consent check. =20 Ask more, assert less. [Aijun]: Ok, thanks for your advices and all kind attitude of this = group, I just want to the TURN/ICE protocol more robust and more = efficient. We have implemented one system that cover all the scenarios = that mentioned in TURN/ICE related scenarios, but use some different = procedures described in current related RFC/Draft. =20 Simon ------=_NextPart_000_0091_01D02B4D.67F092C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

From:= Simon = Perreault [mailto:sperreault@jive.com] =
Sent: Wednesday, January 07, 2015 10:22 PM
To: = Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; = Pal Martinsen (palmarti); tram@ietf.org; Varun = Singh
Subject: Re: [tram] New Version Notification for = draft-reddy-tram-stun-path-data-00.txt

<= p class=3DMsoNormal> 

 

On Wed, Jan 7, 2015 at 4:36 AM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

> = > Can you assure the applications that relied on them will be = more
> > efficiency and reliable? I prefer to putting all = usable interfaces
> > into a pool(via ICE continuously checking = proposal) and give more
> > flexibility to the application. = More detections and decision can be
> > made by the upper = layer, not the ICE itself.
>
> The decision need not be made = by ICE, it can expose path metrics like RTT,
> packet loss to the = upper layer.

=E3=80=90Aijun=E3=80=91: The upper layer = can get such information via its data sending and responding naturally = in real time.

 

But how would that work? Assuming = the upper layer is RTP, and you want to modify it so that it measures = path RTTs. Wouldn't that enhanced RTP upper layer then make use of this = draft to make its measurements? What alternative are you concretely = proposing?

 

[Aiiun] RFC3550 for RTP has the following = description:

The data transport is augmented by a control = protocol (RTCP) to allow monitoring of the data delivery in a manner = scalable to large multicast networks, and to provide minimal control and = identification functionality.

 

And the Sender Report RTCP Packet and Receiver Report RTCP Packet = that described in section 6.4.1 and 6.4.2 of this RFC illustrate the = detail information that can be gathered by RTCP. Is it sufficient enough = for RTP upper layer?

 

 

=E3=80=90Aijun=E3=80=91: 1. Does current = ICE consider the communication scenarios that one IPv4-only endpoint = wants to talks to one IPv6-only = endpoint?

 

Yes. = [RFC6156]

 

[Aijun]: The function that described in RFC6156 for packet = translation is needed for IPv4-Only host to communicate with IPv6-Only = host, but the procedure should be re-clarified. For example, when will = the endpoint send the =E2=80=9CAllocate Request=E2=80=9D that includes = =E2=80=9CREQUSTED-ADDRESS-FAMILY=E2=80=9D attribute to require one relay = address different from its supported address type?=C2=A0 =

There is also other issue for the specific relay address when the = endpoint is behind endpoint-dependent NAT. I will give one example = below.

 

      =    2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant = NAT environment in one determined manner, not the possible success rate = via trying every pair of check = list?

 

I don't understand what you mean. = If the NAT is BEHAVE-compliant, then ICE will pick the STUN candidate. = What is missing?

 

[Aijun]: http://tools.ietf.= org/html/rfc6544#appendix-A =E2=80=9CLimitations of ICE TCP=E2=80=9D = give more detail description that related to the above two questions. = RFC6544 gives only the simultaneous-open solution for TCP NAT = transversal, but its success rate is not 100%, even under the = BEHAVE-compliant environment.

 

      =    3. Does ICE mention how to make sure the relayed packet to = pass through the non-BEHAVE-compliant NAT device? Especially for TCP = protocol?

 

I don't understand what you mean. = Can you be more specific? Perhaps illustrate with an = example?

 

[Aijun]: Here is one example:

1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint = Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A = is behind NAT-A, and Host B is behind NAT-B

2. Host A and Host B all send the =E2=80=9CAllocation = Request=E2=80=9D to the TURN server=E2=80=99s well-known address, to get = its relayed address respectively. At the same time, they all punch one = TCP hole at NAT-A and NAT-B, but this TCP hole will only receive the = packet from the TURN server=E2=80=99s well-known transport address, this = is the behavior of EDM type NAT.

3. when Host A send data traffic to Host B, via the TURN = server.=C2=A0 The TURN server will change the packet source address to = Host A=E2=80=99s relay address, which is allocated in step 2. Because = the packet=E2=80=99s source address did not match any NAT table item in = NAT-B, this packet will be discard in silence.

4. Did current ICE notice this? This is same as the UDP transport, = but TCP transport maybe more complex.

 

> > > Periodic = ICE connectivity checks for media streams for consent
> > > = freshness is already covered in
> > > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-conse= nt-freshness-
> > > 11
> > >
> > I = was also curious that how this problem that mentioned in this = draft
> > is raised. If the corresponding endpoint doesn't want = to receive the
> > data from other endpoint, it need just close = the TCP/UDP session that
> > built by ICE process, why should = we use the consent freshness check?
>
> Consent freshness = will help the endpoint determine if the remote peer is
> = interested in receiving the traffic or not.

=E3=80=90Aijun=E3=80=91: There is other = system to make this decision. For example, If I want to talk to you via = Skype, I should first find you in my Skype contact list, and make a call = to you. If you accept the call, the ICE process for data transfer then = begin. If you drop the call, the ICE process will be terminated. ICE = itself needs not do the consent = check.


Here's a = tip...

 

You obviously don't understand why = consent checks are needed. Fine. Maybe we're all wrong and consent = checks are not needed. But instead of asking questions you try to argue. = Not fine. If you ask questions we can try to help you understand, and if = we're all wrong our answers will make it obvious to everyone. If instead = you try to argue I'm afraid you will just get = ignored.

 

[Aijun]: Ok. I am trying to catch up with all the relevant = discussion. Currently, I read only http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshnes= s-11 and there is little background introduction for the consent = fresh check.=C2=A0 I personally think the consent check should be = controlled also by the application layer, not the ICE protocol, which is = one basic connectivity check protocol, and may be used by various = application, even for that does not require the consent = check.

 

Ask more, assert = less.

[Aijun]: Ok, thanks for your advices and all kind attitude of this = group, I just want to the TURN/ICE protocol more robust and more = efficient. We have implemented one system that cover all the scenarios = that mentioned in TURN/ICE related scenarios, but use some different = procedures described in current related = RFC/Draft.

 

Simon

------=_NextPart_000_0091_01D02B4D.67F092C0-- From nobody Wed Jan 7 22:21:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9AF1A8869 for ; Wed, 7 Jan 2015 22:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 DOqPEOTH0fnw for ; Wed, 7 Jan 2015 22:21:11 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADD61A8868 for ; Wed, 7 Jan 2015 22:21:09 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06AbxwKzDK5UIOGeAA==.40436S4; Thu, 08 Jan 2015 12:51:03 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <00a501d02a3e$d7bcd4c0$87367e40$@org.cn> In-Reply-To: Date: Thu, 8 Jan 2015 14:20:59 +0800 Message-ID: <00a101d02b0b$455e58b0$d01b0a10$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01D02B4E.538198B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAqdXZq/CvWvo+GSAKHV1RY4Ki4CwAlY55g Content-Language: zh-cn X-CM-TRANSID: Z0GX06AbxwKzDK5UIOGeAA==.40436S4 X-Coremail-Antispam: 1U3129KBjvJXoW7Zw13uw48ury8Wr4ftr43Wrg_yoW8ur4kpF WUWa45Cr93XrW7AF15u3y3uF1F9ry8WFy3Jwn3Ka17Zws0yF10vF9Igr4F9ryUGrn5Ka4j vF1jg3Z7Z3W3Z3DanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU U8F7k0a2IF6r1UMc02F40Eb7x2x7xS6ryj6rWUMc02F40E57IF67AEF4xIwI1l5I8CrVAK z4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xM7kC6x804xWl14x267AKxVW8JVW5Jw AFxVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE 17CEb7AF67AKxVWUXVWUAwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4U0xZFpf9x0JURE__UUUUU= Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gb0ArAp0k9otHuXHVyijVyt3QLU Cc: tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 06:21:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01D02B4E.538198B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Simon, =20 I have covered all your concerns in the response to Mr.Brandon, please = refer to it. =20 Best Regards. Aijun =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Wednesday, January 07, 2015 9:57 PM To: Aijun Wang Cc: Brandon Williams; tram@ietf.org Subject: Re: [tram] Fwd: New Version Notification for = draft-williams-peer-redirect-02.txt =20 =20 On Wed, Jan 7, 2015 at 12:57 AM, Aijun Wang = wrote: 1. Is it possible for two peers to select different Relay Server to communicate? =20 It's already possible with today's ICE, without this draft. Or do you = mean something else? =20 =E3=80=90Aijun=E3=80=91: in = http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/, it described = only the process that the communication endpoints under one same TURN = server. The process for endpoints that under different TURN server is = not mentioned and is complex if we allow it happen. =20 On the contrary, things would be more complex if we tried to disallow = it. If so, will the communication channel between the Relay Server will be changed by the CHECK-ALTERNATE attribute? If not, how to ensure = two peers select the same Relay Server? =20 Why would it be necessary that the two peers select the same server? =20 =E3=80=90Aijun=E3=80=91: To simplify the realization of TURN process. =20 Sorry, I don't see how enforcing that would simplify anything. It would = be nice if it just happened because it would eliminate a leg and the = TURN server could apply hairpinning optimization, but from a protocol = point of view it would be exactly the same thing. Enforcing that this = always happen would actually make the protocol more complex. =20 Two questions: 1. How do we encapsulate the application data between the TURN servers? = Using the =E2=80=9CChannelData Message=E2=80=9D or using pure UDP = message? =20 Per the TURN spec it would be pure UDP. Each TURN server would not know = it is talking to another TURN server. =20 2. how about the TCP communication channel between two TURN servers? Assuming you mean RFC 6062, it would be pure TCP. Each TURN server would = not know it is talking to another TURN server. =20 Simon ------=_NextPart_000_00A2_01D02B4E.538198B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Simon,

 

I have covered all your concerns in the response to Mr.Brandon, = please refer to it.

 

Best Regards.

Aijun

 

From:= Simon = Perreault [mailto:sperreault@jive.com]
Sent: Wednesday, = January 07, 2015 9:57 PM
To: Aijun Wang
Cc: Brandon = Williams; tram@ietf.org
Subject: Re: [tram] Fwd: New Version = Notification for = draft-williams-peer-redirect-02.txt

 

 

On Wed, Jan 7, 2015 at 12:57 AM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

1. Is it possible for two peers to select different Relay = Server to
communicate?

 

It's already possible with today's ICE, without this draft. = Or do you mean something else?

 

=E3=80=90Aijun=E3=80=91: in http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis= /, it described only the process that the communication endpoints = under one same TURN server. The process for endpoints that under = different TURN server is not mentioned and is complex if we allow it = happen.

 

On the contrary, things would be = more complex if we tried to disallow = it.

If so, will the communication channel between the Relay = Server
will be changed by the CHECK-ALTERNATE attribute? If not, how = to ensure two
peers select the same Relay = Server?

 

Why would it be necessary that the two peers select the = same server?

 

=E3=80=90Aijun=E3=80=91: To simplify the realization of TURN process.

 

Sorry, I don't see how enforcing = that would simplify anything. It would be nice if it just happened = because it would eliminate a leg and the TURN server could apply = hairpinning optimization, but from a protocol point of view it would be = exactly the same thing. Enforcing that this always happen would actually = make the protocol more complex.

 

Two questions:

1. How do we encapsulate the application data between the TURN = servers? Using the =E2=80=9CChannelData Message=E2=80=9D or using pure = UDP message?

 

Per the TURN spec it would be pure = UDP. Each TURN server would not know it is talking to another TURN = server.

 

2. how about the TCP communication channel between two TURN = servers?


Assuming you mean RFC 6062, it = would be pure TCP. Each TURN server would not know it is talking to = another TURN server.

 

Simon

------=_NextPart_000_00A2_01D02B4E.538198B0-- From nobody Wed Jan 7 23:15:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC951A887F for ; Wed, 7 Jan 2015 23:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.113 X-Spam-Level: * X-Spam-Status: No, score=1.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_PSBL=2.7] autolearn=no 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 lIQA76kK8h3U for ; Wed, 7 Jan 2015 23:14:55 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CFE001A8877 for ; Wed, 7 Jan 2015 23:14:53 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06A7uwAyGa5UHeyhAA==.42501S4; Thu, 08 Jan 2015 13:44:35 +0800 (CST) From: "Aijun Wang" To: "'Justin Uberti'" , "'Tirumaleswar Reddy \(tireddy\)'" References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Thu, 8 Jan 2015 15:14:19 +0800 Message-ID: <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01D02B55.CEEDCD50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAq66Be41GmMNmhTm2jFuU0o2czCwAIkpNg Content-Language: zh-cn X-CM-TRANSID: Z0GX06A7uwAyGa5UHeyhAA==.42501S4 X-Coremail-Antispam: 1U3129KBjvJXoWxGrykGw4fAr1UtrWUJFykuFg_yoWrXF1DpF W3J3y5Gr4kJryxJw4kZr1jqF1FvrWrtryDKrn5tryxZ398Ja1DAw48Kw45G3srXrn5Gw4j qr4Uuw4Uurn8XrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JURE__UUUUU= Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-sDNf4akvMsskmQ3Tm0CnwTyhzg Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 07:14:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01D02B55.CEEDCD50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Justin, =20 Is it more straightforward to define one new attribute that named = =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F and = OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this = attribute will be assigned the relay address that is the same type as = seen from the source address of =E2=80=9CAllocate Request=E2=80=9D = packet, not default in IPv4 relay address. =20 For reducing the port resource consumption on TURN server that described = in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have = another proposal = http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can = mitigate the ip address/port allocation burden on TURN server------All = endpoints that under one TURN server can use the same IPv4/IPv6 relay = address/port.=20 =20 Best Regards. Aijun Wang. =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Thursday, January 08, 2015 12:02 PM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: [SPAM] Re: [tram] SSODA in TURN-bis =20 I promised I would write up a summary of the current mechanism, and what = we could do instead, so here goes: =20 The currently documented mechanism is to send two R-A-F attributes in = the request, and get back either a single address (from legacy servers), = v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/:: = (for new servers that only support one address family), or an error-code = (to indicate complete failure). =20 At the time, there were 2 concerns listed, namely: 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may = fail the request completely, or do other weird things. 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; = specifically, detailed error information cannot be included. =20 I also thought of a 3rd problem: 3) an old(5766) server may fail the request completely, due to the fact = that R-A-F is comprehension-required. Thus an extra roundtrip may be = needed in this case, negating one of the benefits of SSODA. =20 I think the ideal solution to #1/#3 is to add a new = OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but = comprehension-optional, where multiple values are explicitly supported. = Old servers can safely ignore this and will return IPv4 (solving #3), = while new servers can process this to return multiple = XOR-RELAYED-ADDRESSes in the response. #2 is not a serious issue, but it could easily be solved by defining a = new ADDRESS-ERROR-CODE as follows: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Rsvd |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Then a server could return a normal IPv4 address, but a error code for = IPv6 with either 440 (unsupported address family) or 508 (insufficient = capacity) or some other TBD error. =20 I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple = and prevents potential interoperability problems with old servers. I = could go either way on ADDRESS-ERROR-CODE. =20 =20 =20 On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) = wrote: Hi all, =20 We are working on incorporating RFC6156 and SSODA into TURN-bis. During = IETF-91 meeting there was discussion if the technique proposed in = https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break = existing TURN server implementations. Pal had mentioned testing with = four implementations and did not face any problem. =20 Please let us know if there are any concerns with the existing proposal = of conveying two REQUESTED-ADDRESS-FAMILY attributes with different = attribute values in Allocate request ? =20 Cheers, -Tiru _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_00B3_01D02B55.CEEDCD50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Justin,

 

Is it more straightforward to define one new attribute that named = =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F = and=C2=A0 OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include = this attribute will be assigned the relay address that is the same type = as seen from the source address of =E2=80=9CAllocate Request=E2=80=9D = packet, not default in IPv4 relay address.

 

For reducing the port resource consumption on TURN server that = described in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-= 01, we have another proposal http:/= /datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can = mitigate the ip address/port allocation burden on TURN server------All = endpoints that under one TURN server can use the same IPv4/IPv6 relay = =C2=A0address/port.

 

Best Regards.

Aijun Wang.

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: = Tirumaleswar Reddy (tireddy)
Cc: = tram@ietf.org
Subject: [SPAM] Re: [tram] SSODA in = TURN-bis

 

I promised I would write up a summary of the current = mechanism, and what we could do instead, so here = goes:

 

The currently documented mechanism = is to send two R-A-F attributes in the request, and get back either a = single address (from legacy servers), v4 + v6 addresses (from new = servers), a single address + a 0.0.0.0/:: (for new servers that only = support one address family), or an error-code (to indicate complete = failure).

 

At the time, there were 2 concerns = listed, namely:

1) sending multiple R-A-Fs is = undefined behavior; old (6156) servers may fail the request completely, = or do other weird things.

2) using 0.0.0.0/:: to indicate partial success is = somewhat unclean; specifically, detailed error information cannot be = included.

 

I also thought of a 3rd = problem:

3) an old(5766) server may fail the request completely, due = to the fact that R-A-F is comprehension-required. Thus an extra = roundtrip may be needed in this case, negating one of the benefits of = SSODA.

 

I think the ideal solution to #1/#3 = is to add a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F = but comprehension-optional, where multiple values are explicitly = supported. Old servers can safely ignore this and will return IPv4 = (solving #3), while new servers can process this to return multiple = XOR-RELAYED-ADDRESSes in the = response.

#2 is not a serious issue, but it could easily be solved by = defining a new ADDRESS-ERROR-CODE as = follows:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Address =
Family=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Rsvd=C2=A0 |Class|=C2=A0=C2=A0=C2=A0=C2=A0 =
Number=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reason Phrase =
(variable)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
..
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Then a server =
could return a normal IPv4 address, but a error code for IPv6 with =
either 440 (unsupported address family) or 508 (insufficient capacity) =
or some other TBD error.
 
I =
advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and =
prevents potential interoperability problems with old servers. I could =
go either way on ADDRESS-ERROR-CODE.
 
 

 

On Wed, Jan 7, 2015 at 6:02 PM, = Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> = wrote:

Hi all,

 

We are working on incorporating RFC6156 and SSODA into = TURN-bis. During IETF-91 meeting there was discussion if the technique = proposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-= 01 would break existing TURN server implementations.  Pal had = mentioned testing with four implementations and did not face any = problem.

 

Please let us know if there are any concerns with the = existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes = with different attribute values in Allocate request = ?

 

Cheers,

-Tiru


_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

------=_NextPart_000_00B3_01D02B55.CEEDCD50-- From nobody Thu Jan 8 06:14:25 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78A21A00C6 for ; Thu, 8 Jan 2015 06:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jMHpktb2rdVd for ; Thu, 8 Jan 2015 06:14:19 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 221A31A6ED8 for ; Thu, 8 Jan 2015 06:14:05 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 45F0D47894 for ; Thu, 8 Jan 2015 14:14:05 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 38FCA47891 for ; Thu, 8 Jan 2015 14:14:05 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 240732026 for ; Thu, 8 Jan 2015 14:14:05 +0000 (GMT) Message-ID: <54AE90AD.8030605@akamai.com> Date: Thu, 08 Jan 2015 09:14:05 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:14:23 -0000 +1 On 01/07/2015 08:05 PM, Justin Uberti wrote: > > > On Thu, Dec 18, 2014 at 11:12 AM, Simon Perreault > wrote: > > Ok here's our recap of the discussion, as chairs: > > - Nobody disagrees about the technical merit of TURN over WebSockets > (ToWS). That is, nobody said it won't work, it will break stuff, or > won't actually solve the problem. > > - There is disagreement about what the problem actually is, and > whether we really do need ToWS in the context of WebRTC. > > - Nevertheless, there is an important number of TRAMsters that > appear to be interested in working on ToWS. > > So, unless somebody makes a compelling argument against enabling > that group of interested people to work on ToWS within TRAM, we will > propose a new milestone for this work, and > adopt draft-chenxin-behave-turn-websocket as WG document. > > > I have a really hard time seeing how the WG could get behind this as > long as the problem to solve remains underspecified. A detailed > description of the problem to be solved, and an explanation of how the > new work will solve said problem, seem like clear prerequisites for any > WG-sponsored effort. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Jan 8 06:37:05 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E71A00C2 for ; Thu, 8 Jan 2015 06:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 RdqLs9qbsEAe for ; Thu, 8 Jan 2015 06:37:00 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E179C1A01C6 for ; Thu, 8 Jan 2015 06:36:59 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so3165749lbv.0 for ; Thu, 08 Jan 2015 06:36:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xl5LH3zzrtuhjrnQm8h7fZFI5e0a3AtDi1zvRw3B4Vk=; b=j017uxFef135qI1bzDghHAj6OCQqanLW8BGfuX4UmKYOB/IRg4NQJZ6xy3qPIBc7SJ b0zF/JbsvgxanZLsLcg7kjBTX/0GgCIcVk88KKttF7fcIi5dpKwFXmtAya8HC5ORln9S JFuT1ZCVqGVBmZTdb8cZ1KoERU+Gcn6GvHKE1rwLPCo0xn2k9dwZVnyxjPSt8OfhPEFa MMkOLSHCI9QPPxT6OqXE4yW6e2AR+ORVcQLOSsVvETVzAk2jtvkJUwsxLrbU0n4w4c88 Z/7pFtFHPvm7K+VYcYlQK30kqGO8NxVWNQtHAQ3PDTJ8DENesVkIasVWK6UFBBENyuL4 TIaQ== X-Gm-Message-State: ALoCoQk/GNTMf4mk7CbgrsNJ8jQq/dF8pGea0xQ0LT2dueT7/qVFLdXFX3ecoxJTfQym3BgB4iqk MIME-Version: 1.0 X-Received: by 10.152.8.11 with SMTP id n11mr12891421laa.38.1420727818272; Thu, 08 Jan 2015 06:36:58 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 8 Jan 2015 06:36:58 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 09:36:58 -0500 Message-ID: From: Simon Perreault To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c366e2ee5bbb050c24f8fd Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:37:02 -0000 --001a11c366e2ee5bbb050c24f8fd Content-Type: text/plain; charset=UTF-8 On Wed, Jan 7, 2015 at 8:05 PM, Justin Uberti wrote: > > On Thu, Dec 18, 2014 at 11:12 AM, Simon Perreault > wrote: >> >> So, unless somebody makes a compelling argument against enabling that >> group of interested people to work on ToWS within TRAM, we will propose a >> new milestone for this work, and adopt draft-chenxin-behave-turn-websocket >> as WG document. >> > > I have a really hard time seeing how the WG could get behind this as long > as the problem to solve remains underspecified. A detailed description of > the problem to be solved, and an explanation of how the new work will solve > said problem, seem like clear prerequisites for any WG-sponsored effort. > Yeah, it's called an "introduction section". It's not finished yet. So... please send text. :) To be perfectly clear, the introduction section not being perfect yet isn't "a compelling argument against enabling that group of interested people to work on ToWS within TRAM". The TRAMsters who expressed a need for ToWS now need to work toward WG consensus on the introduction section as a priority. A WG sends a draft to IESG when it has reached WG consensus, not before. Simon --001a11c366e2ee5bbb050c24f8fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 7, 2015 at 8:05 PM, Justin Uberti <juberti@google.com= > wrote:
On Thu, Dec 18, 2014 at 11:= 12 AM, Simon Perreault <sperreault@jive.com> wrote:
So, unless somebod= y makes a compelling argument against enabling that group of interested peo= ple to work on ToWS within TRAM, we will propose a new milestone for this w= ork, and adopt=C2=A0draft-chenxin-behave-turn-websocket as WG document.

I have a really hard time s= eeing how the WG could get behind this as long as the problem to solve rema= ins underspecified. A detailed description of the problem to be solved, and= an explanation of how the new work will solve said problem, seem like clea= r prerequisites for any WG-sponsored effort.

Yeah, it's called an "introduction section". It's= not finished yet. So... please send text. :)

To be perfectly clear, the introduc= tion section not being perfect yet isn't "a compelling argument against enabling that group= of interested people to work on ToWS within TRAM".

=
The TRAMsters who expressed a need for ToWS now need to work= toward WG consensus on the introduction section as a priority. A WG sends = a draft to IESG when it has reached WG consensus, not before.
<= div class=3D"gmail_extra">
Simon
--001a11c366e2ee5bbb050c24f8fd-- From nobody Thu Jan 8 07:20:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD9F1A8A8C for ; Thu, 8 Jan 2015 07:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 1qhhulVsrKU8 for ; Thu, 8 Jan 2015 07:20:30 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFD81A6EE0 for ; Thu, 8 Jan 2015 07:20:29 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so9735559lab.4 for ; Thu, 08 Jan 2015 07:20:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rRjIkrNqeI1S/KtZ9f4jSo+o4SoG78AyXt0icdbU73s=; b=CXeImOLzyWuigIqipPozycufIfWcBDJkw20hO32FGfSmzLN5/OhNzDtuNXR3Rl9jW9 b39NZ19Nk51hVRJ1vrFHYDrefWYOJ3W87IUOEXo8OZ0LQ9cKUsuPnlHVqHU3hj7NChB2 594Hc6/JjYJziX6Ee0T0AbWUEIGhISyS7HM+uZTTi9WW3o7FHyZFSdWvLEFgiUBBH976 91hChhA8LtNh4EJ40YgpyQYt4QjWKxs2g/D6UXoe9cm+F4/gnzs+FgnbASDj/yv2yXap 8X0aDj417Dtf0VGKR+/cl0/7vZBk5EWIu9X7O1T3SyuyGDJFeLSp/p45wkOZNICZNuMl b9dA== X-Gm-Message-State: ALoCoQm3IMu7ryCgnYNaXmj0LWhmNk29BZhl1EquaOGFBd1THmFuc+xnVNLFtEA16GpMxjGvNU3F MIME-Version: 1.0 X-Received: by 10.112.125.41 with SMTP id mn9mr14447910lbb.80.1420730089595; Thu, 08 Jan 2015 07:14:49 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 8 Jan 2015 07:14:49 -0800 (PST) In-Reply-To: <009001d02b0a$59cd52c0$0d67f840$@org.cn> References: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> <009001d02b0a$59cd52c0$0d67f840$@org.cn> Date: Thu, 8 Jan 2015 10:14:49 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=089e0112c2004ffd89050c2580b1 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , Varun Singh , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:20:34 -0000 --089e0112c2004ffd89050c2580b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 8, 2015 at 1:14 AM, Aijun Wang wrote: > > =E3=80=90Aijun=E3=80=91: The upper layer can get such information via its= data sending > and responding naturally in real time. > > > > But how would that work? Assuming the upper layer is RTP, and you want to > modify it so that it measures path RTTs. Wouldn't that enhanced RTP upper > layer then make use of this draft to make its measurements? What > alternative are you concretely proposing? > > > > [Aiiun] RFC3550 for RTP has the following description: > > The data transport is augmented by a control protocol (RTCP) to allow > monitoring of the data delivery in a manner scalable to large multicast > networks, and to provide minimal control and identification functionality= . > > > > And the Sender Report RTCP Packet and Receiver Report RTCP Packet that > described in section 6.4.1 and 6.4.2 of this RFC illustrate the detail > information that can be gathered by RTCP. Is it sufficient enough for RTP > upper layer? > In general no, it's not sufficient. Off the top of my head: - You need the special flavour of RTP that multiplexes RTP and RTCP on the same 5-tuple. - You need the special flavour of RTP, MPRTP, that could work with multiple paths simultaneously. Now, consider other upper-layer protocols that would need to implement that additional functionality as well. Why wouldn't it make sense that ICE provide this service for them? =E3=80=90Aijun=E3=80=91: 1. Does current ICE consider the communication sce= narios that one > IPv4-only endpoint wants to talks to one IPv6-only endpoint? > > > > Yes. [RFC6156] > > > > [Aijun]: The function that described in RFC6156 for packet translation is > needed for IPv4-Only host to communicate with IPv6-Only host, but the > procedure should be re-clarified. For example, when will the endpoint sen= d > the =E2=80=9CAllocate Request=E2=80=9D that includes =E2=80=9CREQUSTED-AD= DRESS-FAMILY=E2=80=9D attribute to > require one relay address different from its supported address type? > An ICE node should always gather both IPv4 and IPv6 relayed candidates. See also: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.2 https://tools.ietf.org/html/rfc6157#section-4 2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT > environment in one determined manner, not the possible success rate via > trying every pair of check list? > > > > I don't understand what you mean. If the NAT is BEHAVE-compliant, then IC= E > will pick the STUN candidate. What is missing? > > > > [Aijun]: http://tools.ietf.org/html/rfc6544#appendix-A =E2=80=9CLimitatio= ns of > ICE TCP=E2=80=9D give more detail description that related to the above t= wo > questions. RFC6544 gives only the simultaneous-open solution for TCP NAT > transversal, but its success rate is not 100%, even under the > BEHAVE-compliant environment. > How is that well-known limitation problematic? > 3. Does ICE mention how to make sure the relayed packet to pass > through the non-BEHAVE-compliant NAT device? Especially for TCP protocol? > > > > I don't understand what you mean. Can you be more specific? Perhaps > illustrate with an example? > > > > [Aijun]: Here is one example: > > 1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint > Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A is > behind NAT-A, and Host B is behind NAT-B > > 2. Host A and Host B all send the =E2=80=9CAllocation Request=E2=80=9D to= the TURN > server=E2=80=99s well-known address, to get its relayed address respectiv= ely. At > the same time, they all punch one TCP hole at NAT-A and NAT-B, but this T= CP > hole will only receive the packet from the TURN server=E2=80=99s well-kno= wn > transport address, this is the behavior of EDM type NAT. > > 3. when Host A send data traffic to Host B, via the TURN server. The TUR= N > server will change the packet source address to Host A=E2=80=99s relay ad= dress, > which is allocated in step 2. > That's not what will happen. There are two allocations on the same server. Conceptually, the packets will loopback from the first allocation's relayed address to the second allocation's relayed address, and will then be sent to host B over the same 5-tuple that host B initially used to send its allocate request. A server can also notice when two allocations are talking to each other and apply hairpinning optimization and avoid looping back real packets. > Because the packet=E2=80=99s source address did not match any NAT table i= tem in > NAT-B, this packet will be discard in silence. > > 4. Did current ICE notice this? This is same as the UDP transport, but TC= P > transport maybe more complex. > It's exactly the same for TURN-TCP, except that a separate data connection is used. Simon --089e0112c2004ffd89050c2580b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 1:14 AM, Aijun Wang <wangaijun@tsinghua= .org.cn> wrote:

=E3=80=90Aijun=E3=80=91: The upper layer can get = such information via its data sending and responding naturally in real time= .

= =C2=A0

But how would that work? Assuming the u= pper layer is RTP, and you want to modify it so that it measures path RTTs.= Wouldn't that enhanced RTP upper layer then make use of this draft to = make its measurements? What alternative are you concretely proposing?

= =C2=A0

[Aiiun] RFC3550 for RTP has the following description:

The data transport is augmented by a control pro= tocol (RTCP) to allow monitoring of the data delivery in a manner scalable = to large multicast networks, and to provide minimal control and identificat= ion functionality.

=C2=A0

And the Sender Report RTCP Packet and Receiver Report RTCP Pa= cket that described in section 6.4.1 and 6.4.2 of this RFC illustrate the d= etail information that can be gathered by RTCP. Is it sufficient enough for= RTP upper layer?


In general no, it's not sufficient. Off the= top of my head:

- You need the special flavour of= RTP that multiplexes RTP and RTCP on the same 5-tuple.
- You nee= d the special flavour of RTP, MPRTP, that could work with multiple paths si= multaneously.

Now, consider other upper-layer prot= ocols that would need to implement that additional functionality as well. W= hy wouldn't it make sense that ICE provide this service for them?
=

=E3=80=90Aijun=E3=80=91: 1. Does current ICE consid= er the communication scenarios that one IPv4-only endpoint wants to talks t= o one IPv6-only endpoint?

=C2=A0

<= div>

Yes. [RFC6156]

= =C2=A0

=

[Aijun]: The function that = described in RFC6156 for packet translation is needed for IPv4-Only host to= communicate with IPv6-Only host, but the procedure should be re-clarified.= For example, when will the endpoint send the =E2=80=9CAllocate Request=E2= =80=9D that includes =E2=80=9CREQUSTED-ADDRESS-FAMILY=E2=80=9D attribute to= require one relay address different from its supported address type?=C2=A0=


=
An ICE node should always gather both IPv4 and IPv6 relayed cand= idates.

See also:
https://tools.ietf.= org/html/rfc6157#section-4=C2=A0

=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Can ICE s= olve the TCP-NAT traversal in BEHAVE-compliant NAT environment in one deter= mined manner, not the possible success rate via trying every pair of check = list?

=C2=A0

I don't understand what you mean. If the NA= T is BEHAVE-compliant, then ICE will pick the STUN candidate. What is missi= ng?


<= div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Does ICE mention how to make su= re the relayed packet to pass through the non-BEHAVE-compliant NAT device? = Especially for TCP protocol?

=C2=A0

= I don't understand what you mean. Can you be more specific? Perhaps ill= ustrate with an example?

=C2=A0

[Aijun]: Here is one example:

1. Suppose Host A a= nd Host B are all behind EDM type NAT(Endpoint Dependent Map NAT, also non-= BEHAVE compliant NAT) devices, that Host A is behind NAT-A, and Host B is b= ehind NAT-B

2. Host A and Host B all send the =E2=80=9CAllocation Request=E2= =80=9D to the TURN server=E2=80=99s well-known address, to get its relayed = address respectively. At the same time, they all punch one TCP hole at NAT-= A and NAT-B, but this TCP hole will only receive the packet from the TURN s= erver=E2=80=99s well-known transport address, this is the behavior of EDM t= ype NAT.

3. when Host A send data traffic to Host B, via the TURN server.=C2= =A0 The TURN server will change the packet source address to Host A=E2=80= =99s relay address, which is allocated in step 2.



=
Simon
--089e0112c2004ffd89050c2580b1-- From nobody Thu Jan 8 07:22:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84101A8A23 for ; Thu, 8 Jan 2015 07:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 3AJJvEU32Oam for ; Thu, 8 Jan 2015 07:22:24 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199801A6F34 for ; Thu, 8 Jan 2015 07:22:24 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so3414446lbi.4 for ; Thu, 08 Jan 2015 07:22:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=30Raw071OKe3GQYj/Ghew+NHjXRUPNRuAQ9FeEO/t7w=; b=bryGCaJZoUFoOkW5Q6Br1ah6kDX9UDZow2uwF2DTvfnuzH3J6n12Q95SwcKYQcQr9P bthYDuo7iZQ7zx4OthRJQQwiJjDgaMvxMkTfhyHqZC0/9FgAjgGMpKrx7hEUQCxMv1m6 qOyhnvHqZ6fmUnvcb0FsNjmR+QJJh2gvZvR25h8YvTT45G6T67QVNe8cZNhw+Ja+oRqN yIbDS1+H/vwgy6E2VtSDf0H0DGYc5zZWcZQiwjdWkV2z6VQiEjZxty9bUJAn2hFdRRNI o4p6ZaOUKKAT5u9g3wFwsGzIkR4jOwIk/3sEt9prWeQqJuQWLcQqQabVybE0Fypf+/Mv HKcw== X-Gm-Message-State: ALoCoQlYcqDKoAmqa05SnOplrZ8x2OZa4wjlSZ06y8mMTZ5D0DO2oumxLkPKa9M1tPJpjWvY9Pav MIME-Version: 1.0 X-Received: by 10.152.44.129 with SMTP id e1mr14600366lam.43.1420730542084; Thu, 08 Jan 2015 07:22:22 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 8 Jan 2015 07:22:22 -0800 (PST) In-Reply-To: <005b01d02ae3$17832d80$46898880$@org.cn> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> Date: Thu, 8 Jan 2015 10:22:22 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=089e0160bc38486d29050c259ba2 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:22:27 -0000 --089e0160bc38486d29050c259ba2 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 7, 2015 at 8:33 PM, Aijun Wang wrote: > [Aijun]: section 2.4 and section 10.1&10.2 of the draft > http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the process > for transferring data via the TURN server(here we select the brief > description in section 2.4 for discussion): > > ---------------------------------------------------------------------------- > ---------------------------------------------- > When using the Send mechanism, the client sends a Send indication to > the TURN server containing (a) an XOR-PEER-ADDRESS attribute > specifying the (server-reflexive) transport address of the peer and > (b) a DATA attribute holding the application data. When the TURN > server receives the Send indication, it extracts the application data > from the DATA attribute and sends it in a UDP datagram to the peer, > using the allocated relay address as the source address. Note that > there is no need to specify the relayed transport address, since it > is implied by the 5-tuple used for the Send indication. > > In the reverse direction, UDP datagrams arriving at the relayed > transport address on the TURN server are converted into Data > indications and sent to the client, with the server-reflexive > transport address of the peer included in an XOR-PEER-ADDRESS > attribute and the data itself in a DATA attribute. Since the relayed > transport address uniquely identified the allocation, the server > knows which client should receive the data. > > ---------------------------------------------------------------------------- > --------------------------------------------------- > So, from the client to TURN server, the application data is encapsulated in > the DATA attribute and also the XOR-PEER-ADDRESS should be included. But > from TURN server to the peer, it is one pure UDP datagram, there is no any > STUN attribute included, and the application data is directly on the UDP > data part. Then it is different for application data transfer between > client/server and server/peer pair. > I'll just copy my answer to your similar question in another email: That's not what will happen. There are two allocations on the same server. Conceptually, the packets will loopback from the first allocation's relayed address to the second allocation's relayed address, and will then be sent to host B over the same 5-tuple that host B initially used to send its allocate request. A server can also notice when two allocations are talking to each other and apply hairpinning optimization and avoid looping back real packets. > If we allow the communication pair connected two different TURN servers, > how > to transport application data between two TURN servers? Using send > indication or use pure UDP datagram? How does the upstream TURN server know > the transport address of the downstream TURN Server? > Peer A communicates its relayed address to peer B through ICE. Peer B includes that address in a Send indication that it sends to its own TURN server. B's server then sends a raw UDP packet to A's server. > > 2. Is it better for ICE server to determine the appropriate Relay > > > Server for two peers at the beginning of ICE connectivity check? The > > > determination process can be based on information such as the load > > > status of each Relay Server, the link usage of its interfaces and the > > > proximity of two peers(based solely on the reflex-address of each > peer). > > > > [bw] I'm not sure what you're getting at here. The 3rd party relay system > has > > the necessary information to determine whether a redirect would be > beneficial, > > so why would it make sense for something else to make that determination? > > > > [Aijun]: My concern at here is same as the above question: how the upstream > TURN server knows the transport address of downstream TURN server for one > peer? > (see above) > If ICE can determine the appropriate TURN server for the corresponding > communication pair, then there is no need the server redirect mechanism. Am > I right? > I don't see how you come to this conclusion. This mechanism has nothing to do with the 2-servers case. It applies to TURN in general. Simon --089e0160bc38486d29050c259ba2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 7, 2015 at 8:33 PM, Aijun Wang <wangaijun@tsinghua.org= .cn> wrote:
[Aijun]: section 2.4 and section 10.1&10.2 of = the draft
http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe= the process
for transferring data via the TURN server(here we select the brief
description in section 2.4 for discussion):
---------------------------------------------------------------------------= -
----------------------------------------------
When using the Send mechanism, the client sends a Send indication to
=C2=A0 =C2=A0the TURN server containing (a) an XOR-PEER-ADDRESS attribute =C2=A0 =C2=A0specifying the (server-reflexive) transport address of the pee= r and
=C2=A0 =C2=A0(b) a DATA attribute holding the application data.=C2=A0 When = the TURN
=C2=A0 =C2=A0server receives the Send indication, it extracts the applicati= on data
=C2=A0 =C2=A0from the DATA attribute and sends it in a UDP datagram to the = peer,
=C2=A0 =C2=A0using the allocated relay address as the source address.=C2=A0= Note that
=C2=A0 =C2=A0there is no need to specify the relayed transport address, sin= ce it
=C2=A0 =C2=A0is implied by the 5-tuple used for the Send indication.

=C2=A0 =C2=A0In the reverse direction, UDP datagrams arriving at the relaye= d
=C2=A0 =C2=A0transport address on the TURN server are converted into Data =C2=A0 =C2=A0indications and sent to the client, with the server-reflexive<= br> =C2=A0 =C2=A0transport address of the peer included in an XOR-PEER-ADDRESS<= br> =C2=A0 =C2=A0attribute and the data itself in a DATA attribute.=C2=A0 Since= the relayed
transport address uniquely identified the allocation, the server
=C2=A0 =C2=A0knows which client should receive the data.
---------------------------------------------------------------------------= -
---------------------------------------------------
So, from the client to TURN server, the application data is encapsulated in=
the DATA attribute and also the XOR-PEER-ADDRESS should be included. But from TURN server to the peer, it is one pure UDP datagram, there is no any<= br> STUN attribute included, and the application data is directly on the UDP data part. Then it is different for application data transfer between
client/server and server/peer pair.

I'll just copy my answer to your similar question in another email:<= /div>

That's not what = will happen. There are two allocations on the same server. Conceptually, th= e packets will loopback from the first allocation's relayed address to = the second allocation's relayed address, and will then be sent to host = B over the same 5-tuple that host B initially used to send its allocate req= uest.

A server can also notice when two allocations are talking to each oth= er and apply hairpinning optimization and avoid looping back real packets.<= /div>
=C2=A0
If we allow the communication pair connected two different TURN servers, ho= w
to transport application data between two TURN servers? Using send
indication or use pure UDP datagram? How does the upstream TURN server know=
the transport address of the downstream TURN Server?
=

Peer A communicates its relayed address to peer B throu= gh ICE. Peer B includes that address in a Send indication that it sends to = its own TURN server. B's server then sends a raw UDP packet to A's = server.

> > 2. Is it better for ICE server to determine the appropriate Relay=
> > Server for two peers at the beginning of ICE connectivity check? = The
> > determination process can be based on information such as the loa= d
> > status of each Relay Server, the link usage of its interfaces and= the
> > proximity of two peers(based solely on the reflex-address of each= peer).
>
> [bw] I'm not sure what you're getting at here. The 3rd party r= elay system
has
> the necessary information to determine whether a redirect would be
beneficial,
> so why would it make sense for something else to make that determinati= on?
>

[Aijun]: My concern at here is same as the above question: how the u= pstream
TURN server knows the transport address of downstream TURN server for one peer?

(see above)
=C2=A0
= If ICE can determine the appropriate TURN server for the corresponding
communication pair, then there is no need the server redirect mechanism. Am=
I right?

I don't see how you come to this c= onclusion. This mechanism has nothing to do with the 2-servers case. It app= lies to TURN in general.

Simon
--089e0160bc38486d29050c259ba2-- From nobody Thu Jan 8 10:15:29 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE01A8ADD for ; Thu, 8 Jan 2015 10:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Yoyqa_uzMrtl for ; Thu, 8 Jan 2015 10:15:24 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 957501A00E4 for ; Thu, 8 Jan 2015 10:15:24 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 90E4B47943 for ; Thu, 8 Jan 2015 18:15:23 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B91E447847 for ; Thu, 8 Jan 2015 18:15:21 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B55D7202E for ; Thu, 8 Jan 2015 18:15:21 +0000 (GMT) Message-ID: <54AEC939.2000908@akamai.com> Date: Thu, 08 Jan 2015 13:15:21 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:15:27 -0000 My experience in other working groups leads me to expect the proponents of a draft to make a compelling argument in favor of adding a WG milestone, rather than those with questions having to making a compelling argument against. For that reason, I was surprised to see the milestone created when it did not seem to me that there was WG consensus on the need for this effort. I'm not suggesting that all working groups must function with the same criteria for adding a milestone. I prefer a model that requires WG consensus that this is a problem that needs to be solved, but I can also accept that there are other ways of viewing the process. I'm just calling out the difference in approach so that I can be sure I understand your intention and what the expected process for milestone adoption is within this WG. On a separate note, I consider interoperability to be an important goal for the WG, and in my opinion adding new transport options works against that goal. For this reason, I would prefer to see a clear problem statement before adding a milestone for a new transport option so that we avoid unnecessary interoperability risks. I find this argument compelling, but also recognize that you and some others who have commented on the thread disagree. I'm mostly reiterating the argument because I don't think it was clearly represented in your earlier summary of the discussion. --Brandon On 01/08/2015 09:36 AM, Simon Perreault wrote: > > > On Wed, Jan 7, 2015 at 8:05 PM, Justin Uberti > wrote: > > On Thu, Dec 18, 2014 at 11:12 AM, Simon Perreault > > wrote: > > So, unless somebody makes a compelling argument against enabling > that group of interested people to work on ToWS within TRAM, we > will propose a new milestone for this work, and > adopt draft-chenxin-behave-turn-websocket as WG document. > > > I have a really hard time seeing how the WG could get behind this as > long as the problem to solve remains underspecified. A detailed > description of the problem to be solved, and an explanation of how > the new work will solve said problem, seem like clear prerequisites > for any WG-sponsored effort. > > > Yeah, it's called an "introduction section". It's not finished yet. > So... please send text. :) > > To be perfectly clear, the introduction section not being perfect yet > isn't "a compelling argument against enabling that group of interested > people to work on ToWS within TRAM". > > The TRAMsters who expressed a need for ToWS now need to work toward WG > consensus on the introduction section as a priority. A WG sends a draft > to IESG when it has reached WG consensus, not before. > > Simon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Jan 8 10:26:39 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9959A1A7005 for ; Thu, 8 Jan 2015 10:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 JkWt5cU-sL1h for ; Thu, 8 Jan 2015 10:26:35 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A2B081A00E4 for ; Thu, 8 Jan 2015 10:26:34 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 14BB0479ED; Thu, 8 Jan 2015 18:26:34 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C9FB7479F1; Thu, 8 Jan 2015 18:26:33 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id BEA3380068; Thu, 8 Jan 2015 18:26:33 +0000 (GMT) Message-ID: <54AECBD9.5010903@akamai.com> Date: Thu, 08 Jan 2015 13:26:33 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aijun Wang , "tram@ietf.org" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> In-Reply-To: <005b01d02ae3$17832d80$46898880$@org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:26:38 -0000 See inline ... On 01/07/2015 08:33 PM, Aijun Wang wrote: > Hi, Brandon: > > Please see the reply inline. > > Best Regards. > Aijun Wang. > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Thursday, January 08, 2015 5:35 AM >> To: Aijun Wang; tram@ietf.org >> Subject: Re: [tram] Fwd: New Version Notification for >> draft-williams-peer-redirect-02.txt >> >> see [bw] inline >> >> On 01/06/2015 01:14 AM, Aijun Wang wrote: >>> Hi, Brandon. >>> >>> I read your draft just and wants to ask you some question for > clarification: >>> 1. Is it possible for two peers to select different Relay Server to >>> communicate? If so, will the communication channel between the Relay >>> Server will be changed by the CHECK-ALTERNATE attribute? If not, how >>> to ensure two peers select the same Relay Server? >> >> [bw] Yes, they can select different relay servers. The mechanism doesn't > add >> any new restriction in that regard, nor does it changes the communication >> channel between the servers (there's no need for that). >> Basically, redirect would end up providing a new relay candidate and > there's >> some ongoing work in mmusic that will help ICE to make more effective use > of >> the new relay candidate. > > [Aijun]: section 2.4 and section 10.1&10.2 of the draft > http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the process > for transferring data via the TURN server(here we select the brief > description in section 2.4 for discussion): > ---------------------------------------------------------------------------- > ---------------------------------------------- > When using the Send mechanism, the client sends a Send indication to > the TURN server containing (a) an XOR-PEER-ADDRESS attribute > specifying the (server-reflexive) transport address of the peer and > (b) a DATA attribute holding the application data. When the TURN > server receives the Send indication, it extracts the application data > from the DATA attribute and sends it in a UDP datagram to the peer, > using the allocated relay address as the source address. Note that > there is no need to specify the relayed transport address, since it > is implied by the 5-tuple used for the Send indication. > > In the reverse direction, UDP datagrams arriving at the relayed > transport address on the TURN server are converted into Data > indications and sent to the client, with the server-reflexive > transport address of the peer included in an XOR-PEER-ADDRESS > attribute and the data itself in a DATA attribute. Since the relayed > transport address uniquely identified the allocation, the server > knows which client should receive the data. > ---------------------------------------------------------------------------- > --------------------------------------------------- > So, from the client to TURN server, the application data is encapsulated in > the DATA attribute and also the XOR-PEER-ADDRESS should be included. But > from TURN server to the peer, it is one pure UDP datagram, there is no any > STUN attribute included, and the application data is directly on the UDP > data part. Then it is different for application data transfer between > client/server and server/peer pair. > If we allow the communication pair connected two different TURN servers, how > to transport application data between two TURN servers? Using send > indication or use pure UDP datagram? How does the upstream TURN server know > the transport address of the downstream TURN Server? [bw] I consider the "(server-reflexive)" to be incorrect. When only one peer is using a relay, then this would be the server-reflexive or host address, but when both are using relays then it would be the relay address. > >> >>> 2. Is it better for ICE server to determine the appropriate Relay >>> Server for two peers at the beginning of ICE connectivity check? The >>> determination process can be based on information such as the load >>> status of each Relay Server, the link usage of its interfaces and the >>> proximity of two peers(based solely on the reflex-address of each peer). >> >> [bw] I'm not sure what you're getting at here. The 3rd party relay system > has >> the necessary information to determine whether a redirect would be > beneficial, >> so why would it make sense for something else to make that determination? >> > > [Aijun]: My concern at here is same as the above question: how the upstream > TURN server knows the transport address of downstream TURN server for one > peer? If ICE can determine the appropriate TURN server for the corresponding > communication pair, then there is no need the server redirect mechanism. Am > I right? [bw] The server knows the relay address of the remote peer via the XOR-PEER-ADDRESS attribute, and that is used to direct traffic to the downstream relay. The upstream relay doesn't need to know the nature of the downstream address, just that this is the address to use to get data to the peer. > >>> >>> Best Regards. >>> >>>> -----Original Message----- >>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon >>>> Williams >>>> Sent: Tuesday, December 30, 2014 6:04 AM >>>> To: tram@ietf.org >>>> Subject: [tram] Fwd: New Version Notification for >>>> draft-williams-peer-redirect-02.txt >>>> >>>> Hi all, >>>> >>>> I've just updated the peer redirect draft to provide the warning >>>> labels >>> that Ted >>>> asked for back in Toronto. I also added brief discussion of a load >>> balancing use >>>> case when adding a new flow to an existing allocation. >>>> >>>> There's some work going on both here and in mmusic related to ICE >>>> that can help provide a framework for making more effective use of >>>> this redirection capability. >>>> >>>> I hope that there might be enough interest in this draft for WG >>>> adoption >>> and >>>> would like to hear thoughts on that from the list. >>>> >>>> Thanks, >>>> --Brandon >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for >>>> draft-williams-peer-redirect-02.txt >>>> Date: Mon, 29 Dec 2014 16:53:47 -0500 >>>> From: internet-drafts@ietf.org >>>> To: Williams, Brandon , Tirumaleswar Reddy >>>> , Tirumaleswar Reddy , >>>> Williams, Brandon >>>> >>>> >>>> A new version of I-D, draft-williams-peer-redirect-02.txt >>>> has been successfully submitted by Brandon Williams and posted to the >>>> IETF repository. >>>> >>>> Name: draft-williams-peer-redirect >>>> Revision: 02 >>>> Title: Peer-specific Redirection for Traversal Using Relays >>> around NAT >>>> (TURN) >>>> Document date: 2014-12-29 >>>> Group: Individual Submission >>>> Pages: 13 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.t >>>> xt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ >>>> Htmlized: > http://tools.ietf.org/html/draft-williams-peer-redirect-02 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 >>>> >>>> Abstract: >>>> This specification describes a peer-specific redirection method > that >>>> allows the TURN server to redirect a client for the purpose of >>>> improving communication with a specific peer without negatively >>>> affecting communication with other peers. >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>> Products Engineering; Akamai Technologies Inc. >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >>> >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Jan 8 11:03:56 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C951A8FD3 for ; Thu, 8 Jan 2015 11:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 4wYlSclLLPMY for ; Thu, 8 Jan 2015 11:03:52 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8A51A008F for ; Thu, 8 Jan 2015 11:03:52 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so1771360vcb.5 for ; Thu, 08 Jan 2015 11:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=twrkqOzDjiA79nDqmw97VAfCcmmTCVgo4FNRKjxwId8=; b=L57G3a52o7ZNj+nbcU47qKkdiZ+B0fZCwuXYXDCLyGQoQ35hbET+rSnd5QuDVLlPUy KSUCO2FjpRDZL8WI2yvCNNEhf0kdj1Nir81EMPiv0KFx25H+icB+LgmnmxXUvuhg0YMh 1KaTmJm+oV0IAO7G/7O8V/iGv6j8me7Nlo74cxCUKpLbkbUU/qO593enSMmGoIKA5AIb UmMI/lFGb3TKn38r3lymwF8wV4co+2sZMCzmsrlH6Q/Rb22OkWfPH6czUZBTs75rjqy3 KHBiyYUEFmI7EXmJIyXp3s5awJacCLdzG1+17PolIqP+NUKnqePsg1Gt0D45+91R6fHx reAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=twrkqOzDjiA79nDqmw97VAfCcmmTCVgo4FNRKjxwId8=; b=XAaPOn92ll5J1edwo5iFEtGfaKDmc4nHr3FTM7APccJADKibBZB8ligGIXF85TCNmi QDf286zU/gF0bBw2uFkWsDThE1pe1YM7hNdWASqONpGdNHfFXWR3G9C8jp8qJ/3n2bqu G+tLbxDlk974+2IEJ3aQ+kWPfol2tJalspv2wdVAeMcKG7V0fiAb1Cr9gbUfcwmojjIf LFUaS52OnCdRkh+ffTbqdZJN8ft5YI0GMfdFCfYU0Y2LQE17oZ+FJ3W04Gaw2+bP8kzD GUKNK+zpN4HT20cOZWvaHuWUNjdJmylHyCIJG5/gq0Dwzn3Vh4gHQqqczS3ylu+m5jpj +vjg== X-Gm-Message-State: ALoCoQl2F+AxgQrvGDv5Gj4WnVNSAdkfdd0k7m2Silgue454NS6bmku0RqLSGca9llkBE4nIY0zT X-Received: by 10.220.127.79 with SMTP id f15mr8143315vcs.22.1420743831814; Thu, 08 Jan 2015 11:03:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 11:03:30 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 8 Jan 2015 11:03:30 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b342e1e69b36d050c28b37b Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:03:54 -0000 --047d7b342e1e69b36d050c28b37b Content-Type: text/plain; charset=UTF-8 On Thu, Jan 8, 2015 at 6:36 AM, Simon Perreault wrote: > > > On Wed, Jan 7, 2015 at 8:05 PM, Justin Uberti wrote: >> >> On Thu, Dec 18, 2014 at 11:12 AM, Simon Perreault >> wrote: >>> >>> So, unless somebody makes a compelling argument against enabling that >>> group of interested people to work on ToWS within TRAM, we will propose a >>> new milestone for this work, and adopt draft-chenxin-behave-turn-websocket >>> as WG document. >>> >> >> I have a really hard time seeing how the WG could get behind this as long >> as the problem to solve remains underspecified. A detailed description of >> the problem to be solved, and an explanation of how the new work will solve >> said problem, seem like clear prerequisites for any WG-sponsored effort. >> > > Yeah, it's called an "introduction section". It's not finished yet. So... > please send text. :) > > To be perfectly clear, the introduction section not being perfect yet > isn't "a compelling argument against enabling that group of interested > people to work on ToWS within TRAM". > I think this is being dismissive. It's not that the intro text isn't perfect, it's that we still don't understand what the point of this work is, which seems important in deciding whether the WG should spend WG time on it. Like Brandon says, I think we could have the draft move forward as an individual draft while this stuff gets sorted out. --047d7b342e1e69b36d050c28b37b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 6:36 AM, Simon Perreault <<= a href=3D"mailto:sperreault@jive.com" target=3D"_blank">sperreault@jive.com= > wrote:
<= br>

On Wed, = Jan 7, 2015 at 8:05 PM, Justin Uberti <juberti@google.com> = wrote:
<= div class=3D"gmail_quote">On Thu, Dec 18, 2014 at 11:12 AM, Sim= on Perreault <sperreault@jive.com> wrote:
So, unless some= body makes a compelling argument against enabling that group of interested = people to work on ToWS within TRAM, we will propose a new milestone for thi= s work, and adopt=C2=A0draft-chenxin-behave-turn-websocket as WG document.<= /div>

I have a re= ally hard time seeing how the WG could get behind this as long as the probl= em to solve remains underspecified. A detailed description of the problem t= o be solved, and an explanation of how the new work will solve said problem= , seem like clear prerequisites for any WG-sponsored effort.

Yeah, it's called an "introduction section". It's= not finished yet. So... please send text. :)

To be perfectly clear, the introduc= tion section not being perfect yet isn't "a compelling argument against enabling that group= of interested people to work on ToWS within TRAM".
=

I think this is being dismissive. It= 's not that the intro text isn't perfect, it's that we still do= n't understand what the point of this work is, which seems important in= deciding whether the WG should spend WG time on it.

Like Brandon says, I think we could have the draft move forward as an in= dividual draft while this stuff gets sorted out.
--047d7b342e1e69b36d050c28b37b-- From nobody Thu Jan 8 12:05:37 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3F91ACD4D for ; Thu, 8 Jan 2015 12:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 cQvlLpG0zZKV for ; Thu, 8 Jan 2015 12:05:33 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69DD1ACD2F for ; Thu, 8 Jan 2015 12:05:19 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so4791835lbd.9 for ; Thu, 08 Jan 2015 12:05:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o80CvtsxHDZ5IjOIuFSmAnVAl8DFYUNNOpeiFyVsa4w=; b=gnisyhuFJCDtyAC+vzZ56vLYSIvfWbIHe4J/xZuJNw0YbKrCxkDVnfF0jNltkegJUI 6WG7uEi+rB9hfOi+vVZlFtKH+tGZESGdaTam/9UWJ35314JAErNZ6nVtgwFbWgdV8bdm iAM1U8hORp9wmAZpqS6JAN9xU5rJ3LKrvOOdheU3hBkO7/x7Cqu74KLiDbZUOsildHoa zDFdxg4iJx7DpM5xKAEvWk02dtTlwzL8NOF2e8buVw/K4e3lqYdleWtSP0BYe8Z5fqhR txS3LSmiN7O+vAUwOcg7jv7+1mNC02nit7A2Glz4Lp7Rxld8PCssWcZuBhyibeazWCuF HBVQ== X-Gm-Message-State: ALoCoQlyVOiLX0S3VQwvxK7fL3tj7HMbrLAOiRuqRDAE9NX4mqyob8aJd+IeyrLXeiShO+DkD16m MIME-Version: 1.0 X-Received: by 10.152.8.11 with SMTP id n11mr15897511laa.38.1420747509112; Thu, 08 Jan 2015 12:05:09 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 8 Jan 2015 12:05:08 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 15:05:08 -0500 Message-ID: From: Simon Perreault To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c366e298b77d050c298ee2 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:05:35 -0000 --001a11c366e298b77d050c298ee2 Content-Type: text/plain; charset=UTF-8 Justin, Brandon, TRAMsters, I started writing a long response but erased all of it in favour of this happy, shorter one: Would anyone scream if the draft went through another revision focusing on the problem statement before getting adopted? Work needs to be done on the problem statement at one point or another, so it doesn't really change anything from an end-goal perspective. Hoping we can get back to technical arguments soon... Simon --001a11c366e298b77d050c298ee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin, Brandon, TRAMsters,

I started= writing a long response but erased all of it in favour of this happy, shor= ter one:

Would anyone scream if the draft went through another revision focusing = on the problem statement before getting adopted? Work needs to be done on t= he problem statement at one point or another, so it doesn't really chan= ge anything from an end-goal perspective.
<= br>
Hoping we can get back to technical arg= uments soon...
Simon
--001a11c366e298b77d050c298ee2-- From nobody Thu Jan 8 12:23:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21AD1A1A73 for ; Thu, 8 Jan 2015 12:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 xXKZrgb095qE for ; Thu, 8 Jan 2015 12:23:39 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1551A1A5E for ; Thu, 8 Jan 2015 12:23:38 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so1922843vcb.2 for ; Thu, 08 Jan 2015 12:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9qoSzTRIu/s+ZgoNKQdUhM6fDcNVbiQZnZQY81CL+C8=; b=AFcwu6Gfr+F6SDJX6Ln806tozLQJqhMGA9A6ToUu6nE2ge9acFJvY+2enk656PuXbS YzFqj2xRBFNCrUYF5GZhKdhIXeUQIEwC3rH57WTEiX2o1FBqFqyPFhq4wlJxFgGl2pGn 7Ilyh+PJAmnanzF2YCLXEgeDqVOYPVbT8VoFgzonRvoa/Pu1+OrBFnH34oQachL0QLwC 4FHbAtpdwmooe89tdRFbr20VPTEkaavUCJ7ix1pJSVAOqzlgIL8TjmpiJOG2Q821Us7l SlInUvnQXbRs7yY4gpEyZc8ewMOEQ4IEib0kotsYzpIuJyuZdRGBnMz05Jch2j+95bD2 jvzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9qoSzTRIu/s+ZgoNKQdUhM6fDcNVbiQZnZQY81CL+C8=; b=eh4Sn6bouk1S7y7i3bbrmR62A+jsWENBX548Jbkg/ZFkN21xROv2/uprd/7+tWTsRi fABGPredkiyMeWys6HvhsSkSqUcZd/RgxvmS7yEyXiFg1xkvL467cjVsRoE+fTrbkIFT wWSVy/7hTnGBb0JutAE9Cy3cyYcbF0RtX11o0PAAerDdNcm/0MasSz3u/YsSdm6HJTZv BRAHP2b0vTP6nemAiQORdAosUeQiXK7sEd0w1gHr7DafJFM/2r95YzuXXwcmoA7guaK5 sBJcjW9h8iUl//cCQhJIJ6eX2paqUCr9I4yFn+kA2IkcVKdJCl6LN7Kfw52Hgelv0fhw KJeA== X-Gm-Message-State: ALoCoQkKgNpqlJ7O9FVDk++vEVmTy18MOZtLCgMUuz9eanr9UQm2lqBp/COGhSCEUTR4y1ubg1fw X-Received: by 10.53.12.139 with SMTP id eq11mr6985323vdd.58.1420748617944; Thu, 08 Jan 2015 12:23:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 12:23:17 -0800 (PST) In-Reply-To: <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> From: Justin Uberti Date: Thu, 8 Jan 2015 12:23:17 -0800 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary=001a1134a3f2b02ea1050c29d047 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:23:42 -0000 --001a1134a3f2b02ea1050c29d047 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang wrote: > Hi, Justin, > > > > Is it more straightforward to define one new attribute that named > =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F and > OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this attribut= e > will be assigned the relay address that is the same type as seen from the > source address of =E2=80=9CAllocate Request=E2=80=9D packet, not default = in IPv4 relay > address. > I suppose this could be a third option (c), in addition to (a) multiple R-A-F and (b) multiple optional-a-f. Here's how a/b/c look on the wire when requesting v4+v6 simultaneously. If requesting v4 or v6 only for some reason, a/b/c would all send a single RAF. a: RAF (v4) + RAF (v6) a1: server is 5766: error (RAF required-comprehension but unknown) a2: server is 6156: v4 address, or error (undefined behavior) a3: server is SSODA: v4 address + v6 address b: OAF (v4) + OAF (v6) b1: server is 5766/6156: v4 address (OAF ignored) b2: server is SSODA: v4 address + v6 address c: AAF (v6) c1: server is 5766/6156: v4 address (AAF ignored) c2: server is SSODA: v4 address + v6 address Note that for c), one could send RAF(v4) + AAF(v6), but since that would fail on a 5766 server, sending just AAF(v6) would be preferable. Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 server would return a v4 address, which is slightly inelegant. For either b/c, we would need to say that including both RAF and OAF/AAF for the same address family is prohibited. b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the default AF), but feels a bit more complicated than c). I am supportive of either b)/c), with maybe a slight preference for c). > > For reducing the port resource consumption on TURN server that described > in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have > another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite= / > that can mitigate the ip address/port allocation burden on TURN > server------All endpoints that under one TURN server can use the same > IPv4/IPv6 relay address/port. > The port consumption is a side benefit; the primary benefit of SSODA is the reduction in the overall number of candidates. > > > Best Regards. > > Aijun Wang. > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Thursday, January 08, 2015 12:02 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* [SPAM] Re: [tram] SSODA in TURN-bis > > > > I promised I would write up a summary of the current mechanism, and what > we could do instead, so here goes: > > > > The currently documented mechanism is to send two R-A-F attributes in the > request, and get back either a single address (from legacy servers), v4 + > v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new > servers that only support one address family), or an error-code (to > indicate complete failure). > > > > At the time, there were 2 concerns listed, namely: > > 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may > fail the request completely, or do other weird things. > > 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; > specifically, detailed error information cannot be included. > > > > I also thought of a 3rd problem: > > 3) an old(5766) server may fail the request completely, due to the fact > that R-A-F is comprehension-required. Thus an extra roundtrip may be need= ed > in this case, negating one of the benefits of SSODA. > > > > I think the ideal solution to #1/#3 is to add a new > OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but > comprehension-optional, where multiple values are explicitly supported. O= ld > servers can safely ignore this and will return IPv4 (solving #3), while n= ew > servers can process this to return multiple XOR-RELAYED-ADDRESSes in the > response. > > #2 is not a serious issue, but it could easily be solved by defining a ne= w > ADDRESS-ERROR-CODE as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family | Rsvd |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Then a server could return a normal IPv4 address, but a error code for IP= v6 with either 440 (unsupported address family) or 508 (insufficient capaci= ty) or some other TBD error. > > > > I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple an= d prevents potential interoperability problems with old servers. I could go= either way on ADDRESS-ERROR-CODE. > > > > > > > > On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi all, > > > > We are working on incorporating RFC6156 and SSODA into TURN-bis. During > IETF-91 meeting there was discussion if the technique proposed in > https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break > existing TURN server implementations. Pal had mentioned testing with fou= r > implementations and did not face any problem. > > > > Please let us know if there are any concerns with the existing proposal o= f > conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribut= e > values in Allocate request ? > > > > Cheers, > > -Tiru > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --001a1134a3f2b02ea1050c29d047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <wangaijun@tsinghu= a.org.cn> wrote:

Hi, Justin,

=C2=A0

Is it more straightforward to define one new attribute = that named =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-= F and=C2=A0 OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include thi= s attribute will be assigned the relay address that is the same type as see= n from the source address of =E2=80=9CAllocate Request=E2=80=9D packet, not= default in IPv4 relay address.

I suppose this could be a third option (c), in addition to (a) = multiple R-A-F and (b) multiple optional-a-f.=C2=A0 Here's how a/b/c lo= ok on the wire when requesting v4+v6 simultaneously. If requesting v4 or v6= only for some reason, a/b/c would all send a single RAF.

a: RAF (v4) + RAF (v6)
a1: server is 5766: error (RAF req= uired-comprehension but unknown)
a2: server is 6156: v4 address, = or error (undefined behavior)
a3: server is SSODA: v4 address= + v6 address
b: OAF (v4) + OAF (v6)
b1: server is 5766= /6156: v4 address (OAF ignored)
b2: server is SSODA: v4 address += v6 address
c: AAF (v6)
c1: server is 5766/6156: v4= address (AAF ignored)
c2: server is SSODA: v4 address + v6 addre= ss

Note that for c), one could send RAF(v4) + = AAF(v6), but since that would fail on a 5766 server, sending just AAF(v6) w= ould be preferable.
Note that for b), if one sent OAF(v6) by itse= lf for some reason, a 5766 server would return a v4 address, which is sligh= tly inelegant.
For either b/c, we would need to say that includin= g both RAF and OAF/AAF for the same address family is prohibited.

b) is nice in that it avoids implicit behavior (i.e. that I= Pv4 is the default AF), but feels a bit more complicated than c). I am supp= ortive of either b)/c), with maybe a slight preference for c).

=

=C2=A0

For reducing the po= rt resource consumption on TURN server that described in https= ://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have another p= roposal http://datatracker.ietf.org/doc/draft-wang-tram-turnli= te/ that can mitigate the ip address/port allocation burden on TURN ser= ver------All endpoints that under one TURN server can use the same IPv4/IPv= 6 relay =C2=A0address/port.


The port consumption is a side benefit; the primary benefit of SSOD= A is the reduction in the overall number of candidates.

=C2=A0

Best Regards.

Aijun Wang.

=C2=A0=

From: = tram [mailto:tra= m-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: T= hursday, January 08, 2015 12:02 PM
To: Tirumaleswar Reddy (tiredd= y)
Cc: tram@ie= tf.org
Subject: [SPAM] Re: [tram] SSODA in TURN-bis=

=C2=A0

I promised I would write up a summary of the curren= t mechanism, and what we could do instead, so here goes:

=C2=A0=

The curre= ntly documented mechanism is to send two R-A-F attributes in the request, a= nd get back either a single address (from legacy servers), v4 + v6 addresse= s (from new servers), a single address + a 0.0.0.0/:: (for new servers that only support one address= family), or an error-code (to indicate complete failure).

=C2= =A0

At the time, there were 2 concerns listed, namely:

1) sending multiple= R-A-Fs is undefined behavior; old (6156) servers may fail the request comp= letely, or do other weird things.

2) using 0.0.0.0/:: to indicate partial success is somewhat un= clean; specifically, detailed error information cannot be included.<= u>

= =C2=A0

I also thought of a 3rd problem:

3) an old(5766) server may fai= l the request completely, due to the fact that R-A-F is comprehension-requi= red. Thus an extra roundtrip may be needed in this case, negating one of th= e benefits of SSODA.

=C2=A0

I think the ideal solution to #1/#3 is = to add a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but comp= rehension-optional, where multiple values are explicitly supported. Old ser= vers can safely ignore this and will return IPv4 (solving #3), while new se= rvers can process this to return multiple XOR-RELAYED-ADDRESSes in the resp= onse.

#2 is not a serious issue, but it could easily be solved by defi= ning a new ADDRESS-ERROR-CODE as follows:

=C2=A0

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Address Family=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0 Rsvd=C2=A0 |Class|=C2=A0=C2=A0=C2=A0=C2=A0 Number=C2=A0=C2=A0=
=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Reason Phrase (variable)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 ..
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0
Th=
en a server could return a normal IPv4 address, but a error code for IPv6 w=
ith either 440 (unsupported address family) or 508 (insufficient capacity) =
or some other TBD error.<=
u>
<=
u>=C2=A0
I advocate we do the OPTIONAL-ADD=
RESS-FAMILY attribute as it is simple and prevents potential interoperabili=
ty problems with old servers. I could go either way on ADDRESS-ERROR-CODE.<=
/span>
=C2=A0
=C2=A0

=C2=A0

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy= ) <tireddy@cisco.= com> wrote:

Hi all,

=C2=A0

We are working on incorporating RFC6156 and SSODA in= to TURN-bis. During IETF-91 meeting there was discussion if the technique p= roposed in https://tools.ietf.org/html/draft-martinsen-tram-ss= oda-01 would break existing TURN server implementations.=C2=A0 Pal had = mentioned testing with four implementations and did not face any problem.

=C2=A0

Please l= et us know if there are any concerns with the existing proposal of conveyin= g two REQUESTED-ADDRESS-FAMILY attributes with different attribute values i= n Allocate request ?

=C2=A0

Cheers,

-Tiru


________________= _______________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mai= lman/listinfo/tram

=C2=A0


--001a1134a3f2b02ea1050c29d047-- From nobody Thu Jan 8 12:25:31 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7374A1ACD71 for ; Thu, 8 Jan 2015 12:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 P0522tTHDHfV for ; Thu, 8 Jan 2015 12:25:27 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F2B1A1A73 for ; Thu, 8 Jan 2015 12:25:27 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so1919114vcb.8 for ; Thu, 08 Jan 2015 12:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dQtmEtmF6ndqziX8Jyv9xRrnuVpbOaOZUEG7JyP7T2k=; b=SBo1lmTvxW7RD5IrIC3EbJ7ZLy+WkAmGo+ilgrHWTcbyLAhdbA32EJvLkIacW3gJK5 XUxxATGF3AeT9mn++aMAgJN2ubzwasjTNfwjON4lNZ8f1BvHP0OjgipMhreaRYfh+k9u xrA0V6+L45Hh3og0l781E1r13xjtkPNwW6t+gNXdYx279Z/Xam80byeWPuD9SoVw9NFY bfAvyHFC6TnPKzGXtM6MF7d+IHWdXOPTX30Zzq8tXlH6LvpjAGafcTJa5wnMITzPCFv8 gQrtf2fq8cdEiEwSCa1ar0dMn8mu2/eFkRhPdSrFTjpEnCg6OlmesI70c6ptuRxnqww5 ktFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dQtmEtmF6ndqziX8Jyv9xRrnuVpbOaOZUEG7JyP7T2k=; b=clr0wHZPoOqO6b9lsvpFqjhouaouZvuiOcTHu8rSH9qwQRz1qKUQZ32pVFaZu/LFT+ 5WqmXLKJJqPT7zasNwhwzNlRf0pRRaL2Ggf6XqhOvPwGn4oYmtq5GeZkMJYZe3+joi2p dOZnuLVfV2pN7LwuYMS1qjNNpG+uXPAPjZb85JWgZFXc5v3eIbQ1fMPno5bGzdMk8Rxq fMu2E/HC3p7+CaFi0yF6N+oIcrTOm/BIRYD0XLQFqeTskvZNmYIzP1CyZ3dgG7eB4S1g w8zh8Me7+JC7dd00WLX1zQnStL2IiOrbOH14jRlG1Yxfbu92uKRqwvwLAx2awkvZYkVj feGw== X-Gm-Message-State: ALoCoQlvaYVWWG0JmJLddaoUnkEwZ1mgY1vIJgdbCvcRZngpKK/s8L7Us5XiZXG+wcZEK/oThPed X-Received: by 10.52.97.9 with SMTP id dw9mr7047252vdb.4.1420748726332; Thu, 08 Jan 2015 12:25:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 12:25:06 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 8 Jan 2015 12:25:06 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf307f3186260fc2050c29d700 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:25:28 -0000 --20cf307f3186260fc2050c29d700 Content-Type: text/plain; charset=UTF-8 Sounds good to me. On Thu, Jan 8, 2015 at 12:05 PM, Simon Perreault wrote: > Justin, Brandon, TRAMsters, > > I started writing a long response but erased all of it in favour of this > happy, shorter one: > > Would anyone scream if the draft went through another revision focusing on > the problem statement before getting adopted? Work needs to be done on the > problem statement at one point or another, so it doesn't really change > anything from an end-goal perspective. > > Hoping we can get back to technical arguments soon... > Simon > --20cf307f3186260fc2050c29d700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me.

On Thu, Jan 8, 2015 at 12:05 PM, Simon Perreault <sperreault@jive.com> wrote:
Justin, Brandon, TRAMsters,<= /div>

I star= ted writing a long response but erased all of it in favour of this happy, s= horter one:

Would anyone scream if the draft went through another revision focusi= ng on the problem statement before getting adopted? Work needs to be done o= n the problem statement at one point or another, so it doesn't really c= hange anything from an end-goal perspective.

Hoping we can get back to technical = arguments soon...
Simon

--20cf307f3186260fc2050c29d700-- From nobody Thu Jan 8 14:34:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86681A0177 for ; Thu, 8 Jan 2015 14:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 h6sAr1j7KSgl for ; Thu, 8 Jan 2015 14:34:44 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAE81A0095 for ; Thu, 8 Jan 2015 14:34:43 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hy10so2146694vcb.0 for ; Thu, 08 Jan 2015 14:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Cxq1pSgdr4AS1pVCtwFm6PrDW81HI3LSbo2MHGBV8vc=; b=UK7hDboxsWZFUYdC72jCUG2sLfXeOi/MoEULSMJBwqGRNaU2fYbZTwKFU8Qcq95eVO a3nUZ7g5VlwdtkmD1ynPNwObfqwnXI5M3c1SaZDS4XRs0cjuosGSMmJdr0BO+V0LN+vV /4VpRmY0PQhzbCeuF+Xq3I3gT/X14NznmrVEB4afQ516dL3JbnZD2AJQUw7m4lns6Fct r+I1582f0wXjtKWiwBq3977qIUQG6TaQiBczy9zxBneoRBH/BZOFQsu8cidK+QGehp4l hmBDh4egnV0m3B9Y0y7cUTUDhyaMnuuNGoXAmJahzSuTCu/gOv4UYXGGRMixqIyYpjbt 0QNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Cxq1pSgdr4AS1pVCtwFm6PrDW81HI3LSbo2MHGBV8vc=; b=XrCuqlF7CFZwnu29ahoGyRcnMFosef3NlvCEyWxBd/vA/A0kkDjJsagSrSg9gFYxmN Uw0ONZ2N/JLW3GIOInYzdQBXt5dt3kRJDPNg/bCMVOJKnxiYAmLRiNUSH94aMFmm43kD Eo7Sp4CUq2hYq2RzPYihL7aX4qBoR3wQn0Ht19fiY95OxgT1oOWYrauW0Z7JiMYP+JUk NAC+2l0ogZCtDPL6X8L5b9hjtn6qFwORabEyB6MRELhXHD8CRiS8goNNoLyjAKI1klhd dYh0FE6l4Jig0E6t3f5cyUxTrTkEcx3ShE123vFY1w/cQ7BiORy6LHEESRHuVZiyE+6x p1Vw== X-Gm-Message-State: ALoCoQk7TPFYuiOCVwQjpusdVdD3c8YIXkqH6KC+ExAe82IlCtFvj5BsMzjVH+WjozY5Ik80t2Oz X-Received: by 10.220.89.132 with SMTP id e4mr8628868vcm.2.1420756482893; Thu, 08 Jan 2015 14:34:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 14:34:22 -0800 (PST) From: Justin Uberti Date: Thu, 8 Jan 2015 14:34:22 -0800 Message-ID: To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a8a2079c8de050c2ba5c2 Archived-At: Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 22:34:46 -0000 --047d7b3a8a2079c8de050c2ba5c2 Content-Type: text/plain; charset=UTF-8 At IETF 91, I promised to send feedback on this document, so here goes. Generally, I think many of the issues mentioned in this document are important, but the recommendations are confusing and possibly contradictory; a developer with little knowledge of TURN will have a hard time figuring out exactly what to do. Furthermore, many of the properties discussed in this document are dynamic, and should be handled by the ICE process, rather than in TURN server selection (for example, the notion of RTT as it relates to user experience). Therefore, I think this document should take a stronger stance and put forth explicit best practices for selection (as opposed to "things to consider"), for non-dynamic properties, and leave the decisions on dynamic properties to be resolved by ICE. For example, I think we should omit the text in Section 3 about what to do with non-working TURN servers, and measuring RTT. Same for Section 3.3, which also discusses RTT, and Section 3.4, which talks about multiple interfaces. This can all be handled by ICE. In addition, the sections on local config and location privacy are unnecessary when RETURN is used. When RETURN is used, the application can always use the app TURN server for location privacy, and the relationship between local TURN server and app TURN server is fully spelled out, so there is nothing for the application to decide on. This leaves only the Security, Authentication, and Mobility sections. For security, I think we can give some clear guidance on what applications should do. For security, I think the guidance should be to use only DTLS + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback may be contraindicated, but at this point in time, DTLS deployment isn't widespread enough to truly recommend this. This relates to the Authentication section - but I think any failures to authenticate the server cert should cause the TURN allocation to fail. This is just like any other misconfiguration on the TURN server - there's no reason we should even allow use of TURN servers whose cert chains don't validate. So, this section could probably be removed. Lastly, the Mobility section says that if "all other parameters [are] equal", a TURN server with mobility should be used. Clearly, all other parameters will not be equal (e.g. RTT), and even if they were, the client has no way to know if a server is mobility-capable a priori. So I think this recommendation ought to be removed, or perhaps turned into some sort of recommendation for TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), probably in a separate doc. These recommendations should reduce the size of this document and provide much clearer advice to app developers. --047d7b3a8a2079c8de050c2ba5c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At IETF 91, I promised to send feedback on this document, = so here goes.

Generally, I think many of the issues ment= ioned in this document are important, but the recommendations are confusing= and possibly contradictory; a developer with little knowledge of TURN will= have a hard time figuring out exactly what to do. Furthermore, many of the= properties discussed in this document are dynamic, and should be handled b= y the ICE process, rather than in TURN server selection (for example, the n= otion of RTT as it relates to user experience).

Th= erefore, I think this document should take a stronger stance and put forth = explicit best practices for selection (as opposed to "things to consid= er"), for non-dynamic properties, and leave the decisions on dynamic p= roperties to be resolved by ICE.=C2=A0

For example= , I think we should omit the text in Section 3 about what to do with non-wo= rking TURN servers, and measuring RTT. Same for Section 3.3, which also dis= cusses RTT, and Section 3.4, which talks about multiple interfaces. This ca= n all be handled by ICE.

In addition, the sections= on local config and location privacy are unnecessary when RETURN is used. = When RETURN is used, the application can always use the app TURN server for= location privacy, and the relationship between local TURN server and app T= URN server is fully spelled out, so there is nothing for the application to= decide on.

This leaves only the Security, Authent= ication, and Mobility sections.=C2=A0

For security= , I think we can give some clear guidance on what applications should do. F= or security, I think the guidance should be to use only DTLS + TLS, if both= are available, with fallback to UDP or TCP if DTLS or TLS aren't avail= able. If privacy is paramount, UDP/TCP fallback may be contraindicated, but= at this point in time, DTLS deployment isn't widespread enough to trul= y recommend this.

This relates to the Authenticati= on section - but I think any failures to authenticate the server cert shoul= d cause the TURN allocation to fail. This is just like any other misconfigu= ration on the TURN server - there's no reason we should even allow use = of TURN servers whose cert chains don't validate. So, this section coul= d probably be removed.

Lastly, the Mobility sectio= n says that if "all other parameters [are] equal", a TURN server = with mobility should be used. Clearly, all other parameters will not be equ= al (e.g. RTT), and even if they were, the client has no way to know if a se= rver is mobility-capable a priori. So I think this recommendation ought to = be removed, or perhaps turned into some sort of recommendation for TURN ser= ver developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support m= obility, SHOULD support redirect), probably in a separate doc.
These recommendations should reduce the size of this document = and provide much clearer advice to app developers.
--047d7b3a8a2079c8de050c2ba5c2-- From nobody Thu Jan 8 17:56:18 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF591A702C for ; Thu, 8 Jan 2015 17:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 JHBYYy-iy3zm for ; Thu, 8 Jan 2015 17:56:13 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 82EF51A1A32 for ; Thu, 8 Jan 2015 17:56:12 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06C7UwT5H69UKpCrAA==.3671S4; Fri, 09 Jan 2015 08:25:47 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <913383AAA69FF945B8F946018B75898A355276B9@xmb-rcd-x10.cisco.com> <00bb01d02a5d$6f65c4d0$4e314e70$@org.cn> <009001d02b0a$59cd52c0$0d67f840$@org.cn> In-Reply-To: Date: Fri, 9 Jan 2015 09:55:42 +0800 Message-ID: <006601d02baf$68e31c90$3aa955b0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D02BF2.77065C90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdArSYeFTiB2HmlsRLe58aABU0UN4wAXWSgg Content-Language: zh-cn X-CM-TRANSID: Z0GX06C7UwT5H69UKpCrAA==.3671S4 X-Coremail-Antispam: 1U3129KBjvJXoW3GrWfWFykZF1xKw15Kr45Jrb_yoW3uw13pa y5Gry3Gwn5Jr42yrs7Zw4xWr1F9a95CFWUJrykKry7Aws8KFySkF9akw1Yva47Cr1kZa12 qr42vw4DG3W5Z3DanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjHCb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwCY1x0262kK e7AKxVWUAVWUtwC2zVAF1VAY17CE14v26r126r1D0xZFpf9x0JUG1v3UUUUU= Archived-At: Cc: "'Pal Martinsen \(palmarti\)'" , 'Varun Singh' , tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Brandon Williams' Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 01:56:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0067_01D02BF2.77065C90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Simon, =20 Please see again the reply below. =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Thursday, January 08, 2015 11:15 PM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); Brandon Williams; Pal Martinsen = (palmarti); tram@ietf.org; Varun Singh Subject: Re: [tram] New Version Notification for = draft-reddy-tram-stun-path-data-00.txt =20 =20 =20 On Thu, Jan 8, 2015 at 1:14 AM, Aijun Wang = wrote: =E3=80=90Aijun=E3=80=91: The upper layer can get such information via = its data sending and responding naturally in real time. =20 But how would that work? Assuming the upper layer is RTP, and you want = to modify it so that it measures path RTTs. Wouldn't that enhanced RTP = upper layer then make use of this draft to make its measurements? What = alternative are you concretely proposing? =20 [Aiiun] RFC3550 for RTP has the following description: The data transport is augmented by a control protocol (RTCP) to allow = monitoring of the data delivery in a manner scalable to large multicast = networks, and to provide minimal control and identification = functionality. =20 And the Sender Report RTCP Packet and Receiver Report RTCP Packet that = described in section 6.4.1 and 6.4.2 of this RFC illustrate the detail = information that can be gathered by RTCP. Is it sufficient enough for = RTP upper layer? =20 In general no, it's not sufficient. Off the top of my head: =20 - You need the special flavour of RTP that multiplexes RTP and RTCP on = the same 5-tuple. =20 [Aijun]: RTP and RTCP use the different 5-tuple, please see RFC3550, = section 11, that is described as below: =20 =E2=80=A6=E2=80=A6RTP relies on the underlying protocol(s) to provide = demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port = number=E2=80=A6=E2=80=A6 =20 - You need the special flavour of RTP, MPRTP, that could work with = multiple paths simultaneously. =20 [Aijun]: As Reddy pointed out in previous mail, the original purpose for = the path characteristic detection is to utilize the multipath of the = available interfaces, so is this one extra requirement? =20 Now, consider other upper-layer protocols that would need to implement = that additional functionality as well. Why wouldn't it make sense that = ICE provide this service for them? =20 [Aijun]: Except RTP, which other upper-layer protocols will use this = path characteristic then? Even if it may be used by other on-coming = protocol, I suggest this information should be gathered by the network = operator and feedback them to the APP provider, as the work done by ALTO = group.=20 =20 =E3=80=90Aijun=E3=80=91: 1. Does current ICE consider the communication = scenarios that one IPv4-only endpoint wants to talks to one IPv6-only = endpoint? =20 Yes. [RFC6156] =20 [Aijun]: The function that described in RFC6156 for packet translation = is needed for IPv4-Only host to communicate with IPv6-Only host, but the = procedure should be re-clarified. For example, when will the endpoint = send the =E2=80=9CAllocate Request=E2=80=9D that includes = =E2=80=9CREQUSTED-ADDRESS-FAMILY=E2=80=9D attribute to require one relay = address different from its supported address type?=20 =20 An ICE node should always gather both IPv4 and IPv6 relayed candidates. =20 See also: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.2 https://tools.ietf.org/html/rfc6157#section-4=20 =20 [Aijun]: There is no detail description in these sections to answer the = above question. It mentioned only =E2=80=9Cshould=E2=80=9D, but not = =E2=80=9Cwhen=E2=80=9D. Specially, in = https://tools.ietf.org/html/rfc6157#section-4, it describes as below: A direct offer/answer exchange between an IPv4-only user agent and an IPv6-only user agent does not result in the establishment of a session. The IPv6-only user agent wishes to receive media on one or more IPv6 addresses, but the IPv4-only user agent cannot send media to these addresses, and generally does not even understand their format. Consequently, user agents need a means to obtain both IPv4 and IPv6 addresses to receive media and to place them in offers and answers. so, where is the procedures to accomplish the communication task between = the IPv4-Only node and IPv6-Only node? =20 2. Can ICE solve the TCP-NAT traversal in BEHAVE-compliant NAT = environment in one determined manner, not the possible success rate via = trying every pair of check list? =20 I don't understand what you mean. If the NAT is BEHAVE-compliant, then = ICE will pick the STUN candidate. What is missing? =20 [Aijun]: http://tools.ietf.org/html/rfc6544#appendix-A = =E2=80=9CLimitations of ICE TCP=E2=80=9D give more detail description = that related to the above two questions. RFC6544 gives only the = simultaneous-open solution for TCP NAT transversal, but its success rate = is not 100%, even under the BEHAVE-compliant environment. =20 How is that well-known limitation problematic? [Aijun]: There are methods to assure the 100% success of TCP NAT = transverse under BEHAVE-compliant NAT environment. ICE does not solve = it, this is the problematic. =20 3. Does ICE mention how to make sure the relayed packet to pass = through the non-BEHAVE-compliant NAT device? Especially for TCP = protocol? =20 I don't understand what you mean. Can you be more specific? Perhaps = illustrate with an example? =20 [Aijun]: Here is one example: 1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint = Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A = is behind NAT-A, and Host B is behind NAT-B 2. Host A and Host B all send the =E2=80=9CAllocation Request=E2=80=9D = to the TURN server=E2=80=99s well-known address, to get its relayed = address respectively. At the same time, they all punch one TCP hole at = NAT-A and NAT-B, but this TCP hole will only receive the packet from the = TURN server=E2=80=99s well-known transport address, this is the behavior = of EDM type NAT. 3. when Host A send data traffic to Host B, via the TURN server. The = TURN server will change the packet source address to Host A=E2=80=99s = relay address, which is allocated in step 2. =20 That's not what will happen. There are two allocations on the same = server. Conceptually, the packets will loopback from the first = allocation's relayed address to the second allocation's relayed address, = and will then be sent to host B over the same 5-tuple that host B = initially used to send its allocate request. =20 A server can also notice when two allocations are talking to each other = and apply hairpinning optimization and avoid looping back real packets. =20 [Aijun]: No. There is only one allocation on TURN server for each = client. Actually, there are two address in TURN server, one is the = =E2=80=9CRelayed Transport Address=E2=80=9D for every client, the other = is =E2=80=9CTURN Server Transport Address=E2=80=9D that is same to every = client. (please refer to the figure 1 in = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-2 ) =20 For data sending process, please refer to = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-16, that = described as below: =20 The client now sends a ChannelData message to the server with data destined for Peer B. The ChannelData message is not a STUN message, and thus has no transaction id. Instead, it has only three fields: a channel number, data, and data length; here the channel number field is 0x4000 (the channel the client just bound to Peer B). When the server receives the ChannelData message, it checks that the channel is currently bound (which it is) and then sends the data onward to Peer B in a UDP datagram, using the relayed transport address as the source transport address and 192.0.2.210:49191 (the value of the XOR- PEER-ADDRESS attribute in the ChannelBind request) as the destination transport address.=20 =20 It described clearly the =E2=80=9Crelayed transport address=E2=80=9D is = used as the source transport address, not the address that the host B = send the allocate request. So is it problematic? =20 Because the packet=E2=80=99s source address did not match any NAT table = item in NAT-B, this packet will be discard in silence. 4. Did current ICE notice this? This is same as the UDP transport, but = TCP transport maybe more complex. =20 It's exactly the same for TURN-TCP, except that a separate data = connection is used. =20 Simon ------=_NextPart_000_0067_01D02BF2.77065C90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Simon,

 

Please see again the reply below.

 

From:= Simon = Perreault [mailto:sperreault@jive.com]
Sent: Thursday, = January 08, 2015 11:15 PM
To: Aijun Wang
Cc: = Tirumaleswar Reddy (tireddy); Brandon Williams; Pal Martinsen = (palmarti); tram@ietf.org; Varun Singh
Subject: Re: [tram] New = Version Notification for = draft-reddy-tram-stun-path-data-00.txt

<= p class=3DMsoNormal> 

 

 

On Thu, Jan 8, 2015 at 1:14 AM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

=E3=80=90Aijun=E3=80=91: The upper = layer can get such information via its data sending and responding = naturally in real time.

 

But how would that work? Assuming the upper layer is RTP, = and you want to modify it so that it measures path RTTs. Wouldn't that = enhanced RTP upper layer then make use of this draft to make its = measurements? What alternative are you concretely = proposing?

 

[Aiiun] RFC3550 for RTP has the following description:

The data transport is = augmented by a control protocol (RTCP) to allow monitoring of the data = delivery in a manner scalable to large multicast networks, and to = provide minimal control and identification functionality.

 

And the Sender Report RTCP Packet and Receiver Report RTCP Packet = that described in section 6.4.1 and 6.4.2 of this RFC illustrate the = detail information that can be gathered by RTCP. Is it sufficient enough = for RTP upper layer?

 

In general no, it's not sufficient. = Off the top of my head:

 

- You need the special flavour of = RTP that multiplexes RTP and RTCP on the same = 5-tuple.

 

[Aijun]: RTP and RTCP use the different 5-tuple, please see RFC3550, = section 11, that is described as below:

 

=E2=80=A6=E2=80=A6RTP relies on the underlying protocol(s) to provide = demultiplexing of

=C2=A0=C2=A0 RTP data and RTCP control streams.=C2=A0 For UDP and = similar protocols,

=C2=A0=C2=A0 RTP SHOULD use an even destination port number and the = corresponding

=C2=A0=C2=A0 RTCP stream SHOULD use the next higher (odd) destination = port number=E2=80=A6=E2=80=A6

 

- You need the special flavour of RTP, MPRTP, that could = work with multiple paths simultaneously.

 

[Aijun]: As Reddy pointed out in previous mail, the original purpose = for the path characteristic detection is to utilize the multipath of the = available interfaces, so is this one extra = requirement?

 

Now, consider other upper-layer = protocols that would need to implement that additional functionality as = well. Why wouldn't it make sense that ICE provide this service for = them?

 

[Aijun]: Except RTP, which other upper-layer protocols will use this = path characteristic then? =C2=A0Even if it may be used by other = on-coming protocol, I suggest this information should be gathered by the = network operator and feedback them to the APP provider, as the work done = by ALTO group.

 

=E3=80=90Aijun=E3=80=91: 1. Does = current ICE consider the communication scenarios that one IPv4-only = endpoint wants to talks to one IPv6-only = endpoint?

 

Yes. [RFC6156]

 

[Aijun]: The function that described in RFC6156 for packet = translation is needed for IPv4-Only host to communicate with IPv6-Only = host, but the procedure should be re-clarified. For example, when will = the endpoint send the =E2=80=9CAllocate Request=E2=80=9D that includes = =E2=80=9CREQUSTED-ADDRESS-FAMILY=E2=80=9D attribute to require one relay = address different from its supported address type? 

 

An ICE node should always gather = both IPv4 and IPv6 relayed = candidates.

 

See = also:

 

[Aijun]: There is no detail description in these sections to answer = the above question. It mentioned only =E2=80=9Cshould=E2=80=9D, but not = =E2=80=9Cwhen=E2=80=9D. =C2=A0Specially, in https://tools.ietf= .org/html/rfc6157#section-4, = it describes as below:

A direct offer/answer exchange between an = IPv4-only user agent and an

=C2=A0=C2=A0 IPv6-only user agent does not = result in the establishment of a

=C2=A0=C2=A0session.=C2=A0 The IPv6-only = user agent wishes to receive media on one or

=C2=A0=C2=A0 more IPv6 addresses, but the = IPv4-only user agent cannot send media

=C2=A0=C2=A0 to these addresses, and = generally does not even understand their

=C2=A0=C2=A0 format.=C2=A0 Consequently, user = agents need a means to obtain both IPv4

=C2=A0=C2=A0 and IPv6 addresses to receive = media and to place them in offers and

=C2=A0=C2=A0 answers.

so, where is the procedures to accomplish the communication task = between the IPv4-Only node and IPv6-Only node?

 

         2. Can ICE solve the = TCP-NAT traversal in BEHAVE-compliant NAT environment in one determined = manner, not the possible success rate via trying every pair of check = list?

 

I don't understand what you mean. If the NAT is = BEHAVE-compliant, then ICE will pick the STUN candidate. What is = missing?

 

[Aijun]: http://tools.ietf.org/html/rfc6544#appendix-A = =E2=80=9CLimitations of ICE TCP=E2=80=9D give more detail description = that related to the above two questions. RFC6544 gives only the = simultaneous-open solution for TCP NAT transversal, but its success rate = is not 100%, even under the BEHAVE-compliant environment.

 

How is that well-known limitation = problematic?

[Aijun]: There are methods to assure the 100% success of TCP NAT = transverse under BEHAVE-compliant NAT environment.=C2=A0 ICE does not = solve it, this is the problematic.

 

         3. Does ICE mention how = to make sure the relayed packet to pass through the non-BEHAVE-compliant = NAT device? Especially for TCP = protocol?

 

I don't understand what you mean. Can you be more specific? = Perhaps illustrate with an example?

 

[Aijun]: Here is one example:

1. Suppose Host A and Host B are all behind EDM type NAT(Endpoint = Dependent Map NAT, also non-BEHAVE compliant NAT) devices, that Host A = is behind NAT-A, and Host B is behind NAT-B

2. Host A and Host B all send the =E2=80=9CAllocation = Request=E2=80=9D to the TURN server=E2=80=99s well-known address, to get = its relayed address respectively. At the same time, they all punch one = TCP hole at NAT-A and NAT-B, but this TCP hole will only receive the = packet from the TURN server=E2=80=99s well-known transport address, this = is the behavior of EDM type NAT.

3. when Host A send data traffic to Host B, via the TURN = server.  The TURN server will change the packet source address to = Host A=E2=80=99s relay address, which is allocated in step = 2.

 

That's not what will happen. There = are two allocations on the same server. Conceptually, the packets will = loopback from the first allocation's relayed address to the second = allocation's relayed address, and will then be sent to host B over the = same 5-tuple that host B initially used to send its allocate = request.

 

A server can also notice when two = allocations are talking to each other and apply hairpinning optimization = and avoid looping back real packets.

 

[Aijun]: No. There is only one allocation on TURN server for each = client. Actually, there are two address in TURN server, one is the = =E2=80=9CRelayed Transport Address=E2=80=9D for every client, the other = is =E2=80=9CTURN Server Transport Address=E2=80=9D that is same to every = client. (please refer to =C2=A0the figure 1 in = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-2 = )

 

For data sending = process, please refer to http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-16, = that described as below:

 

The client now sends a = ChannelData message to the server with data

=C2=A0=C2=A0 destined for Peer = B.=C2=A0 The ChannelData message is not a STUN = message,

=C2=A0=C2=A0 and thus has no = transaction id.=C2=A0 Instead, it has only three fields: = a

=C2=A0=C2=A0 channel number, = data, and data length; here the channel number = field

=C2=A0=C2=A0 is 0x4000 (the = channel the client just bound to Peer B).=C2=A0 When = the

=C2=A0=C2=A0 server receives = the ChannelData message, it checks that the = channel

=C2=A0=C2=A0 is currently bound = (which it is) and then sends the data onward to

=C2=A0=C2=A0 Peer B in a UDP = datagram, using the relayed transport address as = the

=C2=A0=C2=A0 source transport = address and 192.0.2.210:49191 (the = value of the XOR-

=C2=A0=C2=A0 PEER-ADDRESS = attribute in the ChannelBind request) as the = destination

=C2=A0=C2=A0 transport address. =

 

It described clearly the = =E2=80=9Crelayed transport address=E2=80=9D is used as the source = transport address, not the address that the host B send the allocate = request. So is it problematic?

 

Because the packet=E2=80=99s source address did not match any NAT = table item in NAT-B, this packet will be discard in silence.

4. Did current ICE notice this? This is same as the UDP transport, = but TCP transport maybe more complex.

 

It's exactly the same for TURN-TCP, = except that a separate data connection is = used.

 

Simon

------=_NextPart_000_0067_01D02BF2.77065C90-- From nobody Thu Jan 8 18:29:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570391A7030 for ; Thu, 8 Jan 2015 18:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.712 X-Spam-Level: *** X-Spam-Status: No, score=3.712 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_PSBL=2.7] autolearn=no 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 jxE_qRjvb3XT for ; Thu, 8 Jan 2015 18:29:09 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 65D291A7028 for ; Thu, 8 Jan 2015 18:29:08 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06ALkwWjJ69UfMqzAA==.4599S4; Fri, 09 Jan 2015 08:58:29 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> In-Reply-To: Date: Fri, 9 Jan 2015 10:28:25 +0800 Message-ID: <007701d02bb3$fb348d50$f19da7f0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01D02BF7.0957CD50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdArS54soHWeWFAZQrq8am6f/mw9bgAZHxog Content-Language: zh-cn X-CM-TRANSID: Z0GX06ALkwWjJ69UfMqzAA==.4599S4 X-Coremail-Antispam: 1U3129KBjvJXoW3GrWDKr4xKFWxtrW3uF4rKrg_yoWxAr13pF W3Gry3Jw1DJr4xArWkZw48Xr1F9a93Wr43Jr1DKr4xZws8AF17KryDKw10kryUCrWkW3Wj qr1Yva1Duwn0vrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JURE__UUUUU= Archived-At: Cc: tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 02:29:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0078_01D02BF7.0957CD50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Simon, Brandon, =20 Please see the reply below. =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Thursday, January 08, 2015 11:22 PM To: Aijun Wang Cc: Brandon Williams; tram@ietf.org Subject: Re: [tram] Fwd: New Version Notification for = draft-williams-peer-redirect-02.txt =20 =20 On Wed, Jan 7, 2015 at 8:33 PM, Aijun Wang = wrote: [Aijun]: section 2.4 and section 10.1&10.2 of the draft http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the = process for transferring data via the TURN server(here we select the brief description in section 2.4 for discussion): -------------------------------------------------------------------------= --- ---------------------------------------------- When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication. In the reverse direction, UDP datagrams arriving at the relayed transport address on the TURN server are converted into Data indications and sent to the client, with the server-reflexive transport address of the peer included in an XOR-PEER-ADDRESS attribute and the data itself in a DATA attribute. Since the relayed transport address uniquely identified the allocation, the server knows which client should receive the data. -------------------------------------------------------------------------= --- --------------------------------------------------- So, from the client to TURN server, the application data is encapsulated = in the DATA attribute and also the XOR-PEER-ADDRESS should be included. But from TURN server to the peer, it is one pure UDP datagram, there is no = any STUN attribute included, and the application data is directly on the UDP data part. Then it is different for application data transfer between client/server and server/peer pair. =20 I'll just copy my answer to your similar question in another email: =20 That's not what will happen. There are two allocations on the same = server. Conceptually, the packets will loopback from the first = allocation's relayed address to the second allocation's relayed address, = and will then be sent to host B over the same 5-tuple that host B = initially used to send its allocate request. =20 A server can also notice when two allocations are talking to each other = and apply hairpinning optimization and avoid looping back real packets. =20 [Aijun]: I also copy the answer in previous mail as below. After these = discussion, I think it is better to do one summary of our discussion in = these interactive e-mail.=20 =20 [Aijun]: No. There is only one allocation on TURN server for each = client. Actually, there are two address in TURN server, one is the = =E2=80=9CRelayed Transport Address=E2=80=9D for every client, the other = is =E2=80=9CTURN Server Transport Address=E2=80=9D that is same to every = client. (please refer to the figure 1 in = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-2 ) =20 For data sending process, please refer to = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-16, that = described as below: =20 The client now sends a ChannelData message to the server with data destined for Peer B. The ChannelData message is not a STUN message, and thus has no transaction id. Instead, it has only three fields: a channel number, data, and data length; here the channel number field is 0x4000 (the channel the client just bound to Peer B). When the server receives the ChannelData message, it checks that the channel is currently bound (which it is) and then sends the data onward to Peer B in a UDP datagram, using the relayed transport address as the source transport address and 192.0.2.210:49191 (the value of the XOR- PEER-ADDRESS attribute in the ChannelBind request) as the destination transport address.=20 =20 It described clearly the =E2=80=9Crelayed transport address=E2=80=9D is = used as the source transport address, not the address that the host B = send the allocate request. So is it problematic?=20 =20 If we allow the communication pair connected two different TURN servers, = how to transport application data between two TURN servers? Using send indication or use pure UDP datagram? How does the upstream TURN server = know the transport address of the downstream TURN Server? =20 Peer A communicates its relayed address to peer B through ICE. Peer B = includes that address in a Send indication that it sends to its own TURN = server. B's server then sends a raw UDP packet to A's server. =20 [Aijun] How the B=E2=80=99s server find A=E2=80=99s server and how the = A=E2=80=99s server find A then if you use the raw UDP packet? Under = current ICE procedure, Host B will send application data in encapsulate = format, together with the XOR-PEER-Address to indicate it want to send = to peer A, where is the information of A=E2=80=99s relay?=20 =20 > > 2. Is it better for ICE server to determine the appropriate Relay > > Server for two peers at the beginning of ICE connectivity check? The > > determination process can be based on information such as the load > > status of each Relay Server, the link usage of its interfaces and = the > > proximity of two peers(based solely on the reflex-address of each = peer). > > [bw] I'm not sure what you're getting at here. The 3rd party relay = system has > the necessary information to determine whether a redirect would be beneficial, > so why would it make sense for something else to make that = determination? > [Aijun]: My concern at here is same as the above question: how the = upstream TURN server knows the transport address of downstream TURN server for = one peer? =20 (see above) [Aijun] There is no attribute to transfer the well-known TURN Server = Transport address now in current ICE RFC/Draft. =20 If ICE can determine the appropriate TURN server for the corresponding communication pair, then there is no need the server redirect mechanism. = Am I right? I don't see how you come to this conclusion. This mechanism has nothing = to do with the 2-servers case. It applies to TURN in general. =20 [Aijun] Let=E2=80=99s discuss this later after we reach an agreement on = the above two questions. =20 Simon ------=_NextPart_000_0078_01D02BF7.0957CD50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Simon, Brandon,

 

Please see the reply below.

 

From:= Simon = Perreault [mailto:sperreault@jive.com] =
Sent: Thursday, January 08, 2015 11:22 PM
To: Aijun = Wang
Cc: Brandon Williams; tram@ietf.org
Subject: Re: = [tram] Fwd: New Version Notification for = draft-williams-peer-redirect-02.txt

 

 

On Wed, Jan 7, 2015 at 8:33 PM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

[Aijun]: section 2.4 and section 10.1&10.2 of the = draft
http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the process
for transferring data via the TURN = server(here we select the brief
description in section 2.4 for = discussion):
---------------------------------------------------------= -------------------
----------------------------------------------
= When using the Send mechanism, the client sends a Send indication = to
   the TURN server containing (a) an XOR-PEER-ADDRESS = attribute
   specifying the (server-reflexive) transport = address of the peer and
   (b) a DATA attribute holding the = application data.  When the TURN
   server receives = the Send indication, it extracts the application data
  =  from the DATA attribute and sends it in a UDP datagram to the = peer,
   using the allocated relay address as the source = address.  Note that
   there is no need to specify the = relayed transport address, since it
   is implied by the = 5-tuple used for the Send indication.

   In the reverse = direction, UDP datagrams arriving at the relayed
  =  transport address on the TURN server are converted into = Data
   indications and sent to the client, with the = server-reflexive
   transport address of the peer included = in an XOR-PEER-ADDRESS
   attribute and the data itself in = a DATA attribute.  Since the relayed
transport address uniquely = identified the allocation, the server
   knows which client = should receive the = data.
----------------------------------------------------------------= ------------
---------------------------------------------------
So= , from the client to TURN server, the application data is encapsulated = in
the DATA attribute and also the XOR-PEER-ADDRESS should be = included. But
from TURN server to the peer, it is one pure UDP = datagram, there is no any
STUN attribute included, and the = application data is directly on the UDP
data part. Then it is = different for application data transfer between
client/server and = server/peer pair.

[Aijun]: No. There is only one allocation on TURN server for each = client. Actually, there are two address in TURN server, one is the = =E2=80=9CRelayed Transport Address=E2=80=9D for every client, the other = is =E2=80=9CTURN Server Transport Address=E2=80=9D that is same to every = client. (please refer to  the figure 1 in = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-2 = )

 

For data sending process, = please refer to http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-16, = that described as below:

 

The client now sends a = ChannelData message to the server with data

   destined for Peer = B.  The ChannelData message is not a STUN = message,

   and thus has no = transaction id.  Instead, it has only three fields: = a

   channel number, = data, and data length; here the channel number = field

   is 0x4000 (the = channel the client just bound to Peer B).  When = the

   server receives = the ChannelData message, it checks that the = channel

   is currently bound = (which it is) and then sends the data onward to

   Peer B in a UDP = datagram, using the relayed transport address as = the

   source transport = address and 192.0.2.210:49191 (the = value of the XOR-

   PEER-ADDRESS = attribute in the ChannelBind request) as the = destination

   transport address. =

 

It described clearly the = =E2=80=9Crelayed transport address=E2=80=9D is used as the source transport address, not the address = that the host B send the allocate request. So is it = problematic? 

 

If we = allow the communication pair connected two different TURN servers, = how
to transport application data between two TURN servers? Using = send
indication or use pure UDP datagram? How does the upstream TURN = server know
the transport address of the downstream TURN = Server?

 

Peer A communicates its relayed = address to peer B through ICE. Peer B includes that address in a Send = indication that it sends to its own TURN server. B's server then sends a = raw UDP packet to A's server.

 

[Aijun] How the B=E2=80=99s = server find A=E2=80=99s server and how the A=E2=80=99s server find A = then if you use the raw UDP packet? Under current ICE procedure, Host B = will send application data in encapsulate format, together with the = XOR-PEER-Address to indicate it want to send to peer A, where is the = information of A=E2=80=99s relay?

 

> > = 2. Is it better for ICE server to determine the appropriate = Relay
> > Server for two peers at the beginning of ICE = connectivity check? The
> > determination process can be based = on information such as the load
> > status of each Relay = Server, the link usage of its interfaces and the
> > proximity = of two peers(based solely on the reflex-address of each = peer).
>
> [bw] I'm not sure what you're getting at here. = The 3rd party relay system
has
> the necessary information to = determine whether a redirect would be
beneficial,
> so why = would it make sense for something else to make that = determination?
>

[Aijun]: My concern at here is same as the = above question: how the upstream
TURN server knows the transport = address of downstream TURN server for = one
peer?

 

(see above)

[Aijun] There is no attribute = to transfer the well-known TURN Server Transport address now in current = ICE RFC/Draft.

 

If ICE = can determine the appropriate TURN server for the = corresponding
communication pair, then there is no need the server = redirect mechanism. Am
I = right?


I don't see how you come to = this conclusion. This mechanism has nothing to do with the 2-servers = case. It applies to TURN in general.

 

[Aijun] Let=E2=80=99s discuss = this later after we reach an agreement on the above two = questions.

 

Simon

------=_NextPart_000_0078_01D02BF7.0957CD50-- From nobody Thu Jan 8 18:34:40 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6641A1B18 for ; Thu, 8 Jan 2015 18:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lI9CQ-rKXj7h for ; Thu, 8 Jan 2015 18:34:34 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEC01A0151 for ; Thu, 8 Jan 2015 18:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38582; q=dns/txt; s=iport; t=1420770875; x=1421980475; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ORbaJOFoNASV6BpAMCgjnNeoqOFeN7wLhwMxmh/ajJA=; b=DZW25RHdCbPuOB9QbzAGXNwVxLEO1OhOqm3hUWdbwwrAFr6e86EpFgwD jXOLYFrkeg7t7bXGK/himnk4L0wUZBYgabTON5KjGZuX58iUouDMJvWvg guyUy0W0dYssr1W2jeT0oBf5hodY3/jqv8so1s5ciRoEB8I4oUtmDXLiV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4dAHk9r1StJV2S/2dsb2JhbABcEwEBgi5DUlgEgwGeKZUzCox2PIFfAQmFcQIcKVJDAQEBAQF9hAwBAQEEAQEBIAoeASILEAIBCA4DAgIBAQsWAQYDAgICIwILFAkIAQEEAQ0FCBOIEQ2zJYVnAY4TAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49IFhcEBgEJgl8ugRMFhDcCiCCBWoNDhlIwgkGNbyKDbm8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,727,1413244800"; d="scan'208,217";a="385879817" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jan 2015 02:34:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t092YX9R020653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 02:34:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 20:34:32 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti , Aijun Wang Thread-Topic: [tram] SSODA in TURN-bis Thread-Index: AdAq5yRwxEi4Jbc7TpCKn/lLZn1lewAQwSOAAAa2Z4AAG43pgAAAI5Ug Date: Fri, 9 Jan 2015 02:34:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.240] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35529742xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 02:34:38 -0000 --_000_913383AAA69FF945B8F946018B75898A35529742xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpvcHRpb24gYykgbG9va3MgZ29vZCwgaXQgd2FzIGRpc2N1c3NlZCBpbiB0 aGUgV0cgc29tZXRpbWUgYmFjayB0aGF0IFRVUk4tYmlzIGNsaWVudCBNVVNUIGluY2x1ZGUgUi1B LUYgaW4gdGhlIEFsbG9jYXRlIHJlcXVlc3QuDQoNCi1UaXJ1DQoNCkZyb206IEp1c3RpbiBVYmVy dGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMDks IDIwMTUgMTo1MyBBTQ0KVG86IEFpanVuIFdhbmcNCkNjOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpOyB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1dIFNTT0RBIGluIFRVUk4t YmlzDQoNCg0KDQpPbiBXZWQsIEphbiA3LCAyMDE1IGF0IDExOjE0IFBNLCBBaWp1biBXYW5nIDx3 YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPG1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNu Pj4gd3JvdGU6DQpIaSwgSnVzdGluLA0KDQpJcyBpdCBtb3JlIHN0cmFpZ2h0Zm9yd2FyZCB0byBk ZWZpbmUgb25lIG5ldyBhdHRyaWJ1dGUgdGhhdCBuYW1lZCDigJxBZGRpdGlvbmFsLUFkZHJlc3Mt RmFtaWx5IOKAnSBpbnN0ZWFkIG9mIHRoZSBSLUEtRiBhbmQgIE9QVElPTkFMLUFERFJFU1MtRkFN SUxZPyBUaGUgZW5kcG9pbnQgdGhhdCBkb2VzIG5vdCBpbmNsdWRlIHRoaXMgYXR0cmlidXRlIHdp bGwgYmUgYXNzaWduZWQgdGhlIHJlbGF5IGFkZHJlc3MgdGhhdCBpcyB0aGUgc2FtZSB0eXBlIGFz IHNlZW4gZnJvbSB0aGUgc291cmNlIGFkZHJlc3Mgb2Yg4oCcQWxsb2NhdGUgUmVxdWVzdOKAnSBw YWNrZXQsIG5vdCBkZWZhdWx0IGluIElQdjQgcmVsYXkgYWRkcmVzcy4NCg0KSSBzdXBwb3NlIHRo aXMgY291bGQgYmUgYSB0aGlyZCBvcHRpb24gKGMpLCBpbiBhZGRpdGlvbiB0byAoYSkgbXVsdGlw bGUgUi1BLUYgYW5kIChiKSBtdWx0aXBsZSBvcHRpb25hbC1hLWYuICBIZXJlJ3MgaG93IGEvYi9j IGxvb2sgb24gdGhlIHdpcmUgd2hlbiByZXF1ZXN0aW5nIHY0K3Y2IHNpbXVsdGFuZW91c2x5LiBJ ZiByZXF1ZXN0aW5nIHY0IG9yIHY2IG9ubHkgZm9yIHNvbWUgcmVhc29uLCBhL2IvYyB3b3VsZCBh bGwgc2VuZCBhIHNpbmdsZSBSQUYuDQoNCmE6IFJBRiAodjQpICsgUkFGICh2NikNCmExOiBzZXJ2 ZXIgaXMgNTc2NjogZXJyb3IgKFJBRiByZXF1aXJlZC1jb21wcmVoZW5zaW9uIGJ1dCB1bmtub3du KQ0KYTI6IHNlcnZlciBpcyA2MTU2OiB2NCBhZGRyZXNzLCBvciBlcnJvciAodW5kZWZpbmVkIGJl aGF2aW9yKQ0KYTM6IHNlcnZlciBpcyBTU09EQTogdjQgYWRkcmVzcyArIHY2IGFkZHJlc3MNCmI6 IE9BRiAodjQpICsgT0FGICh2NikNCmIxOiBzZXJ2ZXIgaXMgNTc2Ni82MTU2OiB2NCBhZGRyZXNz IChPQUYgaWdub3JlZCkNCmIyOiBzZXJ2ZXIgaXMgU1NPREE6IHY0IGFkZHJlc3MgKyB2NiBhZGRy ZXNzDQpjOiBBQUYgKHY2KQ0KYzE6IHNlcnZlciBpcyA1NzY2LzYxNTY6IHY0IGFkZHJlc3MgKEFB RiBpZ25vcmVkKQ0KYzI6IHNlcnZlciBpcyBTU09EQTogdjQgYWRkcmVzcyArIHY2IGFkZHJlc3MN Cg0KTm90ZSB0aGF0IGZvciBjKSwgb25lIGNvdWxkIHNlbmQgUkFGKHY0KSArIEFBRih2NiksIGJ1 dCBzaW5jZSB0aGF0IHdvdWxkIGZhaWwgb24gYSA1NzY2IHNlcnZlciwgc2VuZGluZyBqdXN0IEFB Rih2Nikgd291bGQgYmUgcHJlZmVyYWJsZS4NCk5vdGUgdGhhdCBmb3IgYiksIGlmIG9uZSBzZW50 IE9BRih2NikgYnkgaXRzZWxmIGZvciBzb21lIHJlYXNvbiwgYSA1NzY2IHNlcnZlciB3b3VsZCBy ZXR1cm4gYSB2NCBhZGRyZXNzLCB3aGljaCBpcyBzbGlnaHRseSBpbmVsZWdhbnQuDQpGb3IgZWl0 aGVyIGIvYywgd2Ugd291bGQgbmVlZCB0byBzYXkgdGhhdCBpbmNsdWRpbmcgYm90aCBSQUYgYW5k IE9BRi9BQUYgZm9yIHRoZSBzYW1lIGFkZHJlc3MgZmFtaWx5IGlzIHByb2hpYml0ZWQuDQoNCmIp IGlzIG5pY2UgaW4gdGhhdCBpdCBhdm9pZHMgaW1wbGljaXQgYmVoYXZpb3IgKGkuZS4gdGhhdCBJ UHY0IGlzIHRoZSBkZWZhdWx0IEFGKSwgYnV0IGZlZWxzIGEgYml0IG1vcmUgY29tcGxpY2F0ZWQg dGhhbiBjKS4gSSBhbSBzdXBwb3J0aXZlIG9mIGVpdGhlciBiKS9jKSwgd2l0aCBtYXliZSBhIHNs aWdodCBwcmVmZXJlbmNlIGZvciBjKS4NCg0KDQpGb3IgcmVkdWNpbmcgdGhlIHBvcnQgcmVzb3Vy Y2UgY29uc3VtcHRpb24gb24gVFVSTiBzZXJ2ZXIgdGhhdCBkZXNjcmliZWQgaW4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi10cmFtLXNzb2RhLTAxLCB3ZSBoYXZl IGFub3RoZXIgcHJvcG9zYWwgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13 YW5nLXRyYW0tdHVybmxpdGUvIHRoYXQgY2FuIG1pdGlnYXRlIHRoZSBpcCBhZGRyZXNzL3BvcnQg YWxsb2NhdGlvbiBidXJkZW4gb24gVFVSTiBzZXJ2ZXItLS0tLS1BbGwgZW5kcG9pbnRzIHRoYXQg dW5kZXIgb25lIFRVUk4gc2VydmVyIGNhbiB1c2UgdGhlIHNhbWUgSVB2NC9JUHY2IHJlbGF5ICBh ZGRyZXNzL3BvcnQuDQoNClRoZSBwb3J0IGNvbnN1bXB0aW9uIGlzIGEgc2lkZSBiZW5lZml0OyB0 aGUgcHJpbWFyeSBiZW5lZml0IG9mIFNTT0RBIGlzIHRoZSByZWR1Y3Rpb24gaW4gdGhlIG92ZXJh bGwgbnVtYmVyIG9mIGNhbmRpZGF0ZXMuDQoNCkJlc3QgUmVnYXJkcy4NCkFpanVuIFdhbmcuDQoN CkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUaHVyc2Rh eSwgSmFudWFyeSAwOCwgMjAxNSAxMjowMiBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDog W1NQQU1dIFJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXMNCg0KSSBwcm9taXNlZCBJIHdvdWxk IHdyaXRlIHVwIGEgc3VtbWFyeSBvZiB0aGUgY3VycmVudCBtZWNoYW5pc20sIGFuZCB3aGF0IHdl IGNvdWxkIGRvIGluc3RlYWQsIHNvIGhlcmUgZ29lczoNCg0KVGhlIGN1cnJlbnRseSBkb2N1bWVu dGVkIG1lY2hhbmlzbSBpcyB0byBzZW5kIHR3byBSLUEtRiBhdHRyaWJ1dGVzIGluIHRoZSByZXF1 ZXN0LCBhbmQgZ2V0IGJhY2sgZWl0aGVyIGEgc2luZ2xlIGFkZHJlc3MgKGZyb20gbGVnYWN5IHNl cnZlcnMpLCB2NCArIHY2IGFkZHJlc3NlcyAoZnJvbSBuZXcgc2VydmVycyksIGEgc2luZ2xlIGFk ZHJlc3MgKyBhIDAuMC4wLjAvPGh0dHA6Ly8wLjAuMC4wLz46OiAoZm9yIG5ldyBzZXJ2ZXJzIHRo YXQgb25seSBzdXBwb3J0IG9uZSBhZGRyZXNzIGZhbWlseSksIG9yIGFuIGVycm9yLWNvZGUgKHRv IGluZGljYXRlIGNvbXBsZXRlIGZhaWx1cmUpLg0KDQpBdCB0aGUgdGltZSwgdGhlcmUgd2VyZSAy IGNvbmNlcm5zIGxpc3RlZCwgbmFtZWx5Og0KMSkgc2VuZGluZyBtdWx0aXBsZSBSLUEtRnMgaXMg dW5kZWZpbmVkIGJlaGF2aW9yOyBvbGQgKDYxNTYpIHNlcnZlcnMgbWF5IGZhaWwgdGhlIHJlcXVl c3QgY29tcGxldGVseSwgb3IgZG8gb3RoZXIgd2VpcmQgdGhpbmdzLg0KMikgdXNpbmcgMC4wLjAu MC88aHR0cDovLzAuMC4wLjAvPjo6IHRvIGluZGljYXRlIHBhcnRpYWwgc3VjY2VzcyBpcyBzb21l d2hhdCB1bmNsZWFuOyBzcGVjaWZpY2FsbHksIGRldGFpbGVkIGVycm9yIGluZm9ybWF0aW9uIGNh bm5vdCBiZSBpbmNsdWRlZC4NCg0KSSBhbHNvIHRob3VnaHQgb2YgYSAzcmQgcHJvYmxlbToNCjMp IGFuIG9sZCg1NzY2KSBzZXJ2ZXIgbWF5IGZhaWwgdGhlIHJlcXVlc3QgY29tcGxldGVseSwgZHVl IHRvIHRoZSBmYWN0IHRoYXQgUi1BLUYgaXMgY29tcHJlaGVuc2lvbi1yZXF1aXJlZC4gVGh1cyBh biBleHRyYSByb3VuZHRyaXAgbWF5IGJlIG5lZWRlZCBpbiB0aGlzIGNhc2UsIG5lZ2F0aW5nIG9u ZSBvZiB0aGUgYmVuZWZpdHMgb2YgU1NPREEuDQoNCkkgdGhpbmsgdGhlIGlkZWFsIHNvbHV0aW9u IHRvICMxLyMzIGlzIHRvIGFkZCBhIG5ldyBPUFRJT05BTC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1 dGUsIGlkZW50aWNhbCB0byBSLUEtRiBidXQgY29tcHJlaGVuc2lvbi1vcHRpb25hbCwgd2hlcmUg bXVsdGlwbGUgdmFsdWVzIGFyZSBleHBsaWNpdGx5IHN1cHBvcnRlZC4gT2xkIHNlcnZlcnMgY2Fu IHNhZmVseSBpZ25vcmUgdGhpcyBhbmQgd2lsbCByZXR1cm4gSVB2NCAoc29sdmluZyAjMyksIHdo aWxlIG5ldyBzZXJ2ZXJzIGNhbiBwcm9jZXNzIHRoaXMgdG8gcmV0dXJuIG11bHRpcGxlIFhPUi1S RUxBWUVELUFERFJFU1NlcyBpbiB0aGUgcmVzcG9uc2UuDQojMiBpcyBub3QgYSBzZXJpb3VzIGlz c3VlLCBidXQgaXQgY291bGQgZWFzaWx5IGJlIHNvbHZlZCBieSBkZWZpbmluZyBhIG5ldyBBRERS RVNTLUVSUk9SLUNPREUgYXMgZm9sbG93czoNCg0KDQogICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICB8 ICBBZGRyZXNzIEZhbWlseSAgICAgICAgICAgICAgICB8ICBSc3ZkICB8Q2xhc3N8ICAgICBOdW1i ZXIgICAgfA0KDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICB8ICAgICAgUmVhc29uIFBocmFzZSAo dmFyaWFibGUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLg0KDQogICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KDQoNCg0KVGhlbiBhIHNlcnZlciBjb3VsZCByZXR1cm4gYSBub3JtYWwgSVB2NCBhZGRy ZXNzLCBidXQgYSBlcnJvciBjb2RlIGZvciBJUHY2IHdpdGggZWl0aGVyIDQ0MCAodW5zdXBwb3J0 ZWQgYWRkcmVzcyBmYW1pbHkpIG9yIDUwOCAoaW5zdWZmaWNpZW50IGNhcGFjaXR5KSBvciBzb21l IG90aGVyIFRCRCBlcnJvci4NCg0KDQoNCkkgYWR2b2NhdGUgd2UgZG8gdGhlIE9QVElPTkFMLUFE RFJFU1MtRkFNSUxZIGF0dHJpYnV0ZSBhcyBpdCBpcyBzaW1wbGUgYW5kIHByZXZlbnRzIHBvdGVu dGlhbCBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIHdpdGggb2xkIHNlcnZlcnMuIEkgY291bGQg Z28gZWl0aGVyIHdheSBvbiBBRERSRVNTLUVSUk9SLUNPREUuDQoNCg0KDQoNCg0KT24gV2VkLCBK YW4gNywgMjAxNSBhdCA2OjAyIFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIDx0aXJl ZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCkhpIGFsbCwN Cg0KV2UgYXJlIHdvcmtpbmcgb24gaW5jb3Jwb3JhdGluZyBSRkM2MTU2IGFuZCBTU09EQSBpbnRv IFRVUk4tYmlzLiBEdXJpbmcgSUVURi05MSBtZWV0aW5nIHRoZXJlIHdhcyBkaXNjdXNzaW9uIGlm IHRoZSB0ZWNobmlxdWUgcHJvcG9zZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW1hcnRpbnNlbi10cmFtLXNzb2RhLTAxIHdvdWxkIGJyZWFrIGV4aXN0aW5nIFRVUk4gc2Vy dmVyIGltcGxlbWVudGF0aW9ucy4gIFBhbCBoYWQgbWVudGlvbmVkIHRlc3Rpbmcgd2l0aCBmb3Vy IGltcGxlbWVudGF0aW9ucyBhbmQgZGlkIG5vdCBmYWNlIGFueSBwcm9ibGVtLg0KDQpQbGVhc2Ug bGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFueSBjb25jZXJucyB3aXRoIHRoZSBleGlzdGluZyBw cm9wb3NhbCBvZiBjb252ZXlpbmcgdHdvIFJFUVVFU1RFRC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1 dGVzIHdpdGggZGlmZmVyZW50IGF0dHJpYnV0ZSB2YWx1ZXMgaW4gQWxsb2NhdGUgcmVxdWVzdCA/ DQoNCkNoZWVycywNCi1UaXJ1DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJh bUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0K DQoNCg== --_000_913383AAA69FF945B8F946018B75898A35529742xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5vcHRpb24gYykgbG9va3MgZ29vZCwgaXQgd2FzIGRpc2N1c3Nl ZCBpbiB0aGUgV0cgc29tZXRpbWUgYmFjayB0aGF0IFRVUk4tYmlzIGNsaWVudCBNVVNUIGluY2x1 ZGUgUi1BLUYgaW4gdGhlIEFsbG9jYXRlIHJlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWls dG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFy eSAwOSwgMjAxNSAxOjUzIEFNPGJyPg0KPGI+VG86PC9iPiBBaWp1biBXYW5nPGJyPg0KPGI+Q2M6 PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyB0cmFtQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gNywgMjAxNSBhdCAxMToxNCBQ TSwgQWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcu Y24iIHRhcmdldD0iX2JsYW5rIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkhpLCBKdXN0aW4sPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+SXMgaXQgbW9yZSBzdHJhaWdodGZvcndhcmQgdG8gZGVmaW5lIG9u ZSBuZXcgYXR0cmlidXRlIHRoYXQgbmFtZWQg4oCcQWRkaXRpb25hbC1BZGRyZXNzLUZhbWlseQ0K IOKAnSBpbnN0ZWFkIG9mIHRoZSBSLUEtRiBhbmQmbmJzcDsgT1BUSU9OQUwtQUREUkVTUy1GQU1J TFk/IFRoZSBlbmRwb2ludCB0aGF0IGRvZXMgbm90IGluY2x1ZGUgdGhpcyBhdHRyaWJ1dGUgd2ls bCBiZSBhc3NpZ25lZCB0aGUgcmVsYXkgYWRkcmVzcyB0aGF0IGlzIHRoZSBzYW1lIHR5cGUgYXMg c2VlbiBmcm9tIHRoZSBzb3VyY2UgYWRkcmVzcyBvZiDigJxBbGxvY2F0ZSBSZXF1ZXN04oCdIHBh Y2tldCwgbm90IGRlZmF1bHQgaW4gSVB2NCByZWxheSBhZGRyZXNzLjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvc2UgdGhp cyBjb3VsZCBiZSBhIHRoaXJkIG9wdGlvbiAoYyksIGluIGFkZGl0aW9uIHRvIChhKSBtdWx0aXBs ZSBSLUEtRiBhbmQgKGIpIG11bHRpcGxlIG9wdGlvbmFsLWEtZi4mbmJzcDsgSGVyZSdzIGhvdyBh L2IvYyBsb29rIG9uIHRoZSB3aXJlIHdoZW4gcmVxdWVzdGluZyB2NCYjNDM7djYgc2ltdWx0YW5l b3VzbHkuIElmIHJlcXVlc3RpbmcgdjQgb3IgdjYgb25seSBmb3Igc29tZSByZWFzb24sIGEvYi9j IHdvdWxkDQogYWxsIHNlbmQgYSBzaW5nbGUgUkFGLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hOiBSQUYgKHY0KSAmIzQzOyBSQUYgKHY2KTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YTE6IHNl cnZlciBpcyA1NzY2OiBlcnJvciAoUkFGIHJlcXVpcmVkLWNvbXByZWhlbnNpb24gYnV0IHVua25v d24pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h Mjogc2VydmVyIGlzIDYxNTY6IHY0IGFkZHJlc3MsIG9yIGVycm9yICh1bmRlZmluZWQgYmVoYXZp b3IpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h Mzogc2VydmVyIGlzIFNTT0RBOiB2NCBhZGRyZXNzICYjNDM7IHY2IGFkZHJlc3M8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmI6IE9BRiAodjQpICYj NDM7IE9BRiAodjYpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5iMTogc2VydmVyIGlzIDU3NjYvNjE1NjogdjQgYWRkcmVzcyAoT0FGIGlnbm9yZWQp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iMjog c2VydmVyIGlzIFNTT0RBOiB2NCBhZGRyZXNzICYjNDM7IHY2IGFkZHJlc3M8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmM6IEFBRiAodjYpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jMTogc2VydmVy IGlzIDU3NjYvNjE1NjogdjQgYWRkcmVzcyAoQUFGIGlnbm9yZWQpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jMjogc2VydmVyIGlzIFNTT0RBOiB2 NCBhZGRyZXNzICYjNDM7IHY2IGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IGZvciBjKSwgb25lIGNvdWxkIHNlbmQg UkFGKHY0KSAmIzQzOyBBQUYodjYpLCBidXQgc2luY2UgdGhhdCB3b3VsZCBmYWlsIG9uIGEgNTc2 NiBzZXJ2ZXIsIHNlbmRpbmcganVzdCBBQUYodjYpIHdvdWxkIGJlIHByZWZlcmFibGUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlIHRoYXQg Zm9yIGIpLCBpZiBvbmUgc2VudCBPQUYodjYpIGJ5IGl0c2VsZiBmb3Igc29tZSByZWFzb24sIGEg NTc2NiBzZXJ2ZXIgd291bGQgcmV0dXJuIGEgdjQgYWRkcmVzcywgd2hpY2ggaXMgc2xpZ2h0bHkg aW5lbGVnYW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIGVpdGhlciBiL2MsIHdlIHdvdWxkIG5lZWQgdG8gc2F5IHRoYXQgaW5jbHVkaW5n IGJvdGggUkFGIGFuZCBPQUYvQUFGIGZvciB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSBpcyBwcm9o aWJpdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5iKSBpcyBuaWNlIGluIHRoYXQgaXQgYXZvaWRzIGltcGxpY2l0IGJlaGF2aW9yIChpLmUu IHRoYXQgSVB2NCBpcyB0aGUgZGVmYXVsdCBBRiksIGJ1dCBmZWVscyBhIGJpdCBtb3JlIGNvbXBs aWNhdGVkIHRoYW4gYykuIEkgYW0gc3VwcG9ydGl2ZSBvZiBlaXRoZXIgYikvYyksIHdpdGggbWF5 YmUgYSBzbGlnaHQgcHJlZmVyZW5jZSBmb3IgYykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Rm9yIHJlZHVjaW5nIHRoZSBwb3J0IHJlc291cmNlIGNvbnN1bXB0aW9uIG9uIFRVUk4g c2VydmVyIHRoYXQgZGVzY3JpYmVkDQogaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW1hcnRpbnNlbi10cmFtLXNzb2RhLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3NvZGEtMDE8 L2E+LCB3ZSBoYXZlIGFub3RoZXIgcHJvcG9zYWwNCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy10cmFtLXR1cm5saXRlLyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLXRyYW0tdHVybmxp dGUvPC9hPiB0aGF0IGNhbiBtaXRpZ2F0ZSB0aGUgaXAgYWRkcmVzcy9wb3J0IGFsbG9jYXRpb24g YnVyZGVuIG9uIFRVUk4gc2VydmVyLS0tLS0tQWxsIGVuZHBvaW50cyB0aGF0IHVuZGVyIG9uZSBU VVJOIHNlcnZlciBjYW4gdXNlIHRoZSBzYW1lIElQdjQvSVB2NiByZWxheSAmbmJzcDthZGRyZXNz L3BvcnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwb3J0IGNvbnN1bXB0aW9uIGlzIGEgc2lkZSBi ZW5lZml0OyB0aGUgcHJpbWFyeSBiZW5lZml0IG9mIFNTT0RBIGlzIHRoZSByZWR1Y3Rpb24gaW4g dGhlIG92ZXJhbGwgbnVtYmVyIG9mIGNhbmRpZGF0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPkJlc3QgUmVnYXJkcy48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5BaWp1biBXYW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiB0cmFtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW0tYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIEphbnVhcnkgMDgsIDIwMTUgMTI6MDIgUE08YnI+DQo8Yj5Ubzo8L2I+IFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0 bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW1NQQU1dIFJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXM8L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JIHByb21pc2VkIEkgd291bGQgd3JpdGUg dXAgYSBzdW1tYXJ5IG9mIHRoZSBjdXJyZW50IG1lY2hhbmlzbSwgYW5kIHdoYXQgd2UgY291bGQg ZG8gaW5zdGVhZCwgc28gaGVyZSBnb2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PlRoZSBjdXJyZW50bHkgZG9jdW1lbnRlZCBtZWNoYW5pc20gaXMgdG8gc2VuZCB0d28gUi1BLUYg YXR0cmlidXRlcyBpbiB0aGUgcmVxdWVzdCwgYW5kIGdldCBiYWNrIGVpdGhlciBhIHNpbmdsZSBh ZGRyZXNzIChmcm9tIGxlZ2FjeSBzZXJ2ZXJzKSwNCiB2NCAmIzQzOyB2NiBhZGRyZXNzZXMgKGZy b20gbmV3IHNlcnZlcnMpLCBhIHNpbmdsZSBhZGRyZXNzICYjNDM7IGEgPGEgaHJlZj0iaHR0cDov LzAuMC4wLjAvIiB0YXJnZXQ9Il9ibGFuayI+DQowLjAuMC4wLzwvYT46OiAoZm9yIG5ldyBzZXJ2 ZXJzIHRoYXQgb25seSBzdXBwb3J0IG9uZSBhZGRyZXNzIGZhbWlseSksIG9yIGFuIGVycm9yLWNv ZGUgKHRvIGluZGljYXRlIGNvbXBsZXRlIGZhaWx1cmUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+QXQgdGhlIHRpbWUsIHRoZXJlIHdlcmUgMiBjb25jZXJucyBsaXN0 ZWQsIG5hbWVseTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ MSkgc2VuZGluZyBtdWx0aXBsZSBSLUEtRnMgaXMgdW5kZWZpbmVkIGJlaGF2aW9yOyBvbGQgKDYx NTYpIHNlcnZlcnMgbWF5IGZhaWwgdGhlIHJlcXVlc3QgY29tcGxldGVseSwgb3IgZG8gb3RoZXIg d2VpcmQgdGhpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4yKSB1c2luZw0KPGEgaHJlZj0iaHR0cDovLzAuMC4wLjAvIiB0YXJnZXQ9Il9ibGFuayI+MC4w LjAuMC88L2E+OjogdG8gaW5kaWNhdGUgcGFydGlhbCBzdWNjZXNzIGlzIHNvbWV3aGF0IHVuY2xl YW47IHNwZWNpZmljYWxseSwgZGV0YWlsZWQgZXJyb3IgaW5mb3JtYXRpb24gY2Fubm90IGJlIGlu Y2x1ZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSBhbHNvIHRo b3VnaHQgb2YgYSAzcmQgcHJvYmxlbTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+MykgYW4gb2xkKDU3NjYpIHNlcnZlciBtYXkgZmFpbCB0aGUgcmVxdWVzdCBj b21wbGV0ZWx5LCBkdWUgdG8gdGhlIGZhY3QgdGhhdCBSLUEtRiBpcyBjb21wcmVoZW5zaW9uLXJl cXVpcmVkLiBUaHVzIGFuIGV4dHJhIHJvdW5kdHJpcCBtYXkNCiBiZSBuZWVkZWQgaW4gdGhpcyBj YXNlLCBuZWdhdGluZyBvbmUgb2YgdGhlIGJlbmVmaXRzIG9mIFNTT0RBLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSB0aGluayB0aGUgaWRlYWwgc29sdXRpb24gdG8g IzEvIzMgaXMgdG8gYWRkIGEgbmV3IE9QVElPTkFMLUFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZSwg aWRlbnRpY2FsIHRvIFItQS1GIGJ1dCBjb21wcmVoZW5zaW9uLW9wdGlvbmFsLCB3aGVyZQ0KIG11 bHRpcGxlIHZhbHVlcyBhcmUgZXhwbGljaXRseSBzdXBwb3J0ZWQuIE9sZCBzZXJ2ZXJzIGNhbiBz YWZlbHkgaWdub3JlIHRoaXMgYW5kIHdpbGwgcmV0dXJuIElQdjQgKHNvbHZpbmcgIzMpLCB3aGls ZSBuZXcgc2VydmVycyBjYW4gcHJvY2VzcyB0aGlzIHRvIHJldHVybiBtdWx0aXBsZSBYT1ItUkVM QVlFRC1BRERSRVNTZXMgaW4gdGhlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4jMiBpcyBub3QgYSBzZXJpb3VzIGlzc3VlLCBidXQgaXQgY291 bGQgZWFzaWx5IGJlIHNvbHZlZCBieSBkZWZpbmluZyBhIG5ldyBBRERSRVNTLUVSUk9SLUNPREUg YXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IEFkZHJlc3MgRmFt aWx5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgUnN2ZCZuYnNwOyB8 Q2xhc3N8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE51bWJlciZuYnNwOyZuYnNwOyZuYnNwOyB8 PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVhc29uIFBocmFzZSAo dmFyaWFibGUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZW4gYSBzZXJ2ZXIgY291bGQgcmV0dXJuIGEg bm9ybWFsIElQdjQgYWRkcmVzcywgYnV0IGEgZXJyb3IgY29kZSBmb3IgSVB2NiB3aXRoIGVpdGhl ciA0NDAgKHVuc3VwcG9ydGVkIGFkZHJlc3MgZmFtaWx5KSBvciA1MDggKGluc3VmZmljaWVudCBj YXBhY2l0eSkgb3Igc29tZSBvdGhlciBUQkQgZXJyb3IuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPkkgYWR2b2NhdGUgd2UgZG8gdGhlIE9QVElPTkFMLUFERFJFU1MtRkFN SUxZIGF0dHJpYnV0ZSBhcyBpdCBpcyBzaW1wbGUgYW5kIHByZXZlbnRzIHBvdGVudGlhbCBpbnRl cm9wZXJhYmlsaXR5IHByb2JsZW1zIHdpdGggb2xkIHNlcnZlcnMuIEkgY291bGQgZ28gZWl0aGVy IHdheSBvbiBBRERSRVNTLUVSUk9SLUNPREUuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PbiBXZWQs IEphbiA3LCAyMDE1IGF0IDY6MDIgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0 OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVk ZHlAY2lzY28uY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XZSBhcmUgd29ya2luZyBvbiBpbmNv cnBvcmF0aW5nIFJGQzYxNTYgYW5kIFNTT0RBIGludG8gVFVSTi1iaXMuIER1cmluZyBJRVRGLTkx IG1lZXRpbmcgdGhlcmUgd2FzIGRpc2N1c3Npb24gaWYgdGhlIHRlY2huaXF1ZSBwcm9wb3NlZCBp bg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi10 cmFtLXNzb2RhLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3NvZGEtMDE8L2E+IHdvdWxkIGJyZWFrIGV4aXN0aW5n IFRVUk4gc2VydmVyIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgUGFsIGhhZCBtZW50aW9uZWQgdGVz dGluZyB3aXRoIGZvdXIgaW1wbGVtZW50YXRpb25zIGFuZCBkaWQgbm90IGZhY2UgYW55IHByb2Js ZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5QbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFueSBjb25jZXJu cyB3aXRoIHRoZSBleGlzdGluZyBwcm9wb3NhbCBvZiBjb252ZXlpbmcgdHdvIFJFUVVFU1RFRC1B RERSRVNTLUZBTUlMWSBhdHRyaWJ1dGVzIHdpdGggZGlmZmVyZW50DQogYXR0cmlidXRlIHZhbHVl cyBpbiBBbGxvY2F0ZSByZXF1ZXN0ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A35529742xmbrcdx10ciscoc_-- From nobody Thu Jan 8 18:40:40 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DEF1A1B43 for ; Thu, 8 Jan 2015 18:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 qkrP8-1fVvLt for ; Thu, 8 Jan 2015 18:40:36 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 399F21A0211 for ; Thu, 8 Jan 2015 18:40:35 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06C75QZjKq9U7Ri1AA==.5002S4; Fri, 09 Jan 2015 09:10:13 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> In-Reply-To: <54AECBD9.5010903@akamai.com> Date: Fri, 9 Jan 2015 10:40:09 +0800 Message-ID: <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdArZElJeR9wiem3QPGuZ3A67MsNAQAT72WQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06C75QZjKq9U7Ri1AA==.5002S4 X-Coremail-Antispam: 1U3129KBjvJXoW3JryUKw13Cw4fXFyfuF1UGFg_yoWDGw43pF W3JFW7Gr1kJr1xCwsFvw1jvF1Yv3ykXrWfXr15tr1xA390kF17tF1jgr1ruryUGryrGryj qr4UCa17C3W5ArJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjllb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY 1x0267AKxVWUJVW8JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4U0xZFpf9x0JUCD73UUUUU= Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 02:40:39 -0000 Hi, Brandon: Please see the reply below. Aijun Wang Best Regards. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, January 09, 2015 2:27 AM > To: Aijun Wang; tram@ietf.org > Subject: Re: [tram] Fwd: New Version Notification for > draft-williams-peer-redirect-02.txt > > See inline ... > > On 01/07/2015 08:33 PM, Aijun Wang wrote: > > Hi, Brandon: > > > > Please see the reply inline. > > > > Best Regards. > > Aijun Wang. > > > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >> Williams > >> Sent: Thursday, January 08, 2015 5:35 AM > >> To: Aijun Wang; tram@ietf.org > >> Subject: Re: [tram] Fwd: New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> > >> see [bw] inline > >> > >> On 01/06/2015 01:14 AM, Aijun Wang wrote: > >>> Hi, Brandon. > >>> > >>> I read your draft just and wants to ask you some question for > > clarification: > >>> 1. Is it possible for two peers to select different Relay Server to > >>> communicate? If so, will the communication channel between the Relay > >>> Server will be changed by the CHECK-ALTERNATE attribute? If not, how > >>> to ensure two peers select the same Relay Server? > >> > >> [bw] Yes, they can select different relay servers. The mechanism > >> doesn't > > add > >> any new restriction in that regard, nor does it changes the > >> communication channel between the servers (there's no need for that). > >> Basically, redirect would end up providing a new relay candidate and > > there's > >> some ongoing work in mmusic that will help ICE to make more effective > >> use > > of > >> the new relay candidate. > > > > [Aijun]: section 2.4 and section 10.1&10.2 of the draft > > http://www.ietf.org/id/draft-ietf-tram-turnbis-00.txt describe the > > process for transferring data via the TURN server(here we select the > > brief description in section 2.4 for discussion): > > ---------------------------------------------------------------------- > > ------ > > ---------------------------------------------- > > When using the Send mechanism, the client sends a Send indication to > > the TURN server containing (a) an XOR-PEER-ADDRESS attribute > > specifying the (server-reflexive) transport address of the peer and > > (b) a DATA attribute holding the application data. When the TURN > > server receives the Send indication, it extracts the application data > > from the DATA attribute and sends it in a UDP datagram to the peer, > > using the allocated relay address as the source address. Note that > > there is no need to specify the relayed transport address, since it > > is implied by the 5-tuple used for the Send indication. > > > > In the reverse direction, UDP datagrams arriving at the relayed > > transport address on the TURN server are converted into Data > > indications and sent to the client, with the server-reflexive > > transport address of the peer included in an XOR-PEER-ADDRESS > > attribute and the data itself in a DATA attribute. Since the > > relayed transport address uniquely identified the allocation, the server > > knows which client should receive the data. > > ---------------------------------------------------------------------- > > ------ > > --------------------------------------------------- > > So, from the client to TURN server, the application data is > > encapsulated in the DATA attribute and also the XOR-PEER-ADDRESS > > should be included. But from TURN server to the peer, it is one pure > > UDP datagram, there is no any STUN attribute included, and the > > application data is directly on the UDP data part. Then it is > > different for application data transfer between client/server and server/peer > pair. > > If we allow the communication pair connected two different TURN > > servers, how to transport application data between two TURN servers? > > Using send indication or use pure UDP datagram? How does the upstream > > TURN server know the transport address of the downstream TURN Server? > > [bw] I consider the "(server-reflexive)" to be incorrect. When only one peer is > using a relay, then this would be the server-reflexive or host address, but when > both are using relays then it would be the relay address. > [Aijun]: There are two relay address, one is the TURN server well-known address, another is the relay address that allocated to each client. Which one should be used then? On the other hand, when client want to send traffic to other peer, it does not know whether the other part is under the same TURN server or not, how do it select this information? > > > >> > >>> 2. Is it better for ICE server to determine the appropriate Relay > >>> Server for two peers at the beginning of ICE connectivity check? The > >>> determination process can be based on information such as the load > >>> status of each Relay Server, the link usage of its interfaces and the > >>> proximity of two peers(based solely on the reflex-address of each peer). > >> > >> [bw] I'm not sure what you're getting at here. The 3rd party relay system > > has > >> the necessary information to determine whether a redirect would be > > beneficial, > >> so why would it make sense for something else to make that determination? > >> > > > > [Aijun]: My concern at here is same as the above question: how the upstream > > TURN server knows the transport address of downstream TURN server for > one > > peer? If ICE can determine the appropriate TURN server for the > corresponding > > communication pair, then there is no need the server redirect mechanism. > Am > > I right? > > [bw] The server knows the relay address of the remote peer via the > XOR-PEER-ADDRESS attribute, and that is used to direct traffic to the > downstream relay. The upstream relay doesn't need to know the nature of > the downstream address, just that this is the address to use to get data > to the peer. [Aijun]: as the definition in http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, the XOR-PEER-ADDRESS is the address seen from the TURN server, so it can't be used to find the relay address of the remote peer, and then can't be used to direct traffic to downstream relay. > > > > >>> > >>> Best Regards. > >>> > >>>> -----Original Message----- > >>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >>>> Williams > >>>> Sent: Tuesday, December 30, 2014 6:04 AM > >>>> To: tram@ietf.org > >>>> Subject: [tram] Fwd: New Version Notification for > >>>> draft-williams-peer-redirect-02.txt > >>>> > >>>> Hi all, > >>>> > >>>> I've just updated the peer redirect draft to provide the warning > >>>> labels > >>> that Ted > >>>> asked for back in Toronto. I also added brief discussion of a load > >>> balancing use > >>>> case when adding a new flow to an existing allocation. > >>>> > >>>> There's some work going on both here and in mmusic related to ICE > >>>> that can help provide a framework for making more effective use of > >>>> this redirection capability. > >>>> > >>>> I hope that there might be enough interest in this draft for WG > >>>> adoption > >>> and > >>>> would like to hear thoughts on that from the list. > >>>> > >>>> Thanks, > >>>> --Brandon > >>>> > >>>> -------- Forwarded Message -------- > >>>> Subject: New Version Notification for > >>>> draft-williams-peer-redirect-02.txt > >>>> Date: Mon, 29 Dec 2014 16:53:47 -0500 > >>>> From: internet-drafts@ietf.org > >>>> To: Williams, Brandon , Tirumaleswar Reddy > >>>> , Tirumaleswar Reddy , > >>>> Williams, Brandon > >>>> > >>>> > >>>> A new version of I-D, draft-williams-peer-redirect-02.txt > >>>> has been successfully submitted by Brandon Williams and posted to the > >>>> IETF repository. > >>>> > >>>> Name: draft-williams-peer-redirect > >>>> Revision: 02 > >>>> Title: Peer-specific Redirection for Traversal Using Relays > >>> around NAT > >>>> (TURN) > >>>> Document date: 2014-12-29 > >>>> Group: Individual Submission > >>>> Pages: 13 > >>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.t > >>>> xt > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ > >>>> Htmlized: > > http://tools.ietf.org/html/draft-williams-peer-redirect-02 > >>>> Diff: > >>>> http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 > >>>> > >>>> Abstract: > >>>> This specification describes a peer-specific redirection method > > that > >>>> allows the TURN server to redirect a client for the purpose of > >>>> improving communication with a specific peer without negatively > >>>> affecting communication with other peers. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 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. > >>>> > >>>> The IETF Secretariat > >>>> > >>>> > >>>> -- > >>>> Brandon Williams; Senior Principal Software Engineer Emerging > >>>> Products Engineering; Akamai Technologies Inc. > >>>> > >>>> > >>>> _______________________________________________ > >>>> tram mailing list > >>>> tram@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tram > >>> > >>> > >>> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging Products > >> Engineering; Akamai Technologies Inc. > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > > > > > > > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Jan 8 19:12:08 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0284B1A802D for ; Thu, 8 Jan 2015 19:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Rs5mdTijnetY for ; Thu, 8 Jan 2015 19:12:02 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7141A802C for ; Thu, 8 Jan 2015 19:11:59 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06DrHwa7Ma9Uvx+pAA==.6043S4; Fri, 09 Jan 2015 09:41:32 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> Date: Fri, 9 Jan 2015 11:11:29 +0800 Message-ID: <008f01d02bb9$fef15f80$fcd41e80$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01D02BFD.0D149F80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAq5yRwxEi4Jbc7TpCKn/lLZn1lewAQwSOAAAa2Z4AAG43pgAAAI5UgAADeryA= Content-Language: zh-cn X-CM-TRANSID: Z0GX06DrHwa7Ma9Uvx+pAA==.6043S4 X-Coremail-Antispam: 1U3129KBjvJXoW3Wry3GF4UuFWrWrWkuF45KFg_yoWxXFW7pF W5J3yrGr4kXryxJw4kZr10vF1FvFZ0yFyktr95tryxZ398JFZrAw4UKw45Ga9rWrs5Gw4j qr4Uuw4Dur15ZrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JURE__UUUUU= Archived-At: Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 03:12:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0090_01D02BFD.0D149F80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Reddy and Justin: =20 Can we use only one attribute to accomplish the requirement of relay = address that for additional address family? The TURN server can deduct = the default relay address type by the XOR-MAP-Address that it seen from = the allocation request. It can also satisfy the further situation such = as only IPv6 TURN server deployed, but there is still the Dual stack ICE = client exist. =20 Reuse or Redefine the RAF attribute then? =20 Best Regards. =20 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Sent: Friday, January 09, 2015 10:35 AM To: Justin Uberti; Aijun Wang Cc: tram@ietf.org Subject: RE: [tram] SSODA in TURN-bis =20 Hi Justin, =20 option c) looks good, it was discussed in the WG sometime back that = TURN-bis client MUST include R-A-F in the Allocate request. =20 -Tiru =20 From: Justin Uberti [mailto:juberti@google.com]=20 Sent: Friday, January 09, 2015 1:53 AM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 =20 =20 On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang = wrote: Hi, Justin, =20 Is it more straightforward to define one new attribute that named = =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F and = OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this = attribute will be assigned the relay address that is the same type as = seen from the source address of =E2=80=9CAllocate Request=E2=80=9D = packet, not default in IPv4 relay address. =20 I suppose this could be a third option (c), in addition to (a) multiple = R-A-F and (b) multiple optional-a-f. Here's how a/b/c look on the wire = when requesting v4+v6 simultaneously. If requesting v4 or v6 only for = some reason, a/b/c would all send a single RAF. =20 a: RAF (v4) + RAF (v6) a1: server is 5766: error (RAF required-comprehension but unknown) a2: server is 6156: v4 address, or error (undefined behavior) a3: server is SSODA: v4 address + v6 address b: OAF (v4) + OAF (v6) b1: server is 5766/6156: v4 address (OAF ignored) b2: server is SSODA: v4 address + v6 address c: AAF (v6) c1: server is 5766/6156: v4 address (AAF ignored) c2: server is SSODA: v4 address + v6 address =20 Note that for c), one could send RAF(v4) + AAF(v6), but since that would = fail on a 5766 server, sending just AAF(v6) would be preferable. Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 = server would return a v4 address, which is slightly inelegant. For either b/c, we would need to say that including both RAF and OAF/AAF = for the same address family is prohibited. =20 b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the = default AF), but feels a bit more complicated than c). I am supportive = of either b)/c), with maybe a slight preference for c). =20 =20 For reducing the port resource consumption on TURN server that described = in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have = another proposal = http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can = mitigate the ip address/port allocation burden on TURN server------All = endpoints that under one TURN server can use the same IPv4/IPv6 relay = address/port. =20 The port consumption is a side benefit; the primary benefit of SSODA is = the reduction in the overall number of candidates. =20 Best Regards. Aijun Wang. =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Thursday, January 08, 2015 12:02 PM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: [SPAM] Re: [tram] SSODA in TURN-bis =20 I promised I would write up a summary of the current mechanism, and what = we could do instead, so here goes: =20 The currently documented mechanism is to send two R-A-F attributes in = the request, and get back either a single address (from legacy servers), = v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/:: = (for new servers that only support one address family), or an error-code = (to indicate complete failure). =20 At the time, there were 2 concerns listed, namely: 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may = fail the request completely, or do other weird things. 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; = specifically, detailed error information cannot be included. =20 I also thought of a 3rd problem: 3) an old(5766) server may fail the request completely, due to the fact = that R-A-F is comprehension-required. Thus an extra roundtrip may be = needed in this case, negating one of the benefits of SSODA. =20 I think the ideal solution to #1/#3 is to add a new = OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but = comprehension-optional, where multiple values are explicitly supported. = Old servers can safely ignore this and will return IPv4 (solving #3), = while new servers can process this to return multiple = XOR-RELAYED-ADDRESSes in the response. #2 is not a serious issue, but it could easily be solved by defining a = new ADDRESS-ERROR-CODE as follows: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Rsvd |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Then a server could return a normal IPv4 address, but a error code for = IPv6 with either 440 (unsupported address family) or 508 (insufficient = capacity) or some other TBD error. =20 I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple = and prevents potential interoperability problems with old servers. I = could go either way on ADDRESS-ERROR-CODE. =20 =20 =20 On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) = wrote: Hi all, =20 We are working on incorporating RFC6156 and SSODA into TURN-bis. During = IETF-91 meeting there was discussion if the technique proposed in = https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break = existing TURN server implementations. Pal had mentioned testing with = four implementations and did not face any problem. =20 Please let us know if there are any concerns with the existing proposal = of conveying two REQUESTED-ADDRESS-FAMILY attributes with different = attribute values in Allocate request ? =20 Cheers, -Tiru _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_0090_01D02BFD.0D149F80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Reddy and Justin:

 

Can we use only one attribute to accomplish the requirement of relay = address that for additional address family? The TURN server can deduct = the default relay address type by the XOR-MAP-Address that it seen from = the =C2=A0allocation request. =C2=A0It can also satisfy the further = situation such as only IPv6 TURN server deployed, but there is still the = Dual stack ICE client exist.

 

Reuse or Redefine the RAF attribute then?

 

Best Regards.

 

From:= = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: = Friday, January 09, 2015 10:35 AM
To: Justin Uberti; Aijun = Wang
Cc: tram@ietf.org
Subject: RE: [tram] SSODA in = TURN-bis

 

Hi Justin,

 

option c) looks good, it was discussed in the WG sometime back that = TURN-bis client MUST include R-A-F in the Allocate = request.

 

-Tiru

 

From:= Justin = Uberti [mailto:juberti@google.com] =
Sent: Friday, January 09, 2015 1:53 AM
To: Aijun = Wang
Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: = [tram] SSODA in TURN-bis

 

 

 

On Wed, Jan 7, 2015 at 11:14 PM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi, Justin,

 

Is it more straightforward to define one new attribute that named = =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F = and  OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include = this attribute will be assigned the relay address that is the same type = as seen from the source address of =E2=80=9CAllocate Request=E2=80=9D = packet, not default in IPv4 relay address.

 

I suppose this could be a third = option (c), in addition to (a) multiple R-A-F and (b) multiple = optional-a-f.  Here's how a/b/c look on the wire when requesting = v4+v6 simultaneously. If requesting v4 or v6 only for some reason, a/b/c = would all send a single RAF.

 

a: RAF (v4) + RAF = (v6)

a1: server is 5766: error (RAF required-comprehension but = unknown)

a2: server is 6156: v4 address, or error (undefined = behavior)

a3: server is SSODA: v4 address + v6 = address

b: OAF (v4) + OAF (v6)

b1: server is 5766/6156: v4 address = (OAF ignored)

b2: server is SSODA: v4 address + v6 = address

c: AAF (v6)

c1: server is 5766/6156: v4 address = (AAF ignored)

c2: server is SSODA: v4 address + v6 = address

 

Note that for c), one could send = RAF(v4) + AAF(v6), but since that would fail on a 5766 server, sending = just AAF(v6) would be preferable.

Note that for b), if one sent = OAF(v6) by itself for some reason, a 5766 server would return a v4 = address, which is slightly inelegant.

For either b/c, we would need to = say that including both RAF and OAF/AAF for the same address family is = prohibited.

 

b) is nice in that it avoids = implicit behavior (i.e. that IPv4 is the default AF), but feels a bit = more complicated than c). I am supportive of either b)/c), with maybe a = slight preference for c).

 

 

For reducing the port resource consumption on TURN server that = described in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-= 01, we have another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlit= e/ that can mitigate the ip address/port allocation burden on TURN = server------All endpoints that under one TURN server can use the same = IPv4/IPv6 relay  address/port.

 

The port consumption is a side = benefit; the primary benefit of SSODA is the reduction in the overall = number of candidates.

 

Best Regards.

Aijun Wang.

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: = Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: [SPAM] Re: [tram] = SSODA in TURN-bis

 

I promised I would write up a summary of the current = mechanism, and what we could do instead, so here = goes:

 

The currently documented mechanism is to send two R-A-F = attributes in the request, and get back either a single address (from = legacy servers), v4 + v6 addresses (from new servers), a single address = + a 0.0.0.0/:: (for = new servers that only support one address family), or an error-code (to = indicate complete failure).

 

At the time, there were 2 concerns listed, = namely:

1) sending multiple R-A-Fs is undefined behavior; old = (6156) servers may fail the request completely, or do other weird = things.

2) using 0.0.0.0/:: to indicate partial success is somewhat = unclean; specifically, detailed error information cannot be = included.

 

I also thought of a 3rd = problem:

3) an old(5766) server may fail the request completely, due = to the fact that R-A-F is comprehension-required. Thus an extra = roundtrip may be needed in this case, negating one of the benefits of = SSODA.

 

I think the ideal solution to #1/#3 is to add a new = OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but = comprehension-optional, where multiple values are explicitly supported. = Old servers can safely ignore this and will return IPv4 (solving #3), = while new servers can process this to return multiple = XOR-RELAYED-ADDRESSes in the = response.

#2 is not a serious issue, but it could easily be solved by = defining a new ADDRESS-ERROR-CODE as = follows:

 

      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
span lang=3DEN-US>
      |  Address =
Family           &=
nbsp;    |  Rsvd  =
|Class|     Number    |
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
span lang=3DEN-US>
      =
|      Reason Phrase =
(variable)          &nb=
sp;           &nbs=
p;         ..
      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
span lang=3DEN-US>
 
Then a server =
could return a normal IPv4 address, but a error code for IPv6 with =
either 440 (unsupported address family) or 508 (insufficient capacity) =
or some other TBD error.
 
I advocate we =
do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and prevents =
potential interoperability problems with old servers. I could go either =
way on ADDRESS-ERROR-CODE.
 
 

 

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy = (tireddy) <tireddy@cisco.com> = wrote:

Hi all,

 

We are working on incorporating RFC6156 and SSODA into = TURN-bis. During IETF-91 meeting there was discussion if the technique = proposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-= 01 would break existing TURN server implementations.  Pal had = mentioned testing with four implementations and did not face any = problem.

 

Please let us know if there are any concerns with the = existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes = with different attribute values in Allocate request = ?

 

Cheers,

-Tiru


_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

------=_NextPart_000_0090_01D02BFD.0D149F80-- From nobody Thu Jan 8 19:33:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F1B1A1B60 for ; Thu, 8 Jan 2015 19:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no 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 lb6saMvo8OKM for ; Thu, 8 Jan 2015 19:33:25 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520D51A1A28 for ; Thu, 8 Jan 2015 19:33:25 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id r5so6461078qcx.2 for ; Thu, 08 Jan 2015 19:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=leUpVzCKmS5mGLx+BtBpkLow3IMf+JnJa+4Nl05jGkU=; b=cIbozolusSfdXeAZdUSuObO6mW6qQdop/u2Z7PQ2PEBv9Z9OZB7fE71yoMiXiyhacY BVGcSKvo0ftamrjNpVddtLt+OG6aiqSv6Lwi/U5K/pDJTO99u4EDiENw1ro+hwat4n4H nuVQENVIWFL4rzi76+nN89va0ZA9+faLbPpSRHLZ4YzwCWKBzI1q6wG8JuRXsGVbz4iX VXpKLZPZKVBYwfx3wF0B45B7iPQMcNLS/cB8t2wc6U3cWm9KIxymqwT8qPwp+xSVjTfq sUE2ZBy2dx6BvVqoH8TFT9SxxZDbjb2hfb/wf9GkVNy8nnGcjAKIYcpzXbPgQr5oDrzw UpRw== X-Received: by 10.229.92.196 with SMTP id s4mr1821012qcm.25.1420774404489; Thu, 08 Jan 2015 19:33:24 -0800 (PST) Received: from [10.73.211.179] (nat-dip31-wl-e.cfw-a-gci.corp.yahoo.com. [66.228.162.48]) by mx.google.com with ESMTPSA id p69sm5886232qga.27.2015.01.08.19.33.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 19:33:23 -0800 (PST) References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> Mime-Version: 1.0 (1.0) In-Reply-To: <008f01d02bb9$fef15f80$fcd41e80$@org.cn> Content-Type: multipart/alternative; boundary=Apple-Mail-B6B34FC4-5048-43D2-9265-088B38F2CFB4 Content-Transfer-Encoding: 7bit Message-Id: <7AD7A728-F88F-484C-8F46-CBDAD9203A40@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Thu, 8 Jan 2015 19:33:24 -0800 To: Aijun Wang Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 03:33:29 -0000 --Apple-Mail-B6B34FC4-5048-43D2-9265-088B38F2CFB4 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable That is my proposal, too. The main objection is that some are saying that that will break the old serv= ers. But nobody provided an example of an old server that would be broken. T= hat possibility is remote; I believe that making a "symmetric" clean protoco= l with RAF for both ipv4 and ipv6 is more important. Thanks Oleg Sent from my iPhone > On Jan 8, 2015, at 7:11 PM, "Aijun Wang" wrote= : >=20 > Hi, Reddy and Justin: > =20 > Can we use only one attribute to accomplish the requirement of relay addre= ss that for additional address family? The TURN server can deduct the defaul= t relay address type by the XOR-MAP-Address that it seen from the allocatio= n request. It can also satisfy the further situation such as only IPv6 TURN= server deployed, but there is still the Dual stack ICE client exist. > =20 > Reuse or Redefine the RAF attribute then? > =20 > Best Regards. > =20 > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 > Sent: Friday, January 09, 2015 10:35 AM > To: Justin Uberti; Aijun Wang > Cc: tram@ietf.org > Subject: RE: [tram] SSODA in TURN-bis > =20 > Hi Justin, > =20 > option c) looks good, it was discussed in the WG sometime back that TURN-b= is client MUST include R-A-F in the Allocate request. > =20 > -Tiru > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > Sent: Friday, January 09, 2015 1:53 AM > To: Aijun Wang > Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] SSODA in TURN-bis > =20 > =20 > =20 > On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang wr= ote: > Hi, Justin, > =20 > Is it more straightforward to define one new attribute that named =93Addit= ional-Address-Family =94 instead of the R-A-F and OPTIONAL-ADDRESS-FAMILY? T= he endpoint that does not include this attribute will be assigned the relay a= ddress that is the same type as seen from the source address of =93Allocate R= equest=94 packet, not default in IPv4 relay address. > =20 > I suppose this could be a third option (c), in addition to (a) multiple R-= A-F and (b) multiple optional-a-f. Here's how a/b/c look on the wire when r= equesting v4+v6 simultaneously. If requesting v4 or v6 only for some reason,= a/b/c would all send a single RAF. > =20 > a: RAF (v4) + RAF (v6) > a1: server is 5766: error (RAF required-comprehension but unknown) > a2: server is 6156: v4 address, or error (undefined behavior) > a3: server is SSODA: v4 address + v6 address > b: OAF (v4) + OAF (v6) > b1: server is 5766/6156: v4 address (OAF ignored) > b2: server is SSODA: v4 address + v6 address > c: AAF (v6) > c1: server is 5766/6156: v4 address (AAF ignored) > c2: server is SSODA: v4 address + v6 address > =20 > Note that for c), one could send RAF(v4) + AAF(v6), but since that would f= ail on a 5766 server, sending just AAF(v6) would be preferable. > Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 se= rver would return a v4 address, which is slightly inelegant. > For either b/c, we would need to say that including both RAF and OAF/AAF f= or the same address family is prohibited. > =20 > b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the defa= ult AF), but feels a bit more complicated than c). I am supportive of either= b)/c), with maybe a slight preference for c). > =20 > =20 > For reducing the port resource consumption on TURN server that described i= n https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have another= proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can= mitigate the ip address/port allocation burden on TURN server------All endp= oints that under one TURN server can use the same IPv4/IPv6 relay address/p= ort. > =20 > The port consumption is a side benefit; the primary benefit of SSODA is th= e reduction in the overall number of candidates. > =20 > Best Regards. > Aijun Wang. > =20 > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti > Sent: Thursday, January 08, 2015 12:02 PM > To: Tirumaleswar Reddy (tireddy) > Cc: tram@ietf.org > Subject: [SPAM] Re: [tram] SSODA in TURN-bis > =20 > I promised I would write up a summary of the current mechanism, and what w= e could do instead, so here goes: > =20 > The currently documented mechanism is to send two R-A-F attributes in the r= equest, and get back either a single address (from legacy servers), v4 + v6 a= ddresses (from new servers), a single address + a 0.0.0.0/:: (for new server= s that only support one address family), or an error-code (to indicate compl= ete failure). > =20 > At the time, there were 2 concerns listed, namely: > 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may f= ail the request completely, or do other weird things. > 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; speci= fically, detailed error information cannot be included. > =20 > I also thought of a 3rd problem: > 3) an old(5766) server may fail the request completely, due to the fact th= at R-A-F is comprehension-required. Thus an extra roundtrip may be needed in= this case, negating one of the benefits of SSODA. > =20 > I think the ideal solution to #1/#3 is to add a new OPTIONAL-ADDRESS-FAMIL= Y attribute, identical to R-A-F but comprehension-optional, where multiple v= alues are explicitly supported. Old servers can safely ignore this and will r= eturn IPv4 (solving #3), while new servers can process this to return multip= le XOR-RELAYED-ADDRESSes in the response. > #2 is not a serious issue, but it could easily be solved by defining a new= ADDRESS-ERROR-CODE as follows: > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address Family | Rsvd |Class| Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reason Phrase (variable) .. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Then a server could return a normal IPv4 address, but a error code for IPv= 6 with either 440 (unsupported address family) or 508 (insufficient capacity= ) or some other TBD error. > =20 > I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and= prevents potential interoperability problems with old servers. I could go e= ither way on ADDRESS-ERROR-CODE. > =20 > =20 > =20 > On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi all, > =20 > We are working on incorporating RFC6156 and SSODA into TURN-bis. During IE= TF-91 meeting there was discussion if the technique proposed in https://tool= s.ietf.org/html/draft-martinsen-tram-ssoda-01 would break existing TURN serv= er implementations. Pal had mentioned testing with four implementations and= did not face any problem. > =20 > Please let us know if there are any concerns with the existing proposal of= conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute v= alues in Allocate request ? > =20 > Cheers, > -Tiru >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 > =20 > =20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail-B6B34FC4-5048-43D2-9265-088B38F2CFB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That is my proposal, too.
The main objection is that some are saying that that will break= the old servers. But nobody provided an example of an old server that would= be broken. That possibility is remote; I believe that making a "symmetric" c= lean protocol with RAF for both ipv4 and ipv6 is more important.
<= br>
Thanks
Oleg

Sent from my iPhone
On Jan 8, 2015, at 7:11 PM, "Aijun Wang" <wangaijun@tsinghua.org.cn> wrote:

Hi, Reddy and Justin:=

 

Can we use only one attribute to accomplish the require= ment of relay address that for additional address family? The TURN server ca= n deduct the default relay address type by the XOR-MAP-Address that it seen f= rom the  allocation request.  It can also satisfy the further situ= ation such as only IPv6 TURN server deployed, but there is still the Dual st= ack ICE client exist.

 

Reuse or Redefine the RAF att= ribute then?

 

Best Regards.

 

From: Tirumaleswar Reddy (tiredd= y) [mailto:tireddy@cisco.com]
<= b>Sent: Friday, January 09, 2015 10:35 AM
To: Justin Uberti; A= ijun Wang
Cc: tram@ietf.orgSubject: RE: [tram] SSODA in TURN-bis

 

=

Hi Justin,

 

option c) looks good, it was discussed in the WG som= etime back that TURN-bis client MUST include R-A-F in the Allocate request.<= o:p>

 

-Tiru

<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri"= ;,"sans-serif";color:#1F497D"> 

From:<= /b> Justin Uberti [mailto:juberti@google.com]
Sent: Friday, January 09, 2= 015 1:53 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tired= dy); tram@ietf.org
Subject: R= e: [tram] SSODA in TURN-bis

 

 

 

On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang &= lt;wangaijun@= tsinghua.org.cn> wrote:

Hi, Justin,

 

Is it more straightforward to define one new attribute t= hat named =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F a= nd  OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this at= tribute will be assigned the relay address that is the same type as seen fro= m the source address of =E2=80=9CAllocate Request=E2=80=9D packet, not defau= lt in IPv4 relay address.

<= /div>

 

I suppose= this could be a third option (c), in addition to (a) multiple R-A-F and (b)= multiple optional-a-f.  Here's how a/b/c look on the wire when request= ing v4+v6 simultaneously. If requesting v4 or v6 only for some reason, a/b/c= would all send a single RAF.

 

a: RAF (v4) + RAF (v6)

a1: server is 57= 66: error (RAF required-comprehension but unknown)

a2: server is 6156: v4 ad= dress, or error (undefined behavior)

a3: server is SSODA: v4 address + v6 ad= dress

b: OAF (v4) + OAF (v6)

b1: server is 5766/6156: v4 address (OAF ignore= d)

b2: server is SSODA: v4 address + v6 address

<= div>

c: AAF (v6)

c1: server is 57= 66/6156: v4 address (AAF ignored)

c2: server is SSODA: v4 address + v6 addres= s

 

Note that for c), one could send RAF(v4) + AAF(v6), but since that w= ould fail on a 5766 server, sending just AAF(v6) would be preferable.

Note t= hat for b), if one sent OAF(v6) by itself for some reason, a 5766 server wou= ld return a v4 address, which is slightly inelegant.

For either b/c, we woul= d need to say that including both RAF and OAF/AAF for the same address famil= y is prohibited.

 

b) is nice in that it avoids implicit behavior (i.e.= that IPv4 is the default AF), but feels a bit more complicated than c). I a= m supportive of either b)/c), with maybe a slight preference for c).

&n= bsp;

 

For reducing the port res= ource consumption on TURN server that described in https://tools= .ietf.org/html/draft-martinsen-tram-ssoda-01, we have another proposal <= a href=3D"http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/" target=3D= "_blank">http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that c= an mitigate the ip address/port allocation burden on TURN server------All en= dpoints that under one TURN server can use the same IPv4/IPv6 relay  ad= dress/port.

 =

The port c= onsumption is a side benefit; the primary benefit of SSODA is the reduction i= n the overall number of candidates.

<= div>

 

Best Regards.

Aijun Wang.

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: Tirumaleswar Reddy (tire= ddy)
Cc: tram@i= etf.org
Subject: [SPAM] Re: [tram] SSODA in TURN-bis

 

I p= romised I would write up a summary of the current mechanism, and what we cou= ld do instead, so here goes:

 

Th= e currently documented mechanism is to send two R-A-F attributes in the requ= est, and get back either a single address (from legacy servers), v4 + v6 add= resses (from new servers), a single address + a 0.0.0.0/:: (for new servers that only support one addre= ss family), or an error-code (to indicate complete failure).

 

At the time, there were 2 concerns lis= ted, namely:

1)= sending multiple R-A-Fs is undefined behavior; old (6156) servers may fail t= he request completely, or do other weird things.

=

2) using 0.0.0.0/:: to indicate partial success is somewhat unclean;= specifically, detailed error information cannot be included.

 

<= /div>

I also thought of a 3rd problem:=

3) an old(5766) ser= ver may fail the request completely, due to the fact that R-A-F is comprehen= sion-required. Thus an extra roundtrip may be needed in this case, negating o= ne of the benefits of SSODA.

 

I think the ideal solution to #1/#3 is to add a new OPTIONAL-ADDRESS-FA= MILY attribute, identical to R-A-F but comprehension-optional, where multipl= e values are explicitly supported. Old servers can safely ignore this and wi= ll return IPv4 (solving #3), while new servers can process this to return mu= ltiple XOR-RELAYED-ADDRESSes in the response.

#2 is not a serious issue, but it could easil= y be solved by defining a new ADDRESS-ERROR-CODE as follows:

 

   &=
nbsp;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+
      |  Address Fami=
ly            &n=
bsp;   |  Rsvd  |Class|     Number&n=
bsp;   |
<=
span lang=3D"EN-US" style=3D"color:black">      +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Rea=
son Phrase (variable)         &=
nbsp;            =
;          ..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+
= 
 
Then a server could=
 return a normal IPv4 address, but a error code for IPv6 with either 440 (un=
supported address family) or 508 (insufficient capacity) or some other TBD e=
rror.
 
I advocate we do the OPTIONAL-ADDRESS-=
FAMILY attribute as it is simple and prevents potential interoperability pro=
blems with old servers. I could go either way on ADDRESS-ERROR-CODE.<=
span lang=3D"EN-US">
 
 <= /pre>

 <= /p>

On Wed, Jan 7, 2015 at 6:02 PM, Tirumal= eswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Hi all,

 

We are working o= n incorporating RFC6156 and SSODA into TURN-bis. During IETF-91 meeting ther= e was discussion if the technique proposed in https://tools.ietf= .org/html/draft-martinsen-tram-ssoda-01 would break existing TURN server= implementations.  Pal had mentioned testing with four implementations a= nd did not face any problem.

 

Please let us kn= ow if there are any concerns with the existing proposal of conveying two REQ= UESTED-ADDRESS-FAMILY attributes with different attribute values in Allocate= request ?

 

Cheers,

-Tiru


_______________________________________________
tram mailing l= ist
tram@ietf.org<= br>= https://www.ietf.org/mailman/listinfo/tram

 

 

____________________________________= ___________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram
= --Apple-Mail-B6B34FC4-5048-43D2-9265-088B38F2CFB4-- From nobody Thu Jan 8 22:26:06 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9D1A700E for ; Thu, 8 Jan 2015 22:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Q1rZV8LwNe-t for ; Thu, 8 Jan 2015 22:26:01 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057AF1A00B6 for ; Thu, 8 Jan 2015 22:26:00 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id hq12so2642754vcb.13 for ; Thu, 08 Jan 2015 22:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8t711T1Vl02LaetTcvdsF8Az+jcstgILmsW517g9e/k=; b=Z+rklLjtHGVeXA16KE5Bob7GztmXed5hDBPmm+RYxFvkb03SN7ReEpbakod4X+rVCU NAmFZ7YUVBGcFkLL8ISHbTKPpCubb9kbh8eISic14f0lyA6TwmFQC1HLSx1eC/pbfCNe KNkRr8G09jbuIRYrZLrgnIinosy6wF6Xlj54trUS+IkxWp7lOzOkzPMpEERJiBMeDt9M BL9is1u3ZsTAELQQWVCN0V+wJCKoNPSpy6hIN3PTkoA28UjYAwYtH17kN24leLXpKBF1 q4Jtcj3TkYIRXXBYWyQFBVwLZVXEshMwlH5dg+YhbOkugpj7/dQi9GYHRQkUpbtqT6tv oRYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8t711T1Vl02LaetTcvdsF8Az+jcstgILmsW517g9e/k=; b=IYYoJxrw/kcxrqflDb+FyVddEw0rEKUV7br/VnCPI19SbcKvFsbV1C/mObo63gF7Zw ZBw/36LasKbwIxFBvQM90hbZr7yoj8UhCpoaOnCl3g0cdl1mgP2bvSpOixMrkcx7qoPM 0JsyUqCtexvFV8Xr0cPpbTnWJ2VGG4mqqDGJO6G2Vyvv8jJhNHCr2YEMD3jm0IktDIeA v+iAQTDKRj7adoWL/baIj6qGBVZgUiXDD9I7MXQYKkK+YYjvR1rLFyetD5u+THQLBLeQ F7pI74vFqaV/AvCrlqqZ7gUHJwcnV3/nfxD/8gmHrPLGw1RHZozp/bPjHmp1IX9uej87 aDSg== X-Gm-Message-State: ALoCoQmmQgj4HaH22YwMUyZyd0v8iYQfzqUb7IXXKoNBAdjE/ZC+vkKeQOnUzBOatM11tAItOWq9 X-Received: by 10.52.190.40 with SMTP id gn8mr864935vdc.56.1420784760005; Thu, 08 Jan 2015 22:26:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 22:25:39 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Thu, 8 Jan 2015 22:25:39 -0800 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1133f782ec41fc050c323af8 Archived-At: Cc: Aijun Wang , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:26:04 -0000 --001a1133f782ec41fc050c323af8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 8, 2015 at 6:34 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Justin, > > > > option c) looks good, it was discussed in the WG sometime back that > TURN-bis client MUST include R-A-F in the Allocate request. > I'm not sure this is a good idea since 5766 servers will choke on this. > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Friday, January 09, 2015 1:53 AM > *To:* Aijun Wang > *Cc:* Tirumaleswar Reddy (tireddy); tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > > > > > On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang > wrote: > > Hi, Justin, > > > > Is it more straightforward to define one new attribute that named > =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F and > OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this attribut= e > will be assigned the relay address that is the same type as seen from the > source address of =E2=80=9CAllocate Request=E2=80=9D packet, not default = in IPv4 relay > address. > > > > I suppose this could be a third option (c), in addition to (a) multiple > R-A-F and (b) multiple optional-a-f. Here's how a/b/c look on the wire > when requesting v4+v6 simultaneously. If requesting v4 or v6 only for som= e > reason, a/b/c would all send a single RAF. > > > > a: RAF (v4) + RAF (v6) > > a1: server is 5766: error (RAF required-comprehension but unknown) > > a2: server is 6156: v4 address, or error (undefined behavior) > > a3: server is SSODA: v4 address + v6 address > > b: OAF (v4) + OAF (v6) > > b1: server is 5766/6156: v4 address (OAF ignored) > > b2: server is SSODA: v4 address + v6 address > > c: AAF (v6) > > c1: server is 5766/6156: v4 address (AAF ignored) > > c2: server is SSODA: v4 address + v6 address > > > > Note that for c), one could send RAF(v4) + AAF(v6), but since that would > fail on a 5766 server, sending just AAF(v6) would be preferable. > > Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 > server would return a v4 address, which is slightly inelegant. > > For either b/c, we would need to say that including both RAF and OAF/AAF > for the same address family is prohibited. > > > > b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the > default AF), but feels a bit more complicated than c). I am supportive of > either b)/c), with maybe a slight preference for c). > > > > > > For reducing the port resource consumption on TURN server that described > in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have > another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite= / > that can mitigate the ip address/port allocation burden on TURN > server------All endpoints that under one TURN server can use the same > IPv4/IPv6 relay address/port. > > > > The port consumption is a side benefit; the primary benefit of SSODA is > the reduction in the overall number of candidates. > > > > Best Regards. > > Aijun Wang. > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Thursday, January 08, 2015 12:02 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* [SPAM] Re: [tram] SSODA in TURN-bis > > > > I promised I would write up a summary of the current mechanism, and what > we could do instead, so here goes: > > > > The currently documented mechanism is to send two R-A-F attributes in the > request, and get back either a single address (from legacy servers), v4 + > v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new > servers that only support one address family), or an error-code (to > indicate complete failure). > > > > At the time, there were 2 concerns listed, namely: > > 1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may > fail the request completely, or do other weird things. > > 2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; > specifically, detailed error information cannot be included. > > > > I also thought of a 3rd problem: > > 3) an old(5766) server may fail the request completely, due to the fact > that R-A-F is comprehension-required. Thus an extra roundtrip may be need= ed > in this case, negating one of the benefits of SSODA. > > > > I think the ideal solution to #1/#3 is to add a new > OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but > comprehension-optional, where multiple values are explicitly supported. O= ld > servers can safely ignore this and will return IPv4 (solving #3), while n= ew > servers can process this to return multiple XOR-RELAYED-ADDRESSes in the > response. > > #2 is not a serious issue, but it could easily be solved by defining a ne= w > ADDRESS-ERROR-CODE as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family | Rsvd |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Then a server could return a normal IPv4 address, but a error code for IP= v6 with either 440 (unsupported address family) or 508 (insufficient capaci= ty) or some other TBD error. > > > > I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple an= d prevents potential interoperability problems with old servers. I could go= either way on ADDRESS-ERROR-CODE. > > > > > > > > On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi all, > > > > We are working on incorporating RFC6156 and SSODA into TURN-bis. During > IETF-91 meeting there was discussion if the technique proposed in > https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break > existing TURN server implementations. Pal had mentioned testing with fou= r > implementations and did not face any problem. > > > > Please let us know if there are any concerns with the existing proposal o= f > conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribut= e > values in Allocate request ? > > > > Cheers, > > -Tiru > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > --001a1133f782ec41fc050c323af8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 6:34 PM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Hi Justin,<= /span>

=C2=A0

option c) looks good, it = was discussed in the WG sometime back that TURN-bis client MUST include R-A= -F in the Allocate request.


I'm not sure this is a good idea since 5766 servers will choke = on this.
=C2=A0

=C2=A0

-Tiru

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Friday, January 09, 2015 1:53 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] SSODA in TURN-bis

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <wangaijun@tsingh= ua.org.cn> wrote:

Hi, Justin,<= u>

=C2=A0

Is it more straightforwar= d to define one new attribute that named =E2=80=9CAdditional-Address-Family =E2=80=9D instead of the R-A-F and=C2=A0 OPTIONAL-ADDRESS-FAMILY? The endp= oint that does not include this attribute will be assigned the relay addres= s that is the same type as seen from the source address of =E2=80=9CAllocat= e Request=E2=80=9D packet, not default in IPv4 relay address.<= u>

=C2=A0

I suppose this could be a third option (c), in addit= ion to (a) multiple R-A-F and (b) multiple optional-a-f.=C2=A0 Here's h= ow a/b/c look on the wire when requesting v4+v6 simultaneously. If requesti= ng v4 or v6 only for some reason, a/b/c would all send a single RAF.

=C2=A0

a: RAF (v4) + RAF (v6)

a1: server is 5766: error (RAF required-comprehensio= n but unknown)

a2: server is 6156: v4 address, or error (undefined = behavior)

a3: server is SSODA: v4 address + v6 address<= u>

b: OAF (v4) + OAF (v6)

b1: server is 5766/6156: v4 address (OAF ignored)=

b2: server is SSODA: v4 address + v6 address<= u>

c: AAF (v6)

c1: server is 5766/6156: v4 address (AAF ignored)=

c2: server is SSODA: v4 address + v6 address<= u>

=C2=A0

Note that for c), one could send RAF(v4) + AAF(v6), = but since that would fail on a 5766 server, sending just AAF(v6) would be p= referable.

Note that for b), if one sent OAF(v6) by itself for = some reason, a 5766 server would return a v4 address, which is slightly ine= legant.

For either b/c, we would need to say that including = both RAF and OAF/AAF for the same address family is prohibited.

=C2=A0

b) is nice in that it avoids implicit behavior (i.e.= that IPv4 is the default AF), but feels a bit more complicated than c). I = am supportive of either b)/c), with maybe a slight preference for c).

=C2=A0

=C2=A0

For reducing the port res= ource consumption on TURN server that described in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have anot= her proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can miti= gate the ip address/port allocation burden on TURN server------All endpoint= s that under one TURN server can use the same IPv4/IPv6 relay =C2=A0address= /port.

=C2=A0

The port consumption is a side benefit; the primary = benefit of SSODA is the reduction in the overall number of candidates.

=C2=A0

Best Regards.

Aijun Wang.<= u>

=C2=A0

From: tram [mailto:tr= am-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: [SPAM] Re: [tram] SSODA in TURN-bis<= /u>

=C2=A0

I promised I would write up a summary of the c= urrent mechanism, and what we could do instead, so here goes:=

=C2=A0

The currently documented mechanism is to send = two R-A-F attributes in the request, and get back either a single address (= from legacy servers), v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new servers that only support one address family), or a= n error-code (to indicate complete failure).

=C2=A0

At the time, there were 2 concerns listed, nam= ely:

1) sending multiple R-A-Fs is undefined behavi= or; old (6156) servers may fail the request completely, or do other weird t= hings.

2) using 0.0.0.0/:: to indicate pa= rtial success is somewhat unclean; specifically, detailed error information= cannot be included.

=C2=A0

I also thought of a 3rd problem:=

3) an old(5766) server may fail the request co= mpletely, due to the fact that R-A-F is comprehension-required. Thus an ext= ra roundtrip may be needed in this case, negating one of the benefits of SSODA.

=C2=A0

I think the ideal solution to #1/#3 is to add = a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but comprehensi= on-optional, where multiple values are explicitly supported. Old servers can safely ignore th= is and will return IPv4 (solving #3), while new servers can process this to= return multiple XOR-RELAYED-ADDRESSes in the response.

#2 is not a serious issue, but it could easily= be solved by defining a new ADDRESS-ERROR-CODE as follows:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Add=
ress Family=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Rsvd=C2=A0 |Class|=C2=A0=C2=A0=C2=A0=C2=
=A0 Number=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Reason Phrase (variable)=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 ..
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
u>
=C2=A0

Then a server could return a normal IPv4 address, but a error =
code for IPv6 with either 440 (unsupported address family) or 508 (insuffic=
ient capacity) or some other TBD error.

=C2=A0

I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it i=
s simple and prevents potential interoperability problems with old servers.=
 I could go either way on ADDRESS-ERROR-CODE.


=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar R= eddy (tireddy) <t= ireddy@cisco.com> wrote:

Hi all,

=C2=A0

We are working on incorporating RFC6156 and SS= ODA into TURN-bis. During IETF-91 meeting there was discussion if the techn= ique proposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break e= xisting TURN server implementations.=C2=A0 Pal had mentioned testing with f= our implementations and did not face any problem.

=C2=A0

Please let us know if there are any concerns w= ith the existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attribu= tes with different attribute values in Allocate request ?

=C2=A0

Cheers,

-Tiru


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0

=C2=A0


--001a1133f782ec41fc050c323af8-- From nobody Thu Jan 8 22:27:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383B01A700E for ; Thu, 8 Jan 2015 22:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 zMyWlE6rdrCc for ; Thu, 8 Jan 2015 22:27:13 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F771A00B6 for ; Thu, 8 Jan 2015 22:27:12 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id kv19so2639542vcb.4 for ; Thu, 08 Jan 2015 22:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gw1/YKIdnLs7RNxqDUAIx9AtfzG5uHH91OD77U6ZPLw=; b=TdEfgCpaks5b5fegx1IeA5ROZ11HgjxgsbYpCrD4fOJRDRgRIg5Ct2pEiWCcXvAu9V w/TN3mjf94C7HzStbeytmlRmZeYEkdBAK7un6rEsI1i5rWajMAlyTPDRf+pxI1W26l/s cy1buJN2TqofBoi58dJuSjQvHdSOduxKoZ/hya+4xxk8Jl1JKZuxvquFc22Uwr0MjA49 78Y+iJNGfP5ivwDbSG1NjktXJabSQJaoalgpy+ZXX+QTUQZZkztMdnCR/o/ubiZrGH9p LqCcLFaUPEb4Ebzjqq4dUvOL9hP/RpCsLN0dUL4fUMSF7FZ1oZL7+kgEy4wDEWeqILCF nvig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gw1/YKIdnLs7RNxqDUAIx9AtfzG5uHH91OD77U6ZPLw=; b=cn8PDZU2WUJSC4SFSNXTLZJ10c9+LEg4n1MxW5IOhlvtXagnsa0FiXO9XFmh5H2FHv UtHFfaBVJj+bGX3/OdVJ6qB1oRsRDumyI9T0qy7m7OujMC2uEyLxhWq3CP111VMU0/Nt 0kpuCWmtzQ8zLinyjBf+/DXXjWUjPxhCEnu+DEcLDKTD6nEz8/TxQtTKVeg1rcxrs+Ir 4lITAmexvTWyZ0EzJO7R8UiCnwht6hi+uTcNMItEsBbLsCMhyCNBDfUmEvkIDJtAuprD O0c9JU9ikne0PolXGlIeiOFWYpAKHgPTKgl8tpk6pUsWY7pSF6WP4nW0v0QxSkpsSrdc pssQ== X-Gm-Message-State: ALoCoQkBthMovhc/8/lULNJ3lQCU+BxEf4xmc0BDmezan6zAp77biO5SXH1Xfn0evJaUSeYkM441 X-Received: by 10.52.36.51 with SMTP id n19mr7787819vdj.77.1420784831780; Thu, 08 Jan 2015 22:27:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 22:26:51 -0800 (PST) In-Reply-To: <008f01d02bb9$fef15f80$fcd41e80$@org.cn> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> From: Justin Uberti Date: Thu, 8 Jan 2015 22:26:51 -0800 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary=20cf307cfd16337ded050c323f54 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:27:14 -0000 --20cf307cfd16337ded050c323f54 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 8, 2015 at 7:11 PM, Aijun Wang wrote: > Hi, Reddy and Justin: > > > > Can we use only one attribute to accomplish the requirement of relay > address that for additional address family? The TURN server can deduct the > default relay address type by the XOR-MAP-Address that it seen from the > allocation request. It can also satisfy the further situation such as > only IPv6 TURN server deployed, but there is still the Dual stack ICE > client exist. > > > > Reuse or Redefine the RAF attribute then? > > > I am not sure what you are proposing; I thought c) reflected your earlier suggestion. --20cf307cfd16337ded050c323f54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 7:11 PM, Aijun Wang <wangaijun@tsinghua= .org.cn> wrote:

Hi, Reddy and Justin:

=C2=A0

Can we use only one attribute to accomplish the requirem= ent of relay address that for additional address family? The TURN server ca= n deduct the default relay address type by the XOR-MAP-Address that it seen= from the =C2=A0allocation request.=C2=A0 It can also satisfy the further s= ituation such as only IPv6 TURN server deployed, but there is still the Dua= l stack ICE client exist.

=C2=A0

Reuse or Redef= ine the RAF attribute then?

= =C2=A0

I am not sure what you are proposing; I thought c) ref= lected your earlier suggestion.

--20cf307cfd16337ded050c323f54-- From nobody Thu Jan 8 22:31:24 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1711A19F6 for ; Thu, 8 Jan 2015 22:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 d1OQvx0UgnDh for ; Thu, 8 Jan 2015 22:31:20 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88561A0055 for ; Thu, 8 Jan 2015 22:31:20 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so2640755vcb.8 for ; Thu, 08 Jan 2015 22:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zZjQwiMKENw+bKOuejExIdRhUtDu2WKppblqA5hBEPo=; b=o1UpIzXwP/xP+NcoE6JbQ9zbFEkWaQqFSfXfFkos4O6Xvi4GE13vtCWyhXJy8yqlFF nZGCM9q6JTAOP1GJ+XxPDLlnKQSaVeGaQdcJy4aWgjY8Z5GgD4yKOaBem6gX/mFHC35P VR751RWSDyRrS+E6fd49F4qg9JcijUhwXXJ4BrTlubbX6KPobJwX1KHGi05LoRUPBSCK Zs9EerBoDH5hIPr69j2CZWYGvzDUij4lUECT68rb8+8CL9B8LVPwYAhR0eLlJlF13Sds EELY0zRLvp7gHYJWZnwCYPVtM/uHczH5Bfxx0tQlYPKdSR1e52iLNdWnMMVhpZA0HXo5 Nabg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zZjQwiMKENw+bKOuejExIdRhUtDu2WKppblqA5hBEPo=; b=R4NO1GxgTqlIlgkz3yabh9d0LIhv+ZCVR+fjrrKBbfmDQBTjnloVP3+ds4HT1VCVua 4s9GxzHP/djY1GNrNlhqAhGYW1gpj37OxJNeLjJI5nfGofo5CNKLPlrK7s5d6j0Ej1Ot BXQPxNljAi7tA00S5wbk+GEiuAF+e473RlGNCbB7UIF6wHrWHKYV0Bsvc7WL0MBF8IVw Yf9yoEy2k8NEjRZjvxbgKcGoRgFVv1WXEcVGokBYYRVWRS1Af6dn0uFtXlqel36rLgwu thiAluV1YiWJ65ZzqX7vkB0mdAELdv24x/1JHZIVBtb7rW3wLHqET4/ZPQ+uS8YUcDV6 TwUg== X-Gm-Message-State: ALoCoQk7e7sFf4qC2rGfr+pZWizQ6VlLN8Vh+y3voPlblNQyNKhexdjWYoKxGEBSeQ65Fb1FG8fr X-Received: by 10.220.139.135 with SMTP id e7mr9161430vcu.75.1420785079858; Thu, 08 Jan 2015 22:31:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 22:30:59 -0800 (PST) In-Reply-To: <7AD7A728-F88F-484C-8F46-CBDAD9203A40@gmail.com> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <7AD7A728-F88F-484C-8F46-CBDAD9203A40@gmail.com> From: Justin Uberti Date: Thu, 8 Jan 2015 22:30:59 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=047d7b343306fcd3dd050c324d3b Archived-At: Cc: Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:31:22 -0000 --047d7b343306fcd3dd050c324d3b Content-Type: text/plain; charset=UTF-8 On Thu, Jan 8, 2015 at 7:33 PM, Oleg Moskalenko wrote: > That is my proposal, too. > > The main objection is that some are saying that that will break the old > servers. But nobody provided an example of an old server that would be > broken. That possibility is remote; I believe that making a "symmetric" > clean protocol with RAF for both ipv4 and ipv6 is more important. > I disagree. If there are even a few servers out there that fail, Chrome will have to not use SSODA or have some complicated fallback heuristic. The IETF has had a long tradition of making protocols that are backwards compatible, sometimes at the cost of elegance. Well, except for IPv6. --047d7b343306fcd3dd050c324d3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 7:33 PM, Oleg Moskalenko <<= a href=3D"mailto:mom040267@gmail.com" target=3D"_blank">mom040267@gmail.com= > wrote:
=
That is my proposal, too.

The main objection = is that some are saying that that will break the old servers. But nobody pr= ovided an example of an old server that would be broken. That possibility i= s remote; I believe that making a "symmetric" clean protocol with= RAF for both ipv4 and ipv6 is more important.

I disagree. If there are even a few servers out there that = fail, Chrome will have to not use SSODA or have some complicated fallback h= euristic.

The IETF has had a long tradition of mak= ing protocols that are backwards compatible, sometimes at the cost of elega= nce. Well, except for IPv6.
--047d7b343306fcd3dd050c324d3b-- From nobody Thu Jan 8 22:44:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C571A701E for ; Thu, 8 Jan 2015 22:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 sEzpF0VGriRG for ; Thu, 8 Jan 2015 22:44:10 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2167F1A0055 for ; Thu, 8 Jan 2015 22:44:10 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so6411832wgg.5 for ; Thu, 08 Jan 2015 22:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sJ72fOZKG44af3YaqpUt3EUXMI2hEwbZBRcBOVh+dtk=; b=REkGTRNj0NNWiS5c3JQxG/FPiRLuUTxLidBIidAgoYWzTQ3drv5qShQpduX8uAlNEZ FcUVhcj5L4Pce31hwFppb6It6Nf2v2+FcOnD6eR+BN3NP5L5A+sggigo8rMlbwEBl7gU wQiPcmI/GrNBsM/8bqrNF8v1bb6eCt1nln4ClD+UB/AVf+cU3d1yobvFjvjr/UivkwDw 4lozhaQdS40gsYWIK93D+iEb/lZ5o4zCLaZSGsY5A2DzhgkfpnB6uHP48Dtb74B7gwp/ QO1u16wU9XkGq/TXz5+G9I2bc6rL+IheLi7pyCEuaitdMfsJBbFjYP4iZm7W6I+5zDyw NgqQ== MIME-Version: 1.0 X-Received: by 10.181.13.242 with SMTP id fb18mr2274075wid.1.1420785848897; Thu, 08 Jan 2015 22:44:08 -0800 (PST) Received: by 10.194.238.132 with HTTP; Thu, 8 Jan 2015 22:44:08 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <7AD7A728-F88F-484C-8F46-CBDAD9203A40@gmail.com> Date: Thu, 8 Jan 2015 22:44:08 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d043c05c4d355b8050c327bb1 Archived-At: Cc: Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:44:12 -0000 --f46d043c05c4d355b8050c327bb1 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 8, 2015 at 10:30 PM, Justin Uberti wrote: > > > On Thu, Jan 8, 2015 at 7:33 PM, Oleg Moskalenko > wrote: > >> That is my proposal, too. >> >> The main objection is that some are saying that that will break the old >> servers. But nobody provided an example of an old server that would be >> broken. That possibility is remote; I believe that making a "symmetric" >> clean protocol with RAF for both ipv4 and ipv6 is more important. >> > > I disagree. If there are even a few servers out there that fail, Chrome > will have to not use SSODA or have some complicated fallback heuristic. > > The IETF has had a long tradition of making protocols that are backwards > compatible, sometimes at the cost of elegance. Well, except for IPv6. > Well, we are talking exactly about IPv6 here, so... Let's find a single server that will be broken. Then I may agree. Can anybody provide an example ? There are just a few server implementations out there, I believe. If we choose an ugly option, then we will have to deal with the problems for many years. My opinion is that IPv6 and IPv4 are designed as 'equal' network protocols, by their nature. So the right solution must not assume that one protocol is the first-class protocol, and the other one is a 'special case'. --f46d043c05c4d355b8050c327bb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 10:30 PM, Justin Uberti <juberti@google.com> wrote:

=

= On Thu, Jan 8, 2015 at 7:33 PM, Oleg Moskalenko <mom040267@gmail.com= > wrote:
That is my proposal, too.

The main objection is t= hat some are saying that that will break the old servers. But nobody provid= ed an example of an old server that would be broken. That possibility is re= mote; I believe that making a "symmetric" clean protocol with RAF= for both ipv4 and ipv6 is more important.
I disagree. If there are even a few servers out there th= at fail, Chrome will have to not use SSODA or have some complicated fallbac= k heuristic.

The IETF has had a long tradition of = making protocols that are backwards compatible, sometimes at the cost of el= egance. Well, except for IPv6.
Well, we are talking exactly about IPv6 here, so...

Let's find a single server that will be broken. Then I may agree= .

Can anybody provide an example ? There are just a few s= erver implementations out there, I believe.

If we choose = an ugly option, then we will have to deal with the problems for many years.=

My opinion is that IPv6 and IPv4 are designed as 'eq= ual' network protocols, by their nature. So the right solution must not= assume that one protocol is the first-class protocol, and the other one is= a 'special case'.


=C2=A0
--f46d043c05c4d355b8050c327bb1-- From nobody Fri Jan 9 01:17:31 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCB11A86EB for ; Fri, 9 Jan 2015 01:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7] autolearn=no 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 vd2iFeHKKyCa for ; Fri, 9 Jan 2015 01:17:26 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id E4D131A701C for ; Fri, 9 Jan 2015 01:17:24 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BLmgRhh69U5HSzAA==.15823S4; Fri, 09 Jan 2015 15:46:59 +0800 (CST) From: "Aijun Wang" To: "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> In-Reply-To: Date: Fri, 9 Jan 2015 17:17:00 +0800 Message-ID: <00d301d02bed$0f0406b0$2d0c1410$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01D02C30.1D2746B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAryPlQt8YbwC+cQHi82Dkjzkwt3wAIuUfA Content-Language: zh-cn X-CM-TRANSID: Z0GX06BLmgRhh69U5HSzAA==.15823S4 X-Coremail-Antispam: 1U3129KBjvdXoWrtFWrJFW8Gw1rJr4fGF18uFg_yoWDZwbEq3 yxWrWUG3Z5AF4fWw15tr4avF1fZ347Cr48Xr48XrnFqrW0va13A34kKryru3W5G3yIkr9I gr9Fkry7Jr9xWjkaLaAFLSUrUUUUjbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnQAYjs xI4VWUJwAqx4xG67k08I80eVW8JVW5JwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048I F2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1I0E4x 80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4ylYx0E74AGY7Cv6cx26r47MI8E67AF67kF 1VAFwI0_Jrv_JFUI43ZEXa7VU1RuWJUUUUU== Archived-At: Cc: tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:17:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D4_01D02C30.1D2746B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable After your detail analysis and the sentence =E2=80=9CFor either b/c, we = would need to say that including both RAF and OAF/AAF for the same = address family is prohibited.=E2=80=9D, I think it may be better to keep = only one attribute to fulfill the SSODA requirement? =20 =20 From: Justin Uberti [mailto:juberti@google.com]=20 Sent: Friday, January 09, 2015 2:27 PM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 =20 =20 On Thu, Jan 8, 2015 at 7:11 PM, Aijun Wang = wrote: Hi, Reddy and Justin: =20 Can we use only one attribute to accomplish the requirement of relay = address that for additional address family? The TURN server can deduct = the default relay address type by the XOR-MAP-Address that it seen from = the allocation request. It can also satisfy the further situation such = as only IPv6 TURN server deployed, but there is still the Dual stack ICE = client exist. =20 Reuse or Redefine the RAF attribute then? =20 I am not sure what you are proposing; I thought c) reflected your = earlier suggestion. =20 ------=_NextPart_000_00D4_01D02C30.1D2746B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

After your detail analysis and the sentence =E2=80=9CFor either b/c, = we would need to say that including both RAF and OAF/AAF for the same = address family is prohibited.=E2=80=9D, I think it may be better to keep = only one attribute to fulfill the SSODA requirement? = =C2=A0

 

From:= Justin = Uberti [mailto:juberti@google.com]
Sent: Friday, January 09, = 2015 2:27 PM
To: Aijun Wang
Cc: Tirumaleswar Reddy = (tireddy); tram@ietf.org
Subject: Re: [tram] SSODA in = TURN-bis

 

 

 

On Thu, Jan 8, 2015 at 7:11 PM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi, Reddy and Justin:

 

Can we use only one attribute to accomplish the requirement of relay = address that for additional address family? The TURN server can deduct = the default relay address type by the XOR-MAP-Address that it seen from = the  allocation request.  It can also satisfy the further = situation such as only IPv6 TURN server deployed, but there is still the = Dual stack ICE client exist.

 

Reuse or Redefine the RAF attribute then?

 

I am not sure what you are = proposing; I thought c) reflected your earlier = suggestion.

 

------=_NextPart_000_00D4_01D02C30.1D2746B0-- From nobody Fri Jan 9 06:12:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7D11A8AC6 for ; Fri, 9 Jan 2015 06:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 95nyn8CtyssC for ; Fri, 9 Jan 2015 06:12:09 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB3E1A8968 for ; Fri, 9 Jan 2015 06:11:32 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id hs14so14651339lab.8 for ; Fri, 09 Jan 2015 06:11:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cE6IA0uOrXAhs+2b6UGXtzisMTOkiP+DqVRnFKNK5dg=; b=MWcF1zPAdE672l40NgLyFviNfaJ/FxiStzn2B/E3cwt7P2mSJQhTJwwNvsXZoXKdmg uIjsZopkHXO6eQGWBbRsKVWFFnaXKwYAZcyu1kOAa235YTEEmWfLDxP+gQOsqidupzQt oNBlBesLTtZVGmaJWhXbV53Z8gMWhNm63LOb5Xwj7ut6FhxUTsOLPtWqWC4Gj+u/wRJZ ubALGfDNVvmn8py2g0zi0KQwa9ZmbND6bKSL5TPwy6kXY72cGbWgjxRBunYAruTSyoHF bQrWgXi1qhXJp/Y1VOnKOnec0I7Mu371tn5r7nV4Ta+YGsxzHPERqm/qxZxAOHDWargu 1xMA== X-Gm-Message-State: ALoCoQlNfsxXazL8WEIG18tRlcVOMIE3D1wPAhJdEhc1/guD/eUxmguHfFhNCDHIjkfCMcsQ/+Lm MIME-Version: 1.0 X-Received: by 10.152.19.7 with SMTP id a7mr21532349lae.16.1420812690964; Fri, 09 Jan 2015 06:11:30 -0800 (PST) Received: by 10.25.84.145 with HTTP; Fri, 9 Jan 2015 06:11:30 -0800 (PST) In-Reply-To: <00d301d02bed$0f0406b0$2d0c1410$@org.cn> References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> Date: Fri, 9 Jan 2015 09:11:30 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=089e01494268bcd7b7050c38bbaa Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:12:14 -0000 --089e01494268bcd7b7050c38bbaa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang wrote: > After your detail analysis and the sentence =E2=80=9CFor either b/c, we w= ould need > to say that including both RAF and OAF/AAF for the same address family is > prohibited.=E2=80=9D, I think it may be better to keep only one attribute= to > fulfill the SSODA requirement? There is no requirement that SSODA functionality be realized with only one attribute, nor that the protocol be elegant, nor that it exhibits symmetry that is pleasing to the eye. There *is* a requirement that it be backwards-compatible though. Whether that means compatible with the spec or compatible with actual implementations is a matter of debate. Justin, if we can't find a single implementation that would barf, why would Chrome have to implement a complex fallback mechanism? Simon --089e01494268bcd7b7050c38bbaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <wangaijun@tsinghua.org= .cn> wrote:
After your deta= il analysis and the sentence =E2=80=9CFor either b/c, we would need to say = that including both RAF and OAF/AAF for the same address family is prohibit= ed.=E2=80=9D, I think it may be better to keep only one attribute to fulfil= l the SSODA requirement? =C2=A0

There is no requireme= nt that SSODA functionality be realized with only one attribute, nor that t= he protocol be elegant, nor that it exhibits symmetry that is pleasing to t= he eye.

There *is* a requirement that it be backwards-compatible though. Whether = that means compatible with the spec or compatible with actual implementatio= ns is a matter of debate.

Justin, if we can't find a single implementation th= at would barf, why would Chrome have to implement a complex fallback mechan= ism?

S= imon
--089e01494268bcd7b7050c38bbaa-- From nobody Fri Jan 9 06:36:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B550B1A89FC for ; Fri, 9 Jan 2015 06:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9I73uUEz6R4i for ; Fri, 9 Jan 2015 06:36:50 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCB11A89B5 for ; Fri, 9 Jan 2015 06:36:50 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B3077285A4 for ; Fri, 9 Jan 2015 14:36:49 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A04412859F for ; Fri, 9 Jan 2015 14:36:49 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 7FE61202F for ; Fri, 9 Jan 2015 14:36:49 +0000 (GMT) Message-ID: <54AFE781.5060804@akamai.com> Date: Fri, 09 Jan 2015 09:36:49 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:36:52 -0000 Sounds good. On 01/08/2015 03:05 PM, Simon Perreault wrote: > Justin, Brandon, TRAMsters, > > I started writing a long response but erased all of it in favour of this > happy, shorter one: > > Would anyone scream if the draft went through another revision focusing > on the problem statement before getting adopted? Work needs to be done > on the problem statement at one point or another, so it doesn't really > change anything from an end-goal perspective. > > Hoping we can get back to technical arguments soon... > Simon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Jan 9 08:29:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACEA1A6F2B for ; Fri, 9 Jan 2015 08:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nblO094BpW80 for ; Fri, 9 Jan 2015 08:28:51 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFAB1A6F22 for ; Fri, 9 Jan 2015 08:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3418; q=dns/txt; s=iport; t=1420820931; x=1422030531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=B9WQsrfSDZqhESG80IWKHp5dm9aKLCvDImngSwsEwm4=; b=ZuIqh367M33nWTOMdyMLNO4iJltHjLOvhFJ5iWhyiUaHHEElYfpGMwje 5JN2VfwBxP2TA4P6NWHtY6tT3C0ArCiXtZq0JRr4mPBRAhl4elA/Yw04e xh2lhTVxjXsZ/J6ypPijMeEKArgjnO+Q7LXy9tP09l7h9dt0sbBqWg/v9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAKoAsFStJV2S/2dsb2JhbABcgwZSWATDWYIbCoVxAoEVQwEBAQEBfYQMAQEBAwEBAQE3NAQHBQsCAQgOCh4QJwslAgQOBYgkCA3JeAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj0YzB4MWgRMFhDoCiXyJC4EOjSyDOiKDbm+BBSQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,731,1413244800"; d="scan'208";a="111824423" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 09 Jan 2015 16:28:49 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t09GSn4X006066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 16:28:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.3]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 10:28:48 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AQHQK5NX2llrTGH0okea8gkUzfSuD5y4YB2A Date: Fri, 9 Jan 2015 16:28:47 +0000 Message-ID: <1EA9BD83-A95A-427D-B007-6DADD43D998D@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.52] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 16:28:58 -0000 Thanks, Justin. We'll collect Brandon's feedback on the draft too and the = authors will deliberate on text edits and produce a new version for your re= view. -G > On Jan 8, 2015, at 5:34 PM, Justin Uberti wrote: >=20 > At IETF 91, I promised to send feedback on this document, so here goes. >=20 > Generally, I think many of the issues mentioned in this document are impo= rtant, but the recommendations are confusing and possibly contradictory; a = developer with little knowledge of TURN will have a hard time figuring out = exactly what to do. Furthermore, many of the properties discussed in this d= ocument are dynamic, and should be handled by the ICE process, rather than = in TURN server selection (for example, the notion of RTT as it relates to u= ser experience). >=20 > Therefore, I think this document should take a stronger stance and put fo= rth explicit best practices for selection (as opposed to "things to conside= r"), for non-dynamic properties, and leave the decisions on dynamic propert= ies to be resolved by ICE.=20 >=20 > For example, I think we should omit the text in Section 3 about what to d= o with non-working TURN servers, and measuring RTT. Same for Section 3.3, w= hich also discusses RTT, and Section 3.4, which talks about multiple interf= aces. This can all be handled by ICE. >=20 > In addition, the sections on local config and location privacy are unnece= ssary when RETURN is used. When RETURN is used, the application can always = use the app TURN server for location privacy, and the relationship between = local TURN server and app TURN server is fully spelled out, so there is not= hing for the application to decide on. >=20 > This leaves only the Security, Authentication, and Mobility sections.=20 >=20 > For security, I think we can give some clear guidance on what application= s should do. For security, I think the guidance should be to use only DTLS = + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS ar= en't available. If privacy is paramount, UDP/TCP fallback may be contraindi= cated, but at this point in time, DTLS deployment isn't widespread enough t= o truly recommend this. >=20 > This relates to the Authentication section - but I think any failures to = authenticate the server cert should cause the TURN allocation to fail. This= is just like any other misconfiguration on the TURN server - there's no re= ason we should even allow use of TURN servers whose cert chains don't valid= ate. So, this section could probably be removed. >=20 > Lastly, the Mobility section says that if "all other parameters [are] equ= al", a TURN server with mobility should be used. Clearly, all other paramet= ers will not be equal (e.g. RTT), and even if they were, the client has no = way to know if a server is mobility-capable a priori. So I think this recom= mendation ought to be removed, or perhaps turned into some sort of recommen= dation for TURN server developers (e.g. TURN servers SHOULD support TLS/DTL= S, SHOULD support mobility, SHOULD support redirect), probably in a separat= e doc. >=20 > These recommendations should reduce the size of this document and provide= much clearer advice to app developers. > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Jan 9 09:12:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A751A8728 for ; Fri, 9 Jan 2015 09:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QlrYHvIVeBFZ for ; Fri, 9 Jan 2015 09:12:44 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 487A21A7D82 for ; Fri, 9 Jan 2015 09:12:44 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 504782859D for ; Fri, 9 Jan 2015 17:12:43 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3B57A28598 for ; Fri, 9 Jan 2015 17:12:43 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 3558B80054 for ; Fri, 9 Jan 2015 17:12:43 +0000 (GMT) Message-ID: <54B00C0B.2080703@akamai.com> Date: Fri, 09 Jan 2015 12:12:43 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> In-Reply-To: <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 17:12:47 -0000 By relay address, I mean the XOR-RELAYED-ADDRESS returned in the allocation request. This clearly identifies the true source and destination for the data in the packet as well as the two relay servers involved. If both relayed addresses are on the same server, it will of course know that and be able to optimize as Simon indicated in an earlier e-mail. --Brandon On 01/08/2015 09:40 PM, Aijun Wang wrote: > > [Aijun]: There are two relay address, one is the TURN server well-known > address, another is the relay address that allocated to each client. Which > one should be used then? On the other hand, when client want to send traffic > to other peer, it does not know whether the other part is under the same > TURN server or not, how do it select this information? > > > [Aijun]: as the definition in > http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, the > XOR-PEER-ADDRESS is the address seen from the TURN server, so it can't be > used to find the relay address of the remote peer, and then can't be used to > direct traffic to downstream relay. > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Jan 9 09:34:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0011A87BB for ; Fri, 9 Jan 2015 09:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 1GmwB_B6BVfQ for ; Fri, 9 Jan 2015 09:34:35 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616E31A6FCB for ; Fri, 9 Jan 2015 09:34:35 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so3572216vcb.2 for ; Fri, 09 Jan 2015 09:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7kcLvYxwGRhwhY7c9QrcJ23zM0cTdlDgnAJ8vfuDTKs=; b=oMJzH1JRExNnaOGMMQlZ+9K69/TnB3KLXmnkynDeu1J8BT//m6grwcapNpcQiWtDp7 BtA1JdSx7dgPWSh1QL3lj1hRR8nDRpdJjbSvXZGsLHOVuXw2mmRC4xbfj2l3VeO6PVSK CLXCJQlVKM7Aw5WxcSD76YrjjjxjNhbGrqIfdp8qAkOXUv2k24voA37dM2ZzUOuVHVo3 MDcstx9MD3ik1JlVJCLT2GEdYkyNvuePtjk9jMZoSM3tmlLGSOV+oNPA+qOx2usvp1tC 20v8TNCaCiTVZ+f0ItLmUhstss80Ku+0y6GUe8IOo6QpY5S65D30dkKJtRJPM7yB4CdY 2YmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7kcLvYxwGRhwhY7c9QrcJ23zM0cTdlDgnAJ8vfuDTKs=; b=PJFsyRgJ1d0szAadqxsgEa6tvE2UJOC7VpdarUejKzNMG5Byzd4754+YAI8JOEoHv1 wbKmvDaMKsyjCb9E2Wvp14ohXjf8kj9FLai5jKXymcqn7UhrgJXSa7oq7OQ2ZjZZH5TJ LoZubkwF1l0awyz/XgV+qb8dVBKIc7dLhG7E4FTDmuza+mauj9DrM7luQrtG2kgddYeN kWlJBP0mSN7BFZbI/AHV2l9CxC3W6EVxw4tU4RlnkUA6XX1uJ5z159yblTEpbUXSPNK1 uIedWU71dG1ipAfzHreusIfupqKgKi0+ee1Pen3vxJJIzCpx5jQ5yvE9yq+CSuf9/2Wm 4VvQ== X-Gm-Message-State: ALoCoQlysQ7uFDx+Je3L66GxBZEVaWsPCoM4T9EkZ0ZJhG9U5ezysDnm2nrGjoT0VcqqCTGL58Oy X-Received: by 10.52.82.166 with SMTP id j6mr8587217vdy.21.1420824874373; Fri, 09 Jan 2015 09:34:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Fri, 9 Jan 2015 09:34:14 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> From: Justin Uberti Date: Fri, 9 Jan 2015 09:34:14 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1136ac4cecf983050c3b91af Archived-At: Cc: Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 17:34:37 -0000 --001a1136ac4cecf983050c3b91af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I reviewed the code for restund, reTurn, and rfc5766-turn-server and they all appear to handle RAF (and multiple RAF) OK. The problem, as I see it, is that there may be other TURN servers, perhaps non-open-source ones, that work fine today with Chrome, but will start returning errors when we include RAF or multiple RAF, and so making this change may break some small number of apps (who will then blame Chrome). We just don't know what is out there. On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault wrote= : > > On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang > wrote: > >> After your detail analysis and the sentence =E2=80=9CFor either b/c, we = would >> need to say that including both RAF and OAF/AAF for the same address fam= ily >> is prohibited.=E2=80=9D, I think it may be better to keep only one attri= bute to >> fulfill the SSODA requirement? > > > There is no requirement that SSODA functionality be realized with only on= e > attribute, nor that the protocol be elegant, nor that it exhibits symmetr= y > that is pleasing to the eye. > > There *is* a requirement that it be backwards-compatible though. Whether > that means compatible with the spec or compatible with actual > implementations is a matter of debate. > > Justin, if we can't find a single implementation that would barf, why > would Chrome have to implement a complex fallback mechanism? > > Simon > --001a1136ac4cecf983050c3b91af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I reviewed the code for restund, reTurn, and rfc5766-turn-= server and they all appear to handle RAF (and multiple RAF) OK.

The problem, as I see it, is that there may be other TURN servers, = perhaps non-open-source ones, that work fine today with Chrome, but will st= art returning errors when we include RAF or multiple RAF, and so making thi= s change may break some small number of apps (who will then blame Chrome). = We just don't know what is out there.



On Fri, J= an 9, 2015 at 6:11 AM, Simon Perreault <sperreault@jive.com> wrote:

On Fri, Jan 9,= 2015 at 4:17 AM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
After your detail analysis an= d the sentence =E2=80=9CFor either b/c, we would need to say that including= both RAF and OAF/AAF for the same address family is prohibited.=E2=80=9D, = I think it may be better to keep only one attribute to fulfill the SSODA re= quirement? =C2=A0

There is no requirement that= SSODA functionality be realized with only one attribute, nor that the prot= ocol be elegant, nor that it exhibits symmetry that is pleasing to the eye.=

There= *is* a requirement that it be backwards-compatible though. Whether that me= ans compatible with the spec or compatible with actual implementations is a= matter of debate.

Justin, if we can't find a single implementation that woul= d barf, why would Chrome have to implement a complex fallback mechanism?

Simon

--001a1136ac4cecf983050c3b91af-- From nobody Fri Jan 9 10:01:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF53F1A0075 for ; Fri, 9 Jan 2015 10:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 iqxfM06tAI8z for ; Fri, 9 Jan 2015 10:01:09 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E4A1A009E for ; Fri, 9 Jan 2015 10:01:09 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so3959017wiw.3 for ; Fri, 09 Jan 2015 10:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LKyAclnMlEspJiKfsT7c/er5TTIfYF+LpnAQXzQjv+Y=; b=vbZJOmgVfn/YJg6Lqi74FBLBCXcaTYWa3xKp7W9tF7S4KNS73tYEkp9v0VzuydLve/ SfsbWhMm4KwKjgObL+XBNd152tVVi1NxcHZtPOun10wKZC/3iw2pygIvRN7HwfEBkSs9 h7ol2w8UvVfi7NAzXw1IwWmPOhuQlD4e8M4gxJPZz3cKD/pI9JwS3bFeWxYUbm9Lph7/ 6ZvtuXzQ0y+l+5s9VtlvzF4NN6iWJaTy2NEfZ1SzSMr2nD8MYWRSMbDB02UMUjZDX5O4 CARu5Xvq07MSvsjWgZfKi/tXFQc2S2DzmcVeLFCjHHr9tnB/mV58WKJzLI6agyIcPr69 cy4g== MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr33460459wjr.48.1420826468279; Fri, 09 Jan 2015 10:01:08 -0800 (PST) Received: by 10.194.238.132 with HTTP; Fri, 9 Jan 2015 10:01:08 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> Date: Fri, 9 Jan 2015 10:01:08 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b86c898edede8050c3bf0ec Archived-At: Cc: Simon Perreault , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 18:01:12 -0000 --047d7b86c898edede8050c3bf0ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I checked the code of rfc5766-turn-server again, and I found that it will NOT handle the multiple-RAF case. It will return 400 error with the message "Only one address family attribute can be used in a request". At least, it's been that way in the 2014 releases. I did not check the older releases= . Sorry that I provided a wrong information about the implementation, before. I can fix that code but still there are people out there who will be using the "wrong" versions. So, if we do have to be absolutely backward compatible then we have to use a different option... Oleg On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti wrote: > I reviewed the code for restund, reTurn, and rfc5766-turn-server and they > all appear to handle RAF (and multiple RAF) OK. > > The problem, as I see it, is that there may be other TURN servers, perhap= s > non-open-source ones, that work fine today with Chrome, but will start > returning errors when we include RAF or multiple RAF, and so making this > change may break some small number of apps (who will then blame Chrome). = We > just don't know what is out there. > > > > On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault > wrote: > >> >> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >> wrote: >> >>> After your detail analysis and the sentence =E2=80=9CFor either b/c, we= would >>> need to say that including both RAF and OAF/AAF for the same address fa= mily >>> is prohibited.=E2=80=9D, I think it may be better to keep only one attr= ibute to >>> fulfill the SSODA requirement? >> >> >> There is no requirement that SSODA functionality be realized with only >> one attribute, nor that the protocol be elegant, nor that it exhibits >> symmetry that is pleasing to the eye. >> >> There *is* a requirement that it be backwards-compatible though. Whether >> that means compatible with the spec or compatible with actual >> implementations is a matter of debate. >> >> Justin, if we can't find a single implementation that would barf, why >> would Chrome have to implement a complex fallback mechanism? >> >> Simon >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b86c898edede8050c3bf0ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I checked the code of rfc5766-turn-server again, and = I found that it will NOT handle the multiple-RAF case. It will return 400 e= rror with the message "Only one address family attribute can be used i= n a request". At least, it's been that way in the 2014 releases. I= did not check the older releases.

Sorry that I provided = a wrong information about the implementation, before.

I c= an fix that code but still there are people out there who will be using the= "wrong" versions.

So, if we do have to be abso= lutely backward compatible then we have to use a different option...
Oleg
=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <j= uberti@google.com> wrote:
<= div dir=3D"ltr">I reviewed the code for restund, reTurn, and rfc5766-turn-s= erver and they all appear to handle RAF (and multiple RAF) OK.

The problem, as I see it, is that there may be other TURN servers, p= erhaps non-open-source ones, that work fine today with Chrome, but will sta= rt returning errors when we include RAF or multiple RAF, and so making this= change may break some small number of apps (who will then blame Chrome). W= e just don't know what is out there.


<= br>
On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreau= lt <sperreault@jive.com> wrote:

On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang = <wangaiju= n@tsinghua.org.cn> wrote:
A= fter your detail analysis and the sentence =E2=80=9CFor either b/c, we woul= d need to say that including both RAF and OAF/AAF for the same address fami= ly is prohibited.=E2=80=9D, I think it may be better to keep only one attri= bute to fulfill the SSODA requirement? =C2=A0

= There is no requirement that SSODA functionality be realized with only one = attribute, nor that the protocol be elegant, nor that it exhibits symmetry = that is pleasing to the eye.

There *is* a requirement that it be backwards-compat= ible though. Whether that means compatible with the spec or compatible with= actual implementations is a matter of debate.

Justin, if we can't find a sin= gle implementation that would barf, why would Chrome have to implement a co= mplex fallback mechanism?

Simon
=


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b86c898edede8050c3bf0ec-- From nobody Fri Jan 9 10:53:46 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A761A8AE0 for ; Fri, 9 Jan 2015 10:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 fAiW_9Cxordq for ; Fri, 9 Jan 2015 10:53:44 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5141A8ADE for ; Fri, 9 Jan 2015 10:53:43 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id q58so9520286wes.4 for ; Fri, 09 Jan 2015 10:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MnJc7pT3Kr8pGzFnw0TPI0qAYDeGnPsFfGtx0Z9KBOg=; b=z0ygP4w93iVRVI00F1XFov1NRFFcRZOEDliuGypLgikIu6NB0/7mbcZyigAzyx8X4D OAGhhDzwYdYEFp4tKnGBKWIDgdWC3QMZNVaf6ZXCtRQt/hmBMwzodFDvBvu7wydnv9DW //7mRd62yuY3IRchaUrDmO8f2nugqS32wOQNhrBXGrqaqNBo1D1evJ0T+LgVvfswSTqX aIQveQVbTTOQG3lRMqLHMuG5SlfEGjiEJJMcsnK89MfVlF+07Ps+A6NlxPGsFMws/xl2 fYrMFVCVBxuezGv6mpiNJqXNmjBYXWcIkjd0zhgS+qWMdvwHwKKFcUM2u0qoxVYLPmkt /Vmw== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr7820871wic.21.1420829622245; Fri, 09 Jan 2015 10:53:42 -0800 (PST) Received: by 10.194.238.132 with HTTP; Fri, 9 Jan 2015 10:53:42 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> Date: Fri, 9 Jan 2015 10:53:42 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=001a1134cd58eba37e050c3cac10 Archived-At: Cc: Simon Perreault , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 18:53:46 -0000 --001a1134cd58eba37e050c3cac10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I double-checked that with a real test. I ran the coTurn test client (that implements experimental SSODA draft with two RAF attributes) against rfc5766-turn-server and the server yielded error 400 with the message "Only one address family attribute can be used in a request" :( As I said, I can eliminate that problem in the subsequent rfc5766-turn-server maintenance releases, but still... I am sorry that I did not discover that previously and that I advocated an incompatible implementation option. So, if the WG insists on a backward-compatible protocol in all senses, then we have to choose another option. Thanks Oleg On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko wrote: > I checked the code of rfc5766-turn-server again, and I found that it will > NOT handle the multiple-RAF case. It will return 400 error with the messa= ge > "Only one address family attribute can be used in a request". At least, > it's been that way in the 2014 releases. I did not check the older releas= es. > > Sorry that I provided a wrong information about the implementation, befor= e. > > I can fix that code but still there are people out there who will be usin= g > the "wrong" versions. > > So, if we do have to be absolutely backward compatible then we have to us= e > a different option... > > Oleg > > > On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti wrote: > >> I reviewed the code for restund, reTurn, and rfc5766-turn-server and the= y >> all appear to handle RAF (and multiple RAF) OK. >> >> The problem, as I see it, is that there may be other TURN servers, >> perhaps non-open-source ones, that work fine today with Chrome, but will >> start returning errors when we include RAF or multiple RAF, and so makin= g >> this change may break some small number of apps (who will then blame >> Chrome). We just don't know what is out there. >> >> >> >> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >> wrote: >> >>> >>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >>> wrote: >>> >>>> After your detail analysis and the sentence =E2=80=9CFor either b/c, w= e would >>>> need to say that including both RAF and OAF/AAF for the same address f= amily >>>> is prohibited.=E2=80=9D, I think it may be better to keep only one att= ribute to >>>> fulfill the SSODA requirement? >>> >>> >>> There is no requirement that SSODA functionality be realized with only >>> one attribute, nor that the protocol be elegant, nor that it exhibits >>> symmetry that is pleasing to the eye. >>> >>> There *is* a requirement that it be backwards-compatible though. Whethe= r >>> that means compatible with the spec or compatible with actual >>> implementations is a matter of debate. >>> >>> Justin, if we can't find a single implementation that would barf, why >>> would Chrome have to implement a complex fallback mechanism? >>> >>> Simon >>> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --001a1134cd58eba37e050c3cac10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I double-checked that with a real test= . I ran the coTurn test client (that implements experimental SSODA draft wi= th two RAF attributes) against rfc5766-turn-server and the server yielded e= rror 400 with the message "Only one address family attribute can be us= ed in a request"

:(

As I said, I can eliminate tha= t problem in the subsequent rfc5766-turn-server maintenance releases, but s= till...

I am sorry that I did not discover that previously and= that I advocated an incompatible implementation option.

So, i= f the WG insists on a backward-compatible protocol in all senses, then we h= ave to choose another option.

Thanks
Oleg

=


On Fri, Jan 9, 2015 at 10:= 01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
I checked the code of rfc= 5766-turn-server again, and I found that it will NOT handle the multiple-RA= F case. It will return 400 error with the message "Only one address fa= mily attribute can be used in a request". At least, it's been that= way in the 2014 releases. I did not check the older releases.

Sorry that I provided a wrong information about the implementation, b= efore.

I can fix that code but still there are people out= there who will be using the "wrong" versions.

= So, if we do have to be absolutely backward compatible then we have to use = a different option...
Ol= eg
=C2=A0

On Fri, Jan 9, 2015 at 9:34= AM, Justin Uberti <juberti@google.com> wrote:
I= reviewed the code for restund, reTurn, and rfc5766-turn-server and they al= l appear to handle RAF (and multiple RAF) OK.

The proble= m, as I see it, is that there may be other TURN servers, perhaps non-open-s= ource ones, that work fine today with Chrome, but will start returning erro= rs when we include RAF or multiple RAF, and so making this change may break= some small number of apps (who will then blame Chrome). We just don't = know what is out there.


=

On Fri, Jan 9, 20= 15 at 6:11 AM, Simon Perreault <sperreault@jive.com> wrote= :

On Fri, Jan 9, 2015 at 4:17 AM, A= ijun Wang <wangaijun@tsinghua.org.cn> wrote:
After your detail analysis and the sentence =E2= =80=9CFor either b/c, we would need to say that including both RAF and OAF/= AAF for the same address family is prohibited.=E2=80=9D, I think it may be = better to keep only one attribute to fulfill the SSODA requirement? =C2=A0<= /blockquote>

There is no requirement that SSODA functionali= ty be realized with only one attribute, nor that the protocol be elegant, n= or that it exhibits symmetry that is pleasing to the eye.

There *is* a requirem= ent that it be backwards-compatible though. Whether that means compatible w= ith the spec or compatible with actual implementations is a matter of debat= e.

Jus= tin, if we can't find a single implementation that would barf, why woul= d Chrome have to implement a complex fallback mechanism?

Simon


______________________________= _________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



--001a1134cd58eba37e050c3cac10-- From nobody Fri Jan 9 12:49:02 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753771A9066 for ; Fri, 9 Jan 2015 12:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 sOcEfYCiucDo for ; Fri, 9 Jan 2015 12:48:54 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017131A9061 for ; Fri, 9 Jan 2015 12:48:53 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hy4so3901123vcb.1 for ; Fri, 09 Jan 2015 12:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p9cJwkMSNm2HwJeDOz+0okv/DZv0g/d9yuFn4oAvZH8=; b=W1g3CZZNe5tm2zCLoBIgfaYHYyKRs6cy7OMyQGeOjT5BaZl3tuRRbAIFsFS8TNTJow OBSNLadhyPW4eyd+cuncxW4vksiAieWYIlGQP4EtGTmabNP8FJlHkaboWfJGXgo20Wwd cq7VJepEL2YIJLc9Md28YrMqrdUJUAc8ELH4CPgNvis8ki25kXm9tgbWH2CXV0lCzkBX ilNPEFoGVDMMBuK5s1Pij7F0vzZju/yFeI/f0sHLbMB0dC6ZDMSq1dPto6oMn9YJHvOp BkSSkAoa3Ri9/Ixes2YMJ9bJMeXz4zt/UiMZqcvoEWWebYx9I2/D9bTbcDM17z9yFrXx ySXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p9cJwkMSNm2HwJeDOz+0okv/DZv0g/d9yuFn4oAvZH8=; b=Hk0Y5wDr/4vtQZfe3pApvJ/WAjHUSoSVe3KGoy2h413UiMwieKI7bfQNznejR2Fzm3 vpBezPAeFPkTzxdvsUMtfhUXiEbjOey1ZjnMCeDeNLmzltyTLBnffpAyYt5iV+Q2J2rX R1X6qXMdFdwuhhEm47dzOB2svYBwFZ/B5yUY0wat17rDYItCnsumk0uAYf2ZlZYA71NA rffzT26uC8rP823VCVafWAYU3v6g5Bt1oCAJQkBmyGhsY1dupmsvPjhSfVVtVvyyaM0S N0XUSkhR8HVfLMJJP/cSfitKpmlHXZvH7CPviVOpQtIQ0I1iB/mTDpodtvUst0tB+dOZ HX/g== X-Gm-Message-State: ALoCoQlbB5k3J7UlDWnNTGO2YRFeE0MZWfV1Y1VlGSgmmDSKRzsEa7Lz9px2NoRnaLsmPa+hXQRW X-Received: by 10.52.190.40 with SMTP id gn8mr1927780vdc.56.1420836533049; Fri, 09 Jan 2015 12:48:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Fri, 9 Jan 2015 12:48:31 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> From: Justin Uberti Date: Fri, 9 Jan 2015 12:48:31 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a1133f782d6391c050c3e480a Archived-At: Cc: Simon Perreault , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 20:48:57 -0000 --001a1133f782d6391c050c3e480a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, so we have clear evidence that some deployed servers will fail (deterministically, fortunately) on the current SSODA proposal. So we're back to which backwards-compatible option we want to pursue. I suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY. Separately, we need to decide whether we want to pursue issue #2 that I identified previously, i.e., allowing specific error codes to be returned for each address family. On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko wrote: > I double-checked that with a real test. I ran the coTurn test client (tha= t > implements experimental SSODA draft with two RAF attributes) against > rfc5766-turn-server and the server yielded error 400 with the message "On= ly > one address family attribute can be used in a request" > > :( > > As I said, I can eliminate that problem in the subsequent > rfc5766-turn-server maintenance releases, but still... > > I am sorry that I did not discover that previously and that I advocated a= n > incompatible implementation option. > > So, if the WG insists on a backward-compatible protocol in all senses, > then we have to choose another option. > > Thanks > Oleg > > > > On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko > wrote: > >> I checked the code of rfc5766-turn-server again, and I found that it wil= l >> NOT handle the multiple-RAF case. It will return 400 error with the mess= age >> "Only one address family attribute can be used in a request". At least, >> it's been that way in the 2014 releases. I did not check the older relea= ses. >> >> Sorry that I provided a wrong information about the implementation, >> before. >> >> I can fix that code but still there are people out there who will be >> using the "wrong" versions. >> >> So, if we do have to be absolutely backward compatible then we have to >> use a different option... >> >> Oleg >> >> >> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti wrote= : >> >>> I reviewed the code for restund, reTurn, and rfc5766-turn-server and >>> they all appear to handle RAF (and multiple RAF) OK. >>> >>> The problem, as I see it, is that there may be other TURN servers, >>> perhaps non-open-source ones, that work fine today with Chrome, but wil= l >>> start returning errors when we include RAF or multiple RAF, and so maki= ng >>> this change may break some small number of apps (who will then blame >>> Chrome). We just don't know what is out there. >>> >>> >>> >>> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >>> wrote: >>> >>>> >>>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >>>> wrote: >>>> >>>>> After your detail analysis and the sentence =E2=80=9CFor either b/c, = we would >>>>> need to say that including both RAF and OAF/AAF for the same address = family >>>>> is prohibited.=E2=80=9D, I think it may be better to keep only one at= tribute to >>>>> fulfill the SSODA requirement? >>>> >>>> >>>> There is no requirement that SSODA functionality be realized with only >>>> one attribute, nor that the protocol be elegant, nor that it exhibits >>>> symmetry that is pleasing to the eye. >>>> >>>> There *is* a requirement that it be backwards-compatible though. >>>> Whether that means compatible with the spec or compatible with actual >>>> implementations is a matter of debate. >>>> >>>> Justin, if we can't find a single implementation that would barf, why >>>> would Chrome have to implement a complex fallback mechanism? >>>> >>>> Simon >>>> >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >> > --001a1133f782d6391c050c3e480a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, so we have clear evidence that some deployed servers w= ill fail (deterministically, fortunately) on the current SSODA proposal.
So we're back to which backwards-compatible option we = want to pursue. I suggest c), which is the optional-comprehension ADDITIONA= L-ADDRESS-FAMILY.

Separately, we need to decide wh= ether we want to pursue issue #2 that I identified previously, i.e., allowi= ng specific error codes to be returned for each address family.

On Fri, Jan 9, 2015 at = 10:53 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
=
I doubl= e-checked that with a real test. I ran the coTurn test client (that impleme= nts experimental SSODA draft with two RAF attributes) against rfc5766-turn-= server and the server yielded error 400 with the message "Only one add= ress family attribute can be used in a request"

:(

As I said, I can eliminate that problem in the subsequent rfc5766-turn-ser= ver maintenance releases, but still...

I am sorry that I did n= ot discover that previously and that I advocated an incompatible implementa= tion option.

So, if the WG insists on a backward-compatible pr= otocol in all senses, then we have to choose another option.

T= hanks
Oleg



On Fri, Jan 9, 2= 015 at 10:01 AM, Oleg Moskalenko <mom040267@gmail.com> wro= te:
I checked the c= ode of rfc5766-turn-server again, and I found that it will NOT handle the m= ultiple-RAF case. It will return 400 error with the message "Only one = address family attribute can be used in a request". At least, it's= been that way in the 2014 releases. I did not check the older releases.
Sorry that I provided a wrong information about the impleme= ntation, before.

I can fix that code but still there are = people out there who will be using the "wrong" versions.

<= /div>
So, if we do have to be absolutely backward compatible then we ha= ve to use a different option...

Oleg
=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti = <juberti@google.= com> wrote:
I reviewed the code for restund, reTurn, and rfc576= 6-turn-server and they all appear to handle RAF (and multiple RAF) OK.
=
The problem, as I see it, is that there may be other TURN se= rvers, perhaps non-open-source ones, that work fine today with Chrome, but = will start returning errors when we include RAF or multiple RAF, and so mak= ing this change may break some small number of apps (who will then blame Ch= rome). We just don't know what is out there.

<= br>

On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault &= lt;sperreault@jive= .com> wrote:

On Fri, = Jan 9, 2015 at 4:17 AM, Aijun Wang <wangaijun@tsinghua.org.cn&= gt; wrote:
After your detail analy= sis and the sentence =E2=80=9CFor either b/c, we would need to say that inc= luding both RAF and OAF/AAF for the same address family is prohibited.=E2= =80=9D, I think it may be better to keep only one attribute to fulfill the = SSODA requirement? =C2=A0

There is no requirem= ent that SSODA functionality be realized with only one attribute, nor that = the protocol be elegant, nor that it exhibits symmetry that is pleasing to = the eye.

There *is* a requirement that it be backwards-compatible though. Whether= that means compatible with the spec or compatible with actual implementati= ons is a matter of debate.

Justin, if we can't find a single implementation t= hat would barf, why would Chrome have to implement a complex fallback mecha= nism?

Simon


_________________________________________= ______
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram




--001a1133f782d6391c050c3e480a-- From nobody Fri Jan 9 17:00:07 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB84F1A19F2 for ; Fri, 9 Jan 2015 17:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 CiR2EgI0VUQa for ; Fri, 9 Jan 2015 17:00:03 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466811A044D for ; Fri, 9 Jan 2015 17:00:02 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id q58so10683712wes.4 for ; Fri, 09 Jan 2015 17:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q0gBh4+zjImRbnqTm/+AxQMWddJNnn2RQzXDWVvklCw=; b=vto7pLouNTNNfGrIOeSD/yiw+HJC8iA95bZaOZii9Ua0YHaPtKg+wGLjkB2t9RQ8/6 1xjPhpE2qhKg/hlNns7QKRU6RZL1I68CjZuA8muI9udLVpYkenedeKVei+Pt+oKNKRgP K+hB1ajyjzkwesutWj0LVHXPAv7rOf3tL2UvzSRBnkSaqyq0VQRW0KaGAwqaT/AO75Tl sOqk9kkAYkw05+0tro5nLVRKXorx8Zau0lKSTKj3xC6f3eRbNLOPuGMJCbaxHiwXdF3h fM0BNIl68T3RsGWtXUeA1x2qcjqFvOyeFa4ciDl+giCelTfIenCPshkORWwpMuiBnLtC rOQg== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr9846037wic.57.1420851600851; Fri, 09 Jan 2015 17:00:00 -0800 (PST) Received: by 10.216.57.131 with HTTP; Fri, 9 Jan 2015 17:00:00 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> Date: Fri, 9 Jan 2015 17:00:00 -0800 Message-ID: From: Ca By To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c2ac4ef28af5050c41ca19 Archived-At: Cc: Simon Perreault , Oleg Moskalenko , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 01:00:06 -0000 --001a11c2ac4ef28af5050c41ca19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, January 9, 2015, Justin Uberti wrote: > OK, so we have clear evidence that some deployed servers will fail > (deterministically, fortunately) on the current SSODA proposal. > > So we're back to which backwards-compatible option we want to pursue. I > suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY= . > > It was not clear to me earlier in the thread Does option c allow for ipv6-only operation ? CB > Separately, we need to decide whether we want to pursue issue #2 that I > identified previously, i.e., allowing specific error codes to be returned > for each address family. > > On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko > wrote: > >> I double-checked that with a real test. I ran the coTurn test client >> (that implements experimental SSODA draft with two RAF attributes) again= st >> rfc5766-turn-server and the server yielded error 400 with the message "O= nly >> one address family attribute can be used in a request" >> >> :( >> >> As I said, I can eliminate that problem in the subsequent >> rfc5766-turn-server maintenance releases, but still... >> >> I am sorry that I did not discover that previously and that I advocated >> an incompatible implementation option. >> >> So, if the WG insists on a backward-compatible protocol in all senses, >> then we have to choose another option. >> >> Thanks >> Oleg >> >> >> >> On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko > > wrote: >> >>> I checked the code of rfc5766-turn-server again, and I found that it >>> will NOT handle the multiple-RAF case. It will return 400 error with th= e >>> message "Only one address family attribute can be used in a request". A= t >>> least, it's been that way in the 2014 releases. I did not check the old= er >>> releases. >>> >>> Sorry that I provided a wrong information about the implementation, >>> before. >>> >>> I can fix that code but still there are people out there who will be >>> using the "wrong" versions. >>> >>> So, if we do have to be absolutely backward compatible then we have to >>> use a different option... >>> >>> Oleg >>> >>> >>> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti >> > wrote: >>> >>>> I reviewed the code for restund, reTurn, and rfc5766-turn-server and >>>> they all appear to handle RAF (and multiple RAF) OK. >>>> >>>> The problem, as I see it, is that there may be other TURN servers, >>>> perhaps non-open-source ones, that work fine today with Chrome, but wi= ll >>>> start returning errors when we include RAF or multiple RAF, and so mak= ing >>>> this change may break some small number of apps (who will then blame >>>> Chrome). We just don't know what is out there. >>>> >>>> >>>> >>>> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >>> > wrote: >>>> >>>>> >>>>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >>>> > wrote: >>>>> >>>>>> After your detail analysis and the sentence =E2=80=9CFor either b/c,= we would >>>>>> need to say that including both RAF and OAF/AAF for the same address= family >>>>>> is prohibited.=E2=80=9D, I think it may be better to keep only one a= ttribute to >>>>>> fulfill the SSODA requirement? >>>>> >>>>> >>>>> There is no requirement that SSODA functionality be realized with onl= y >>>>> one attribute, nor that the protocol be elegant, nor that it exhibits >>>>> symmetry that is pleasing to the eye. >>>>> >>>>> There *is* a requirement that it be backwards-compatible though. >>>>> Whether that means compatible with the spec or compatible with actual >>>>> implementations is a matter of debate. >>>>> >>>>> Justin, if we can't find a single implementation that would barf, why >>>>> would Chrome have to implement a complex fallback mechanism? >>>>> >>>>> Simon >>>>> >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>> >> > --001a11c2ac4ef28af5050c41ca19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Friday, January 9, 2015, Justin Uberti <juberti@google.com> wrote:
OK, so we have clear evidence that some deployed= servers will fail (deterministically, fortunately) on the current SSODA pr= oposal.

So we're back to which backwards-compatible = option we want to pursue. I suggest c), which is the optional-comprehension= ADDITIONAL-ADDRESS-FAMILY.

It was not clear to me earlier in the thread=C2=A0
Does option c allow for ipv6-only operation ?

CB

=C2=A0
Separately, we need to decide whether we want to= pursue issue #2 that I identified previously, i.e., allowing specific erro= r codes to be returned for each address family.

On Fri, Jan 9, 2015 at 10:53 AM, Oleg M= oskalenko <mom040267@gmail.com<= /a>> wrote:
I double-checked that with a real test. I ran the coTurn = test client (that implements experimental SSODA draft with two RAF attribut= es) against rfc5766-turn-server and the server yielded error 400 with the m= essage "Only one address family attribute can be used in a request&quo= t;

:(

As I said, I can eliminate that problem in the su= bsequent rfc5766-turn-server maintenance releases, but still...

I am sorry that I did not discover that previously and that I advocated a= n incompatible implementation option.

So, if the WG insists on= a backward-compatible protocol in all senses, then we have to choose anoth= er option.

Thanks
Oleg


On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
I checked the code of rf= c5766-turn-server again, and I found that it will NOT handle the multiple-R= AF case. It will return 400 error with the message "Only one address f= amily attribute can be used in a request". At least, it's been tha= t way in the 2014 releases. I did not check the older releases.

Sorry that I provided a wrong information about the implementation, = before.

I can fix that code but still there are people ou= t there who will be using the "wrong" versions.

So, if we do have to be absolutely backward compatible then we have to use= a different option...

<= /div>
Oleg
=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <juberti@google.com> wrote:
I reviewed the code= for restund, reTurn, and rfc5766-turn-server and they all appear to handle= RAF (and multiple RAF) OK.

The problem, as I see it, is= that there may be other TURN servers, perhaps non-open-source ones, that w= ork fine today with Chrome, but will start returning errors when we include= RAF or multiple RAF, and so making this change may break some small number= of apps (who will then blame Chrome). We just don't know what is out t= here.



On Fri, Jan 9, 2015 at 6:11 AM, Sim= on Perreault <sperreault@jive.c= om> wrote:

On Fri, Ja= n 9, 2015 at 4:17 AM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
After your detail analysis and the sentence =E2=80=9CFor ei= ther b/c, we would need to say that including both RAF and OAF/AAF for the = same address family is prohibited.=E2=80=9D, I think it may be better to ke= ep only one attribute to fulfill the SSODA requirement? =C2=A0
=

There is no requirement that SSODA functionality be realiz= ed with only one attribute, nor that the protocol be elegant, nor that it e= xhibits symmetry that is pleasing to the eye.

There *is* a requirement that it be= backwards-compatible though. Whether that means compatible with the spec o= r compatible with actual implementations is a matter of debate.

Justin, if we can= 't find a single implementation that would barf, why would Chrome have = to implement a complex fallback mechanism?

Simon


_________________________________________= ______
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram




--001a11c2ac4ef28af5050c41ca19-- From nobody Fri Jan 9 17:15:25 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804F71A1B64 for ; Fri, 9 Jan 2015 17:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 y-NUpqGmYS7c for ; Fri, 9 Jan 2015 17:15:20 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E7D1A1B5A for ; Fri, 9 Jan 2015 17:15:20 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id hy10so4198933vcb.6 for ; Fri, 09 Jan 2015 17:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FOjasEQwS3ttqu5HZYDgpIulkQ+OB8ttrimF3CTvUdQ=; b=n33aFB8sZEfOMrC3lgI1vGB+I2jZEwgc3nLlFXTrkvrRvJykY7Ne4HBytNYrDIVwcP yFRCbVuWE7qSy943QM9DcyrFsaXXDztd8lN3kOAwidqksl2nQRi0Tb8R2bMzU1eRDCGI 4fooKjr6/SU46iUxMw0vYThZd35KDkKApY6opcBMpulcFap8C7sXxmpK9EpTYuFLohOe F2cFj+QmvnhZhaRm0bvkXvkFr4WkOdbam6GR1n2KuU2ZuHgRoT+VI4w9tf4S/pkBVdoM nLH3BLNcqNqnselQJby5I6iVNIwxhnH7YRDtmhp42iZjc5PRB+8o82jTnqjgGz/Wra8T X97g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FOjasEQwS3ttqu5HZYDgpIulkQ+OB8ttrimF3CTvUdQ=; b=ekEbG2eKsIolhnG4nlrlLTzjvwvshZxXCyaYMM78CVFltqAE2NlulEDyM2C2I1v7vZ 3/zaNaM0Eu1Aju7xWxOVruaPj6v05VIPuQzf/gCG8rpqWXpXfLq+TtOA32eKMD8MRD86 UCjXZieD0wtBzSCcPoFTvlfYUO7JHoL21t+v5DwozcJ4m6owi4s8kCdmqkZp3olxhmAy nSXOC4BJuCiCij3TxSc4hzKhC9BwEX01rOt/khOmfDHZy9ZtuuqbWANsWw+17aj/23y5 Pt3h20AMW51YK/IYvNRMP26jd55Ty0QShIuaxUithXF6xxgHZh9sMbJAcWIYto6GlX02 pmDA== X-Gm-Message-State: ALoCoQlKZ8/XiQAQpJiFpky9MsAhxVv+0t03F/Oc9c7NuTGxgnsof1I7oyHvxrmeXzlUyvrEaPpq X-Received: by 10.52.36.51 with SMTP id n19mr9158240vdj.77.1420852519716; Fri, 09 Jan 2015 17:15:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Fri, 9 Jan 2015 17:14:59 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com> <00b201d02b12$c0ca8d50$425fa7f0$@org.cn> <913383AAA69FF945B8F946018B75898A35529742@xmb-rcd-x10.cisco.com> <008f01d02bb9$fef15f80$fcd41e80$@org.cn> <00d301d02bed$0f0406b0$2d0c1410$@org.cn> From: Justin Uberti Date: Fri, 9 Jan 2015 17:14:59 -0800 Message-ID: To: Ca By Content-Type: multipart/alternative; boundary=20cf307cfd16b76f6b050c420140 Archived-At: Cc: Simon Perreault , Oleg Moskalenko , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 01:15:23 -0000 --20cf307cfd16b76f6b050c420140 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. You just send RAF(v6) by itself, as before. (Same goes for v4-only, or you could omit the attribute entirely.) On Fri, Jan 9, 2015 at 5:00 PM, Ca By wrote: > > > On Friday, January 9, 2015, Justin Uberti wrote: > >> OK, so we have clear evidence that some deployed servers will fail >> (deterministically, fortunately) on the current SSODA proposal. >> >> So we're back to which backwards-compatible option we want to pursue. I >> suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMIL= Y. >> >> > It was not clear to me earlier in the thread > > Does option c allow for ipv6-only operation ? > > CB > > > >> Separately, we need to decide whether we want to pursue issue #2 that I >> identified previously, i.e., allowing specific error codes to be returne= d >> for each address family. >> >> On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko >> wrote: >> >>> I double-checked that with a real test. I ran the coTurn test client >>> (that implements experimental SSODA draft with two RAF attributes) agai= nst >>> rfc5766-turn-server and the server yielded error 400 with the message "= Only >>> one address family attribute can be used in a request" >>> >>> :( >>> >>> As I said, I can eliminate that problem in the subsequent >>> rfc5766-turn-server maintenance releases, but still... >>> >>> I am sorry that I did not discover that previously and that I advocated >>> an incompatible implementation option. >>> >>> So, if the WG insists on a backward-compatible protocol in all senses, >>> then we have to choose another option. >>> >>> Thanks >>> Oleg >>> >>> >>> >>> On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko >>> wrote: >>> >>>> I checked the code of rfc5766-turn-server again, and I found that it >>>> will NOT handle the multiple-RAF case. It will return 400 error with t= he >>>> message "Only one address family attribute can be used in a request". = At >>>> least, it's been that way in the 2014 releases. I did not check the ol= der >>>> releases. >>>> >>>> Sorry that I provided a wrong information about the implementation, >>>> before. >>>> >>>> I can fix that code but still there are people out there who will be >>>> using the "wrong" versions. >>>> >>>> So, if we do have to be absolutely backward compatible then we have to >>>> use a different option... >>>> >>>> Oleg >>>> >>>> >>>> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti >>>> wrote: >>>> >>>>> I reviewed the code for restund, reTurn, and rfc5766-turn-server and >>>>> they all appear to handle RAF (and multiple RAF) OK. >>>>> >>>>> The problem, as I see it, is that there may be other TURN servers, >>>>> perhaps non-open-source ones, that work fine today with Chrome, but w= ill >>>>> start returning errors when we include RAF or multiple RAF, and so ma= king >>>>> this change may break some small number of apps (who will then blame >>>>> Chrome). We just don't know what is out there. >>>>> >>>>> >>>>> >>>>> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >>>>> wrote: >>>>> >>>>>> >>>>>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >>>>> > wrote: >>>>>> >>>>>>> After your detail analysis and the sentence =E2=80=9CFor either b/c= , we >>>>>>> would need to say that including both RAF and OAF/AAF for the same = address >>>>>>> family is prohibited.=E2=80=9D, I think it may be better to keep on= ly one attribute >>>>>>> to fulfill the SSODA requirement? >>>>>> >>>>>> >>>>>> There is no requirement that SSODA functionality be realized with >>>>>> only one attribute, nor that the protocol be elegant, nor that it ex= hibits >>>>>> symmetry that is pleasing to the eye. >>>>>> >>>>>> There *is* a requirement that it be backwards-compatible though. >>>>>> Whether that means compatible with the spec or compatible with actua= l >>>>>> implementations is a matter of debate. >>>>>> >>>>>> Justin, if we can't find a single implementation that would barf, wh= y >>>>>> would Chrome have to implement a complex fallback mechanism? >>>>>> >>>>>> Simon >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tram mailing list >>>>> tram@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tram >>>>> >>>>> >>>> >>> >> --20cf307cfd16b76f6b050c420140 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes. You just send RAF(v6) by itself, as before.
(Same= goes for v4-only, or you could omit the attribute entirely.)

On Fri, Jan 9, 2015= at 5:00 PM, Ca By <cb.list6@gmail.com> wrote:


On Friday, January 9, 2015, = Justin Uberti <j= uberti@google.com> wrote:
OK, so we have clear evidence that some deployed servers will fail= (deterministically, fortunately) on the current SSODA proposal.

So we're back to which backwards-compatible option we want to = pursue. I suggest c), which is the optional-comprehension ADDITIONAL-ADDRES= S-FAMILY.


It was not clear to me earlier in the thread=C2=A0

Does option c allow for ipv6-only operation ?

CB

=C2=A0
Separately, we need to decide whe= ther we want to pursue issue #2 that I identified previously, i.e., allowin= g specific error codes to be returned for each address family.

On Fri, Jan 9, 2015 at 1= 0:53 AM, Oleg Moskalenko <mom040267@gmail.com&g= t; wrote:
I double-checked that with a real test. I ran the coTurn test = client (that implements experimental SSODA draft with two RAF attributes) a= gainst rfc5766-turn-server and the server yielded error 400 with the messag= e "Only one address family attribute can be used in a request"
:(

As I said, I can eliminate that problem in the subsequ= ent rfc5766-turn-server maintenance releases, but still...

I a= m sorry that I did not discover that previously and that I advocated an inc= ompatible implementation option.

So, if the WG insists on a ba= ckward-compatible protocol in all senses, then we have to choose another op= tion.

Thanks
Oleg



On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <= mom040267@gmail.com> wrote:
I checked the code of rfc5766-turn-server again, = and I found that it will NOT handle the multiple-RAF case. It will return 4= 00 error with the message "Only one address family attribute can be us= ed in a request". At least, it's been that way in the 2014 release= s. I did not check the older releases.

Sorry that I provi= ded a wrong information about the implementation, before.

I can fix that code but still there are people out there who will be using= the "wrong" versions.

So, if we do have to be = absolutely backward compatible then we have to use a different option...

Oleg
=C2=A0

On Fri, Jan 9, 2015 at = 9:34 AM, Justin Uberti <juberti@google.com><= /span> wrote:
I reviewed the code for restund, reTurn, and rfc5766-turn-serve= r and they all appear to handle RAF (and multiple RAF) OK.

The problem, as I see it, is that there may be other TURN servers, perha= ps non-open-source ones, that work fine today with Chrome, but will start r= eturning errors when we include RAF or multiple RAF, and so making this cha= nge may break some small number of apps (who will then blame Chrome). We ju= st don't know what is out there.



On F= ri, Jan 9, 2015 at 6:11 AM, Simon Perreault <sperre= ault@jive.com> wrote:

On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <wangai= jun@tsinghua.org.cn> wrote:
After your detail analysis and the sentence =E2=80=9CFor either b/c, we wo= uld need to say that including both RAF and OAF/AAF for the same address fa= mily is prohibited.=E2=80=9D, I think it may be better to keep only one att= ribute to fulfill the SSODA requirement? =C2=A0

There is no requirement that SSODA functionality be realized with only on= e attribute, nor that the protocol be elegant, nor that it exhibits symmetr= y that is pleasing to the eye.

There *is* a requirement that it be backwards-comp= atible though. Whether that means compatible with the spec or compatible wi= th actual implementations is a matter of debate.

Justin, if we can't find a s= ingle implementation that would barf, why would Chrome have to implement a = complex fallback mechanism?

Simon


_________________________________________= ______
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram





--20cf307cfd16b76f6b050c420140-- From nobody Fri Jan 9 19:38:43 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584AA1A8835 for ; Fri, 9 Jan 2015 19:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ApKngwX0ixn2 for ; Fri, 9 Jan 2015 19:38:36 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0B31A7034 for ; Fri, 9 Jan 2015 19:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17032; q=dns/txt; s=iport; t=1420861116; x=1422070716; h=from:to:subject:date:message-id:mime-version; bh=guzOxnhwHfTWidU4Crn9lK/Lalt2L6//dcJkKKMquL8=; b=L0GbMMAxHradDT4k5CR5wVtGwu+7cpWaeZUstUYqNOv8ApgIzM4pp0GD 9+tU60ildDQYixNrA5T39LtucXVEtv1xDRUFk+PYW3sn3sgVu7lCzBA8A V7XwNf/KFAnLMha4OJyZQZCZhyJOdpyJ/M6C+9GCfby7to0pgHExw7aIX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKydsFStJV2d/2dsb2JhbABcgkNDUlgEgwHAXYgWAhx7QwEBAQEBfYQMAQEBBCMKRRkBCA4DBAEBCx0DAgQwFAkJAQQBEgiIJLZUk1YBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0g3gmkugRMFjjiafyKDbm+BBSQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,735,1413244800"; d="scan'208,217";a="112008476" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 10 Jan 2015 03:38:35 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0A3cZg0007903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Jan 2015 03:38:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 21:38:35 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti , "tram@ietf.org" Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AdAshuX6BWxLj30LTtKRU8H8RSyoSQ== Date: Sat, 10 Jan 2015 03:38:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552A0EE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.43.160] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552A0EExmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 03:38:39 -0000 --_000_913383AAA69FF945B8F946018B75898A3552A0EExmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpFbnRlcnByaXNlLXByb3ZpZGVkIFRVUk4gc2VydmVyIGNhbm5vdCBwcm92 aWRlIGxvY2F0aW9uIHByaXZhY3kgbWF5IG5vdCBiZSBhbHdheXMgdHJ1ZS4gRm9yIGV4YW1wbGUg RW50ZXJwcmlzZSBuZXR3b3JrIGNvdWxkIHVzZSBUVVJOIHNlcnZlciBwcm92aWRlZCBieSBhIGNs b3VkIHNlcnZpY2UgYW5kIHRoZSB1c2VyIG5lZWRzIHRvIGtub3cgdGhhdCB0aGUgRW50ZXJwcmlz ZSBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBsb2NhdGlvbiBwcml2YWN5IGFuZCBub3QgcHJvY2Vl ZCB3aXRoIFRVUk4taW4tVFVSTi4NCg0KV2Ugd2lsbCBoYXZlIHRvIGRpc2N1c3MgaWYgVFVSTiBz ZXJ2ZXIgY2FuIGFkdmVydGlzZSB0aGF0IGl0IGNhbiBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kg aW4gYSBuZXcgYXR0cmlidXRlIG9yIHRoaXMgaW5mbyBjYW4gYmUgY29udmV5ZWQgb3V0LW9mLWJh bmQgKGUuZy4gUEFDKS4NCg0KVGhlIG90aGVyIHByb2JsZW0gbm90IGRpc2N1c3NlZCBpbiB0aGUg ZHJhZnQgaXMsIHdoYXQgaWYgdGhlIHVzZXIgd2FudHMgcHJpdmFjeSBhZ2FpbnN0IHRoZSBjYWxs aW5nIHNpdGUgYW5kIGxldOKAmXMgc2F5IHVzZXMgVG9yIGZvciBwcml2YWN5LiBJbiB0aGlzIHNj ZW5hcmlvIGFwcCBUVVJOIHNlcnZlciBtdXN0IG5vdCBiZSBzZWxlY3RlZC4NCg0KLVRpcnUNCg0K RnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1 c3RpbiBVYmVydGkNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAwOSwgMjAxNSA0OjA0IEFNDQpUbzog dHJhbUBpZXRmLm9yZw0KU3ViamVjdDogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LXBhdGlsLXRy YW0tdHVybi1zZXJ2LXNlbGVjdGlvbi0wMA0KDQpBdCBJRVRGIDkxLCBJIHByb21pc2VkIHRvIHNl bmQgZmVlZGJhY2sgb24gdGhpcyBkb2N1bWVudCwgc28gaGVyZSBnb2VzLg0KDQpHZW5lcmFsbHks IEkgdGhpbmsgbWFueSBvZiB0aGUgaXNzdWVzIG1lbnRpb25lZCBpbiB0aGlzIGRvY3VtZW50IGFy ZSBpbXBvcnRhbnQsIGJ1dCB0aGUgcmVjb21tZW5kYXRpb25zIGFyZSBjb25mdXNpbmcgYW5kIHBv c3NpYmx5IGNvbnRyYWRpY3Rvcnk7IGEgZGV2ZWxvcGVyIHdpdGggbGl0dGxlIGtub3dsZWRnZSBv ZiBUVVJOIHdpbGwgaGF2ZSBhIGhhcmQgdGltZSBmaWd1cmluZyBvdXQgZXhhY3RseSB3aGF0IHRv IGRvLiBGdXJ0aGVybW9yZSwgbWFueSBvZiB0aGUgcHJvcGVydGllcyBkaXNjdXNzZWQgaW4gdGhp cyBkb2N1bWVudCBhcmUgZHluYW1pYywgYW5kIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSBJQ0Ug cHJvY2VzcywgcmF0aGVyIHRoYW4gaW4gVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIChmb3IgZXhhbXBs ZSwgdGhlIG5vdGlvbiBvZiBSVFQgYXMgaXQgcmVsYXRlcyB0byB1c2VyIGV4cGVyaWVuY2UpLg0K DQpUaGVyZWZvcmUsIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91bGQgdGFrZSBhIHN0cm9uZ2Vy IHN0YW5jZSBhbmQgcHV0IGZvcnRoIGV4cGxpY2l0IGJlc3QgcHJhY3RpY2VzIGZvciBzZWxlY3Rp b24gKGFzIG9wcG9zZWQgdG8gInRoaW5ncyB0byBjb25zaWRlciIpLCBmb3Igbm9uLWR5bmFtaWMg cHJvcGVydGllcywgYW5kIGxlYXZlIHRoZSBkZWNpc2lvbnMgb24gZHluYW1pYyBwcm9wZXJ0aWVz IHRvIGJlIHJlc29sdmVkIGJ5IElDRS4NCg0KRm9yIGV4YW1wbGUsIEkgdGhpbmsgd2Ugc2hvdWxk IG9taXQgdGhlIHRleHQgaW4gU2VjdGlvbiAzIGFib3V0IHdoYXQgdG8gZG8gd2l0aCBub24td29y a2luZyBUVVJOIHNlcnZlcnMsIGFuZCBtZWFzdXJpbmcgUlRULiBTYW1lIGZvciBTZWN0aW9uIDMu Mywgd2hpY2ggYWxzbyBkaXNjdXNzZXMgUlRULCBhbmQgU2VjdGlvbiAzLjQsIHdoaWNoIHRhbGtz IGFib3V0IG11bHRpcGxlIGludGVyZmFjZXMuIFRoaXMgY2FuIGFsbCBiZSBoYW5kbGVkIGJ5IElD RS4NCg0KSW4gYWRkaXRpb24sIHRoZSBzZWN0aW9ucyBvbiBsb2NhbCBjb25maWcgYW5kIGxvY2F0 aW9uIHByaXZhY3kgYXJlIHVubmVjZXNzYXJ5IHdoZW4gUkVUVVJOIGlzIHVzZWQuIFdoZW4gUkVU VVJOIGlzIHVzZWQsIHRoZSBhcHBsaWNhdGlvbiBjYW4gYWx3YXlzIHVzZSB0aGUgYXBwIFRVUk4g c2VydmVyIGZvciBsb2NhdGlvbiBwcml2YWN5LCBhbmQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVu IGxvY2FsIFRVUk4gc2VydmVyIGFuZCBhcHAgVFVSTiBzZXJ2ZXIgaXMgZnVsbHkgc3BlbGxlZCBv dXQsIHNvIHRoZXJlIGlzIG5vdGhpbmcgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNpZGUgb24u DQoNClRoaXMgbGVhdmVzIG9ubHkgdGhlIFNlY3VyaXR5LCBBdXRoZW50aWNhdGlvbiwgYW5kIE1v YmlsaXR5IHNlY3Rpb25zLg0KDQpGb3Igc2VjdXJpdHksIEkgdGhpbmsgd2UgY2FuIGdpdmUgc29t ZSBjbGVhciBndWlkYW5jZSBvbiB3aGF0IGFwcGxpY2F0aW9ucyBzaG91bGQgZG8uIEZvciBzZWN1 cml0eSwgSSB0aGluayB0aGUgZ3VpZGFuY2Ugc2hvdWxkIGJlIHRvIHVzZSBvbmx5IERUTFMgKyBU TFMsIGlmIGJvdGggYXJlIGF2YWlsYWJsZSwgd2l0aCBmYWxsYmFjayB0byBVRFAgb3IgVENQIGlm IERUTFMgb3IgVExTIGFyZW4ndCBhdmFpbGFibGUuIElmIHByaXZhY3kgaXMgcGFyYW1vdW50LCBV RFAvVENQIGZhbGxiYWNrIG1heSBiZSBjb250cmFpbmRpY2F0ZWQsIGJ1dCBhdCB0aGlzIHBvaW50 IGluIHRpbWUsIERUTFMgZGVwbG95bWVudCBpc24ndCB3aWRlc3ByZWFkIGVub3VnaCB0byB0cnVs eSByZWNvbW1lbmQgdGhpcy4NCg0KVGhpcyByZWxhdGVzIHRvIHRoZSBBdXRoZW50aWNhdGlvbiBz ZWN0aW9uIC0gYnV0IEkgdGhpbmsgYW55IGZhaWx1cmVzIHRvIGF1dGhlbnRpY2F0ZSB0aGUgc2Vy dmVyIGNlcnQgc2hvdWxkIGNhdXNlIHRoZSBUVVJOIGFsbG9jYXRpb24gdG8gZmFpbC4gVGhpcyBp cyBqdXN0IGxpa2UgYW55IG90aGVyIG1pc2NvbmZpZ3VyYXRpb24gb24gdGhlIFRVUk4gc2VydmVy IC0gdGhlcmUncyBubyByZWFzb24gd2Ugc2hvdWxkIGV2ZW4gYWxsb3cgdXNlIG9mIFRVUk4gc2Vy dmVycyB3aG9zZSBjZXJ0IGNoYWlucyBkb24ndCB2YWxpZGF0ZS4gU28sIHRoaXMgc2VjdGlvbiBj b3VsZCBwcm9iYWJseSBiZSByZW1vdmVkLg0KDQpMYXN0bHksIHRoZSBNb2JpbGl0eSBzZWN0aW9u IHNheXMgdGhhdCBpZiAiYWxsIG90aGVyIHBhcmFtZXRlcnMgW2FyZV0gZXF1YWwiLCBhIFRVUk4g c2VydmVyIHdpdGggbW9iaWxpdHkgc2hvdWxkIGJlIHVzZWQuIENsZWFybHksIGFsbCBvdGhlciBw YXJhbWV0ZXJzIHdpbGwgbm90IGJlIGVxdWFsIChlLmcuIFJUVCksIGFuZCBldmVuIGlmIHRoZXkg d2VyZSwgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRvIGtub3cgaWYgYSBzZXJ2ZXIgaXMgbW9iaWxp dHktY2FwYWJsZSBhIHByaW9yaS4gU28gSSB0aGluayB0aGlzIHJlY29tbWVuZGF0aW9uIG91Z2h0 IHRvIGJlIHJlbW92ZWQsIG9yIHBlcmhhcHMgdHVybmVkIGludG8gc29tZSBzb3J0IG9mIHJlY29t bWVuZGF0aW9uIGZvciBUVVJOIHNlcnZlciBkZXZlbG9wZXJzIChlLmcuIFRVUk4gc2VydmVycyBT SE9VTEQgc3VwcG9ydCBUTFMvRFRMUywgU0hPVUxEIHN1cHBvcnQgbW9iaWxpdHksIFNIT1VMRCBz dXBwb3J0IHJlZGlyZWN0KSwgcHJvYmFibHkgaW4gYSBzZXBhcmF0ZSBkb2MuDQoNClRoZXNlIHJl Y29tbWVuZGF0aW9ucyBzaG91bGQgcmVkdWNlIHRoZSBzaXplIG9mIHRoaXMgZG9jdW1lbnQgYW5k IHByb3ZpZGUgbXVjaCBjbGVhcmVyIGFkdmljZSB0byBhcHAgZGV2ZWxvcGVycy4NCg== --_000_913383AAA69FF945B8F946018B75898A3552A0EExmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FbnRlcnByaXNlLXByb3ZpZGVkIFRVUk4gc2VydmVy IGNhbm5vdCBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kgbWF5IG5vdCBiZSBhbHdheXMgdHJ1ZS4g Rm9yIGV4YW1wbGUgRW50ZXJwcmlzZSBuZXR3b3JrIGNvdWxkIHVzZSBUVVJOIHNlcnZlciBwcm92 aWRlZCBieSBhIGNsb3VkDQogc2VydmljZSBhbmQgdGhlIHVzZXIgbmVlZHMgdG8ga25vdyB0aGF0 IHRoZSBFbnRlcnByaXNlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kg YW5kIG5vdCBwcm9jZWVkIHdpdGggVFVSTi1pbi1UVVJOLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSB3aWxsIGhh dmUgdG8gZGlzY3VzcyBpZiBUVVJOIHNlcnZlciBjYW4gYWR2ZXJ0aXNlIHRoYXQgaXQgY2FuIHBy b3ZpZGUgbG9jYXRpb24gcHJpdmFjeSBpbiBhIG5ldyBhdHRyaWJ1dGUgb3IgdGhpcyBpbmZvIGNh biBiZSBjb252ZXllZCBvdXQtb2YtYmFuZCAoZS5nLg0KIFBBQykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3Ro ZXIgcHJvYmxlbSBub3QgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCBpcywgd2hhdCBpZiB0aGUgdXNl ciB3YW50cyBwcml2YWN5IGFnYWluc3QgdGhlIGNhbGxpbmcgc2l0ZSBhbmQgbGV04oCZcyBzYXkg dXNlcyBUb3IgZm9yIHByaXZhY3kuIEluIHRoaXMgc2NlbmFyaW8NCiBhcHAgVFVSTiBzZXJ2ZXIg bXVzdCBub3QgYmUgc2VsZWN0ZWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEphbnVhcnkgMDksIDIwMTUgNDowNCBBTTxicj4NCjxiPlRvOjwvYj4gdHJhbUBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtcGF0 aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IElFVEYgOTEsIEkgcHJvbWlzZWQgdG8gc2Vu ZCBmZWVkYmFjayBvbiB0aGlzIGRvY3VtZW50LCBzbyBoZXJlIGdvZXMuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HZW5lcmFsbHksIEkgdGhpbmsgbWFueSBv ZiB0aGUgaXNzdWVzIG1lbnRpb25lZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBpbXBvcnRhbnQsIGJ1 dCB0aGUgcmVjb21tZW5kYXRpb25zIGFyZSBjb25mdXNpbmcgYW5kIHBvc3NpYmx5IGNvbnRyYWRp Y3Rvcnk7IGEgZGV2ZWxvcGVyIHdpdGggbGl0dGxlIGtub3dsZWRnZSBvZiBUVVJOIHdpbGwgaGF2 ZSBhIGhhcmQgdGltZSBmaWd1cmluZyBvdXQgZXhhY3RseSB3aGF0DQogdG8gZG8uIEZ1cnRoZXJt b3JlLCBtYW55IG9mIHRoZSBwcm9wZXJ0aWVzIGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50IGFy ZSBkeW5hbWljLCBhbmQgc2hvdWxkIGJlIGhhbmRsZWQgYnkgdGhlIElDRSBwcm9jZXNzLCByYXRo ZXIgdGhhbiBpbiBUVVJOIHNlcnZlciBzZWxlY3Rpb24gKGZvciBleGFtcGxlLCB0aGUgbm90aW9u IG9mIFJUVCBhcyBpdCByZWxhdGVzIHRvIHVzZXIgZXhwZXJpZW5jZSkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlZm9yZSwgSSB0aGlu ayB0aGlzIGRvY3VtZW50IHNob3VsZCB0YWtlIGEgc3Ryb25nZXIgc3RhbmNlIGFuZCBwdXQgZm9y dGggZXhwbGljaXQgYmVzdCBwcmFjdGljZXMgZm9yIHNlbGVjdGlvbiAoYXMgb3Bwb3NlZCB0byAm cXVvdDt0aGluZ3MgdG8gY29uc2lkZXImcXVvdDspLCBmb3Igbm9uLWR5bmFtaWMgcHJvcGVydGll cywgYW5kIGxlYXZlIHRoZSBkZWNpc2lvbnMgb24gZHluYW1pYyBwcm9wZXJ0aWVzIHRvIGJlIHJl c29sdmVkDQogYnkgSUNFLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgSSB0aGluayB3ZSBzaG91bGQgb21pdCB0 aGUgdGV4dCBpbiBTZWN0aW9uIDMgYWJvdXQgd2hhdCB0byBkbyB3aXRoIG5vbi13b3JraW5nIFRV Uk4gc2VydmVycywgYW5kIG1lYXN1cmluZyBSVFQuIFNhbWUgZm9yIFNlY3Rpb24gMy4zLCB3aGlj aCBhbHNvIGRpc2N1c3NlcyBSVFQsIGFuZCBTZWN0aW9uIDMuNCwgd2hpY2ggdGFsa3MgYWJvdXQg bXVsdGlwbGUgaW50ZXJmYWNlcy4gVGhpcyBjYW4NCiBhbGwgYmUgaGFuZGxlZCBieSBJQ0UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGFk ZGl0aW9uLCB0aGUgc2VjdGlvbnMgb24gbG9jYWwgY29uZmlnIGFuZCBsb2NhdGlvbiBwcml2YWN5 IGFyZSB1bm5lY2Vzc2FyeSB3aGVuIFJFVFVSTiBpcyB1c2VkLiBXaGVuIFJFVFVSTiBpcyB1c2Vk LCB0aGUgYXBwbGljYXRpb24gY2FuIGFsd2F5cyB1c2UgdGhlIGFwcCBUVVJOIHNlcnZlciBmb3Ig bG9jYXRpb24gcHJpdmFjeSwgYW5kIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBsb2NhbCBUVVJO IHNlcnZlcg0KIGFuZCBhcHAgVFVSTiBzZXJ2ZXIgaXMgZnVsbHkgc3BlbGxlZCBvdXQsIHNvIHRo ZXJlIGlzIG5vdGhpbmcgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNpZGUgb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbGVhdmVz IG9ubHkgdGhlIFNlY3VyaXR5LCBBdXRoZW50aWNhdGlvbiwgYW5kIE1vYmlsaXR5IHNlY3Rpb25z LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Gb3Igc2VjdXJpdHksIEkgdGhpbmsgd2UgY2FuIGdpdmUgc29tZSBjbGVhciBndWlkYW5j ZSBvbiB3aGF0IGFwcGxpY2F0aW9ucyBzaG91bGQgZG8uIEZvciBzZWN1cml0eSwgSSB0aGluayB0 aGUgZ3VpZGFuY2Ugc2hvdWxkIGJlIHRvIHVzZSBvbmx5IERUTFMgJiM0MzsgVExTLCBpZiBib3Ro IGFyZSBhdmFpbGFibGUsIHdpdGggZmFsbGJhY2sgdG8gVURQIG9yIFRDUCBpZiBEVExTIG9yIFRM UyBhcmVuJ3QgYXZhaWxhYmxlLg0KIElmIHByaXZhY3kgaXMgcGFyYW1vdW50LCBVRFAvVENQIGZh bGxiYWNrIG1heSBiZSBjb250cmFpbmRpY2F0ZWQsIGJ1dCBhdCB0aGlzIHBvaW50IGluIHRpbWUs IERUTFMgZGVwbG95bWVudCBpc24ndCB3aWRlc3ByZWFkIGVub3VnaCB0byB0cnVseSByZWNvbW1l bmQgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyByZWxhdGVzIHRvIHRoZSBBdXRoZW50aWNhdGlvbiBzZWN0aW9uIC0gYnV0IEkg dGhpbmsgYW55IGZhaWx1cmVzIHRvIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyIGNlcnQgc2hvdWxk IGNhdXNlIHRoZSBUVVJOIGFsbG9jYXRpb24gdG8gZmFpbC4gVGhpcyBpcyBqdXN0IGxpa2UgYW55 IG90aGVyIG1pc2NvbmZpZ3VyYXRpb24gb24gdGhlIFRVUk4gc2VydmVyIC0gdGhlcmUncyBubyBy ZWFzb24gd2Ugc2hvdWxkDQogZXZlbiBhbGxvdyB1c2Ugb2YgVFVSTiBzZXJ2ZXJzIHdob3NlIGNl cnQgY2hhaW5zIGRvbid0IHZhbGlkYXRlLiBTbywgdGhpcyBzZWN0aW9uIGNvdWxkIHByb2JhYmx5 IGJlIHJlbW92ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkxhc3RseSwgdGhlIE1vYmlsaXR5IHNlY3Rpb24gc2F5cyB0aGF0IGlmICZxdW90 O2FsbCBvdGhlciBwYXJhbWV0ZXJzIFthcmVdIGVxdWFsJnF1b3Q7LCBhIFRVUk4gc2VydmVyIHdp dGggbW9iaWxpdHkgc2hvdWxkIGJlIHVzZWQuIENsZWFybHksIGFsbCBvdGhlciBwYXJhbWV0ZXJz IHdpbGwgbm90IGJlIGVxdWFsIChlLmcuIFJUVCksIGFuZCBldmVuIGlmIHRoZXkgd2VyZSwgdGhl IGNsaWVudCBoYXMgbm8gd2F5IHRvIGtub3cgaWYNCiBhIHNlcnZlciBpcyBtb2JpbGl0eS1jYXBh YmxlIGEgcHJpb3JpLiBTbyBJIHRoaW5rIHRoaXMgcmVjb21tZW5kYXRpb24gb3VnaHQgdG8gYmUg cmVtb3ZlZCwgb3IgcGVyaGFwcyB0dXJuZWQgaW50byBzb21lIHNvcnQgb2YgcmVjb21tZW5kYXRp b24gZm9yIFRVUk4gc2VydmVyIGRldmVsb3BlcnMgKGUuZy4gVFVSTiBzZXJ2ZXJzIFNIT1VMRCBz dXBwb3J0IFRMUy9EVExTLCBTSE9VTEQgc3VwcG9ydCBtb2JpbGl0eSwgU0hPVUxEIHN1cHBvcnQg cmVkaXJlY3QpLA0KIHByb2JhYmx5IGluIGEgc2VwYXJhdGUgZG9jLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSByZWNvbW1lbmRhdGlv bnMgc2hvdWxkIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGlzIGRvY3VtZW50IGFuZCBwcm92aWRlIG11 Y2ggY2xlYXJlciBhZHZpY2UgdG8gYXBwIGRldmVsb3BlcnMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A3552A0EExmbrcdx10ciscoc_-- From nobody Sat Jan 10 12:47:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85D1A883F for ; Sat, 10 Jan 2015 12:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 IRMOhjuJwHGS for ; Sat, 10 Jan 2015 12:47:49 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FD81A87C9 for ; Sat, 10 Jan 2015 12:47:49 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id kv19so4938451vcb.4 for ; Sat, 10 Jan 2015 12:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=alK5nojgLF76JUZVwrQUvbrt12QAF+djlsHlX8+iB8o=; b=PBkAYrP6WVBCwlGuJIfu1Cm2I8HsJo9BKSgN7JJYVyuQI3DpR6moL9eqrHL1Q1WlZF 5ZLYk4qBdgBaZYcJqb8LcRlFLfypW12Lleo4BeIucBNWsp4wym5GH5b5ZkaNgtOPWsc9 EdnTubvvsRaOfg6q4AlRUxBWbtGzY8m5FSk1GOs/3Ls04VWFLHwySRgungknZHJni1yp QB72Q9DOLDqxBzvY367r0oy6Nr/cuB/434vsDpTcL7en8hjyAu/njS4hxP6lo1cbPiIq nZBhrSuvNKkqnYAYtuufvYMjUm5pOcQFQfJbOPcFe8E3ei3IzuUPenAQLHZDlSZRnuFJ Mzjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=alK5nojgLF76JUZVwrQUvbrt12QAF+djlsHlX8+iB8o=; b=jToHjHH1z6pPSMPoYmbq9uBXLvTLSL6TtPz4RlsUs0Ch1bL8+tHtlKFa7CRvXjwZ7S 1MFrQ8m+7O6YSdwIkPpYEOmc7osjZL7MsvNpyRnl/hlVios4HPBMQgj8TKPWLCK0OKND KsdlEJNlVZuvIkCI+eH1+2g3apcMllvQASBHCkSYUK5SCJdxQP4OkNUfiQFU6LqDSMMs ZzJFNvAWHob2zs6BwIEdisx9WRvVlpobldS8xRK5JNPcFRNs/2wQ3NTnxa9eg0vbA5Fq kGGQddbAzWQE1XzKnVau9a8+530YkX0K2/bN03/AnJAOxkpDadSafsiHO2gZeXETL5Kp 204Q== X-Gm-Message-State: ALoCoQnh0xc2LaUYzlXG6HPKu8Iq7lKi81EzgUrmKwwVaJy9VvhqJa1+eBUaIoEei0yVnwgW1rVo X-Received: by 10.220.139.135 with SMTP id e7mr12004214vcu.75.1420922868631; Sat, 10 Jan 2015 12:47:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Sat, 10 Jan 2015 12:47:28 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3552A0EE@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A3552A0EE@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Sat, 10 Jan 2015 12:47:28 -0800 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b343306d6bbb1050c5262c9 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 20:47:52 -0000 --047d7b343306d6bbb1050c5262c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Justin, > > > > Enterprise-provided TURN server cannot provide location privacy may not b= e > always true. For example Enterprise network could use TURN server provide= d > by a cloud service and the user needs to know that the Enterprise TURN > server can provide location privacy and not proceed with TURN-in-TURN. > > > > We will have to discuss if TURN server can advertise that it can provide > location privacy in a new attribute or this info can be conveyed > out-of-band (e.g. PAC). > > > The other problem not discussed in the draft is, what if the user wants > privacy against the calling site and let=E2=80=99s say uses Tor for priva= cy. In > this scenario app TURN server must not be selected. > RETURN handles this situation fine, since the traffic will be routed through the network-provided TURN server before being routed to the app TURN server. Of course, if the application does not try to provide location privacy, only the network-provided TURN server will be used. However, I think the user is much more likely to trust the application than its network provider to provide privacy protection. > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Friday, January 09, 2015 4:04 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > At IETF 91, I promised to send feedback on this document, so here goes. > > > > Generally, I think many of the issues mentioned in this document are > important, but the recommendations are confusing and possibly > contradictory; a developer with little knowledge of TURN will have a hard > time figuring out exactly what to do. Furthermore, many of the properties > discussed in this document are dynamic, and should be handled by the ICE > process, rather than in TURN server selection (for example, the notion of > RTT as it relates to user experience). > > > > Therefore, I think this document should take a stronger stance and put > forth explicit best practices for selection (as opposed to "things to > consider"), for non-dynamic properties, and leave the decisions on dynami= c > properties to be resolved by ICE. > > > > For example, I think we should omit the text in Section 3 about what to d= o > with non-working TURN servers, and measuring RTT. Same for Section 3.3, > which also discusses RTT, and Section 3.4, which talks about multiple > interfaces. This can all be handled by ICE. > > > > In addition, the sections on local config and location privacy are > unnecessary when RETURN is used. When RETURN is used, the application can > always use the app TURN server for location privacy, and the relationship > between local TURN server and app TURN server is fully spelled out, so > there is nothing for the application to decide on. > > > > This leaves only the Security, Authentication, and Mobility sections. > > > > For security, I think we can give some clear guidance on what application= s > should do. For security, I think the guidance should be to use only DTLS = + > TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS > aren't available. If privacy is paramount, UDP/TCP fallback may be > contraindicated, but at this point in time, DTLS deployment isn't > widespread enough to truly recommend this. > > > > This relates to the Authentication section - but I think any failures to > authenticate the server cert should cause the TURN allocation to fail. Th= is > is just like any other misconfiguration on the TURN server - there's no > reason we should even allow use of TURN servers whose cert chains don't > validate. So, this section could probably be removed. > > > > Lastly, the Mobility section says that if "all other parameters [are] > equal", a TURN server with mobility should be used. Clearly, all other > parameters will not be equal (e.g. RTT), and even if they were, the clien= t > has no way to know if a server is mobility-capable a priori. So I think > this recommendation ought to be removed, or perhaps turned into some sort > of recommendation for TURN server developers (e.g. TURN servers SHOULD > support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), > probably in a separate doc. > > > > These recommendations should reduce the size of this document and provide > much clearer advice to app developers. > --047d7b343306d6bbb1050c5262c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Hi Justin,<= /span>

=C2=A0

Enterprise-provided TURN = server cannot provide location privacy may not be always true. For example = Enterprise network could use TURN server provided by a cloud service and the user needs to know that the Enterprise TURN server can pro= vide location privacy and not proceed with TURN-in-TURN.

=C2=A0

We will have to discuss i= f TURN server can advertise that it can provide location privacy in a new a= ttribute or this info can be conveyed out-of-band (e.g. PAC).=C2=A0

=C2=A0

The other problem not dis= cussed in the draft is, what if the user wants privacy against the calling = site and let=E2=80=99s say uses Tor for privacy. In this scenario app TURN server must not be selected.

<= div>
RETURN handles this situation fine, since the traffic wi= ll be routed through the network-provided TURN server before being routed t= o the app TURN server. Of course, if the application does not try to provid= e location privacy, only the network-provided TURN server will be used.

However, I think the user is much more likely to trus= t the application than its network provider to provide privacy protection.<= /div>

=


=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 4:04 AM
To: tram@ietf.org=
Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00<= u>

=C2=A0

At IETF 91, I promised to send feedback on this docu= ment, so here goes.

=C2=A0

Generally, I think many of the issues mentioned in t= his document are important, but the recommendations are confusing and possi= bly contradictory; a developer with little knowledge of TURN will have a ha= rd time figuring out exactly what to do. Furthermore, many of the properties discussed in this document are = dynamic, and should be handled by the ICE process, rather than in TURN serv= er selection (for example, the notion of RTT as it relates to user experien= ce).

=C2=A0

Therefore, I think this document should take a stron= ger stance and put forth explicit best practices for selection (as opposed = to "things to consider"), for non-dynamic properties, and leave t= he decisions on dynamic properties to be resolved by ICE.=C2=A0

=C2=A0

For example, I think we should omit the text in Sect= ion 3 about what to do with non-working TURN servers, and measuring RTT. Sa= me for Section 3.3, which also discusses RTT, and Section 3.4, which talks = about multiple interfaces. This can all be handled by ICE.

=C2=A0

In addition, the sections on local config and locati= on privacy are unnecessary when RETURN is used. When RETURN is used, the ap= plication can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully spelled out, so there is nothing for the appl= ication to decide on.

=C2=A0

This leaves only the Security, Authentication, and M= obility sections.=C2=A0

=C2=A0

For security, I think we can give some clear guidanc= e on what applications should do. For security, I think the guidance should= be to use only DTLS + TLS, if both are available, with fallback to UDP or = TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback may be contraindicated, but at t= his point in time, DTLS deployment isn't widespread enough to truly rec= ommend this.

=C2=A0

This relates to the Authentication section - but I t= hink any failures to authenticate the server cert should cause the TURN all= ocation to fail. This is just like any other misconfiguration on the TURN s= erver - there's no reason we should even allow use of TURN servers whose cert chains don't validate. So, t= his section could probably be removed.

=C2=A0

Lastly, the Mobility section says that if "all = other parameters [are] equal", a TURN server with mobility should be u= sed. Clearly, all other parameters will not be equal (e.g. RTT), and even i= f they were, the client has no way to know if a server is mobility-capable a priori. So I think this recommendation ough= t to be removed, or perhaps turned into some sort of recommendation for TUR= N server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD supp= ort mobility, SHOULD support redirect), probably in a separate doc.

=C2=A0

These recommendations should reduce the size of this= document and provide much clearer advice to app developers.<= /p>


--047d7b343306d6bbb1050c5262c9-- From nobody Sat Jan 10 21:40:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26411A1AEC for ; Sat, 10 Jan 2015 21:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fe4EGEycVK60 for ; Sat, 10 Jan 2015 21:40:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF3B1A1AEA for ; Sat, 10 Jan 2015 21:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27752; q=dns/txt; s=iport; t=1420954812; x=1422164412; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XNs4UMKY5/ZouaBpXR9zrqTW3SEasu2shqNqvoP+zQM=; b=WQv4jt+iDaIdoJRS2aNgtdrA0Ma2ra3285Vg21146vRcP5O4LVRtSFz5 YDSyAio6ht7XREkRogPB4V8/coGBsCEZYB5bxBpg5NbZTjiJAPBJBimDq yX3RJE2Tj95NsJPg18Uu9aFIrt3aovvbqv+g2wrZWUNGML2AZb+JKHVr4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAJELslStJV2R/2dsb2JhbABbgkNDUlgEgwHAUIIlhXECHGlDAQEBAQF9hAwBAQEEIwpFBxACAQgOAwQBAQsdAwICAjAUCQgBAQQOBQiIJA22SZMTAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPSC0EBgGCaC6BEwWEOwKKAINFl0Aig25vgQUkHH4BAQE X-IronPort-AV: E=Sophos;i="5.07,737,1413244800"; d="scan'208,217";a="386369829" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jan 2015 05:40:11 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0B5eBSQ015743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Jan 2015 05:40:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 10 Jan 2015 23:40:11 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AdAshuX6BWxLj30LTtKRU8H8RSyoSQAwgn0AAAWwpiA= Date: Sun, 11 Jan 2015 05:40:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552A3CB@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A3552A0EE@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.228] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552A3CBxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 05:40:16 -0000 --_000_913383AAA69FF945B8F946018B75898A3552A3CBxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xl LmNvbV0NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMSwgMjAxNSAyOjE3IEFNDQpUbzogVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb dHJhbV0gQ29tbWVudHMgb24gZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAw DQoNCg0KDQpPbiBGcmksIEphbiA5LCAyMDE1IGF0IDc6MzggUE0sIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+ IHdyb3RlOg0KSGkgSnVzdGluLA0KDQpFbnRlcnByaXNlLXByb3ZpZGVkIFRVUk4gc2VydmVyIGNh bm5vdCBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kgbWF5IG5vdCBiZSBhbHdheXMgdHJ1ZS4gRm9y IGV4YW1wbGUgRW50ZXJwcmlzZSBuZXR3b3JrIGNvdWxkIHVzZSBUVVJOIHNlcnZlciBwcm92aWRl ZCBieSBhIGNsb3VkIHNlcnZpY2UgYW5kIHRoZSB1c2VyIG5lZWRzIHRvIGtub3cgdGhhdCB0aGUg RW50ZXJwcmlzZSBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBsb2NhdGlvbiBwcml2YWN5IGFuZCBu b3QgcHJvY2VlZCB3aXRoIFRVUk4taW4tVFVSTi4NCg0KV2Ugd2lsbCBoYXZlIHRvIGRpc2N1c3Mg aWYgVFVSTiBzZXJ2ZXIgY2FuIGFkdmVydGlzZSB0aGF0IGl0IGNhbiBwcm92aWRlIGxvY2F0aW9u IHByaXZhY3kgaW4gYSBuZXcgYXR0cmlidXRlIG9yIHRoaXMgaW5mbyBjYW4gYmUgY29udmV5ZWQg b3V0LW9mLWJhbmQgKGUuZy4gUEFDKS4NCg0KVGhlIG90aGVyIHByb2JsZW0gbm90IGRpc2N1c3Nl ZCBpbiB0aGUgZHJhZnQgaXMsIHdoYXQgaWYgdGhlIHVzZXIgd2FudHMgcHJpdmFjeSBhZ2FpbnN0 IHRoZSBjYWxsaW5nIHNpdGUgYW5kIGxldOKAmXMgc2F5IHVzZXMgVG9yIGZvciBwcml2YWN5LiBJ biB0aGlzIHNjZW5hcmlvIGFwcCBUVVJOIHNlcnZlciBtdXN0IG5vdCBiZSBzZWxlY3RlZC4NCg0K UkVUVVJOIGhhbmRsZXMgdGhpcyBzaXR1YXRpb24gZmluZSwgc2luY2UgdGhlIHRyYWZmaWMgd2ls bCBiZSByb3V0ZWQgdGhyb3VnaCB0aGUgbmV0d29yay1wcm92aWRlZCBUVVJOIHNlcnZlciBiZWZv cmUgYmVpbmcgcm91dGVkIHRvIHRoZSBhcHAgVFVSTiBzZXJ2ZXIuIE9mIGNvdXJzZSwgaWYgdGhl IGFwcGxpY2F0aW9uIGRvZXMgbm90IHRyeSB0byBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3ksIG9u bHkgdGhlIG5ldHdvcmstcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgd2lsbCBiZSB1c2VkLg0KDQpbVFJd IEJ1dCB0aGUgcHJvYmxlbSBpcyBob3cgd2lsbCB0aGUgZW5kcG9pbnQgaG93IGlmIG5ldHdvcmst cHJvdmlkZWQgVFVSTiBzZXJ2ZXIgY2FuIHByb3ZpZGUgbG9jYXRpb24gcHJpdmFjeSBvciBub3Qg Pw0KICAgICAgICAgVFVSTiBzZXJ2ZXIgY2FuIGNvbnZleSB0aGlzIGluZm9ybWF0aW9uIGluIGEg bmV3IFNUVU4gYXR0cmlidXRlIHRvIHRoZSBjbGllbnQuDQoNCkhvd2V2ZXIsIEkgdGhpbmsgdGhl IHVzZXIgaXMgbXVjaCBtb3JlIGxpa2VseSB0byB0cnVzdCB0aGUgYXBwbGljYXRpb24gdGhhbiBp dHMgbmV0d29yayBwcm92aWRlciB0byBwcm92aWRlIHByaXZhY3kgcHJvdGVjdGlvbi4NCg0KW1RS XSBVc2VyIG1heSBvciBtYXkgbm90IHRydXN0IHRoZSBhcHBsaWNhdGlvbiBzZXJ2ZXIuIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTEw IGRpc2N1c3NlcyB1c2VycyB1c2luZyBwcml2YWN5IHRlY2huaXF1ZXMgbGlrZSBUb3Igc28gdGhh dCBhcHAgc2VydmVyIGRvZXMgbm90IGxlYXJuIHRoZSB1c2VyJ3MgSVAgYWRkcmVzcy4gVGhlIFBv a2VyIGV4YW1wbGUgZ2l2ZW4gaW4gdGhlIGFib3ZlIGRyYWZ0IGV4cGxhaW5zIHRoYXQgdGhlIHVz ZXJzIGluIHRoZSBjYWxsIGRvIG5vdCB0cnVzdCB0aGUgY2FsbGluZyBzZXJ2aWNlLiBJbiB0aGlz IGNhc2UgSWRQIGVuc3VyZXMgdGhhdCBldmVuIGlmIG1hbGljaW91cyBjYWxsaW5nIHNlcnZpY2Ug cmVwbGFjZXMgdGhlIG1lZGlhIGFkZHJlc3NlcyB3aXRoIGl0cyBvd24gYWRkcmVzc2VzICBhbmQg cmVwbGFjZXMgdGhlIGNlcnRpZmljYXRlIGZpbmdlcnByaW50IGluIFNEUCB3aXRoIGl0cyBvd24g Y2VydGlmaWNhdGUsIElkUCBhc3NlcnRpb24gd291bGQgZW5zdXJlIHRoYXQgdGhlIFBva2VyIHNp dGUgY2Fubm90IGFjdCBhcyAgbWFuLWluLW1pZGRsZSBkZXZpY2UuIEluIHRoaXMgc2NlbmFyaW8g dXNlciBtYXkgbm90IHdhbnQgdG8gcGljayBhcHAgcHJvdmlkZWQgVFVSTiBzZXJ2ZXIuDQoNCi1U aXJ1DQoNCg0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2Vu dDogRnJpZGF5LCBKYW51YXJ5IDA5LCAyMDE1IDQ6MDQgQU0NClRvOiB0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LXBh dGlsLXRyYW0tdHVybi1zZXJ2LXNlbGVjdGlvbi0wMA0KDQpBdCBJRVRGIDkxLCBJIHByb21pc2Vk IHRvIHNlbmQgZmVlZGJhY2sgb24gdGhpcyBkb2N1bWVudCwgc28gaGVyZSBnb2VzLg0KDQpHZW5l cmFsbHksIEkgdGhpbmsgbWFueSBvZiB0aGUgaXNzdWVzIG1lbnRpb25lZCBpbiB0aGlzIGRvY3Vt ZW50IGFyZSBpbXBvcnRhbnQsIGJ1dCB0aGUgcmVjb21tZW5kYXRpb25zIGFyZSBjb25mdXNpbmcg YW5kIHBvc3NpYmx5IGNvbnRyYWRpY3Rvcnk7IGEgZGV2ZWxvcGVyIHdpdGggbGl0dGxlIGtub3ds ZWRnZSBvZiBUVVJOIHdpbGwgaGF2ZSBhIGhhcmQgdGltZSBmaWd1cmluZyBvdXQgZXhhY3RseSB3 aGF0IHRvIGRvLiBGdXJ0aGVybW9yZSwgbWFueSBvZiB0aGUgcHJvcGVydGllcyBkaXNjdXNzZWQg aW4gdGhpcyBkb2N1bWVudCBhcmUgZHluYW1pYywgYW5kIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRo ZSBJQ0UgcHJvY2VzcywgcmF0aGVyIHRoYW4gaW4gVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIChmb3Ig ZXhhbXBsZSwgdGhlIG5vdGlvbiBvZiBSVFQgYXMgaXQgcmVsYXRlcyB0byB1c2VyIGV4cGVyaWVu Y2UpLg0KDQpUaGVyZWZvcmUsIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91bGQgdGFrZSBhIHN0 cm9uZ2VyIHN0YW5jZSBhbmQgcHV0IGZvcnRoIGV4cGxpY2l0IGJlc3QgcHJhY3RpY2VzIGZvciBz ZWxlY3Rpb24gKGFzIG9wcG9zZWQgdG8gInRoaW5ncyB0byBjb25zaWRlciIpLCBmb3Igbm9uLWR5 bmFtaWMgcHJvcGVydGllcywgYW5kIGxlYXZlIHRoZSBkZWNpc2lvbnMgb24gZHluYW1pYyBwcm9w ZXJ0aWVzIHRvIGJlIHJlc29sdmVkIGJ5IElDRS4NCg0KRm9yIGV4YW1wbGUsIEkgdGhpbmsgd2Ug c2hvdWxkIG9taXQgdGhlIHRleHQgaW4gU2VjdGlvbiAzIGFib3V0IHdoYXQgdG8gZG8gd2l0aCBu b24td29ya2luZyBUVVJOIHNlcnZlcnMsIGFuZCBtZWFzdXJpbmcgUlRULiBTYW1lIGZvciBTZWN0 aW9uIDMuMywgd2hpY2ggYWxzbyBkaXNjdXNzZXMgUlRULCBhbmQgU2VjdGlvbiAzLjQsIHdoaWNo IHRhbGtzIGFib3V0IG11bHRpcGxlIGludGVyZmFjZXMuIFRoaXMgY2FuIGFsbCBiZSBoYW5kbGVk IGJ5IElDRS4NCg0KSW4gYWRkaXRpb24sIHRoZSBzZWN0aW9ucyBvbiBsb2NhbCBjb25maWcgYW5k IGxvY2F0aW9uIHByaXZhY3kgYXJlIHVubmVjZXNzYXJ5IHdoZW4gUkVUVVJOIGlzIHVzZWQuIFdo ZW4gUkVUVVJOIGlzIHVzZWQsIHRoZSBhcHBsaWNhdGlvbiBjYW4gYWx3YXlzIHVzZSB0aGUgYXBw IFRVUk4gc2VydmVyIGZvciBsb2NhdGlvbiBwcml2YWN5LCBhbmQgdGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIGxvY2FsIFRVUk4gc2VydmVyIGFuZCBhcHAgVFVSTiBzZXJ2ZXIgaXMgZnVsbHkgc3Bl bGxlZCBvdXQsIHNvIHRoZXJlIGlzIG5vdGhpbmcgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNp ZGUgb24uDQoNClRoaXMgbGVhdmVzIG9ubHkgdGhlIFNlY3VyaXR5LCBBdXRoZW50aWNhdGlvbiwg YW5kIE1vYmlsaXR5IHNlY3Rpb25zLg0KDQpGb3Igc2VjdXJpdHksIEkgdGhpbmsgd2UgY2FuIGdp dmUgc29tZSBjbGVhciBndWlkYW5jZSBvbiB3aGF0IGFwcGxpY2F0aW9ucyBzaG91bGQgZG8uIEZv ciBzZWN1cml0eSwgSSB0aGluayB0aGUgZ3VpZGFuY2Ugc2hvdWxkIGJlIHRvIHVzZSBvbmx5IERU TFMgKyBUTFMsIGlmIGJvdGggYXJlIGF2YWlsYWJsZSwgd2l0aCBmYWxsYmFjayB0byBVRFAgb3Ig VENQIGlmIERUTFMgb3IgVExTIGFyZW4ndCBhdmFpbGFibGUuIElmIHByaXZhY3kgaXMgcGFyYW1v dW50LCBVRFAvVENQIGZhbGxiYWNrIG1heSBiZSBjb250cmFpbmRpY2F0ZWQsIGJ1dCBhdCB0aGlz IHBvaW50IGluIHRpbWUsIERUTFMgZGVwbG95bWVudCBpc24ndCB3aWRlc3ByZWFkIGVub3VnaCB0 byB0cnVseSByZWNvbW1lbmQgdGhpcy4NCg0KVGhpcyByZWxhdGVzIHRvIHRoZSBBdXRoZW50aWNh dGlvbiBzZWN0aW9uIC0gYnV0IEkgdGhpbmsgYW55IGZhaWx1cmVzIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgc2VydmVyIGNlcnQgc2hvdWxkIGNhdXNlIHRoZSBUVVJOIGFsbG9jYXRpb24gdG8gZmFpbC4g VGhpcyBpcyBqdXN0IGxpa2UgYW55IG90aGVyIG1pc2NvbmZpZ3VyYXRpb24gb24gdGhlIFRVUk4g c2VydmVyIC0gdGhlcmUncyBubyByZWFzb24gd2Ugc2hvdWxkIGV2ZW4gYWxsb3cgdXNlIG9mIFRV Uk4gc2VydmVycyB3aG9zZSBjZXJ0IGNoYWlucyBkb24ndCB2YWxpZGF0ZS4gU28sIHRoaXMgc2Vj dGlvbiBjb3VsZCBwcm9iYWJseSBiZSByZW1vdmVkLg0KDQpMYXN0bHksIHRoZSBNb2JpbGl0eSBz ZWN0aW9uIHNheXMgdGhhdCBpZiAiYWxsIG90aGVyIHBhcmFtZXRlcnMgW2FyZV0gZXF1YWwiLCBh IFRVUk4gc2VydmVyIHdpdGggbW9iaWxpdHkgc2hvdWxkIGJlIHVzZWQuIENsZWFybHksIGFsbCBv dGhlciBwYXJhbWV0ZXJzIHdpbGwgbm90IGJlIGVxdWFsIChlLmcuIFJUVCksIGFuZCBldmVuIGlm IHRoZXkgd2VyZSwgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRvIGtub3cgaWYgYSBzZXJ2ZXIgaXMg bW9iaWxpdHktY2FwYWJsZSBhIHByaW9yaS4gU28gSSB0aGluayB0aGlzIHJlY29tbWVuZGF0aW9u IG91Z2h0IHRvIGJlIHJlbW92ZWQsIG9yIHBlcmhhcHMgdHVybmVkIGludG8gc29tZSBzb3J0IG9m IHJlY29tbWVuZGF0aW9uIGZvciBUVVJOIHNlcnZlciBkZXZlbG9wZXJzIChlLmcuIFRVUk4gc2Vy dmVycyBTSE9VTEQgc3VwcG9ydCBUTFMvRFRMUywgU0hPVUxEIHN1cHBvcnQgbW9iaWxpdHksIFNI T1VMRCBzdXBwb3J0IHJlZGlyZWN0KSwgcHJvYmFibHkgaW4gYSBzZXBhcmF0ZSBkb2MuDQoNClRo ZXNlIHJlY29tbWVuZGF0aW9ucyBzaG91bGQgcmVkdWNlIHRoZSBzaXplIG9mIHRoaXMgZG9jdW1l bnQgYW5kIHByb3ZpZGUgbXVjaCBjbGVhcmVyIGFkdmljZSB0byBhcHAgZGV2ZWxvcGVycy4NCg0K --_000_913383AAA69FF945B8F946018B75898A3552A3CBxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5lIFtUUl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEphbnVhcnkgMTEsIDIwMTUgMjox NyBBTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxi PkNjOjwvYj4gdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIENv bW1lbnRzIG9uIGRyYWZ0LXBhdGlsLXRyYW0tdHVybi1zZXJ2LXNlbGVjdGlvbi0wMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiA5LCAyMDE1IGF0 IDc6MzggUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0 bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1 c3Rpbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5FbnRlcnByaXNlLXByb3ZpZGVkIFRVUk4gc2VydmVyIGNhbm5v dCBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kgbWF5IG5vdCBiZSBhbHdheXMgdHJ1ZS4gRm9yIGV4 YW1wbGUNCiBFbnRlcnByaXNlIG5ldHdvcmsgY291bGQgdXNlIFRVUk4gc2VydmVyIHByb3ZpZGVk IGJ5IGEgY2xvdWQgc2VydmljZSBhbmQgdGhlIHVzZXIgbmVlZHMgdG8ga25vdyB0aGF0IHRoZSBF bnRlcnByaXNlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kgYW5kIG5v dCBwcm9jZWVkIHdpdGggVFVSTi1pbi1UVVJOLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Ugd2lsbCBoYXZl IHRvIGRpc2N1c3MgaWYgVFVSTiBzZXJ2ZXIgY2FuIGFkdmVydGlzZSB0aGF0IGl0IGNhbiBwcm92 aWRlIGxvY2F0aW9uIHByaXZhY3kgaW4gYSBuZXcNCiBhdHRyaWJ1dGUgb3IgdGhpcyBpbmZvIGNh biBiZSBjb252ZXllZCBvdXQtb2YtYmFuZCAoZS5nLiBQQUMpLjwvc3Bhbj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3RoZXIgcHJv YmxlbSBub3QgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCBpcywgd2hhdCBpZiB0aGUgdXNlciB3YW50 cyBwcml2YWN5IGFnYWluc3QgdGhlIGNhbGxpbmcNCiBzaXRlIGFuZCBsZXTigJlzIHNheSB1c2Vz IFRvciBmb3IgcHJpdmFjeS4gSW4gdGhpcyBzY2VuYXJpbyBhcHAgVFVSTiBzZXJ2ZXIgbXVzdCBu b3QgYmUgc2VsZWN0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJFVFVSTiBoYW5kbGVz IHRoaXMgc2l0dWF0aW9uIGZpbmUsIHNpbmNlIHRoZSB0cmFmZmljIHdpbGwgYmUgcm91dGVkIHRo cm91Z2ggdGhlIG5ldHdvcmstcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgYmVmb3JlIGJlaW5nIHJvdXRl ZCB0byB0aGUgYXBwIFRVUk4gc2VydmVyLiBPZiBjb3Vyc2UsIGlmIHRoZSBhcHBsaWNhdGlvbiBk b2VzIG5vdCB0cnkgdG8gcHJvdmlkZSBsb2NhdGlvbiBwcml2YWN5LCBvbmx5IHRoZSBuZXR3b3Jr LXByb3ZpZGVkDQogVFVSTiBzZXJ2ZXIgd2lsbCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltU Ul0gQnV0IHRoZSBwcm9ibGVtIGlzIGhvdyB3aWxsIHRoZSBlbmRwb2ludCBob3cgaWYgbmV0d29y ay1wcm92aWRlZCBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBsb2NhdGlvbiBwcml2YWN5IG9yIG5v dCA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VFVSTiBzZXJ2ZXIgY2FuIGNvbnZleSB0 aGlzIGluZm9ybWF0aW9uIGluIGEgbmV3IFNUVU4gYXR0cmlidXRlIHRvIHRoZSBjbGllbnQuPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgSSB0 aGluayB0aGUgdXNlciBpcyBtdWNoIG1vcmUgbGlrZWx5IHRvIHRydXN0IHRoZSBhcHBsaWNhdGlv biB0aGFuIGl0cyBuZXR3b3JrIHByb3ZpZGVyIHRvIHByb3ZpZGUgcHJpdmFjeSBwcm90ZWN0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPltUUl0gVXNlciBtYXkgb3IgbWF5IG5vdCB0cnVzdCB0aGUgYXBw bGljYXRpb24gc2VydmVyLiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0xMCI+DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0xMDwvYT4gZGlzY3Vzc2VzIHVz ZXJzIHVzaW5nIHByaXZhY3kgdGVjaG5pcXVlcyBsaWtlIFRvciBzbyB0aGF0IGFwcCBzZXJ2ZXIg ZG9lcyBub3QgbGVhcm4gdGhlIHVzZXIncyBJUCBhZGRyZXNzLiBUaGUgUG9rZXIgZXhhbXBsZSBn aXZlbiBpbiB0aGUgYWJvdmUgZHJhZnQgZXhwbGFpbnMgdGhhdCB0aGUgdXNlcnMgaW4gdGhlIGNh bGwgZG8gbm90DQogdHJ1c3QgdGhlIGNhbGxpbmcgc2VydmljZS4gSW4gdGhpcyBjYXNlIElkUCBl bnN1cmVzIHRoYXQgZXZlbiBpZiBtYWxpY2lvdXMgY2FsbGluZyBzZXJ2aWNlIHJlcGxhY2VzIHRo ZSBtZWRpYSBhZGRyZXNzZXMgd2l0aCBpdHMgb3duIGFkZHJlc3NlcyZuYnNwOyBhbmQgcmVwbGFj ZXMgdGhlIGNlcnRpZmljYXRlIGZpbmdlcnByaW50IGluIFNEUCB3aXRoIGl0cyBvd24gY2VydGlm aWNhdGUsIElkUCBhc3NlcnRpb24gd291bGQgZW5zdXJlIHRoYXQgdGhlIFBva2VyDQogc2l0ZSBj YW5ub3QgYWN0IGFzICZuYnNwO21hbi1pbi1taWRkbGUgZGV2aWNlLiBJbiB0aGlzIHNjZW5hcmlv IHVzZXIgbWF5IG5vdCB3YW50IHRvIHBpY2sgYXBwIHByb3ZpZGVkIFRVUk4gc2VydmVyLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tVGlydTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg SmFudWFyeSAwOSwgMjAxNSA0OjA0IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vy di1zZWxlY3Rpb24tMDA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkF0IElFVEYgOTEsIEkgcHJvbWlzZWQgdG8gc2VuZCBmZWVkYmFjayBv biB0aGlzIGRvY3VtZW50LCBzbyBoZXJlIGdvZXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R2VuZXJhbGx5LCBJIHRoaW5rIG1hbnkgb2YgdGhlIGlz c3VlcyBtZW50aW9uZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgaW1wb3J0YW50LCBidXQgdGhlIHJl Y29tbWVuZGF0aW9ucyBhcmUgY29uZnVzaW5nIGFuZCBwb3NzaWJseSBjb250cmFkaWN0b3J5OyBh IGRldmVsb3BlciB3aXRoIGxpdHRsZSBrbm93bGVkZ2UNCiBvZiBUVVJOIHdpbGwgaGF2ZSBhIGhh cmQgdGltZSBmaWd1cmluZyBvdXQgZXhhY3RseSB3aGF0IHRvIGRvLiBGdXJ0aGVybW9yZSwgbWFu eSBvZiB0aGUgcHJvcGVydGllcyBkaXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgZHluYW1p YywgYW5kIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSBJQ0UgcHJvY2VzcywgcmF0aGVyIHRoYW4g aW4gVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIChmb3IgZXhhbXBsZSwgdGhlIG5vdGlvbiBvZiBSVFQg YXMgaXQNCiByZWxhdGVzIHRvIHVzZXIgZXhwZXJpZW5jZSkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZWZvcmUsIEkgdGhpbmsg dGhpcyBkb2N1bWVudCBzaG91bGQgdGFrZSBhIHN0cm9uZ2VyIHN0YW5jZSBhbmQgcHV0IGZvcnRo IGV4cGxpY2l0IGJlc3QgcHJhY3RpY2VzIGZvciBzZWxlY3Rpb24gKGFzIG9wcG9zZWQgdG8gJnF1 b3Q7dGhpbmdzIHRvIGNvbnNpZGVyJnF1b3Q7KSwgZm9yIG5vbi1keW5hbWljIHByb3BlcnRpZXMs DQogYW5kIGxlYXZlIHRoZSBkZWNpc2lvbnMgb24gZHluYW1pYyBwcm9wZXJ0aWVzIHRvIGJlIHJl c29sdmVkIGJ5IElDRS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBleGFtcGxlLCBJIHRoaW5rIHdlIHNob3VsZCBvbWl0 IHRoZSB0ZXh0IGluIFNlY3Rpb24gMyBhYm91dCB3aGF0IHRvIGRvIHdpdGggbm9uLXdvcmtpbmcg VFVSTiBzZXJ2ZXJzLCBhbmQgbWVhc3VyaW5nIFJUVC4gU2FtZSBmb3IgU2VjdGlvbiAzLjMsIHdo aWNoIGFsc28gZGlzY3Vzc2VzIFJUVCwgYW5kDQogU2VjdGlvbiAzLjQsIHdoaWNoIHRhbGtzIGFi b3V0IG11bHRpcGxlIGludGVyZmFjZXMuIFRoaXMgY2FuIGFsbCBiZSBoYW5kbGVkIGJ5IElDRS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkluIGFkZGl0aW9uLCB0aGUgc2VjdGlvbnMgb24gbG9jYWwgY29uZmlnIGFuZCBsb2NhdGlvbiBw cml2YWN5IGFyZSB1bm5lY2Vzc2FyeSB3aGVuIFJFVFVSTiBpcyB1c2VkLiBXaGVuIFJFVFVSTiBp cyB1c2VkLCB0aGUgYXBwbGljYXRpb24gY2FuIGFsd2F5cyB1c2UgdGhlIGFwcCBUVVJOIHNlcnZl ciBmb3IgbG9jYXRpb24NCiBwcml2YWN5LCBhbmQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGxv Y2FsIFRVUk4gc2VydmVyIGFuZCBhcHAgVFVSTiBzZXJ2ZXIgaXMgZnVsbHkgc3BlbGxlZCBvdXQs IHNvIHRoZXJlIGlzIG5vdGhpbmcgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNpZGUgb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGlzIGxlYXZlcyBvbmx5IHRoZSBTZWN1cml0eSwgQXV0aGVudGljYXRpb24sIGFuZCBNb2JpbGl0 eSBzZWN0aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkZvciBzZWN1cml0eSwgSSB0aGluayB3ZSBjYW4gZ2l2ZSBzb21l IGNsZWFyIGd1aWRhbmNlIG9uIHdoYXQgYXBwbGljYXRpb25zIHNob3VsZCBkby4gRm9yIHNlY3Vy aXR5LCBJIHRoaW5rIHRoZSBndWlkYW5jZSBzaG91bGQgYmUgdG8gdXNlIG9ubHkgRFRMUyAmIzQz OyBUTFMsIGlmIGJvdGggYXJlIGF2YWlsYWJsZSwNCiB3aXRoIGZhbGxiYWNrIHRvIFVEUCBvciBU Q1AgaWYgRFRMUyBvciBUTFMgYXJlbid0IGF2YWlsYWJsZS4gSWYgcHJpdmFjeSBpcyBwYXJhbW91 bnQsIFVEUC9UQ1AgZmFsbGJhY2sgbWF5IGJlIGNvbnRyYWluZGljYXRlZCwgYnV0IGF0IHRoaXMg cG9pbnQgaW4gdGltZSwgRFRMUyBkZXBsb3ltZW50IGlzbid0IHdpZGVzcHJlYWQgZW5vdWdoIHRv IHRydWx5IHJlY29tbWVuZCB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyByZWxhdGVzIHRvIHRoZSBBdXRoZW50aWNhdGlv biBzZWN0aW9uIC0gYnV0IEkgdGhpbmsgYW55IGZhaWx1cmVzIHRvIGF1dGhlbnRpY2F0ZSB0aGUg c2VydmVyIGNlcnQgc2hvdWxkIGNhdXNlIHRoZSBUVVJOIGFsbG9jYXRpb24gdG8gZmFpbC4gVGhp cyBpcyBqdXN0IGxpa2UgYW55IG90aGVyIG1pc2NvbmZpZ3VyYXRpb24NCiBvbiB0aGUgVFVSTiBz ZXJ2ZXIgLSB0aGVyZSdzIG5vIHJlYXNvbiB3ZSBzaG91bGQgZXZlbiBhbGxvdyB1c2Ugb2YgVFVS TiBzZXJ2ZXJzIHdob3NlIGNlcnQgY2hhaW5zIGRvbid0IHZhbGlkYXRlLiBTbywgdGhpcyBzZWN0 aW9uIGNvdWxkIHByb2JhYmx5IGJlIHJlbW92ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5MYXN0bHksIHRoZSBNb2JpbGl0eSBzZWN0 aW9uIHNheXMgdGhhdCBpZiAmcXVvdDthbGwgb3RoZXIgcGFyYW1ldGVycyBbYXJlXSBlcXVhbCZx dW90OywgYSBUVVJOIHNlcnZlciB3aXRoIG1vYmlsaXR5IHNob3VsZCBiZSB1c2VkLiBDbGVhcmx5 LCBhbGwgb3RoZXIgcGFyYW1ldGVycyB3aWxsIG5vdCBiZSBlcXVhbCAoZS5nLiBSVFQpLA0KIGFu ZCBldmVuIGlmIHRoZXkgd2VyZSwgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRvIGtub3cgaWYgYSBz ZXJ2ZXIgaXMgbW9iaWxpdHktY2FwYWJsZSBhIHByaW9yaS4gU28gSSB0aGluayB0aGlzIHJlY29t bWVuZGF0aW9uIG91Z2h0IHRvIGJlIHJlbW92ZWQsIG9yIHBlcmhhcHMgdHVybmVkIGludG8gc29t ZSBzb3J0IG9mIHJlY29tbWVuZGF0aW9uIGZvciBUVVJOIHNlcnZlciBkZXZlbG9wZXJzIChlLmcu IFRVUk4gc2VydmVycyBTSE9VTEQgc3VwcG9ydA0KIFRMUy9EVExTLCBTSE9VTEQgc3VwcG9ydCBt b2JpbGl0eSwgU0hPVUxEIHN1cHBvcnQgcmVkaXJlY3QpLCBwcm9iYWJseSBpbiBhIHNlcGFyYXRl IGRvYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZXNlIHJlY29tbWVuZGF0aW9ucyBzaG91bGQgcmVkdWNlIHRoZSBzaXplIG9mIHRo aXMgZG9jdW1lbnQgYW5kIHByb3ZpZGUgbXVjaCBjbGVhcmVyIGFkdmljZSB0byBhcHAgZGV2ZWxv cGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A3552A3CBxmbrcdx10ciscoc_-- From nobody Sun Jan 11 16:43:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF401A8873 for ; Sun, 11 Jan 2015 16:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 MVeyITG6pphV for ; Sun, 11 Jan 2015 16:43:33 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id C686C1A8876 for ; Sun, 11 Jan 2015 16:43:32 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CrDABIA7NU27y6AA==.35384S4; Mon, 12 Jan 2015 07:12:26 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> In-Reply-To: <54B00B30.20508@akamai.com> Date: Mon, 12 Jan 2015 08:43:03 +0800 Message-ID: <008b01d02e00$c1be3450$453a9cf0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAsIpyBh5KYDBvJQli6KyIdPyzPPAB2zXVQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06CrDABIA7NU27y6AA==.35384S4 X-Coremail-Antispam: 1U3129KBjvJXoWxZr1ftryxKF4DXryrWFW5trb_yoW5XF18pr WYgrWftF1DJr4xGrsavr4I9F1Y9395XFW3Wr1Utw1fua95XFyayFyjgr4jg348Cr18Wa4Y vF4Yv3W7u3Z0yrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 00:43:35 -0000 Hi, Brandon: In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, it is described as below: When forming a Send indication, the client MUST include an XOR-PEER- ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS attribute contains the transport address of the peer to which the data is to be sent, and the DATA attribute contains the actual application data to be sent to the peer. So, there is no XOR-RELAYED-ADDRESS attribute included to identify the peer's allocated relay address. On the other hand, XOR-RELAYED-ADDRESS is mainly refer to the requester's allocated relay address, not the corresponding peer. Will we define again one new attribute, such as XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's information? Even if so, what will be the source address for the packet from the second TURN server to destination peer? If we use the XOR-RELAYED-ADDRESS, then the return packet from the peer will be passed back directly to the first TURN server, results in non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what is the source address for the packet from the second TURN server back to the first TURN server? Best Regards. > -----Original Message----- > From: Brandon Williams [mailto:bowill@akamai.com] > Sent: Saturday, January 10, 2015 1:09 AM > To: Aijun Wang; tram@ietf.org > Subject: Re: [tram] Fwd: New Version Notification for > draft-williams-peer-redirect-02.txt > > By relay address, I mean the XOR-RELAYED-ADDRESS returned in the allocation > request. This clearly identifies the true source and destination for the data in > the packet as well as the two relay servers involved. If both relayed addresses > are on the same server, it will of course know that and be able to optimize as > Simon indicated in an earlier e-mail. > > --Brandon > > On 01/08/2015 09:40 PM, Aijun Wang wrote: > > > > [Aijun]: There are two relay address, one is the TURN server > > well-known address, another is the relay address that allocated to > > each client. Which one should be used then? On the other hand, when > > client want to send traffic to other peer, it does not know whether > > the other part is under the same TURN server or not, how do it select this > information? > > > > > > > [Aijun]: as the definition in > > http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, > > the XOR-PEER-ADDRESS is the address seen from the TURN server, so it > > can't be used to find the relay address of the remote peer, and then > > can't be used to direct traffic to downstream relay. > > > > > > > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Sun Jan 11 17:38:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21791A89EB for ; Sun, 11 Jan 2015 17:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 T6nWo-7C2CxM for ; Sun, 11 Jan 2015 17:38:34 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBCD1A89D3 for ; Sun, 11 Jan 2015 17:38:31 -0800 (PST) Received: from ctbriwangaij (unknown [124.127.116.138]) by app1 (Coremail) with SMTP id Z0GX06DbGQEgELNUF5q7AA==.36612S4; Mon, 12 Jan 2015 08:07:24 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A3552A0EE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552A3CB@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552A3CB@xmb-rcd-x10.cisco.com> Date: Mon, 12 Jan 2015 09:37:51 +0800 Message-ID: <008c01d02e08$6f42a8c0$4dc7fa40$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01D02E4B.7D65E8C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAshuX6BWxLj30LTtKRU8H8RSyoSQAwgn0AAAWwpiAAKacIYA== Content-Language: zh-cn X-CM-TRANSID: Z0GX06DbGQEgELNUF5q7AA==.36612S4 X-Coremail-Antispam: 1U3129KBjvJXoW3WF17Gw17Cw15KrW3KFy5CFg_yoWxXF47pF W3uryay34kJr1xAw4UZa18uF1S9395WrZrJr98Gr17Z39xJr1Ivrnrtay5CFy7GrykGFyY vrWjv3Z8Z3WrAFJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JURE__UUUUU= Archived-At: Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 01:38:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008D_01D02E4B.7D65E8C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Reddy and Justin: =20 I suggest the TURN server selection should be made by ICE, not the = client itself. This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision. =20 There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc. =20 Best Regards. =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) Sent: Sunday, January 11, 2015 1:40 PM To: Justin Uberti Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Inline [TR] =20 From: Justin Uberti [mailto:juberti@google.com]=20 Sent: Sunday, January 11, 2015 2:17 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) = wrote: Hi Justin, =20 Enterprise-provided TURN server cannot provide location privacy may not = be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.=20 =20 We will have to discuss if TURN server can advertise that it can provide = location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC).=20 =20 The other problem not discussed in the draft is, what if the user wants = privacy against the calling site and let=E2=80=99s say uses Tor for = privacy. In this scenario app TURN server must not be selected. =20 RETURN handles this situation fine, since the traffic will be routed = through the network-provided TURN server before being routed to the app = TURN server. Of course, if the application does not try to provide = location privacy, only the network-provided TURN server will be used. =20 [TR] But the problem is how will the endpoint how if network-provided = TURN server can provide location privacy or not ? TURN server can convey this information in a new STUN attribute = to the client. =20 However, I think the user is much more likely to trust the application = than its network provider to provide privacy protection. =20 [TR] User may or may not trust the application server. = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses = users using privacy techniques like Tor so that app server does not = learn the user's IP address. The Poker example given in the above draft = explains that the users in the call do not trust the calling service. In = this case IdP ensures that even if malicious calling service replaces = the media addresses with its own addresses and replaces the certificate = fingerprint in SDP with its own certificate, IdP assertion would ensure = that the Poker site cannot act as man-in-middle device. In this = scenario user may not want to pick app provided TURN server. =20 -Tiru =20 =20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Friday, January 09, 2015 4:04 AM To: tram@ietf.org Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 At IETF 91, I promised to send feedback on this document, so here goes. =20 Generally, I think many of the issues mentioned in this document are = important, but the recommendations are confusing and possibly = contradictory; a developer with little knowledge of TURN will have a = hard time figuring out exactly what to do. Furthermore, many of the = properties discussed in this document are dynamic, and should be handled = by the ICE process, rather than in TURN server selection (for example, = the notion of RTT as it relates to user experience). =20 Therefore, I think this document should take a stronger stance and put = forth explicit best practices for selection (as opposed to "things to = consider"), for non-dynamic properties, and leave the decisions on = dynamic properties to be resolved by ICE.=20 =20 For example, I think we should omit the text in Section 3 about what to = do with non-working TURN servers, and measuring RTT. Same for Section = 3.3, which also discusses RTT, and Section 3.4, which talks about = multiple interfaces. This can all be handled by ICE. =20 In addition, the sections on local config and location privacy are = unnecessary when RETURN is used. When RETURN is used, the application = can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide on. =20 This leaves only the Security, Authentication, and Mobility sections.=20 =20 For security, I think we can give some clear guidance on what = applications should do. For security, I think the guidance should be to = use only DTLS + TLS, if both are available, with fallback to UDP or TCP = if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend this. =20 This relates to the Authentication section - but I think any failures to = authenticate the server cert should cause the TURN allocation to fail. = This is just like any other misconfiguration on the TURN server - = there's no reason we should even allow use of TURN servers whose cert = chains don't validate. So, this section could probably be removed. =20 Lastly, the Mobility section says that if "all other parameters [are] = equal", a TURN server with mobility should be used. Clearly, all other = parameters will not be equal (e.g. RTT), and even if they were, the = client has no way to know if a server is mobility-capable a priori. So I = think this recommendation ought to be removed, or perhaps turned into = some sort of recommendation for TURN server developers (e.g. TURN = servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support = redirect), probably in a separate doc. =20 These recommendations should reduce the size of this document and = provide much clearer advice to app developers. =20 ------=_NextPart_000_008D_01D02E4B.7D65E8C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Reddy and Justin:

 

I suggest the TURN server selection should be made by ICE, not the = client itself.=C2=A0 This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision.

 

There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc.

 

Best Regards.

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Sunday, January 11, 2015 1:40 PM
To: = Justin Uberti
Cc: tram@ietf.org
Subject: Re: [tram] = Comments on = draft-patil-tram-turn-serv-selection-00

=

 

Inline [TR]

 

From:= Justin = Uberti [mailto:juberti@google.com] =
Sent: Sunday, January 11, 2015 2:17 AM
To: = Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: = [tram] Comments on = draft-patil-tram-turn-serv-selection-00

=

 

 

 

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy = (tireddy) <tireddy@cisco.com> = wrote:

Hi Justin,

 

Enterprise-provided TURN server cannot provide location privacy may = not be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.

 

We will have to discuss if TURN server can advertise that it can = provide location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC). 

 

The other problem not discussed in the draft is, what if the user = wants privacy against the calling site and let=E2=80=99s say uses Tor = for privacy. In this scenario app TURN server must not be = selected.

 

RETURN handles this situation fine, = since the traffic will be routed through the network-provided TURN = server before being routed to the app TURN server. Of course, if the = application does not try to provide location privacy, only the = network-provided TURN server will be used.

 

[TR] But the problem is how will the endpoint how if = network-provided TURN server can provide location privacy or not = ?

         TURN = server can convey this information in a new STUN attribute to the = client.

 

However, I think the user is much = more likely to trust the application than its network provider to = provide privacy protection.

 

[TR] User may or may not trust the application server. h= ttps://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 = discusses users using privacy techniques like Tor so that app server = does not learn the user's IP address. The Poker example given in the = above draft explains that the users in the call do not trust the calling = service. In this case IdP ensures that even if malicious calling service = replaces the media addresses with its own addresses  and replaces = the certificate fingerprint in SDP with its own certificate, IdP = assertion would ensure that the Poker site cannot act as =  man-in-middle device. In this scenario user may not want to pick = app provided TURN server.

 

-Tiru

 

 

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Friday, January 09, 2015 4:04 AM
To: tram@ietf.org
Subject: [tram] Comments = on draft-patil-tram-turn-serv-selection-00

 

At IETF 91, I promised to send feedback on this document, = so here goes.

 

Generally, I think many of the issues mentioned in this = document are important, but the recommendations are confusing and = possibly contradictory; a developer with little knowledge of TURN will = have a hard time figuring out exactly what to do. Furthermore, many of = the properties discussed in this document are dynamic, and should be = handled by the ICE process, rather than in TURN server selection (for = example, the notion of RTT as it relates to user = experience).

 

Therefore, I think this document should take a stronger = stance and put forth explicit best practices for selection (as opposed = to "things to consider"), for non-dynamic properties, and = leave the decisions on dynamic properties to be resolved by = ICE. 

 

For example, I think we should omit the text in Section 3 = about what to do with non-working TURN servers, and measuring RTT. Same = for Section 3.3, which also discusses RTT, and Section 3.4, which talks = about multiple interfaces. This can all be handled by = ICE.

 

In addition, the sections on local config and location = privacy are unnecessary when RETURN is used. When RETURN is used, the = application can always use the app TURN server for location privacy, and = the relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide = on.

 

This leaves only the Security, Authentication, and Mobility = sections. 

 

For security, I think we can give some clear guidance on = what applications should do. For security, I think the guidance should = be to use only DTLS + TLS, if both are available, with fallback to UDP = or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend = this.

 

This relates to the Authentication section - but I think = any failures to authenticate the server cert should cause the TURN = allocation to fail. This is just like any other misconfiguration on the = TURN server - there's no reason we should even allow use of TURN servers = whose cert chains don't validate. So, this section could probably be = removed.

 

Lastly, the Mobility section says that if "all other = parameters [are] equal", a TURN server with mobility should be = used. Clearly, all other parameters will not be equal (e.g. RTT), and = even if they were, the client has no way to know if a server is = mobility-capable a priori. So I think this recommendation ought to be = removed, or perhaps turned into some sort of recommendation for TURN = server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD = support mobility, SHOULD support redirect), probably in a separate = doc.

 

These recommendations should reduce the size of this = document and provide much clearer advice to app = developers.

 

------=_NextPart_000_008D_01D02E4B.7D65E8C0-- From nobody Sun Jan 11 21:08:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7A11A8844 for ; Sun, 11 Jan 2015 21:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kVTTDgm05RuT for ; Sun, 11 Jan 2015 21:08:51 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0FA1A1A23 for ; Sun, 11 Jan 2015 21:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19656; q=dns/txt; s=iport; t=1421039331; x=1422248931; h=from:to:cc:subject:date:message-id:mime-version; bh=Lif+e+uUNeYoTW0/ItCEVF3GbJ4qP1uKU1KeLsp1eCs=; b=AUrK+yXjDqld6ztOwpdBqGPjq9VGTVLl+HC4h3YC/xeaIrMjuwiali0F sBY86bBl1XxSp0T91zbeCj1bEvULNl1oA6U/mNQZowbC3Sb0m4N3/uAYz hh5yzs6J8Kn4KK+PWUdFna9t8tm4lqYR5Ist5nwFi8ntZBfuj4gd8AIEz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcHAPdVs1StJV2a/2dsb2JhbABbgkNDUlgEgwHAUoIbAQmFcQIcckMBAQEBAX2EDAEBAQQBAQEgCkELEgEIDgMEAQELHQMCBB8GCxQJCQEEAQ0FCIgQAxENtz6PNA2DWgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjU+BeS0EBgeCYi6BEwWEOwKKAIdJglOLCIIngzoig25vgQMkHn4BAQE X-IronPort-AV: E=Sophos;i="5.07,741,1413244800"; d="scan'208,217";a="386164213" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jan 2015 05:08:50 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0C58oFT015465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 05:08:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 11 Jan 2015 23:08:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti , Oleg Moskalenko Thread-Topic: [tram] SSODA in TURN-bis Thread-Index: AdAuJda+25AKc4h/S+aWW1oBlMrfVw== Date: Mon, 12 Jan 2015 05:08:49 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.169] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552A58Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , Aijun Wang , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 05:08:56 -0000 --_000_913383AAA69FF945B8F946018B75898A3552A58Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QUREUkVTUy1FUlJPUi1DT0RFIHNlZW1zIHVzZWZ1bCwgY2xpZW50IGNhbiBkZXRlcm1pbmUgaWYg aXTigJlzIGEgdGVtcG9yYXJ5IG9yIGxvbmctdGVybSBlcnJvci4NCg0KLVRpcnUNCg0KRnJvbTog SnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NClNlbnQ6IFNhdHVyZGF5 LCBKYW51YXJ5IDEwLCAyMDE1IDI6MTkgQU0NClRvOiBPbGVnIE1vc2thbGVua28NCkNjOiBTaW1v biBQZXJyZWF1bHQ7IEFpanVuIFdhbmc7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IHRy YW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXMNCg0KT0ss IHNvIHdlIGhhdmUgY2xlYXIgZXZpZGVuY2UgdGhhdCBzb21lIGRlcGxveWVkIHNlcnZlcnMgd2ls bCBmYWlsIChkZXRlcm1pbmlzdGljYWxseSwgZm9ydHVuYXRlbHkpIG9uIHRoZSBjdXJyZW50IFNT T0RBIHByb3Bvc2FsLg0KDQpTbyB3ZSdyZSBiYWNrIHRvIHdoaWNoIGJhY2t3YXJkcy1jb21wYXRp YmxlIG9wdGlvbiB3ZSB3YW50IHRvIHB1cnN1ZS4gSSBzdWdnZXN0IGMpLCB3aGljaCBpcyB0aGUg b3B0aW9uYWwtY29tcHJlaGVuc2lvbiBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZLg0KDQpTZXBh cmF0ZWx5LCB3ZSBuZWVkIHRvIGRlY2lkZSB3aGV0aGVyIHdlIHdhbnQgdG8gcHVyc3VlIGlzc3Vl ICMyIHRoYXQgSSBpZGVudGlmaWVkIHByZXZpb3VzbHksIGkuZS4sIGFsbG93aW5nIHNwZWNpZmlj IGVycm9yIGNvZGVzIHRvIGJlIHJldHVybmVkIGZvciBlYWNoIGFkZHJlc3MgZmFtaWx5Lg0KDQpP biBGcmksIEphbiA5LCAyMDE1IGF0IDEwOjUzIEFNLCBPbGVnIE1vc2thbGVua28gPG1vbTA0MDI2 N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+PiB3cm90ZToNCkkgZG91Ymxl LWNoZWNrZWQgdGhhdCB3aXRoIGEgcmVhbCB0ZXN0LiBJIHJhbiB0aGUgY29UdXJuIHRlc3QgY2xp ZW50ICh0aGF0IGltcGxlbWVudHMgZXhwZXJpbWVudGFsIFNTT0RBIGRyYWZ0IHdpdGggdHdvIFJB RiBhdHRyaWJ1dGVzKSBhZ2FpbnN0IHJmYzU3NjYtdHVybi1zZXJ2ZXIgYW5kIHRoZSBzZXJ2ZXIg eWllbGRlZCBlcnJvciA0MDAgd2l0aCB0aGUgbWVzc2FnZSAiT25seSBvbmUgYWRkcmVzcyBmYW1p bHkgYXR0cmlidXRlIGNhbiBiZSB1c2VkIGluIGEgcmVxdWVzdCINCg0KOigNCkFzIEkgc2FpZCwg SSBjYW4gZWxpbWluYXRlIHRoYXQgcHJvYmxlbSBpbiB0aGUgc3Vic2VxdWVudCByZmM1NzY2LXR1 cm4tc2VydmVyIG1haW50ZW5hbmNlIHJlbGVhc2VzLCBidXQgc3RpbGwuLi4NCkkgYW0gc29ycnkg dGhhdCBJIGRpZCBub3QgZGlzY292ZXIgdGhhdCBwcmV2aW91c2x5IGFuZCB0aGF0IEkgYWR2b2Nh dGVkIGFuIGluY29tcGF0aWJsZSBpbXBsZW1lbnRhdGlvbiBvcHRpb24uDQpTbywgaWYgdGhlIFdH IGluc2lzdHMgb24gYSBiYWNrd2FyZC1jb21wYXRpYmxlIHByb3RvY29sIGluIGFsbCBzZW5zZXMs IHRoZW4gd2UgaGF2ZSB0byBjaG9vc2UgYW5vdGhlciBvcHRpb24uDQpUaGFua3MNCk9sZWcNCg0K DQpPbiBGcmksIEphbiA5LCAyMDE1IGF0IDEwOjAxIEFNLCBPbGVnIE1vc2thbGVua28gPG1vbTA0 MDI2N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+PiB3cm90ZToNCkkgY2hl Y2tlZCB0aGUgY29kZSBvZiByZmM1NzY2LXR1cm4tc2VydmVyIGFnYWluLCBhbmQgSSBmb3VuZCB0 aGF0IGl0IHdpbGwgTk9UIGhhbmRsZSB0aGUgbXVsdGlwbGUtUkFGIGNhc2UuIEl0IHdpbGwgcmV0 dXJuIDQwMCBlcnJvciB3aXRoIHRoZSBtZXNzYWdlICJPbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBh dHRyaWJ1dGUgY2FuIGJlIHVzZWQgaW4gYSByZXF1ZXN0Ii4gQXQgbGVhc3QsIGl0J3MgYmVlbiB0 aGF0IHdheSBpbiB0aGUgMjAxNCByZWxlYXNlcy4gSSBkaWQgbm90IGNoZWNrIHRoZSBvbGRlciBy ZWxlYXNlcy4NClNvcnJ5IHRoYXQgSSBwcm92aWRlZCBhIHdyb25nIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBpbXBsZW1lbnRhdGlvbiwgYmVmb3JlLg0KSSBjYW4gZml4IHRoYXQgY29kZSBidXQgc3Rp bGwgdGhlcmUgYXJlIHBlb3BsZSBvdXQgdGhlcmUgd2hvIHdpbGwgYmUgdXNpbmcgdGhlICJ3cm9u ZyIgdmVyc2lvbnMuDQpTbywgaWYgd2UgZG8gaGF2ZSB0byBiZSBhYnNvbHV0ZWx5IGJhY2t3YXJk IGNvbXBhdGlibGUgdGhlbiB3ZSBoYXZlIHRvIHVzZSBhIGRpZmZlcmVudCBvcHRpb24uLi4NCk9s ZWcNCg0KDQpPbiBGcmksIEphbiA5LCAyMDE1IGF0IDk6MzQgQU0sIEp1c3RpbiBVYmVydGkgPGp1 YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQpJIHJl dmlld2VkIHRoZSBjb2RlIGZvciByZXN0dW5kLCByZVR1cm4sIGFuZCByZmM1NzY2LXR1cm4tc2Vy dmVyIGFuZCB0aGV5IGFsbCBhcHBlYXIgdG8gaGFuZGxlIFJBRiAoYW5kIG11bHRpcGxlIFJBRikg T0suDQoNClRoZSBwcm9ibGVtLCBhcyBJIHNlZSBpdCwgaXMgdGhhdCB0aGVyZSBtYXkgYmUgb3Ro ZXIgVFVSTiBzZXJ2ZXJzLCBwZXJoYXBzIG5vbi1vcGVuLXNvdXJjZSBvbmVzLCB0aGF0IHdvcmsg ZmluZSB0b2RheSB3aXRoIENocm9tZSwgYnV0IHdpbGwgc3RhcnQgcmV0dXJuaW5nIGVycm9ycyB3 aGVuIHdlIGluY2x1ZGUgUkFGIG9yIG11bHRpcGxlIFJBRiwgYW5kIHNvIG1ha2luZyB0aGlzIGNo YW5nZSBtYXkgYnJlYWsgc29tZSBzbWFsbCBudW1iZXIgb2YgYXBwcyAod2hvIHdpbGwgdGhlbiBi bGFtZSBDaHJvbWUpLiBXZSBqdXN0IGRvbid0IGtub3cgd2hhdCBpcyBvdXQgdGhlcmUuDQoNCg0K DQpPbiBGcmksIEphbiA5LCAyMDE1IGF0IDY6MTEgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3BlcnJl YXVsdEBqaXZlLmNvbTxtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT4+IHdyb3RlOg0KDQpPbiBG cmksIEphbiA5LCAyMDE1IGF0IDQ6MTcgQU0sIEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1 YS5vcmcuY248bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCkFmdGVy IHlvdXIgZGV0YWlsIGFuYWx5c2lzIGFuZCB0aGUgc2VudGVuY2Ug4oCcRm9yIGVpdGhlciBiL2Ms IHdlIHdvdWxkIG5lZWQgdG8gc2F5IHRoYXQgaW5jbHVkaW5nIGJvdGggUkFGIGFuZCBPQUYvQUFG IGZvciB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSBpcyBwcm9oaWJpdGVkLuKAnSwgSSB0aGluayBp dCBtYXkgYmUgYmV0dGVyIHRvIGtlZXAgb25seSBvbmUgYXR0cmlidXRlIHRvIGZ1bGZpbGwgdGhl IFNTT0RBIHJlcXVpcmVtZW50Pw0KDQpUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IFNTT0RB IGZ1bmN0aW9uYWxpdHkgYmUgcmVhbGl6ZWQgd2l0aCBvbmx5IG9uZSBhdHRyaWJ1dGUsIG5vciB0 aGF0IHRoZSBwcm90b2NvbCBiZSBlbGVnYW50LCBub3IgdGhhdCBpdCBleGhpYml0cyBzeW1tZXRy eSB0aGF0IGlzIHBsZWFzaW5nIHRvIHRoZSBleWUuDQoNClRoZXJlICppcyogYSByZXF1aXJlbWVu dCB0aGF0IGl0IGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHRob3VnaC4gV2hldGhlciB0aGF0IG1l YW5zIGNvbXBhdGlibGUgd2l0aCB0aGUgc3BlYyBvciBjb21wYXRpYmxlIHdpdGggYWN0dWFsIGlt cGxlbWVudGF0aW9ucyBpcyBhIG1hdHRlciBvZiBkZWJhdGUuDQoNCkp1c3RpbiwgaWYgd2UgY2Fu J3QgZmluZCBhIHNpbmdsZSBpbXBsZW1lbnRhdGlvbiB0aGF0IHdvdWxkIGJhcmYsIHdoeSB3b3Vs ZCBDaHJvbWUgaGF2ZSB0byBpbXBsZW1lbnQgYSBjb21wbGV4IGZhbGxiYWNrIG1lY2hhbmlzbT8N Cg0KU2ltb24NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A3552A58Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BRERSRVNTLUVSUk9SLUNPREUgc2VlbXMgdXNlZnVsLCBjbGllbnQgY2FuIGRldGVybWlu ZSBpZiBpdOKAmXMgYSB0ZW1wb3Jhcnkgb3IgbG9uZy10ZXJtIGVycm9yLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRp cnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29n bGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDEwLCAyMDE1IDI6 MTkgQU08YnI+DQo8Yj5Ubzo8L2I+IE9sZWcgTW9za2FsZW5rbzxicj4NCjxiPkNjOjwvYj4gU2lt b24gUGVycmVhdWx0OyBBaWp1biBXYW5nOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyB0 cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gU1NPREEgaW4gVFVS Ti1iaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywg c28gd2UgaGF2ZSBjbGVhciBldmlkZW5jZSB0aGF0IHNvbWUgZGVwbG95ZWQgc2VydmVycyB3aWxs IGZhaWwgKGRldGVybWluaXN0aWNhbGx5LCBmb3J0dW5hdGVseSkgb24gdGhlIGN1cnJlbnQgU1NP REEgcHJvcG9zYWwuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TbyB3ZSdyZSBiYWNrIHRvIHdoaWNoIGJhY2t3YXJkcy1jb21wYXRpYmxlIG9wdGlvbiB3ZSB3 YW50IHRvIHB1cnN1ZS4gSSBzdWdnZXN0IGMpLCB3aGljaCBpcyB0aGUgb3B0aW9uYWwtY29tcHJl aGVuc2lvbiBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXBhcmF0ZWx5LCB3ZSBuZWVkIHRvIGRl Y2lkZSB3aGV0aGVyIHdlIHdhbnQgdG8gcHVyc3VlIGlzc3VlICMyIHRoYXQgSSBpZGVudGlmaWVk IHByZXZpb3VzbHksIGkuZS4sIGFsbG93aW5nIHNwZWNpZmljIGVycm9yIGNvZGVzIHRvIGJlIHJl dHVybmVkIGZvciBlYWNoIGFkZHJlc3MgZmFtaWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiA5LCAyMDE1IGF0IDEwOjUzIEFNLCBPbGVnIE1vc2th bGVua28gJmx0OzxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZG91YmxlLWNoZWNrZWQgdGhhdCB3aXRoIGEg cmVhbCB0ZXN0LiBJIHJhbiB0aGUgY29UdXJuIHRlc3QgY2xpZW50ICh0aGF0IGltcGxlbWVudHMg ZXhwZXJpbWVudGFsIFNTT0RBIGRyYWZ0IHdpdGggdHdvIFJBRiBhdHRyaWJ1dGVzKSBhZ2FpbnN0 IHJmYzU3NjYtdHVybi1zZXJ2ZXIgYW5kIHRoZSBzZXJ2ZXIgeWllbGRlZCBlcnJvciA0MDAgd2l0 aCB0aGUgbWVzc2FnZQ0KICZxdW90O09ubHkgb25lIGFkZHJlc3MgZmFtaWx5IGF0dHJpYnV0ZSBj YW4gYmUgdXNlZCBpbiBhIHJlcXVlc3QmcXVvdDs8YnI+DQo8YnI+DQo6KDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkFzIEkgc2FpZCwgSSBjYW4gZWxpbWluYXRlIHRoYXQgcHJvYmxlbSBpbiB0aGUgc3Vic2Vx dWVudCByZmM1NzY2LXR1cm4tc2VydmVyIG1haW50ZW5hbmNlIHJlbGVhc2VzLCBidXQgc3RpbGwu Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5JIGFtIHNvcnJ5IHRoYXQgSSBkaWQgbm90IGRpc2NvdmVyIHRo YXQgcHJldmlvdXNseSBhbmQgdGhhdCBJIGFkdm9jYXRlZCBhbiBpbmNvbXBhdGlibGUgaW1wbGVt ZW50YXRpb24gb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNvLCBpZiB0aGUgV0cgaW5zaXN0cyBv biBhIGJhY2t3YXJkLWNvbXBhdGlibGUgcHJvdG9jb2wgaW4gYWxsIHNlbnNlcywgdGhlbiB3ZSBo YXZlIHRvIGNob29zZSBhbm90aGVyIG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3M8c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KT2xlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDks IDIwMTUgYXQgMTA6MDEgQU0sIE9sZWcgTW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1v bTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb20wNDAyNjdAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBjaGVja2VkIHRoZSBjb2RlIG9m IHJmYzU3NjYtdHVybi1zZXJ2ZXIgYWdhaW4sIGFuZCBJIGZvdW5kIHRoYXQgaXQgd2lsbCBOT1Qg aGFuZGxlIHRoZSBtdWx0aXBsZS1SQUYgY2FzZS4gSXQgd2lsbCByZXR1cm4gNDAwIGVycm9yIHdp dGggdGhlIG1lc3NhZ2UgJnF1b3Q7T25seSBvbmUgYWRkcmVzcyBmYW1pbHkgYXR0cmlidXRlIGNh biBiZSB1c2VkIGluIGEgcmVxdWVzdCZxdW90Oy4NCiBBdCBsZWFzdCwgaXQncyBiZWVuIHRoYXQg d2F5IGluIHRoZSAyMDE0IHJlbGVhc2VzLiBJIGRpZCBub3QgY2hlY2sgdGhlIG9sZGVyIHJlbGVh c2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Tb3JyeSB0aGF0IEkgcHJvdmlkZWQgYSB3cm9u ZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW1wbGVtZW50YXRpb24sIGJlZm9yZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+SSBjYW4gZml4IHRoYXQgY29kZSBidXQgc3RpbGwgdGhlcmUgYXJlIHBl b3BsZSBvdXQgdGhlcmUgd2hvIHdpbGwgYmUgdXNpbmcgdGhlICZxdW90O3dyb25nJnF1b3Q7IHZl cnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TbywgaWYgd2UgZG8gaGF2ZSB0byBiZSBh YnNvbHV0ZWx5IGJhY2t3YXJkIGNvbXBhdGlibGUgdGhlbiB3ZSBoYXZlIHRvIHVzZSBhIGRpZmZl cmVudCBvcHRpb24uLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5PbGVnPGJyPg0KJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgOTozNCBBTSwgSnVzdGluIFVi ZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSByZXZpZXdl ZCB0aGUgY29kZSBmb3IgcmVzdHVuZCwgcmVUdXJuLCBhbmQgcmZjNTc2Ni10dXJuLXNlcnZlciBh bmQgdGhleSBhbGwgYXBwZWFyIHRvIGhhbmRsZSBSQUYgKGFuZCBtdWx0aXBsZSBSQUYpIE9LLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0s IGFzIEkgc2VlIGl0LCBpcyB0aGF0IHRoZXJlIG1heSBiZSBvdGhlciBUVVJOIHNlcnZlcnMsIHBl cmhhcHMgbm9uLW9wZW4tc291cmNlIG9uZXMsIHRoYXQgd29yayBmaW5lIHRvZGF5IHdpdGggQ2hy b21lLCBidXQgd2lsbCBzdGFydCByZXR1cm5pbmcgZXJyb3JzIHdoZW4gd2UgaW5jbHVkZSBSQUYg b3IgbXVsdGlwbGUgUkFGLCBhbmQgc28gbWFraW5nIHRoaXMgY2hhbmdlIG1heSBicmVhaw0KIHNv bWUgc21hbGwgbnVtYmVyIG9mIGFwcHMgKHdobyB3aWxsIHRoZW4gYmxhbWUgQ2hyb21lKS4gV2Ug anVzdCBkb24ndCBrbm93IHdoYXQgaXMgb3V0IHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IEphbiA5LCAyMDE1IGF0IDY6MTEgQU0sIFNpbW9uIFBlcnJlYXVsdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwZXJyZWF1bHRAaml2ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zcGVycmVhdWx0QGppdmUu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgNDoxNyBBTSwgQWlqdW4gV2FuZyAmbHQ7PGEg aHJlZj0ibWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24iIHRhcmdldD0iX2JsYW5rIj53 YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciB5b3VyIGRldGFpbCBhbmFseXNpcyBhbmQgdGhlIHNl bnRlbmNlIOKAnEZvciBlaXRoZXIgYi9jLCB3ZSB3b3VsZCBuZWVkIHRvIHNheSB0aGF0IGluY2x1 ZGluZyBib3RoIFJBRiBhbmQgT0FGL0FBRiBmb3IgdGhlIHNhbWUgYWRkcmVzcyBmYW1pbHkgaXMg cHJvaGliaXRlZC7igJ0sIEkgdGhpbmsgaXQgbWF5IGJlIGJldHRlciB0byBrZWVwIG9ubHkgb25l IGF0dHJpYnV0ZSB0byBmdWxmaWxsIHRoZSBTU09EQQ0KIHJlcXVpcmVtZW50PyAmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhlcmUgaXMg bm8gcmVxdWlyZW1lbnQgdGhhdCBTU09EQSBmdW5jdGlvbmFsaXR5IGJlIHJlYWxpemVkIHdpdGgg b25seSBvbmUgYXR0cmlidXRlLCBub3IgdGhhdCB0aGUgcHJvdG9jb2wgYmUgZWxlZ2FudCwgbm9y IHRoYXQgaXQgZXhoaWJpdHMgc3ltbWV0cnkgdGhhdCBpcyBwbGVhc2luZyB0byB0aGUgZXllLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSAqaXMqIGEgcmVxdWlyZW1lbnQgdGhhdCBpdCBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB0aG91 Z2guIFdoZXRoZXIgdGhhdCBtZWFucyBjb21wYXRpYmxlIHdpdGggdGhlIHNwZWMgb3IgY29tcGF0 aWJsZSB3aXRoIGFjdHVhbCBpbXBsZW1lbnRhdGlvbnMgaXMgYSBtYXR0ZXIgb2YgZGViYXRlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0 aW4sIGlmIHdlIGNhbid0IGZpbmQgYSBzaW5nbGUgaW1wbGVtZW50YXRpb24gdGhhdCB3b3VsZCBi YXJmLCB3aHkgd291bGQgQ2hyb21lIGhhdmUgdG8gaW1wbGVtZW50IGEgY29tcGxleCBmYWxsYmFj ayBtZWNoYW5pc20/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPlNpbW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJh bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A3552A58Bxmbrcdx10ciscoc_-- From nobody Sun Jan 11 21:32:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5D1A8A57 for ; Sun, 11 Jan 2015 21:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 3PsrtdoO0JNR for ; Sun, 11 Jan 2015 21:31:50 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5861A88A4 for ; Sun, 11 Jan 2015 21:31:49 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so6103103vcb.2 for ; Sun, 11 Jan 2015 21:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nmc7aylYNc4jx39Uxtkc4x/KJgnJl0Vz/DkUfXW3KqI=; b=f1pXNfGGJvdwfJzLz5HBBi7JiDNg6WoSnjOy+Qhrw421ba8rco24bThHS7sX2l/DSS p5FvonXHQgfUye8rrBvoyTJ+9GqIjxhVoHfPUUVn6+/W2qXrTWvZZ83bBWQrlMYw6wqG XeUDl9YdznscrTVw6fdc5Re7YfyReZC1QU9KAmvpnvxMtY0M8F4UkSWKbG03ilZqTHmb spJq5KiW9eWlDVy6QTBgMoztOoMGxwOfQXgRsV8lSY/s8Xa7J0JpwXnHiR6cObtw5ONs XyHfM6I7DIV0I84EMwBgPPDH+SS1tGbFTXZcP7nqoFQTbvvEVJZ3moVjbQR2I6++m2YU qfQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nmc7aylYNc4jx39Uxtkc4x/KJgnJl0Vz/DkUfXW3KqI=; b=EZH3iCRqLsgv9bsEgy8IUqU+s28cTrJR1uRqa08Z2b2/N1dGMqAZcIZnplOYHuzYFW IGEZw97JBRhHwuCfYw58iUXcfLLu0q3AZm7+UWVflFsinbHgwVb+GGExMHqCKr7Qr2zT u5y7UevpRF/1lgkeDFdEOGF74NzysuyQ3nJpljkdF/0b9hILvF2uUyGJTPFVhb9nOc2p 26V+AHoY1yTlXfb0mERzi6Msza/H13eQOBi5sF6Nz+Pc718FBC//Xv8diUTG3rIGh3Uc WQ7tvJeIMYgAPheR7E9kYxnvTdHFJpxUktRB8XB/VxnyzHgkXEhqFTmEXaVs5XSkqgBu R3nQ== X-Gm-Message-State: ALoCoQnJ6NG/OCUgu5dOswkxYIKUtoGhkbS8Ha9qEg1hwHwrku6zDnPN/VkH/ERbEECvB2mGLDZa X-Received: by 10.53.1.134 with SMTP id bg6mr13497922vdd.37.1421040708790; Sun, 11 Jan 2015 21:31:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Sun, 11 Jan 2015 21:31:28 -0800 (PST) In-Reply-To: <008c01d02e08$6f42a8c0$4dc7fa40$@org.cn> References: <913383AAA69FF945B8F946018B75898A3552A0EE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3552A3CB@xmb-rcd-x10.cisco.com> <008c01d02e08$6f42a8c0$4dc7fa40$@org.cn> From: Justin Uberti Date: Sun, 11 Jan 2015 21:31:28 -0800 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary=001a1135f22ca8d8a1050c6dd28b Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 05:31:54 -0000 --001a1135f22ca8d8a1050c6dd28b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RETURN addresses how the TURN servers communicate. On Sun, Jan 11, 2015 at 5:37 PM, Aijun Wang wrote: > Hi, Reddy and Justin: > > > > I suggest the TURN server selection should be made by ICE, not the client > itself. This can eliminate the needs for the communication between > different TURN server that selected by communication peer. ICE has more > information about the communication situation, and is suitable to make th= is > decision. > > > > There are several issues needed to be solved when the communication peers > select the different TURN server, for example, how to find the second TUR= N > server, what is the communication mechanism between different TURN server= s, > the channel connection among different data segments: client/first TURN > server, first TURN server/second TURN server, and second TURN server/peer > etc. > > > > Best Regards. > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Tirumaleswar > Reddy (tireddy) > *Sent:* Sunday, January 11, 2015 1:40 PM > *To:* Justin Uberti > > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Inline [TR] > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Sunday, January 11, 2015 2:17 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > Enterprise-provided TURN server cannot provide location privacy may not b= e > always true. For example Enterprise network could use TURN server provide= d > by a cloud service and the user needs to know that the Enterprise TURN > server can provide location privacy and not proceed with TURN-in-TURN. > > > > We will have to discuss if TURN server can advertise that it can provide > location privacy in a new attribute or this info can be conveyed > out-of-band (e.g. PAC). > > > > The other problem not discussed in the draft is, what if the user wants > privacy against the calling site and let=E2=80=99s say uses Tor for priva= cy. In > this scenario app TURN server must not be selected. > > > > RETURN handles this situation fine, since the traffic will be routed > through the network-provided TURN server before being routed to the app > TURN server. Of course, if the application does not try to provide locati= on > privacy, only the network-provided TURN server will be used. > > > > [TR] But the problem is how will the endpoint how if network-provided TUR= N > server can provide location privacy or not ? > > TURN server can convey this information in a new STUN attribute > to the client. > > > > However, I think the user is much more likely to trust the application > than its network provider to provide privacy protection. > > > > [TR] User may or may not trust the application server. > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses > users using privacy techniques like Tor so that app server does not learn > the user's IP address. The Poker example given in the above draft explain= s > that the users in the call do not trust the calling service. In this case > IdP ensures that even if malicious calling service replaces the media > addresses with its own addresses and replaces the certificate fingerprin= t > in SDP with its own certificate, IdP assertion would ensure that the Poke= r > site cannot act as man-in-middle device. In this scenario user may not > want to pick app provided TURN server. > > > > -Tiru > > > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Friday, January 09, 2015 4:04 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > At IETF 91, I promised to send feedback on this document, so here goes. > > > > Generally, I think many of the issues mentioned in this document are > important, but the recommendations are confusing and possibly > contradictory; a developer with little knowledge of TURN will have a hard > time figuring out exactly what to do. Furthermore, many of the properties > discussed in this document are dynamic, and should be handled by the ICE > process, rather than in TURN server selection (for example, the notion of > RTT as it relates to user experience). > > > > Therefore, I think this document should take a stronger stance and put > forth explicit best practices for selection (as opposed to "things to > consider"), for non-dynamic properties, and leave the decisions on dynami= c > properties to be resolved by ICE. > > > > For example, I think we should omit the text in Section 3 about what to d= o > with non-working TURN servers, and measuring RTT. Same for Section 3.3, > which also discusses RTT, and Section 3.4, which talks about multiple > interfaces. This can all be handled by ICE. > > > > In addition, the sections on local config and location privacy are > unnecessary when RETURN is used. When RETURN is used, the application can > always use the app TURN server for location privacy, and the relationship > between local TURN server and app TURN server is fully spelled out, so > there is nothing for the application to decide on. > > > > This leaves only the Security, Authentication, and Mobility sections. > > > > For security, I think we can give some clear guidance on what application= s > should do. For security, I think the guidance should be to use only DTLS = + > TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS > aren't available. If privacy is paramount, UDP/TCP fallback may be > contraindicated, but at this point in time, DTLS deployment isn't > widespread enough to truly recommend this. > > > > This relates to the Authentication section - but I think any failures to > authenticate the server cert should cause the TURN allocation to fail. Th= is > is just like any other misconfiguration on the TURN server - there's no > reason we should even allow use of TURN servers whose cert chains don't > validate. So, this section could probably be removed. > > > > Lastly, the Mobility section says that if "all other parameters [are] > equal", a TURN server with mobility should be used. Clearly, all other > parameters will not be equal (e.g. RTT), and even if they were, the clien= t > has no way to know if a server is mobility-capable a priori. So I think > this recommendation ought to be removed, or perhaps turned into some sort > of recommendation for TURN server developers (e.g. TURN servers SHOULD > support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), > probably in a separate doc. > > > > These recommendations should reduce the size of this document and provide > much clearer advice to app developers. > > > --001a1135f22ca8d8a1050c6dd28b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RETURN addresses how the TURN servers communicate.

On Sun, Jan 11, 201= 5 at 5:37 PM, Aijun Wang <wangaijun@tsinghua.org.cn>= wrote:

Hi, Reddy and Justin:

=C2=A0

I sug= gest the TURN server selection should be made by ICE, not the client itself= .=C2=A0 This can eliminate the needs for the communication between differen= t TURN server that selected by communication peer. ICE has more information= about the communication situation, and is suitable to make this decision.<= u>

=C2=A0

There are several issues needed to be = solved when the communication peers select the different TURN server, for e= xample, how to find the second TURN server, what is the communication mecha= nism between different TURN servers, the channel connection among different= data segments: client/first TURN server, first TURN server/second TURN ser= ver, and second TURN server/peer etc.

=C2=A0

Be= st Regards.

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tiruma= leswar Reddy (tireddy)
Sent: Sunday, January 11, 2015 1:40 PM
= To: Justin Uberti


Cc: tram@ietf.org
Su= bject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

Inline [TR]=

=C2=A0

From: Justin Uberti [mailto:juberti@google.com]
Sent: Sunday, January 11, 2015= 2:17 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject= : Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00=

<= u>=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy= ) <tireddy@cisco.= com> wrote:

Hi Justin,

=C2=A0

Enter= prise-provided TURN server cannot provide location privacy may not be alway= s true. For example Enterprise network could use TURN server provided by a = cloud service and the user needs to know that the Enterprise TURN server ca= n provide location privacy and not proceed with TURN-in-TURN.

=C2=A0

We will have to discuss if TURN server can advertise that it can prov= ide location privacy in a new attribute or this info can be conveyed out-of= -band (e.g. PAC).=C2=A0

=C2=A0=

The other problem not discussed in the draft is, what if the user wants pr= ivacy against the calling site and let=E2=80=99s say uses Tor for privacy. = In this scenario app TURN server must not be selected.

=C2=A0

RETURN handles this situation fin= e, since the traffic will be routed through the network-provided TURN serve= r before being routed to the app TURN server. Of course, if the application= does not try to provide location privacy, only the network-provided TURN s= erver will be used.

=C2=A0

[TR] But the problem is how will the en= dpoint how if network-provided TURN server can provide location privacy or = not ?

= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0TURN server can convey thi= s information in a new STUN attribute to the client.

=C2=A0

However, I think the user is much= more likely to trust the application than its network provider to provide = privacy protection.

=C2=A0

[TR] User may or may not trust the appl= ication server. https://tools.ietf.org/html/draft-ietf-rt= cweb-security-arch-10 discusses users using privacy techniques like Tor= so that app server does not learn the user's IP address. The Poker exa= mple given in the above draft explains that the users in the call do not tr= ust the calling service. In this case IdP ensures that even if malicious ca= lling service replaces the media addresses with its own addresses=C2=A0 and= replaces the certificate fingerprint in SDP with its own certificate, IdP = assertion would ensure that the Poker site cannot act as =C2=A0man-in-middl= e device. In this scenario user may not want to pick app provided TURN serv= er.

= =C2=A0

-Ti= ru

=C2=A0

=C2=A0<= /p>

=C2=A0<= /span>

<= p class=3D"MsoNormal">From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Ube= rti
Sent: Friday, January 09, 2015 4:04 AM
To: tram@ietf.org
Subject= : [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

At IETF 91, I promised to send feedback on this= document, so here goes.

=C2=A0

Generally, I think many of the issues m= entioned in this document are important, but the recommendations are confus= ing and possibly contradictory; a developer with little knowledge of TURN w= ill have a hard time figuring out exactly what to do. Furthermore, many of = the properties discussed in this document are dynamic, and should be handle= d by the ICE process, rather than in TURN server selection (for example, th= e notion of RTT as it relates to user experience).

=

=C2=A0=

Therefore= , I think this document should take a stronger stance and put forth explici= t best practices for selection (as opposed to "things to consider"= ;), for non-dynamic properties, and leave the decisions on dynamic properti= es to be resolved by ICE.=C2=A0

=C2=A0

For example, I think we shou= ld omit the text in Section 3 about what to do with non-working TURN server= s, and measuring RTT. Same for Section 3.3, which also discusses RTT, and S= ection 3.4, which talks about multiple interfaces. This can all be handled = by ICE.

=C2=A0

In addition, the sections on local config and locati= on privacy are unnecessary when RETURN is used. When RETURN is used, the ap= plication can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully spelled= out, so there is nothing for the application to decide on.

=C2=A0

= This leaves only the Security, Authentication, and Mobility sections.=C2=A0=

=C2=A0

For security, I think we can give some clear guidance on wh= at applications should do. For security, I think the guidance should be to = use only DTLS + TLS, if both are available, with fallback to UDP or TCP if = DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback= may be contraindicated, but at this point in time, DTLS deployment isn'= ;t widespread enough to truly recommend this.

=C2=A0

This relates t= o the Authentication section - but I think any failures to authenticate the= server cert should cause the TURN allocation to fail. This is just like an= y other misconfiguration on the TURN server - there's no reason we shou= ld even allow use of TURN servers whose cert chains don't validate. So,= this section could probably be removed.

=C2=A0

Lastly, the Mobilit= y section says that if "all other parameters [are] equal", a TURN= server with mobility should be used. Clearly, all other parameters will no= t be equal (e.g. RTT), and even if they were, the client has no way to know= if a server is mobility-capable a priori. So I think this recommendation o= ught to be removed, or perhaps turned into some sort of recommendation for = TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD s= upport mobility, SHOULD support redirect), probably in a separate doc.

= =C2=A0

These recommendations should reduce the size of this document an= d provide much clearer advice to app developers.

=C2=A0


--001a1135f22ca8d8a1050c6dd28b-- From nobody Sun Jan 11 21:35:39 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69F81A8A4B for ; Sun, 11 Jan 2015 21:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 LH9J4i4nobGN for ; Sun, 11 Jan 2015 21:35:33 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E7F1A8895 for ; Sun, 11 Jan 2015 21:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43204; q=dns/txt; s=iport; t=1421040932; x=1422250532; h=from:to:cc:subject:date:message-id:mime-version; bh=QeS7trSNoOPPJj6g9xdZPiFvcRk+hwl7hkLgjxdsA9I=; b=YO0CK2H6VMzUnF7+tUI0RUYluEriTGoMIbxdkfuhR6I14raNYL9KlKw6 OxKJKIGzd9IoReXpvrdZrpOi9e2xO0NmPOxEq/tKJuAQ35ebXGr40sWoX GYjQ0TH7SQM7ury3vRo4SS0PkOYpTDVxLxEQU4DQtsvRQfHvONrGmDVP7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMHANlcs1StJA2I/2dsb2JhbABbgkNDUlgEgwHAUoIlhXECHHJDAQEBAQF9hAwBAQEEIwpFBxIBCBEEAQELFgEGAwIEMBQJCQEEAQ0FCIgkDbdGkx0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBI9ILQQGgmkugRMFhDsCiCWBW4NFl0Aig25vgQUkHH4BAQE X-IronPort-AV: E=Sophos;i="5.07,742,1413244800"; d="scan'208,217";a="383058551" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jan 2015 05:35:29 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0C5ZTUV023271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 05:35:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sun, 11 Jan 2015 23:35:29 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Aijun Wang , "'Justin Uberti'" Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AdAuKY4pv/orH7MMR2aQzKezKRnnvw== Date: Mon, 12 Jan 2015 05:35:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.169] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552A606xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 05:35:36 -0000 --_000_913383AAA69FF945B8F946018B75898A3552A606xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSnVzdGluIGhhcyBwb2ludGVkIG91dCB3ZSB3aWxsIGJlIHVwZGF0aW5nIHRoZSBkcmFmdCB3 aXRoIG1vcmUgZGV0YWlscyBvbiB0aGUgZGVjaXNpb25zIHRoYXQgY291bGQgYmUgbWFkZSBieSBJ Q0UgYW5kIHRoZSBhcHBsaWNhdGlvbiB0byBzZWxlY3QgdGhlIFRVUk4gc2VydmVyLiBUVVJOLWlu LVRVUk4gY29tbXVuaWNhdGlvbiBpcyBhbHJlYWR5IGV4cGxhaW5lZCBpbiBSRVRVUk4gZHJhZnQu DQoNCi1UaXJ1DQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBBaWp1biBXYW5nDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTIsIDIwMTUgNzow OCBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7ICdKdXN0aW4gVWJlcnRpJw0K Q2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQt cGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwDQoNCkhpLCBSZWRkeSBhbmQgSnVzdGlu Og0KDQpJIHN1Z2dlc3QgdGhlIFRVUk4gc2VydmVyIHNlbGVjdGlvbiBzaG91bGQgYmUgbWFkZSBi eSBJQ0UsIG5vdCB0aGUgY2xpZW50IGl0c2VsZi4gIFRoaXMgY2FuIGVsaW1pbmF0ZSB0aGUgbmVl ZHMgZm9yIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gZGlmZmVyZW50IFRVUk4gc2VydmVyIHRo YXQgc2VsZWN0ZWQgYnkgY29tbXVuaWNhdGlvbiBwZWVyLiBJQ0UgaGFzIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgdGhlIGNvbW11bmljYXRpb24gc2l0dWF0aW9uLCBhbmQgaXMgc3VpdGFibGUgdG8g bWFrZSB0aGlzIGRlY2lzaW9uLg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCBpc3N1ZXMgbmVlZGVkIHRv IGJlIHNvbHZlZCB3aGVuIHRoZSBjb21tdW5pY2F0aW9uIHBlZXJzIHNlbGVjdCB0aGUgZGlmZmVy ZW50IFRVUk4gc2VydmVyLCBmb3IgZXhhbXBsZSwgaG93IHRvIGZpbmQgdGhlIHNlY29uZCBUVVJO IHNlcnZlciwgd2hhdCBpcyB0aGUgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2VlbiBkaWZm ZXJlbnQgVFVSTiBzZXJ2ZXJzLCB0aGUgY2hhbm5lbCBjb25uZWN0aW9uIGFtb25nIGRpZmZlcmVu dCBkYXRhIHNlZ21lbnRzOiBjbGllbnQvZmlyc3QgVFVSTiBzZXJ2ZXIsIGZpcnN0IFRVUk4gc2Vy dmVyL3NlY29uZCBUVVJOIHNlcnZlciwgYW5kIHNlY29uZCBUVVJOIHNlcnZlci9wZWVyIGV0Yy4N Cg0KQmVzdCBSZWdhcmRzLg0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KU2VudDogU3Vu ZGF5LCBKYW51YXJ5IDExLCAyMDE1IDE6NDAgUE0NClRvOiBKdXN0aW4gVWJlcnRpDQpDYzogdHJh bUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHJhbV0gQ29t bWVudHMgb24gZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwDQoNCklubGlu ZSBbVFJdDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21d DQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTEsIDIwMTUgMjoxNyBBTQ0KVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1wYXRpbC10cmFtLXR1cm4t c2Vydi1zZWxlY3Rpb24tMDANCg0KDQoNCk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgNzozOCBQTSwg VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRp cmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBKdXN0aW4sDQoNCkVudGVycHJpc2UtcHJvdmlk ZWQgVFVSTiBzZXJ2ZXIgY2Fubm90IHByb3ZpZGUgbG9jYXRpb24gcHJpdmFjeSBtYXkgbm90IGJl IGFsd2F5cyB0cnVlLiBGb3IgZXhhbXBsZSBFbnRlcnByaXNlIG5ldHdvcmsgY291bGQgdXNlIFRV Uk4gc2VydmVyIHByb3ZpZGVkIGJ5IGEgY2xvdWQgc2VydmljZSBhbmQgdGhlIHVzZXIgbmVlZHMg dG8ga25vdyB0aGF0IHRoZSBFbnRlcnByaXNlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIGxvY2F0 aW9uIHByaXZhY3kgYW5kIG5vdCBwcm9jZWVkIHdpdGggVFVSTi1pbi1UVVJOLg0KDQpXZSB3aWxs IGhhdmUgdG8gZGlzY3VzcyBpZiBUVVJOIHNlcnZlciBjYW4gYWR2ZXJ0aXNlIHRoYXQgaXQgY2Fu IHByb3ZpZGUgbG9jYXRpb24gcHJpdmFjeSBpbiBhIG5ldyBhdHRyaWJ1dGUgb3IgdGhpcyBpbmZv IGNhbiBiZSBjb252ZXllZCBvdXQtb2YtYmFuZCAoZS5nLiBQQUMpLg0KDQpUaGUgb3RoZXIgcHJv YmxlbSBub3QgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCBpcywgd2hhdCBpZiB0aGUgdXNlciB3YW50 cyBwcml2YWN5IGFnYWluc3QgdGhlIGNhbGxpbmcgc2l0ZSBhbmQgbGV04oCZcyBzYXkgdXNlcyBU b3IgZm9yIHByaXZhY3kuIEluIHRoaXMgc2NlbmFyaW8gYXBwIFRVUk4gc2VydmVyIG11c3Qgbm90 IGJlIHNlbGVjdGVkLg0KDQpSRVRVUk4gaGFuZGxlcyB0aGlzIHNpdHVhdGlvbiBmaW5lLCBzaW5j ZSB0aGUgdHJhZmZpYyB3aWxsIGJlIHJvdXRlZCB0aHJvdWdoIHRoZSBuZXR3b3JrLXByb3ZpZGVk IFRVUk4gc2VydmVyIGJlZm9yZSBiZWluZyByb3V0ZWQgdG8gdGhlIGFwcCBUVVJOIHNlcnZlci4g T2YgY291cnNlLCBpZiB0aGUgYXBwbGljYXRpb24gZG9lcyBub3QgdHJ5IHRvIHByb3ZpZGUgbG9j YXRpb24gcHJpdmFjeSwgb25seSB0aGUgbmV0d29yay1wcm92aWRlZCBUVVJOIHNlcnZlciB3aWxs IGJlIHVzZWQuDQoNCltUUl0gQnV0IHRoZSBwcm9ibGVtIGlzIGhvdyB3aWxsIHRoZSBlbmRwb2lu dCBob3cgaWYgbmV0d29yay1wcm92aWRlZCBUVVJOIHNlcnZlciBjYW4gcHJvdmlkZSBsb2NhdGlv biBwcml2YWN5IG9yIG5vdCA/DQogICAgICAgICBUVVJOIHNlcnZlciBjYW4gY29udmV5IHRoaXMg aW5mb3JtYXRpb24gaW4gYSBuZXcgU1RVTiBhdHRyaWJ1dGUgdG8gdGhlIGNsaWVudC4NCg0KSG93 ZXZlciwgSSB0aGluayB0aGUgdXNlciBpcyBtdWNoIG1vcmUgbGlrZWx5IHRvIHRydXN0IHRoZSBh cHBsaWNhdGlvbiB0aGFuIGl0cyBuZXR3b3JrIHByb3ZpZGVyIHRvIHByb3ZpZGUgcHJpdmFjeSBw cm90ZWN0aW9uLg0KDQpbVFJdIFVzZXIgbWF5IG9yIG1heSBub3QgdHJ1c3QgdGhlIGFwcGxpY2F0 aW9uIHNlcnZlci4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi LXNlY3VyaXR5LWFyY2gtMTAgZGlzY3Vzc2VzIHVzZXJzIHVzaW5nIHByaXZhY3kgdGVjaG5pcXVl cyBsaWtlIFRvciBzbyB0aGF0IGFwcCBzZXJ2ZXIgZG9lcyBub3QgbGVhcm4gdGhlIHVzZXIncyBJ UCBhZGRyZXNzLiBUaGUgUG9rZXIgZXhhbXBsZSBnaXZlbiBpbiB0aGUgYWJvdmUgZHJhZnQgZXhw bGFpbnMgdGhhdCB0aGUgdXNlcnMgaW4gdGhlIGNhbGwgZG8gbm90IHRydXN0IHRoZSBjYWxsaW5n IHNlcnZpY2UuIEluIHRoaXMgY2FzZSBJZFAgZW5zdXJlcyB0aGF0IGV2ZW4gaWYgbWFsaWNpb3Vz IGNhbGxpbmcgc2VydmljZSByZXBsYWNlcyB0aGUgbWVkaWEgYWRkcmVzc2VzIHdpdGggaXRzIG93 biBhZGRyZXNzZXMgIGFuZCByZXBsYWNlcyB0aGUgY2VydGlmaWNhdGUgZmluZ2VycHJpbnQgaW4g U0RQIHdpdGggaXRzIG93biBjZXJ0aWZpY2F0ZSwgSWRQIGFzc2VydGlvbiB3b3VsZCBlbnN1cmUg dGhhdCB0aGUgUG9rZXIgc2l0ZSBjYW5ub3QgYWN0IGFzICBtYW4taW4tbWlkZGxlIGRldmljZS4g SW4gdGhpcyBzY2VuYXJpbyB1c2VyIG1heSBub3Qgd2FudCB0byBwaWNrIGFwcCBwcm92aWRlZCBU VVJOIHNlcnZlci4NCg0KLVRpcnUNCg0KDQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBK dXN0aW4gVWJlcnRpDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMDksIDIwMTUgNDowNCBBTQ0KVG86 IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdHJhbV0gQ29t bWVudHMgb24gZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwDQoNCkF0IElF VEYgOTEsIEkgcHJvbWlzZWQgdG8gc2VuZCBmZWVkYmFjayBvbiB0aGlzIGRvY3VtZW50LCBzbyBo ZXJlIGdvZXMuDQoNCkdlbmVyYWxseSwgSSB0aGluayBtYW55IG9mIHRoZSBpc3N1ZXMgbWVudGlv bmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIGltcG9ydGFudCwgYnV0IHRoZSByZWNvbW1lbmRhdGlv bnMgYXJlIGNvbmZ1c2luZyBhbmQgcG9zc2libHkgY29udHJhZGljdG9yeTsgYSBkZXZlbG9wZXIg d2l0aCBsaXR0bGUga25vd2xlZGdlIG9mIFRVUk4gd2lsbCBoYXZlIGEgaGFyZCB0aW1lIGZpZ3Vy aW5nIG91dCBleGFjdGx5IHdoYXQgdG8gZG8uIEZ1cnRoZXJtb3JlLCBtYW55IG9mIHRoZSBwcm9w ZXJ0aWVzIGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBkeW5hbWljLCBhbmQgc2hvdWxk IGJlIGhhbmRsZWQgYnkgdGhlIElDRSBwcm9jZXNzLCByYXRoZXIgdGhhbiBpbiBUVVJOIHNlcnZl ciBzZWxlY3Rpb24gKGZvciBleGFtcGxlLCB0aGUgbm90aW9uIG9mIFJUVCBhcyBpdCByZWxhdGVz IHRvIHVzZXIgZXhwZXJpZW5jZSkuDQoNClRoZXJlZm9yZSwgSSB0aGluayB0aGlzIGRvY3VtZW50 IHNob3VsZCB0YWtlIGEgc3Ryb25nZXIgc3RhbmNlIGFuZCBwdXQgZm9ydGggZXhwbGljaXQgYmVz dCBwcmFjdGljZXMgZm9yIHNlbGVjdGlvbiAoYXMgb3Bwb3NlZCB0byAidGhpbmdzIHRvIGNvbnNp ZGVyIiksIGZvciBub24tZHluYW1pYyBwcm9wZXJ0aWVzLCBhbmQgbGVhdmUgdGhlIGRlY2lzaW9u cyBvbiBkeW5hbWljIHByb3BlcnRpZXMgdG8gYmUgcmVzb2x2ZWQgYnkgSUNFLg0KDQpGb3IgZXhh bXBsZSwgSSB0aGluayB3ZSBzaG91bGQgb21pdCB0aGUgdGV4dCBpbiBTZWN0aW9uIDMgYWJvdXQg d2hhdCB0byBkbyB3aXRoIG5vbi13b3JraW5nIFRVUk4gc2VydmVycywgYW5kIG1lYXN1cmluZyBS VFQuIFNhbWUgZm9yIFNlY3Rpb24gMy4zLCB3aGljaCBhbHNvIGRpc2N1c3NlcyBSVFQsIGFuZCBT ZWN0aW9uIDMuNCwgd2hpY2ggdGFsa3MgYWJvdXQgbXVsdGlwbGUgaW50ZXJmYWNlcy4gVGhpcyBj YW4gYWxsIGJlIGhhbmRsZWQgYnkgSUNFLg0KDQpJbiBhZGRpdGlvbiwgdGhlIHNlY3Rpb25zIG9u IGxvY2FsIGNvbmZpZyBhbmQgbG9jYXRpb24gcHJpdmFjeSBhcmUgdW5uZWNlc3Nhcnkgd2hlbiBS RVRVUk4gaXMgdXNlZC4gV2hlbiBSRVRVUk4gaXMgdXNlZCwgdGhlIGFwcGxpY2F0aW9uIGNhbiBh bHdheXMgdXNlIHRoZSBhcHAgVFVSTiBzZXJ2ZXIgZm9yIGxvY2F0aW9uIHByaXZhY3ksIGFuZCB0 aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gbG9jYWwgVFVSTiBzZXJ2ZXIgYW5kIGFwcCBUVVJOIHNl cnZlciBpcyBmdWxseSBzcGVsbGVkIG91dCwgc28gdGhlcmUgaXMgbm90aGluZyBmb3IgdGhlIGFw cGxpY2F0aW9uIHRvIGRlY2lkZSBvbi4NCg0KVGhpcyBsZWF2ZXMgb25seSB0aGUgU2VjdXJpdHks IEF1dGhlbnRpY2F0aW9uLCBhbmQgTW9iaWxpdHkgc2VjdGlvbnMuDQoNCkZvciBzZWN1cml0eSwg SSB0aGluayB3ZSBjYW4gZ2l2ZSBzb21lIGNsZWFyIGd1aWRhbmNlIG9uIHdoYXQgYXBwbGljYXRp b25zIHNob3VsZCBkby4gRm9yIHNlY3VyaXR5LCBJIHRoaW5rIHRoZSBndWlkYW5jZSBzaG91bGQg YmUgdG8gdXNlIG9ubHkgRFRMUyArIFRMUywgaWYgYm90aCBhcmUgYXZhaWxhYmxlLCB3aXRoIGZh bGxiYWNrIHRvIFVEUCBvciBUQ1AgaWYgRFRMUyBvciBUTFMgYXJlbid0IGF2YWlsYWJsZS4gSWYg cHJpdmFjeSBpcyBwYXJhbW91bnQsIFVEUC9UQ1AgZmFsbGJhY2sgbWF5IGJlIGNvbnRyYWluZGlj YXRlZCwgYnV0IGF0IHRoaXMgcG9pbnQgaW4gdGltZSwgRFRMUyBkZXBsb3ltZW50IGlzbid0IHdp ZGVzcHJlYWQgZW5vdWdoIHRvIHRydWx5IHJlY29tbWVuZCB0aGlzLg0KDQpUaGlzIHJlbGF0ZXMg dG8gdGhlIEF1dGhlbnRpY2F0aW9uIHNlY3Rpb24gLSBidXQgSSB0aGluayBhbnkgZmFpbHVyZXMg dG8gYXV0aGVudGljYXRlIHRoZSBzZXJ2ZXIgY2VydCBzaG91bGQgY2F1c2UgdGhlIFRVUk4gYWxs b2NhdGlvbiB0byBmYWlsLiBUaGlzIGlzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbWlzY29uZmlndXJh dGlvbiBvbiB0aGUgVFVSTiBzZXJ2ZXIgLSB0aGVyZSdzIG5vIHJlYXNvbiB3ZSBzaG91bGQgZXZl biBhbGxvdyB1c2Ugb2YgVFVSTiBzZXJ2ZXJzIHdob3NlIGNlcnQgY2hhaW5zIGRvbid0IHZhbGlk YXRlLiBTbywgdGhpcyBzZWN0aW9uIGNvdWxkIHByb2JhYmx5IGJlIHJlbW92ZWQuDQoNCkxhc3Rs eSwgdGhlIE1vYmlsaXR5IHNlY3Rpb24gc2F5cyB0aGF0IGlmICJhbGwgb3RoZXIgcGFyYW1ldGVy cyBbYXJlXSBlcXVhbCIsIGEgVFVSTiBzZXJ2ZXIgd2l0aCBtb2JpbGl0eSBzaG91bGQgYmUgdXNl ZC4gQ2xlYXJseSwgYWxsIG90aGVyIHBhcmFtZXRlcnMgd2lsbCBub3QgYmUgZXF1YWwgKGUuZy4g UlRUKSwgYW5kIGV2ZW4gaWYgdGhleSB3ZXJlLCB0aGUgY2xpZW50IGhhcyBubyB3YXkgdG8ga25v dyBpZiBhIHNlcnZlciBpcyBtb2JpbGl0eS1jYXBhYmxlIGEgcHJpb3JpLiBTbyBJIHRoaW5rIHRo aXMgcmVjb21tZW5kYXRpb24gb3VnaHQgdG8gYmUgcmVtb3ZlZCwgb3IgcGVyaGFwcyB0dXJuZWQg aW50byBzb21lIHNvcnQgb2YgcmVjb21tZW5kYXRpb24gZm9yIFRVUk4gc2VydmVyIGRldmVsb3Bl cnMgKGUuZy4gVFVSTiBzZXJ2ZXJzIFNIT1VMRCBzdXBwb3J0IFRMUy9EVExTLCBTSE9VTEQgc3Vw cG9ydCBtb2JpbGl0eSwgU0hPVUxEIHN1cHBvcnQgcmVkaXJlY3QpLCBwcm9iYWJseSBpbiBhIHNl cGFyYXRlIGRvYy4NCg0KVGhlc2UgcmVjb21tZW5kYXRpb25zIHNob3VsZCByZWR1Y2UgdGhlIHNp emUgb2YgdGhpcyBkb2N1bWVudCBhbmQgcHJvdmlkZSBtdWNoIGNsZWFyZXIgYWR2aWNlIHRvIGFw cCBkZXZlbG9wZXJzLg0KDQo= --_000_913383AAA69FF945B8F946018B75898A3552A606xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9 DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1uYW1lOuaJueazqOahhuaWh+acrDsNCglt c28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIEp1 c3RpbiBoYXMgcG9pbnRlZCBvdXQgd2Ugd2lsbCBiZSB1cGRhdGluZyB0aGUgZHJhZnQgd2l0aCBt b3JlIGRldGFpbHMgb24gdGhlIGRlY2lzaW9ucyB0aGF0IGNvdWxkIGJlIG1hZGUgYnkgSUNFIGFu ZCB0aGUgYXBwbGljYXRpb24gdG8gc2VsZWN0IHRoZSBUVVJODQogc2VydmVyLiBUVVJOLWluLVRV Uk4gY29tbXVuaWNhdGlvbiBpcyBhbHJlYWR5IGV4cGxhaW5lZCBpbiBSRVRVUk4gZHJhZnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5BaWp1biBXYW5nPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAxMiwgMjAxNSA3 OjA4IEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyAnSnVz dGluIFViZXJ0aSc8YnI+DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1z ZWxlY3Rpb24tMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+SGksIFJlZGR5IGFuZCBKdXN0aW46PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JIHN1Z2dlc3QgdGhl IFRVUk4gc2VydmVyIHNlbGVjdGlvbiBzaG91bGQgYmUgbWFkZSBieSBJQ0UsIG5vdCB0aGUgY2xp ZW50IGl0c2VsZi4mbmJzcDsgVGhpcyBjYW4gZWxpbWluYXRlIHRoZSBuZWVkcyBmb3IgdGhlIGNv bW11bmljYXRpb24NCiBiZXR3ZWVuIGRpZmZlcmVudCBUVVJOIHNlcnZlciB0aGF0IHNlbGVjdGVk IGJ5IGNvbW11bmljYXRpb24gcGVlci4gSUNFIGhhcyBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBjb21tdW5pY2F0aW9uIHNpdHVhdGlvbiwgYW5kIGlzIHN1aXRhYmxlIHRvIG1ha2UgdGhpcyBk ZWNpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPlRoZXJlIGFyZSBzZXZlcmFsIGlzc3VlcyBuZWVkZWQgdG8gYmUgc29s dmVkIHdoZW4gdGhlIGNvbW11bmljYXRpb24gcGVlcnMgc2VsZWN0IHRoZSBkaWZmZXJlbnQgVFVS TiBzZXJ2ZXIsIGZvciBleGFtcGxlLCBob3cgdG8gZmluZA0KIHRoZSBzZWNvbmQgVFVSTiBzZXJ2 ZXIsIHdoYXQgaXMgdGhlIGNvbW11bmljYXRpb24gbWVjaGFuaXNtIGJldHdlZW4gZGlmZmVyZW50 IFRVUk4gc2VydmVycywgdGhlIGNoYW5uZWwgY29ubmVjdGlvbiBhbW9uZyBkaWZmZXJlbnQgZGF0 YSBzZWdtZW50czogY2xpZW50L2ZpcnN0IFRVUk4gc2VydmVyLCBmaXJzdCBUVVJOIHNlcnZlci9z ZWNvbmQgVFVSTiBzZXJ2ZXIsIGFuZCBzZWNvbmQgVFVSTiBzZXJ2ZXIvcGVlciBldGMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5CZXN0IFJlZ2FyZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+IHRyYW0gWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 dHJhbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4N CjxiPlNlbnQ6PC9iPiBTdW5kYXksIEphbnVhcnkgMTEsIDIwMTUgMTo0MCBQTTxicj4NCjxiPlRv OjwvYj4gSnVzdGluIFViZXJ0aTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzp0cmFtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LXBhdGlsLXRyYW0tdHVybi1zZXJ2LXNlbGVj dGlvbi0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5JbmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBKdXN0aW4gVWJlcnRpIFs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPm1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb208L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDExLCAyMDE1IDI6MTcgQU08 YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8 L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnRyYW1AaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1w YXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24tMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PbiBGcmksIEphbiA5LCAyMDE1IGF0IDc6 MzggUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnRpcmVkZHlAY2lzY28uY29tPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZndDsNCiB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkhpIEp1c3Rpbiw8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5FbnRlcnByaXNlLXByb3ZpZGVkIFRVUk4gc2VydmVyIGNhbm5vdCBwcm92 aWRlIGxvY2F0aW9uIHByaXZhY3kgbWF5IG5vdA0KIGJlIGFsd2F5cyB0cnVlLiBGb3IgZXhhbXBs ZSBFbnRlcnByaXNlIG5ldHdvcmsgY291bGQgdXNlIFRVUk4gc2VydmVyIHByb3ZpZGVkIGJ5IGEg Y2xvdWQgc2VydmljZSBhbmQgdGhlIHVzZXIgbmVlZHMgdG8ga25vdyB0aGF0IHRoZSBFbnRlcnBy aXNlIFRVUk4gc2VydmVyIGNhbiBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3kgYW5kIG5vdCBwcm9j ZWVkIHdpdGggVFVSTi1pbi1UVVJOLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+V2Ugd2lsbCBoYXZlIHRvIGRpc2N1c3MgaWYgVFVSTiBzZXJ2ZXIg Y2FuIGFkdmVydGlzZSB0aGF0IGl0IGNhbiBwcm92aWRlDQogbG9jYXRpb24gcHJpdmFjeSBpbiBh IG5ldyBhdHRyaWJ1dGUgb3IgdGhpcyBpbmZvIGNhbiBiZSBjb252ZXllZCBvdXQtb2YtYmFuZCAo ZS5nLiBQQUMpLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhlIG90aGVyIHByb2JsZW0gbm90IGRp c2N1c3NlZCBpbiB0aGUgZHJhZnQgaXMsIHdoYXQgaWYgdGhlIHVzZXIgd2FudHMNCiBwcml2YWN5 IGFnYWluc3QgdGhlIGNhbGxpbmcgc2l0ZSBhbmQgbGV04oCZcyBzYXkgdXNlcyBUb3IgZm9yIHBy aXZhY3kuIEluIHRoaXMgc2NlbmFyaW8gYXBwIFRVUk4gc2VydmVyIG11c3Qgbm90IGJlIHNlbGVj dGVkLjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJF VFVSTiBoYW5kbGVzIHRoaXMgc2l0dWF0aW9uIGZpbmUsIHNpbmNlIHRoZSB0cmFmZmljIHdpbGwg YmUgcm91dGVkIHRocm91Z2ggdGhlIG5ldHdvcmstcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgYmVmb3Jl IGJlaW5nIHJvdXRlZCB0byB0aGUgYXBwIFRVUk4gc2VydmVyLiBPZiBjb3Vyc2UsIGlmIHRoZSBh cHBsaWNhdGlvbiBkb2VzIG5vdCB0cnkNCiB0byBwcm92aWRlIGxvY2F0aW9uIHByaXZhY3ksIG9u bHkgdGhlIG5ldHdvcmstcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgd2lsbCBiZSB1c2VkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPltUUl0gQnV0IHRoZSBwcm9ibGVtIGlzIGhvdyB3 aWxsIHRoZSBlbmRwb2ludCBob3cgaWYgbmV0d29yay1wcm92aWRlZCBUVVJOIHNlcnZlciBjYW4g cHJvdmlkZSBsb2NhdGlvbiBwcml2YWN5IG9yIG5vdCA/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VFVS TiBzZXJ2ZXIgY2FuIGNvbnZleSB0aGlzIGluZm9ybWF0aW9uIGluIGEgbmV3IFNUVU4gYXR0cmli dXRlIHRvIHRoZSBjbGllbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+SG93ZXZlciwgSSB0aGluayB0aGUgdXNlciBpcyBtdWNoIG1vcmUg bGlrZWx5IHRvIHRydXN0IHRoZSBhcHBsaWNhdGlvbiB0aGFuIGl0cyBuZXR3b3JrIHByb3ZpZGVy IHRvIHByb3ZpZGUgcHJpdmFjeSBwcm90ZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPltUUl0gVXNlciBtYXkgb3IgbWF5IG5vdCB0cnVzdCB0aGUgYXBwbGljYXRpb24g c2VydmVyLg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTEwIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi1zZWN1cml0eS1hcmNoLTEwPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPiBkaXNjdXNzZXMgdXNlcnMgdXNpbmcNCiBwcml2YWN5IHRlY2huaXF1 ZXMgbGlrZSBUb3Igc28gdGhhdCBhcHAgc2VydmVyIGRvZXMgbm90IGxlYXJuIHRoZSB1c2VyJ3Mg SVAgYWRkcmVzcy4gVGhlIFBva2VyIGV4YW1wbGUgZ2l2ZW4gaW4gdGhlIGFib3ZlIGRyYWZ0IGV4 cGxhaW5zIHRoYXQgdGhlIHVzZXJzIGluIHRoZSBjYWxsIGRvIG5vdCB0cnVzdCB0aGUgY2FsbGlu ZyBzZXJ2aWNlLiBJbiB0aGlzIGNhc2UgSWRQIGVuc3VyZXMgdGhhdCBldmVuIGlmIG1hbGljaW91 cyBjYWxsaW5nIHNlcnZpY2UNCiByZXBsYWNlcyB0aGUgbWVkaWEgYWRkcmVzc2VzIHdpdGggaXRz IG93biBhZGRyZXNzZXMmbmJzcDsgYW5kIHJlcGxhY2VzIHRoZSBjZXJ0aWZpY2F0ZSBmaW5nZXJw cmludCBpbiBTRFAgd2l0aCBpdHMgb3duIGNlcnRpZmljYXRlLCBJZFAgYXNzZXJ0aW9uIHdvdWxk IGVuc3VyZSB0aGF0IHRoZSBQb2tlciBzaXRlIGNhbm5vdCBhY3QgYXMgJm5ic3A7bWFuLWluLW1p ZGRsZSBkZXZpY2UuIEluIHRoaXMgc2NlbmFyaW8gdXNlciBtYXkgbm90IHdhbnQgdG8gcGljayBh cHANCiBwcm92aWRlZCBUVVJOIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiB0cmFtIFtt YWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFyeSAwOSwg MjAxNSA0OjA0IEFNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYt c2VsZWN0aW9uLTAwPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkF0IElFVEYgOTEsIEkgcHJvbWlz ZWQgdG8gc2VuZCBmZWVkYmFjayBvbiB0aGlzIGRvY3VtZW50LCBzbyBoZXJlIGdvZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+R2VuZXJhbGx5LCBJIHRoaW5rIG1hbnkgb2YgdGhl IGlzc3VlcyBtZW50aW9uZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgaW1wb3J0YW50LCBidXQgdGhl IHJlY29tbWVuZGF0aW9ucyBhcmUgY29uZnVzaW5nIGFuZCBwb3NzaWJseSBjb250cmFkaWN0b3J5 Ow0KIGEgZGV2ZWxvcGVyIHdpdGggbGl0dGxlIGtub3dsZWRnZSBvZiBUVVJOIHdpbGwgaGF2ZSBh IGhhcmQgdGltZSBmaWd1cmluZyBvdXQgZXhhY3RseSB3aGF0IHRvIGRvLiBGdXJ0aGVybW9yZSwg bWFueSBvZiB0aGUgcHJvcGVydGllcyBkaXNjdXNzZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgZHlu YW1pYywgYW5kIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSBJQ0UgcHJvY2VzcywgcmF0aGVyIHRo YW4gaW4gVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIChmb3INCiBleGFtcGxlLCB0aGUgbm90aW9uIG9m IFJUVCBhcyBpdCByZWxhdGVzIHRvIHVzZXIgZXhwZXJpZW5jZSkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGVyZWZvcmUsIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBz aG91bGQgdGFrZSBhIHN0cm9uZ2VyIHN0YW5jZSBhbmQgcHV0IGZvcnRoIGV4cGxpY2l0IGJlc3Qg cHJhY3RpY2VzIGZvciBzZWxlY3Rpb24gKGFzIG9wcG9zZWQgdG8gJnF1b3Q7dGhpbmdzDQogdG8g Y29uc2lkZXImcXVvdDspLCBmb3Igbm9uLWR5bmFtaWMgcHJvcGVydGllcywgYW5kIGxlYXZlIHRo ZSBkZWNpc2lvbnMgb24gZHluYW1pYyBwcm9wZXJ0aWVzIHRvIGJlIHJlc29sdmVkIGJ5IElDRS4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZvciBleGFtcGxl LCBJIHRoaW5rIHdlIHNob3VsZCBvbWl0IHRoZSB0ZXh0IGluIFNlY3Rpb24gMyBhYm91dCB3aGF0 IHRvIGRvIHdpdGggbm9uLXdvcmtpbmcgVFVSTiBzZXJ2ZXJzLCBhbmQgbWVhc3VyaW5nIFJUVC4g U2FtZSBmb3IgU2VjdGlvbg0KIDMuMywgd2hpY2ggYWxzbyBkaXNjdXNzZXMgUlRULCBhbmQgU2Vj dGlvbiAzLjQsIHdoaWNoIHRhbGtzIGFib3V0IG11bHRpcGxlIGludGVyZmFjZXMuIFRoaXMgY2Fu IGFsbCBiZSBoYW5kbGVkIGJ5IElDRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPkluIGFkZGl0aW9uLCB0aGUgc2VjdGlvbnMgb24gbG9jYWwgY29uZmlnIGFuZCBsb2Nh dGlvbiBwcml2YWN5IGFyZSB1bm5lY2Vzc2FyeSB3aGVuIFJFVFVSTiBpcyB1c2VkLiBXaGVuIFJF VFVSTiBpcyB1c2VkLCB0aGUgYXBwbGljYXRpb24NCiBjYW4gYWx3YXlzIHVzZSB0aGUgYXBwIFRV Uk4gc2VydmVyIGZvciBsb2NhdGlvbiBwcml2YWN5LCBhbmQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIGxvY2FsIFRVUk4gc2VydmVyIGFuZCBhcHAgVFVSTiBzZXJ2ZXIgaXMgZnVsbHkgc3BlbGxl ZCBvdXQsIHNvIHRoZXJlIGlzIG5vdGhpbmcgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkZWNpZGUg b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGlzIGxlYXZlcyBv bmx5IHRoZSBTZWN1cml0eSwgQXV0aGVudGljYXRpb24sIGFuZCBNb2JpbGl0eSBzZWN0aW9ucy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZvciBzZWN1cml0 eSwgSSB0aGluayB3ZSBjYW4gZ2l2ZSBzb21lIGNsZWFyIGd1aWRhbmNlIG9uIHdoYXQgYXBwbGlj YXRpb25zIHNob3VsZCBkby4gRm9yIHNlY3VyaXR5LCBJIHRoaW5rIHRoZSBndWlkYW5jZSBzaG91 bGQgYmUgdG8gdXNlDQogb25seSBEVExTICYjNDM7IFRMUywgaWYgYm90aCBhcmUgYXZhaWxhYmxl LCB3aXRoIGZhbGxiYWNrIHRvIFVEUCBvciBUQ1AgaWYgRFRMUyBvciBUTFMgYXJlbid0IGF2YWls YWJsZS4gSWYgcHJpdmFjeSBpcyBwYXJhbW91bnQsIFVEUC9UQ1AgZmFsbGJhY2sgbWF5IGJlIGNv bnRyYWluZGljYXRlZCwgYnV0IGF0IHRoaXMgcG9pbnQgaW4gdGltZSwgRFRMUyBkZXBsb3ltZW50 IGlzbid0IHdpZGVzcHJlYWQgZW5vdWdoIHRvIHRydWx5IHJlY29tbWVuZCB0aGlzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhpcyByZWxhdGVzIHRvIHRoZSBBdXRo ZW50aWNhdGlvbiBzZWN0aW9uIC0gYnV0IEkgdGhpbmsgYW55IGZhaWx1cmVzIHRvIGF1dGhlbnRp Y2F0ZSB0aGUgc2VydmVyIGNlcnQgc2hvdWxkIGNhdXNlIHRoZSBUVVJOIGFsbG9jYXRpb24gdG8N CiBmYWlsLiBUaGlzIGlzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbWlzY29uZmlndXJhdGlvbiBvbiB0 aGUgVFVSTiBzZXJ2ZXIgLSB0aGVyZSdzIG5vIHJlYXNvbiB3ZSBzaG91bGQgZXZlbiBhbGxvdyB1 c2Ugb2YgVFVSTiBzZXJ2ZXJzIHdob3NlIGNlcnQgY2hhaW5zIGRvbid0IHZhbGlkYXRlLiBTbywg dGhpcyBzZWN0aW9uIGNvdWxkIHByb2JhYmx5IGJlIHJlbW92ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5MYXN0bHksIHRoZSBNb2JpbGl0eSBzZWN0aW9uIHNheXMg dGhhdCBpZiAmcXVvdDthbGwgb3RoZXIgcGFyYW1ldGVycyBbYXJlXSBlcXVhbCZxdW90OywgYSBU VVJOIHNlcnZlciB3aXRoIG1vYmlsaXR5IHNob3VsZCBiZSB1c2VkLiBDbGVhcmx5LCBhbGwgb3Ro ZXINCiBwYXJhbWV0ZXJzIHdpbGwgbm90IGJlIGVxdWFsIChlLmcuIFJUVCksIGFuZCBldmVuIGlm IHRoZXkgd2VyZSwgdGhlIGNsaWVudCBoYXMgbm8gd2F5IHRvIGtub3cgaWYgYSBzZXJ2ZXIgaXMg bW9iaWxpdHktY2FwYWJsZSBhIHByaW9yaS4gU28gSSB0aGluayB0aGlzIHJlY29tbWVuZGF0aW9u IG91Z2h0IHRvIGJlIHJlbW92ZWQsIG9yIHBlcmhhcHMgdHVybmVkIGludG8gc29tZSBzb3J0IG9m IHJlY29tbWVuZGF0aW9uIGZvciBUVVJOIHNlcnZlciBkZXZlbG9wZXJzDQogKGUuZy4gVFVSTiBz ZXJ2ZXJzIFNIT1VMRCBzdXBwb3J0IFRMUy9EVExTLCBTSE9VTEQgc3VwcG9ydCBtb2JpbGl0eSwg U0hPVUxEIHN1cHBvcnQgcmVkaXJlY3QpLCBwcm9iYWJseSBpbiBhIHNlcGFyYXRlIGRvYy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZXNlIHJlY29tbWVuZGF0aW9u cyBzaG91bGQgcmVkdWNlIHRoZSBzaXplIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHByb3ZpZGUgbXVj aCBjbGVhcmVyIGFkdmljZSB0byBhcHAgZGV2ZWxvcGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A3552A606xmbrcdx10ciscoc_-- From nobody Sun Jan 11 23:10:22 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4901A1AEA for ; Sun, 11 Jan 2015 23:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.712 X-Spam-Level: * X-Spam-Status: No, score=1.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7] autolearn=no 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 xw4gXjC2AJbt for ; Sun, 11 Jan 2015 23:10:07 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CA7FC1A8A4C for ; Sun, 11 Jan 2015 23:10:00 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06DLDQBAVbNUILq6AA==.43942S4; Mon, 12 Jan 2015 13:02:09 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> Date: Mon, 12 Jan 2015 14:32:51 +0800 Message-ID: <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01D02E74.AD9CE8D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAuKY4pv/orH7MMR2aQzKezKRnnvwABc15Q Content-Language: zh-cn X-CM-TRANSID: Z0GX06DLDQBAVbNUILq6AA==.43942S4 X-Coremail-Antispam: 1U3129KBjvJXoW3AFW5Zr1rCF43uF4fWFWrAFb_yoW3CrykpF WfZryay3WkJF4xAw15Zw409F13u395WrW7Jrn8Gr17Z39xJr1Ivrnxtay5CFy7Gr95GF1Y qrWjv3WDZ3WrAFJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JURE__UUUUU= Archived-At: Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 07:10:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D4_01D02E74.AD9CE8D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 Do you refer to the draft = http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN = draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does = not describe the situation that the communication peers select the = different public TURN server, and need the TURN server to relay the app = data(TURN to TURN). =20 In situation that mentioned in RETURN draft, Why not to let ICE or App = Server to select the appropriate TURN server(corporate private TURN = server or public TURN server) based on the information of the two = communication parts? This can even eliminate the solution of RETURN: = two peer will use the corporate TURN server when they are both within = corporate, and will use the public TURN server when one of them is = located outside the corporation? =20 Best Regards. =20 =20 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Sent: Monday, January 12, 2015 1:35 PM To: Aijun Wang; 'Justin Uberti' Cc: tram@ietf.org Subject: RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 As Justin has pointed out we will be updating the draft with more = details on the decisions that could be made by ICE and the application = to select the TURN server. TURN-in-TURN communication is already = explained in RETURN draft. =20 -Tiru =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Monday, January 12, 2015 7:08 AM To: Tirumaleswar Reddy (tireddy); 'Justin Uberti' Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Hi, Reddy and Justin: =20 I suggest the TURN server selection should be made by ICE, not the = client itself. This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision. =20 There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc. =20 Best Regards. =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, January 11, 2015 1:40 PM To: Justin Uberti Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Inline [TR] =20 From: Justin Uberti [ = mailto:juberti@google.com]=20 Sent: Sunday, January 11, 2015 2:17 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) = wrote: Hi Justin, =20 Enterprise-provided TURN server cannot provide location privacy may not = be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.=20 =20 We will have to discuss if TURN server can advertise that it can provide = location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC).=20 =20 The other problem not discussed in the draft is, what if the user wants = privacy against the calling site and let=E2=80=99s say uses Tor for = privacy. In this scenario app TURN server must not be selected. =20 RETURN handles this situation fine, since the traffic will be routed = through the network-provided TURN server before being routed to the app = TURN server. Of course, if the application does not try to provide = location privacy, only the network-provided TURN server will be used. =20 [TR] But the problem is how will the endpoint how if network-provided = TURN server can provide location privacy or not ? TURN server can convey this information in a new STUN attribute = to the client. =20 However, I think the user is much more likely to trust the application = than its network provider to provide privacy protection. =20 [TR] User may or may not trust the application server. = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses = users using privacy techniques like Tor so that app server does not = learn the user's IP address. The Poker example given in the above draft = explains that the users in the call do not trust the calling service. In = this case IdP ensures that even if malicious calling service replaces = the media addresses with its own addresses and replaces the certificate = fingerprint in SDP with its own certificate, IdP assertion would ensure = that the Poker site cannot act as man-in-middle device. In this = scenario user may not want to pick app provided TURN server. =20 -Tiru =20 =20 =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Friday, January 09, 2015 4:04 AM To: tram@ietf.org Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 At IETF 91, I promised to send feedback on this document, so here goes. =20 Generally, I think many of the issues mentioned in this document are = important, but the recommendations are confusing and possibly = contradictory; a developer with little knowledge of TURN will have a = hard time figuring out exactly what to do. Furthermore, many of the = properties discussed in this document are dynamic, and should be handled = by the ICE process, rather than in TURN server selection (for example, = the notion of RTT as it relates to user experience). =20 Therefore, I think this document should take a stronger stance and put = forth explicit best practices for selection (as opposed to "things to = consider"), for non-dynamic properties, and leave the decisions on = dynamic properties to be resolved by ICE.=20 =20 For example, I think we should omit the text in Section 3 about what to = do with non-working TURN servers, and measuring RTT. Same for Section = 3.3, which also discusses RTT, and Section 3.4, which talks about = multiple interfaces. This can all be handled by ICE. =20 In addition, the sections on local config and location privacy are = unnecessary when RETURN is used. When RETURN is used, the application = can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide on. =20 This leaves only the Security, Authentication, and Mobility sections.=20 =20 For security, I think we can give some clear guidance on what = applications should do. For security, I think the guidance should be to = use only DTLS + TLS, if both are available, with fallback to UDP or TCP = if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend this. =20 This relates to the Authentication section - but I think any failures to = authenticate the server cert should cause the TURN allocation to fail. = This is just like any other misconfiguration on the TURN server - = there's no reason we should even allow use of TURN servers whose cert = chains don't validate. So, this section could probably be removed. =20 Lastly, the Mobility section says that if "all other parameters [are] = equal", a TURN server with mobility should be used. Clearly, all other = parameters will not be equal (e.g. RTT), and even if they were, the = client has no way to know if a server is mobility-capable a priori. So I = think this recommendation ought to be removed, or perhaps turned into = some sort of recommendation for TURN server developers (e.g. TURN = servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support = redirect), probably in a separate doc. =20 These recommendations should reduce the size of this document and = provide much clearer advice to app developers. =20 ------=_NextPart_000_00D4_01D02E74.AD9CE8D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

Do you refer to the draft http:= //www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN = draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does = not describe the situation that the communication peers select the = different public TURN server, and need the TURN server to relay the app = data(TURN to TURN).

 

In situation that mentioned in RETURN draft, Why not to let ICE or = App Server to select the appropriate TURN server(corporate private TURN = server or public TURN server) based on the information of the two = communication parts? This can even eliminate the solution of=C2=A0 = RETURN: =C2=A0two peer will use the corporate TURN server when they are = both within corporate, and will use the public TURN server when one of = them is located outside the corporation?

 

Best Regards.

 

 

From:= = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: = Monday, January 12, 2015 1:35 PM
To: Aijun Wang; 'Justin = Uberti'
Cc: tram@ietf.org
Subject: RE: [tram] = Comments on = draft-patil-tram-turn-serv-selection-00

=

 

As Justin has pointed out we will be updating the draft with more = details on the decisions that could be made by ICE and the application = to select the TURN server. TURN-in-TURN communication is already = explained in RETURN draft.

 

-Tiru

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Aijun Wang
Sent: Monday, January 12, 2015 = 7:08 AM
To: Tirumaleswar Reddy (tireddy); 'Justin = Uberti'
Cc: tram@ietf.org
Subject: Re: = [tram] Comments on = draft-patil-tram-turn-serv-selection-00

=

 

Hi, Reddy and Justin:

 

I suggest the TURN server selection should be made by ICE, not the = client itself.  This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision.

 

There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc.

 

Best Regards.

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, = January 11, 2015 1:40 PM
To: Justin Uberti
Cc: = tram@ietf.or= g
Subje= ct: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

=

 

Inline [TR]

 

From:= Justin = Uberti [mailto:juber= ti@google.com] =
Sent: Sunday, January 11, 2015 2:17 AM
To: = Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.or= g
Subje= ct: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

=

 

 

 

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy = (tireddy) <tireddy@cisco.com> = wrote:

Hi Justin,

 

Enterprise-provided TURN server cannot provide location privacy may = not be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.

 

We will have to discuss if TURN server can advertise that it can = provide location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC). 

 

The other problem not discussed in the draft is, what if the user = wants privacy against the calling site and let=E2=80=99s say uses Tor = for privacy. In this scenario app TURN server must not be = selected.

 

RETURN handles this situation fine, = since the traffic will be routed through the network-provided TURN = server before being routed to the app TURN server. Of course, if the = application does not try to provide location privacy, only the = network-provided TURN server will be used.

 

[TR] But the problem is how will the endpoint how if = network-provided TURN server can provide location privacy or not = ?

         TURN = server can convey this information in a new STUN attribute to the = client.

 

However, I think the user is much = more likely to trust the application than its network provider to = provide privacy protection.

 

[TR] User may or may not trust the application server. h= ttps://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 = discusses users using privacy techniques like Tor so that app server = does not learn the user's IP address. The Poker example given in the = above draft explains that the users in the call do not trust the calling = service. In this case IdP ensures that even if malicious calling service = replaces the media addresses with its own addresses  and replaces = the certificate fingerprint in SDP with its own certificate, IdP = assertion would ensure that the Poker site cannot act as =  man-in-middle device. In this scenario user may not want to pick = app provided TURN server.

 

-Tiru

 

 

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 = 4:04 AM
To: tram@ietf.or= g
Subje= ct: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

At IETF 91, I promised to send feedback on this document, = so here goes.

 

Generally, I think many of the issues mentioned in this = document are important, but the recommendations are confusing and = possibly contradictory; a developer with little knowledge of TURN will = have a hard time figuring out exactly what to do. Furthermore, many of = the properties discussed in this document are dynamic, and should be = handled by the ICE process, rather than in TURN server selection (for = example, the notion of RTT as it relates to user = experience).

 

Therefore, I think this document should take a stronger = stance and put forth explicit best practices for selection (as opposed = to "things to consider"), for non-dynamic properties, and = leave the decisions on dynamic properties to be resolved by = ICE. 

 

For example, I think we should omit the text in Section 3 = about what to do with non-working TURN servers, and measuring RTT. Same = for Section 3.3, which also discusses RTT, and Section 3.4, which talks = about multiple interfaces. This can all be handled by = ICE.

 

In addition, the sections on local config and location = privacy are unnecessary when RETURN is used. When RETURN is used, the = application can always use the app TURN server for location privacy, and = the relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide = on.

 

This leaves only the Security, Authentication, and Mobility = sections. 

 

For security, I think we can give some clear guidance on = what applications should do. For security, I think the guidance should = be to use only DTLS + TLS, if both are available, with fallback to UDP = or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend = this.

 

This relates to the Authentication section - but I think = any failures to authenticate the server cert should cause the TURN = allocation to fail. This is just like any other misconfiguration on the = TURN server - there's no reason we should even allow use of TURN servers = whose cert chains don't validate. So, this section could probably be = removed.

 

Lastly, the Mobility section says that if "all other = parameters [are] equal", a TURN server with mobility should be = used. Clearly, all other parameters will not be equal (e.g. RTT), and = even if they were, the client has no way to know if a server is = mobility-capable a priori. So I think this recommendation ought to be = removed, or perhaps turned into some sort of recommendation for TURN = server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD = support mobility, SHOULD support redirect), probably in a separate = doc.

 

These recommendations should reduce the size of this = document and provide much clearer advice to app = developers.

 

------=_NextPart_000_00D4_01D02E74.AD9CE8D0-- From nobody Mon Jan 12 02:53:44 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB151A87E2 for ; Mon, 12 Jan 2015 02:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Gkr6ahBQS3ya for ; Mon, 12 Jan 2015 02:53:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B4B1A8ABF for ; Mon, 12 Jan 2015 02:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5588; q=dns/txt; s=iport; t=1421060018; x=1422269618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2c3bReLvoIZkHsDNrbMRceso/ucjhvtKaY/O2sZFG1U=; b=Mqt6YKG9dQNV4CDU0QBb66Ni3DsvZX6mXzQGCnUo72CGzlfuJlOt70DU rwCe4vfznNW8cH3C8AW/hTMO6zE5+UVItiECww0/Tn+YSSKC1sLzaAOjf f4vDnH4uk99dehuoyYOX/VGKNUiMSQEeeudYsPLAlN7jyWv1ItEfMTRZ/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8GAKyms1StJV2d/2dsb2JhbABRCoMGUlyDAcJwCoVxAhx1QwEBAQEBfYQMAQEBAwEBAQEgEToJAgUHBAIBCBEEAQEBAgIjAwICAiULFAEICAIECgQFiCQIDbd5kygBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGNbQ8pGBsHBoJiLoETBY49g0WFSIE/kDkig25vAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,743,1413244800"; d="scan'208";a="386185572" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jan 2015 10:53:37 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0CAraEM015508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 10:53:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 04:53:36 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] New Version Notification for draft-williams-peer-redirect-02.txt Thread-Index: AQHQLlYD1vVpMOw2XUifqgCvgED9WQ== Date: Mon, 12 Jan 2015 10:53:36 +0000 Message-ID: <945F0E46-220B-4D09-95B5-E933043CCD09@cisco.com> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> In-Reply-To: <008b01d02e00$c1be3450$453a9cf0$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.161.85] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 10:53:40 -0000 SGkgQWlqdW4sDQoNClRVUk4gd2FzIG9yaWdpbmFsbHkgd3JpdHRlbiBhcyBhIGJhY2t1cCBzZXJ2 aWNlIHdoZW4gSUNFIGZhaWxzLiBJdCBhbHNvIGRpZCBwcm92aWRlIGZhbGxiYWNrIHdoZW4gSUNF IGNsaWVudHMgd2FudGVkIHRvIHRhbGsgdG8gbm9uLUlDRSBjbGllbnRzIChCdXQgdGhlbiB0aGUg ZGVmYXVsdCBjYW5kaWRhdGUgbXVzdCBiZSBzZXQgdG8gdGhlIHJlbGF5IGFkZHJlc3MuIFRoZSBw b2ludCBpcyB0aGF0IHRoZSBhbGxvY2F0ZWQgcHVibGljIFJFTEFZIGFkZHJlc3Mgb24gdGhlIHR1 cm4gc2VydmVyIHdvcmtzIGFzIGEgbm9ybWFsIFVEUCAob3IgVENQIGlmIHRoYXQgaXMgaW4gdXNl KSBwb3J0LiBUaGF0IG1lYW5zIHRoYXQgYW55IGNsaWVudCBjYW4gc2VuZCBpdHMgUlRQIHBhY2tl dCBvciB3aGF0ZXZlciBhcyBub3JtYWwgd2l0aG91dCBhbnkga25vd2xlZGdlIHJlZ2FyZGluZyBU VVJOLkFzIGxvbmcgYXMgdGhlIGNsaWVudCBoYXZlIGluc3RhbGxlZCB0aGUgbmVjZXNzYXJ5IHBl cm1pc3Npb25zLg0KDQpJZiB0aGUgdG8gVFVSTiBzZXJ2ZXJzIGFyZSBuZWVkZWQgZHVlIHRvIHJl c3RyaWN0aW5nIEZXcyB0aGUgdHJhZmZpYyBiZXR3ZWVuIHRoZSB0d28gcHVibGljIFJFTEFZIGFk ZHJlc3NlcyB3aWxsIGJlIHB1cmUgVURQIG9yIFRDUC4gIE5vIG5lZWQgZm9yIGFueSBhZGRpdGlv bmFsIGluZm9ybWF0aW9uLiANCg0KV2l0aCBJQ0UgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gZW5k IHVwIHdpdGggYXN5bW1ldHJpY2FsIHJvdXRpbmcuIE5vdCBzdXJlIGhvdyBjb21tb24gdGhhdCBp cy4gSSBhbSBpbmNsaW5lZCB0byBibGFtZSB0aGUgbmV0d29yayBpZiB0aGF0IG9jY3VycywgSUNF IG9ubHkgcHJvYmVzIGFuZCB0aWVzIHRvIGdldCB0aGUgcGFja2V0cyB0aHJvdWdoLiANCg0KSSBk byBub3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHNvbHZlIGJlbG93Lg0KDQou LS4NClDDpWwtRXJpaw0KDQo+IE9uIDEyIEphbiAyMDE1LCBhdCAwMTo0MywgQWlqdW4gV2FuZyA8 d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4gd3JvdGU6DQo+IA0KPiBIaSwgQnJhbmRvbjoNCj4g DQo+IEluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlz LTAwI3NlY3Rpb24tMTAuMSwgaXQgaXMNCj4gZGVzY3JpYmVkIGFzIGJlbG93Og0KPiANCj4gV2hl biBmb3JtaW5nIGEgU2VuZCBpbmRpY2F0aW9uLCB0aGUgY2xpZW50IE1VU1QgaW5jbHVkZSBhbiBY T1ItUEVFUi0NCj4gICBBRERSRVNTIGF0dHJpYnV0ZSBhbmQgYSBEQVRBIGF0dHJpYnV0ZS4gIFRo ZSBYT1ItUEVFUi1BRERSRVNTDQo+ICAgYXR0cmlidXRlIGNvbnRhaW5zIHRoZSB0cmFuc3BvcnQg YWRkcmVzcyBvZiB0aGUgcGVlciB0byB3aGljaCB0aGUNCj4gICBkYXRhIGlzIHRvIGJlIHNlbnQs IGFuZCB0aGUgREFUQSBhdHRyaWJ1dGUgY29udGFpbnMgdGhlIGFjdHVhbA0KPiAgIGFwcGxpY2F0 aW9uIGRhdGEgdG8gYmUgc2VudCB0byB0aGUgcGVlci4NCj4gDQo+IFNvLCB0aGVyZSBpcyBubyBY T1ItUkVMQVlFRC1BRERSRVNTIGF0dHJpYnV0ZSBpbmNsdWRlZCB0byBpZGVudGlmeSB0aGUNCj4g cGVlcidzIGFsbG9jYXRlZCByZWxheSBhZGRyZXNzLiBPbiB0aGUgb3RoZXIgaGFuZCwgWE9SLVJF TEFZRUQtQUREUkVTUyBpcw0KPiBtYWlubHkgcmVmZXIgdG8gdGhlIHJlcXVlc3RlcidzIGFsbG9j YXRlZCByZWxheSBhZGRyZXNzLCBub3QgdGhlDQo+IGNvcnJlc3BvbmRpbmcgcGVlci4gV2lsbCB3 ZSBkZWZpbmUgYWdhaW4gb25lIG5ldyBhdHRyaWJ1dGUsIHN1Y2ggYXMNCj4gWE9SLVBFRVItUkVM QVlFRC1BRERSRVNTIHRvIHRyYW5zZmVyIHRoZSBuZXh0IFRVUk4gc2VydmVyJ3MgaW5mb3JtYXRp b24/DQo+IA0KPiBFdmVuIGlmIHNvLCB3aGF0IHdpbGwgYmUgdGhlIHNvdXJjZSBhZGRyZXNzIGZv ciB0aGUgcGFja2V0IGZyb20gdGhlIHNlY29uZA0KPiBUVVJOIHNlcnZlciB0byBkZXN0aW5hdGlv biBwZWVyPyBJZiB3ZSB1c2UgdGhlIFhPUi1SRUxBWUVELUFERFJFU1MsIHRoZW4gdGhlDQo+IHJl dHVybiBwYWNrZXQgZnJvbSB0aGUgcGVlciB3aWxsIGJlIHBhc3NlZCBiYWNrIGRpcmVjdGx5IHRv IHRoZSBmaXJzdCBUVVJODQo+IHNlcnZlciwgcmVzdWx0cyBpbiBub24tc3ltbWV0cmljIHJvdXRl LiBJZiB3ZSB1c2UgWE9SLVBFRVItUkVMQVlFRC1BRERSRVNTLA0KPiB0aGVuIHdoYXQgaXMgdGhl IHNvdXJjZSBhZGRyZXNzIGZvciB0aGUgcGFja2V0IGZyb20gdGhlIHNlY29uZCBUVVJOIHNlcnZl cg0KPiBiYWNrIHRvIHRoZSBmaXJzdCBUVVJOIHNlcnZlcj8NCj4gDQo+IEJlc3QgUmVnYXJkcy4N Cj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQnJhbmRvbiBXaWxs aWFtcyBbbWFpbHRvOmJvd2lsbEBha2FtYWkuY29tXQ0KPj4gU2VudDogU2F0dXJkYXksIEphbnVh cnkgMTAsIDIwMTUgMTowOSBBTQ0KPj4gVG86IEFpanVuIFdhbmc7IHRyYW1AaWV0Zi5vcmcNCj4+ IFN1YmplY3Q6IFJlOiBbdHJhbV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ PiBkcmFmdC13aWxsaWFtcy1wZWVyLXJlZGlyZWN0LTAyLnR4dA0KPj4gDQo+PiBCeSByZWxheSBh ZGRyZXNzLCBJIG1lYW4gdGhlIFhPUi1SRUxBWUVELUFERFJFU1MgcmV0dXJuZWQgaW4gdGhlDQo+ IGFsbG9jYXRpb24NCj4+IHJlcXVlc3QuIFRoaXMgY2xlYXJseSBpZGVudGlmaWVzIHRoZSB0cnVl IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gZm9yIHRoZQ0KPiBkYXRhIGluDQo+PiB0aGUgcGFja2V0 IGFzIHdlbGwgYXMgdGhlIHR3byByZWxheSBzZXJ2ZXJzIGludm9sdmVkLiBJZiBib3RoIHJlbGF5 ZWQNCj4gYWRkcmVzc2VzDQo+PiBhcmUgb24gdGhlIHNhbWUgc2VydmVyLCBpdCB3aWxsIG9mIGNv dXJzZSBrbm93IHRoYXQgYW5kIGJlIGFibGUgdG8NCj4gb3B0aW1pemUgYXMNCj4+IFNpbW9uIGlu ZGljYXRlZCBpbiBhbiBlYXJsaWVyIGUtbWFpbC4NCj4+IA0KPj4gLS1CcmFuZG9uDQo+PiANCj4+ IE9uIDAxLzA4LzIwMTUgMDk6NDAgUE0sIEFpanVuIFdhbmcgd3JvdGU6DQo+Pj4gDQo+Pj4gW0Fp anVuXTogVGhlcmUgYXJlIHR3byByZWxheSBhZGRyZXNzLCBvbmUgaXMgdGhlIFRVUk4gc2VydmVy DQo+Pj4gd2VsbC1rbm93biBhZGRyZXNzLCBhbm90aGVyIGlzIHRoZSByZWxheSBhZGRyZXNzIHRo YXQgYWxsb2NhdGVkIHRvDQo+Pj4gZWFjaCBjbGllbnQuIFdoaWNoIG9uZSBzaG91bGQgYmUgdXNl ZCB0aGVuPyBPbiB0aGUgb3RoZXIgaGFuZCwgd2hlbg0KPj4+IGNsaWVudCB3YW50IHRvIHNlbmQg dHJhZmZpYyB0byBvdGhlciBwZWVyLCBpdCBkb2VzIG5vdCBrbm93IHdoZXRoZXINCj4+PiB0aGUg b3RoZXIgcGFydCBpcyB1bmRlciB0aGUgc2FtZSBUVVJOIHNlcnZlciBvciBub3QsIGhvdyBkbyBp dCBzZWxlY3QNCj4gdGhpcw0KPj4gaW5mb3JtYXRpb24/DQo+Pj4gDQo+PiANCj4+PiANCj4+PiBb QWlqdW5dOiBhcyB0aGUgZGVmaW5pdGlvbiBpbg0KPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTQuMywNCj4+PiB0aGUgWE9S LVBFRVItQUREUkVTUyBpcyB0aGUgYWRkcmVzcyBzZWVuIGZyb20gdGhlIFRVUk4gc2VydmVyLCBz byBpdA0KPj4+IGNhbid0IGJlIHVzZWQgdG8gZmluZCB0aGUgcmVsYXkgYWRkcmVzcyBvZiB0aGUg cmVtb3RlIHBlZXIsIGFuZCB0aGVuDQo+Pj4gY2FuJ3QgYmUgdXNlZCB0byBkaXJlY3QgdHJhZmZp YyB0byBkb3duc3RyZWFtIHJlbGF5Lg0KPj4+IA0KPj4+IA0KPj4gDQo+PiANCj4+IC0tDQo+PiBC cmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJn aW5nIFByb2R1Y3RzDQo+PiBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo+ IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== From nobody Mon Jan 12 07:44:58 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5921ACCD9 for ; Mon, 12 Jan 2015 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zMZIKuUkQEAO for ; Mon, 12 Jan 2015 07:44:55 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 807601ACCDA for ; Mon, 12 Jan 2015 07:44:54 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9AA6728586; Mon, 12 Jan 2015 15:44:53 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 7C5A428584; Mon, 12 Jan 2015 15:44:53 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 781A22047; Mon, 12 Jan 2015 15:44:53 +0000 (GMT) Message-ID: <54B3EBF5.9090103@akamai.com> Date: Mon, 12 Jan 2015 10:44:53 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aijun Wang , "tram@ietf.org" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> In-Reply-To: <008b01d02e00$c1be3450$453a9cf0$@org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:44:57 -0000 XOR-PEER-ADDRESS contains "the transport address of the peer". It is not required to be a specific type of address (host, reflexive, or relay). It will be any address that can be used to deliver data to the remote peer. If two TURN relays are used, then the XOR-PEER-ADDRESS attribute in Send and Data indications will contain the remote peer's allocated relay address. There is no need the for either of the relays to even be aware that the transport address is a relay address. Consider the following: A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B | | | | |---- TURN ----|-- UDP --|---- TURN ----| A and B are the two peers' host addresses. XA and XB are the two peers' reflexive addresses. TA and TB are the relay servers' addresses used as the TURN session endpoints. RA and RB are the two peers' allocated relay addresses. A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. When A's relay receives the Send indication, it sends the data in a plain UDP datagram with RA as the source and RB as the destination. When B's relay receives the UDP datagram, it sends a Data indication from TB to B with RA as the XOR-PEER-ADDRESS. --Brandon On 01/11/2015 07:43 PM, Aijun Wang wrote: > Hi, Brandon: > > In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, it is > described as below: > > When forming a Send indication, the client MUST include an XOR-PEER- > ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS > attribute contains the transport address of the peer to which the > data is to be sent, and the DATA attribute contains the actual > application data to be sent to the peer. > > So, there is no XOR-RELAYED-ADDRESS attribute included to identify the > peer's allocated relay address. On the other hand, XOR-RELAYED-ADDRESS is > mainly refer to the requester's allocated relay address, not the > corresponding peer. Will we define again one new attribute, such as > XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's information? > > Even if so, what will be the source address for the packet from the second > TURN server to destination peer? If we use the XOR-RELAYED-ADDRESS, then the > return packet from the peer will be passed back directly to the first TURN > server, results in non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, > then what is the source address for the packet from the second TURN server > back to the first TURN server? > > Best Regards. > >> -----Original Message----- >> From: Brandon Williams [mailto:bowill@akamai.com] >> Sent: Saturday, January 10, 2015 1:09 AM >> To: Aijun Wang; tram@ietf.org >> Subject: Re: [tram] Fwd: New Version Notification for >> draft-williams-peer-redirect-02.txt >> >> By relay address, I mean the XOR-RELAYED-ADDRESS returned in the > allocation >> request. This clearly identifies the true source and destination for the > data in >> the packet as well as the two relay servers involved. If both relayed > addresses >> are on the same server, it will of course know that and be able to > optimize as >> Simon indicated in an earlier e-mail. >> >> --Brandon >> >> On 01/08/2015 09:40 PM, Aijun Wang wrote: >>> >>> [Aijun]: There are two relay address, one is the TURN server >>> well-known address, another is the relay address that allocated to >>> each client. Which one should be used then? On the other hand, when >>> client want to send traffic to other peer, it does not know whether >>> the other part is under the same TURN server or not, how do it select > this >> information? >>> >> >>> >>> [Aijun]: as the definition in >>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, >>> the XOR-PEER-ADDRESS is the address seen from the TURN server, so it >>> can't be used to find the relay address of the remote peer, and then >>> can't be used to direct traffic to downstream relay. >>> >>> >> >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Jan 12 12:23:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66D91ACDEE for ; Mon, 12 Jan 2015 12:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 B0i0muhnWqQ8 for ; Mon, 12 Jan 2015 12:23:28 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5121ACDE9 for ; Mon, 12 Jan 2015 12:23:27 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn15so13434339igb.1 for ; Mon, 12 Jan 2015 12:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=suB8dw5XDQhaldJqjVGDtNw9+gILw+avSWoNJQV1M7w=; b=PASe2aVScLWh+c4QOVq42Ev78+gZtaiNNtCjNMMNkDOsxtKbrqKXoMcRAJ/n4RBkC+ mXKgUO2fcPCTx1/pL3JDxMahmrvsNW8mCjDqS7nMyAXMG7+iutpt+p5F1KfIwqH7w1+E /DWoZpf4Nlb19gjTVBQHiarBS0JMObeTl7D+OrT9aeA4zn7UhEdxsjQb+EmF7DpNu/nJ s8kGyvhivH9wEjouGQS3LMts+++jx/3YEYbKORml65R111fR3VpLR6qdoJzxakQajskx c9vtddAHEAf0Bgw2mF9XpEAA2uGImWtHE3jdzjzyaefOtaLeGT3WoG2xBr9WbJZ1PLEN gC8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=suB8dw5XDQhaldJqjVGDtNw9+gILw+avSWoNJQV1M7w=; b=Giyg8Zn8NGnWoYtmuxE20+e5R3viv/LXmvfupgr4ckvGindJG31uvZdpwKZZabaX00 KORa5GQ0mJbHy7t8VCbp/6ZHRLFCe0wQnAxLsSJpDE6YtBQSd+mCz3PwHI1kVo59NevL awvbH1Tzh16hiilE/LzexFBC/YggLbH7q4HhZhGmRVspHfJO7FyBeoNgjw7KRkau7jn8 uE0l+QwKh6dYpSA3wUjOIL/VtPkUBmitMilCxbGAxrxtV1r3AWDqYLVn6+8C8delN/sS bpHUt6xM2X7OMX1gNdqhgcyYdLVFa8g7UjaXS9cLt1noohpWC00YhCziqveLmgqQ0Rxz Lprw== X-Gm-Message-State: ALoCoQmAq7fX7YlqNZoSeiuKUUdd10raukYBPiG0htcIkJorrb50WXtYqPm2HkISKUy6Wxs6eU61 X-Received: by 10.51.18.99 with SMTP id gl3mr16877401igd.6.1421094206959; Mon, 12 Jan 2015 12:23:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Mon, 12 Jan 2015 12:23:06 -0800 (PST) In-Reply-To: <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> References: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> From: Justin Uberti Date: Mon, 12 Jan 2015 12:23:06 -0800 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary=001a1134b4fc664bf0050c7a476f Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 20:23:32 -0000 --001a1134b4fc664bf0050c7a476f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang wrote: > Hi, > > > > Do you refer to the draft > http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN > draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does > not describe the situation that the communication peers select the > different public TURN server, and need the TURN server to relay the app > data(TURN to TURN). > That is just normal UDP. > > > In situation that mentioned in RETURN draft, Why not to let ICE or App > Server to select the appropriate TURN server(corporate private TURN serve= r > or public TURN server) based on the information of the two communication > parts? This can even eliminate the solution of RETURN: two peer will us= e > the corporate TURN server when they are both within corporate, and will u= se > the public TURN server when one of them is located outside the corporatio= n? > a) The TURN server isn't needed when both endpoints are within the enterprise. The TURN server sits on the enterprise border, and is used for inter-enterprise traffic. b) The public TURN server may not be reachable from the enterprise. This is why the corporate TURN server is needed on the border. c) The app may require use of its own TURN server for location privacy purposes, so both TURN servers may be used in this case. This is all spelled out in https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-1. > > > Best Regards. > > > > > > *From:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Monday, January 12, 2015 1:35 PM > *To:* Aijun Wang; 'Justin Uberti' > *Cc:* tram@ietf.org > *Subject:* RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > As Justin has pointed out we will be updating the draft with more details > on the decisions that could be made by ICE and the application to select > the TURN server. TURN-in-TURN communication is already explained in RETUR= N > draft. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Aijun Wang > *Sent:* Monday, January 12, 2015 7:08 AM > *To:* Tirumaleswar Reddy (tireddy); 'Justin Uberti' > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Hi, Reddy and Justin: > > > > I suggest the TURN server selection should be made by ICE, not the client > itself. This can eliminate the needs for the communication between > different TURN server that selected by communication peer. ICE has more > information about the communication situation, and is suitable to make th= is > decision. > > > > There are several issues needed to be solved when the communication peers > select the different TURN server, for example, how to find the second TUR= N > server, what is the communication mechanism between different TURN server= s, > the channel connection among different data segments: client/first TURN > server, first TURN server/second TURN server, and second TURN server/peer > etc. > > > > Best Regards. > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Tirumaleswar Reddy (tireddy) > *Sent:* Sunday, January 11, 2015 1:40 PM > *To:* Justin Uberti > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Inline [TR] > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Sunday, January 11, 2015 2:17 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > Enterprise-provided TURN server cannot provide location privacy may not b= e > always true. For example Enterprise network could use TURN server provide= d > by a cloud service and the user needs to know that the Enterprise TURN > server can provide location privacy and not proceed with TURN-in-TURN. > > > > We will have to discuss if TURN server can advertise that it can provide > location privacy in a new attribute or this info can be conveyed > out-of-band (e.g. PAC). > > > > The other problem not discussed in the draft is, what if the user wants > privacy against the calling site and let=E2=80=99s say uses Tor for priva= cy. In > this scenario app TURN server must not be selected. > > > > RETURN handles this situation fine, since the traffic will be routed > through the network-provided TURN server before being routed to the app > TURN server. Of course, if the application does not try to provide locati= on > privacy, only the network-provided TURN server will be used. > > > > [TR] But the problem is how will the endpoint how if network-provided TUR= N > server can provide location privacy or not ? > > TURN server can convey this information in a new STUN attribute > to the client. > > > > However, I think the user is much more likely to trust the application > than its network provider to provide privacy protection. > > > > [TR] User may or may not trust the application server. > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses > users using privacy techniques like Tor so that app server does not learn > the user's IP address. The Poker example given in the above draft explain= s > that the users in the call do not trust the calling service. In this case > IdP ensures that even if malicious calling service replaces the media > addresses with its own addresses and replaces the certificate fingerprin= t > in SDP with its own certificate, IdP assertion would ensure that the Poke= r > site cannot act as man-in-middle device. In this scenario user may not > want to pick app provided TURN server. > > > > -Tiru > > > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Friday, January 09, 2015 4:04 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > At IETF 91, I promised to send feedback on this document, so here goes. > > > > Generally, I think many of the issues mentioned in this document are > important, but the recommendations are confusing and possibly > contradictory; a developer with little knowledge of TURN will have a hard > time figuring out exactly what to do. Furthermore, many of the properties > discussed in this document are dynamic, and should be handled by the ICE > process, rather than in TURN server selection (for example, the notion of > RTT as it relates to user experience). > > > > Therefore, I think this document should take a stronger stance and put > forth explicit best practices for selection (as opposed to "things to > consider"), for non-dynamic properties, and leave the decisions on dynami= c > properties to be resolved by ICE. > > > > For example, I think we should omit the text in Section 3 about what to d= o > with non-working TURN servers, and measuring RTT. Same for Section 3.3, > which also discusses RTT, and Section 3.4, which talks about multiple > interfaces. This can all be handled by ICE. > > > > In addition, the sections on local config and location privacy are > unnecessary when RETURN is used. When RETURN is used, the application can > always use the app TURN server for location privacy, and the relationship > between local TURN server and app TURN server is fully spelled out, so > there is nothing for the application to decide on. > > > > This leaves only the Security, Authentication, and Mobility sections. > > > > For security, I think we can give some clear guidance on what application= s > should do. For security, I think the guidance should be to use only DTLS = + > TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS > aren't available. If privacy is paramount, UDP/TCP fallback may be > contraindicated, but at this point in time, DTLS deployment isn't > widespread enough to truly recommend this. > > > > This relates to the Authentication section - but I think any failures to > authenticate the server cert should cause the TURN allocation to fail. Th= is > is just like any other misconfiguration on the TURN server - there's no > reason we should even allow use of TURN servers whose cert chains don't > validate. So, this section could probably be removed. > > > > Lastly, the Mobility section says that if "all other parameters [are] > equal", a TURN server with mobility should be used. Clearly, all other > parameters will not be equal (e.g. RTT), and even if they were, the clien= t > has no way to know if a server is mobility-capable a priori. So I think > this recommendation ought to be removed, or perhaps turned into some sort > of recommendation for TURN server developers (e.g. TURN servers SHOULD > support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), > probably in a separate doc. > > > > These recommendations should reduce the size of this document and provide > much clearer advice to app developers. > > > --001a1134b4fc664bf0050c7a476f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang <wangaijun@tsingh= ua.org.cn> wrote:

Hi,

=C2=A0

Do you refer to the draft http://www.ietf.org/= id/draft-schwartz-rtcweb-return-04.txt as RETURN draft? This draft desc= ribes only TURN-in-TURN, not TURN-to-TURN. It does not describe the situati= on that the communication peers select the different public TURN server, an= d need the TURN server to relay the app data(TURN to TURN).


That is just normal UDP.=C2=A0
<= p class=3D"MsoNormal">

=C2=A0

In situation that mentione= d in RETURN draft, Why not to let ICE or App Server to select the appropria= te TURN server(corporate private TURN server or public TURN server) based o= n the information of the two communication parts? This can even eliminate t= he solution of=C2=A0 RETURN: =C2=A0two peer will use the corporate TURN ser= ver when they are both within corporate, and will use the public TURN serve= r when one of them is located outside the corporation?


a) The TURN server isn't needed when= both endpoints are within the enterprise. The TURN server sits on the ente= rprise border, and is used for inter-enterprise traffic.
b) The p= ublic TURN server may not be reachable from the enterprise. This is why the= corporate TURN server is needed on the border.
c) The app may re= quire use of its own TURN server for location privacy purposes, so both TUR= N servers may be used in this case.

<= u>=C2=A0

Best Regards.

=C2=A0

=C2=A0

From: Tirumaleswar Reddy (tireddy) [mailto= :tireddy@cisco.com]
Sent: Monday, January 12, 2015 1:35 PM
To: Aijun W= ang; 'Justin Uberti'
Cc: tram@ietf.org
Subject: RE: [tram] Comments= on draft-patil-tram-turn-serv-selection-00

<= /div>

= =C2=A0

A= s Justin has pointed out we will be updating the draft with more details on= the decisions that could be made by ICE and the application to select the = TURN server. TURN-in-TURN communication is already explained in RETURN draf= t.

=C2=A0

= -Tiru

=C2=A0

<= b>From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wan= g
Sent: Monday, January 12, 2015 7:08 AM
To: Tirumalesw= ar Reddy (tireddy); 'Justin Uberti'
Cc: tram@ietf.org
Subject: Re: = [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2= =A0

Hi, Re= ddy and Justin:

=C2=A0

I suggest the TURN server selection should be made by IC= E, not the client itself.=C2=A0 This can eliminate the needs for the commun= ication between different TURN server that selected by communication peer. = ICE has more information about the communication situation, and is suitable= to make this decision.

=C2=A0

= There are several issues needed to be solved when = the communication peers select the different TURN server, for example, how = to find the second TURN server, what is the communication mechanism between= different TURN servers, the channel connection among different data segmen= ts: client/first TURN server, first TURN server/second TURN server, and sec= ond TURN server/peer etc.

=C2=A0

Best Regards.

=C2=A0

From: tram [mailto:tram= -bounces@ietf.org] On Behalf Of Tirumaleswar Redd= y (tireddy)
Sent: Sunday, January 11, 2015 1:40 PM
To: = Justin Uberti
Cc: tram@ietf.org
Subject: Re: [= tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2= =A0

Inline [= TR]

<= u>=C2=A0

=

= From: Justin Uberti [mailto:juberti@google.com] =
Sent: Sunday, January 11, 2015 2:17 AM
To: Tirumaleswa= r Reddy (tireddy)
Cc: tram@ietf.org
Subject: R= e: [tram] Comments on draft-patil-tram-turn-serv-selection-00=

= =C2=A0

=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com&= gt; wrote:

Hi Justin,=

=C2=A0

Enterprise-provided TURN server cannot provide location privacy may = not be always true. For example Enterprise network could use TURN server pr= ovided by a cloud service and the user needs to know that the Enterprise TU= RN server can provide location privacy and not proceed with TURN-in-TURN. <= /span>

= =C2=A0

We will have to discus= s if TURN server can advertise that it can provide location privacy in a ne= w attribute or this info can be conveyed out-of-band (e.g. PAC).=C2=A0

=C2=A0

The other problem not discussed in the draft is, what if the user w= ants privacy against the calling site and let=E2=80=99s say uses Tor for pr= ivacy. In this scenario app TURN server must not be selected.

=C2=A0

=

RETURN handles this situat= ion fine, since the traffic will be routed through the network-provided TUR= N server before being routed to the app TURN server. Of course, if the appl= ication does not try to provide location privacy, only the network-provided= TURN server will be used.

<= span lang=3D"EN-US" style=3D"font-size:11pt;font-family:Calibri,sans-serif;= color:rgb(31,73,125)">=C2=A0

[TR] But the problem is how will the endpoint how if = network-provided TURN server can provide location privacy or not ?

=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0TURN server can convey this information= in a new STUN attribute to the client.

<= u>=C2=A0

However, I think the user is much more likely to trust the appli= cation than its network provider to provide privacy protection.

=C2=A0=

[TR] User may or= may not trust the application server. https://tools.ietf= .org/html/draft-ietf-rtcweb-security-arch-10 discusses users using priv= acy techniques like Tor so that app server does not learn the user's IP= address. The Poker example given in the above draft explains that the user= s in the call do not trust the calling service. In this case IdP ensures th= at even if malicious calling service replaces the media addresses with its = own addresses=C2=A0 and replaces the certificate fingerprint in SDP with it= s own certificate, IdP assertion would ensure that the Poker site cannot ac= t as =C2=A0man-in-middle device. In this scenario user may not want to pick= app provided TURN server.

<= span lang=3D"EN-US">=C2=A0

<= span lang=3D"EN-US">-Tiru

=C2=A0

=

=C2=A0

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Friday, January 09, = 2015 4:04 AM
To: tram@ietf.org
Subject: [tram= ] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

At IETF 91, I promised to send feedback on this document, = so here goes.

=C2=A0

Generally, I think many of the issues mentioned in t= his document are important, but the recommendations are confusing and possi= bly contradictory; a developer with little knowledge of TURN will have a ha= rd time figuring out exactly what to do. Furthermore, many of the propertie= s discussed in this document are dynamic, and should be handled by the ICE = process, rather than in TURN server selection (for example, the notion of R= TT as it relates to user experience).

=C2=A0

Therefore, I think thi= s document should take a stronger stance and put forth explicit best practi= ces for selection (as opposed to "things to consider"), for non-d= ynamic properties, and leave the decisions on dynamic properties to be reso= lved by ICE.=C2=A0

=C2=A0

For example, I think we should omit the= text in Section 3 about what to do with non-working TURN servers, and meas= uring RTT. Same for Section 3.3, which also discusses RTT, and Section 3.4,= which talks about multiple interfaces. This can all be handled by ICE.<= /u>

=C2=A0

In addition, the sections on local config and location privacy = are unnecessary when RETURN is used. When RETURN is used, the application c= an always use the app TURN server for location privacy, and the relationshi= p between local TURN server and app TURN server is fully spelled out, so th= ere is nothing for the application to decide on.

=C2=A0

This leaves= only the Security, Authentication, and Mobility sections.=C2=A0<= /u>

=C2=A0=

For security, I think we can give some clear guidance on what applicat= ions should do. For security, I think the guidance should be to use only DT= LS + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS= aren't available. If privacy is paramount, UDP/TCP fallback may be con= traindicated, but at this point in time, DTLS deployment isn't widespre= ad enough to truly recommend this.

=C2=A0

This relates to the Authe= ntication section - but I think any failures to authenticate the server cer= t should cause the TURN allocation to fail. This is just like any other mis= configuration on the TURN server - there's no reason we should even all= ow use of TURN servers whose cert chains don't validate. So, this secti= on could probably be removed.

=C2=A0

Lastly, the Mobility section= says that if "all other parameters [are] equal", a TURN server w= ith mobility should be used. Clearly, all other parameters will not be equa= l (e.g. RTT), and even if they were, the client has no way to know if a ser= ver is mobility-capable a priori. So I think this recommendation ought to b= e removed, or perhaps turned into some sort of recommendation for TURN serv= er developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support mo= bility, SHOULD support redirect), probably in a separate doc.=

=C2=A0=

These recommendations should reduce the size of this document and provide= much clearer advice to app developers.

=C2=A0

<= /div>
--001a1134b4fc664bf0050c7a476f-- From nobody Mon Jan 12 16:51:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57D1ACE35 for ; Mon, 12 Jan 2015 16:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.711 X-Spam-Level: * X-Spam-Status: No, score=1.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_22=0.6, RCVD_IN_PSBL=2.7] autolearn=no 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 5jTDljIHDVwZ for ; Mon, 12 Jan 2015 16:51:14 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 168CB1ACE38 for ; Mon, 12 Jan 2015 16:51:12 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BrVgF6VrRU_iPVAA==.16531S4; Tue, 13 Jan 2015 07:19:47 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> In-Reply-To: <54B3EBF5.9090103@akamai.com> Date: Tue, 13 Jan 2015 08:50:33 +0800 Message-ID: <002901d02eca$f8d75f00$ea861d00$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAuckFFwqOBmGH6Qlqm6gFOR1C+AwAVukAA Content-Language: zh-cn X-CM-TRANSID: Z0GX06BrVgF6VrRU_iPVAA==.16531S4 X-Coremail-Antispam: 1U3129KBjvJXoWxuFykGw45GFy8Wry7WF1kAFb_yoW7XrWxpr WSgFW3K3WDJr47Crs2qw129FyY9395Xr13Wr1Utr1xua90qFnIyFyjgw18W347Cr18Wa4Y vF4jv3W7uFn0yrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:51:16 -0000 Hi, Brandon Thanks for your vivid graph for our discussion. Two questions are raised here: 1. How does TURN server A decide when to use UDP to send app data, and when to use TURN to send app data? Which criteria can assistant the TURN server A to make this decision? In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2, it describes the TURN server will send UDP raw packet to the peer, regardless the peer is awareness or unawareness the existence of TURN. 2. In your example, if TURN B use the DATA indication to B, what will B do if it does not support the TURN encapsulation? Best Regards. > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Monday, January 12, 2015 11:45 PM > To: Aijun Wang; tram@ietf.org > Subject: Re: [tram] Fwd: New Version Notification for > draft-williams-peer-redirect-02.txt > > XOR-PEER-ADDRESS contains "the transport address of the peer". It is not > required to be a specific type of address (host, reflexive, or relay). > It will be any address that can be used to deliver data to the remote peer. If > two TURN relays are used, then the XOR-PEER-ADDRESS attribute in Send and > Data indications will contain the remote peer's allocated relay address. There > is no need the for either of the relays to even be aware that the transport > address is a relay address. > > Consider the following: > > A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B > | | | | > |---- TURN ----|-- UDP --|---- TURN ----| > > A and B are the two peers' host addresses. > XA and XB are the two peers' reflexive addresses. > TA and TB are the relay servers' addresses used as the TURN session > endpoints. > RA and RB are the two peers' allocated relay addresses. > > A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. When A's > relay receives the Send indication, it sends the data in a plain UDP datagram > with RA as the source and RB as the destination. When B's relay receives the > UDP datagram, it sends a Data indication from TB to B with RA as the > XOR-PEER-ADDRESS. > > --Brandon > > On 01/11/2015 07:43 PM, Aijun Wang wrote: > > Hi, Brandon: > > > > In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, > > it is described as below: > > > > When forming a Send indication, the client MUST include an XOR-PEER- > > ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS > > attribute contains the transport address of the peer to which the > > data is to be sent, and the DATA attribute contains the actual > > application data to be sent to the peer. > > > > So, there is no XOR-RELAYED-ADDRESS attribute included to identify the > > peer's allocated relay address. On the other hand, XOR-RELAYED-ADDRESS > > is mainly refer to the requester's allocated relay address, not the > > corresponding peer. Will we define again one new attribute, such as > > XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's > information? > > > > Even if so, what will be the source address for the packet from the > > second TURN server to destination peer? If we use the > > XOR-RELAYED-ADDRESS, then the return packet from the peer will be > > passed back directly to the first TURN server, results in > > non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what is > > the source address for the packet from the second TURN server back to the > first TURN server? > > > > Best Regards. > > > >> -----Original Message----- > >> From: Brandon Williams [mailto:bowill@akamai.com] > >> Sent: Saturday, January 10, 2015 1:09 AM > >> To: Aijun Wang; tram@ietf.org > >> Subject: Re: [tram] Fwd: New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> > >> By relay address, I mean the XOR-RELAYED-ADDRESS returned in the > > allocation > >> request. This clearly identifies the true source and destination for > >> the > > data in > >> the packet as well as the two relay servers involved. If both relayed > > addresses > >> are on the same server, it will of course know that and be able to > > optimize as > >> Simon indicated in an earlier e-mail. > >> > >> --Brandon > >> > >> On 01/08/2015 09:40 PM, Aijun Wang wrote: > >>> > >>> [Aijun]: There are two relay address, one is the TURN server > >>> well-known address, another is the relay address that allocated to > >>> each client. Which one should be used then? On the other hand, when > >>> client want to send traffic to other peer, it does not know whether > >>> the other part is under the same TURN server or not, how do it > >>> select > > this > >> information? > >>> > >> > >>> > >>> [Aijun]: as the definition in > >>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, > >>> the XOR-PEER-ADDRESS is the address seen from the TURN server, so it > >>> can't be used to find the relay address of the remote peer, and then > >>> can't be used to direct traffic to downstream relay. > >>> > >>> > >> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > > > > > > > > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Mon Jan 12 17:14:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6119A1ACE57 for ; Mon, 12 Jan 2015 17:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 RYRBhPyg7o7Z for ; Mon, 12 Jan 2015 17:14:47 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id ED3A71A8826 for ; Mon, 12 Jan 2015 17:14:45 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BL_QMOXLRUOgbPAA==.17715S4; Tue, 13 Jan 2015 07:43:28 +0800 (CST) From: "Aijun Wang" To: "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> In-Reply-To: Date: Tue, 13 Jan 2015 09:14:21 +0800 Message-ID: <002a01d02ece$4c063400$e4129c00$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01D02F11.5A297400" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAumR57Lu2j/rgmT7ypHYfWE5j3tAAM7SjA Content-Language: zh-cn X-CM-TRANSID: Z0GX06BL_QMOXLRUOgbPAA==.17715S4 X-Coremail-Antispam: 1U3129KBjvJXoW3GFW5GF45Xw45ury7XFy5Arb_yoWfuryfpF WF9ryay3WkJF1xAw15Zw409F1fu395WrZrJrn8Gr17Z393Jr10vrnxt3y5CFy7Gr95GFyY vrWjv3WDZ3WrAFJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjlmb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Gr0_Xr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r17MIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI 0_Jr0_GrUI43ZEXa7VU1RuWJUUUUU== Archived-At: Cc: tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:14:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01D02F11.5A297400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Justin: =20 Please refer to the reply below. =20 =20 From: Justin Uberti [mailto:juberti@google.com]=20 Sent: Tuesday, January 13, 2015 4:23 AM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang = wrote: Hi,=20 =20 Do you refer to the draft = http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN = draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does = not describe the situation that the communication peers select the = different public TURN server, and need the TURN server to relay the app = data(TURN to TURN). =20 That is just normal UDP.=20 =20 [Aijun]: For TURN to TURN situation, I am discussing it with the = Brandon, please refer to that thread. We should consider carefully for = the transport mechanism between A/TURN Server A; TURN Server A/TURN = Server B and TURN Server B/B when peer A want to talk to B via the two = TURN Server A/B. =20 In situation that mentioned in RETURN draft, Why not to let ICE or App = Server to select the appropriate TURN server(corporate private TURN = server or public TURN server) based on the information of the two = communication parts? This can even eliminate the solution of RETURN: = two peer will use the corporate TURN server when they are both within = corporate, and will use the public TURN server when one of them is = located outside the corporation? =20 a) The TURN server isn't needed when both endpoints are within the = enterprise. The TURN server sits on the enterprise border, and is used = for inter-enterprise traffic. b) The public TURN server may not be reachable from the enterprise. This = is why the corporate TURN server is needed on the border. c) The app may require use of its own TURN server for location privacy = purposes, so both TURN servers may be used in this case. =20 This is all spelled out in = https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-1. =20 [Aijun] Would you like to explain more detail about =E2=80=9Cbut using = only the enterprise's TURN server reveals information about the user = (e.g. organizational affiliation)=E2=80=9D, and how do you achieve this = goal via the RETURN mechanism? =20 Best Regards. =20 =20 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Sent: Monday, January 12, 2015 1:35 PM To: Aijun Wang; 'Justin Uberti' Cc: tram@ietf.org Subject: RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 As Justin has pointed out we will be updating the draft with more = details on the decisions that could be made by ICE and the application = to select the TURN server. TURN-in-TURN communication is already = explained in RETURN draft. =20 -Tiru =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Monday, January 12, 2015 7:08 AM To: Tirumaleswar Reddy (tireddy); 'Justin Uberti' Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Hi, Reddy and Justin: =20 I suggest the TURN server selection should be made by ICE, not the = client itself. This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision. =20 There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc. =20 Best Regards. =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, January 11, 2015 1:40 PM To: Justin Uberti Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Inline [TR] =20 From: Justin Uberti [ = mailto:juberti@google.com]=20 Sent: Sunday, January 11, 2015 2:17 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) = wrote: Hi Justin, =20 Enterprise-provided TURN server cannot provide location privacy may not = be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.=20 =20 We will have to discuss if TURN server can advertise that it can provide = location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC).=20 =20 The other problem not discussed in the draft is, what if the user wants = privacy against the calling site and let=E2=80=99s say uses Tor for = privacy. In this scenario app TURN server must not be selected. =20 RETURN handles this situation fine, since the traffic will be routed = through the network-provided TURN server before being routed to the app = TURN server. Of course, if the application does not try to provide = location privacy, only the network-provided TURN server will be used. =20 [TR] But the problem is how will the endpoint how if network-provided = TURN server can provide location privacy or not ? TURN server can convey this information in a new STUN attribute = to the client. =20 However, I think the user is much more likely to trust the application = than its network provider to provide privacy protection. =20 [TR] User may or may not trust the application server. = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses = users using privacy techniques like Tor so that app server does not = learn the user's IP address. The Poker example given in the above draft = explains that the users in the call do not trust the calling service. In = this case IdP ensures that even if malicious calling service replaces = the media addresses with its own addresses and replaces the certificate = fingerprint in SDP with its own certificate, IdP assertion would ensure = that the Poker site cannot act as man-in-middle device. In this = scenario user may not want to pick app provided TURN server. =20 -Tiru =20 =20 =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Friday, January 09, 2015 4:04 AM To: tram@ietf.org Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 At IETF 91, I promised to send feedback on this document, so here goes. =20 Generally, I think many of the issues mentioned in this document are = important, but the recommendations are confusing and possibly = contradictory; a developer with little knowledge of TURN will have a = hard time figuring out exactly what to do. Furthermore, many of the = properties discussed in this document are dynamic, and should be handled = by the ICE process, rather than in TURN server selection (for example, = the notion of RTT as it relates to user experience). =20 Therefore, I think this document should take a stronger stance and put = forth explicit best practices for selection (as opposed to "things to = consider"), for non-dynamic properties, and leave the decisions on = dynamic properties to be resolved by ICE.=20 =20 For example, I think we should omit the text in Section 3 about what to = do with non-working TURN servers, and measuring RTT. Same for Section = 3.3, which also discusses RTT, and Section 3.4, which talks about = multiple interfaces. This can all be handled by ICE. =20 In addition, the sections on local config and location privacy are = unnecessary when RETURN is used. When RETURN is used, the application = can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide on. =20 This leaves only the Security, Authentication, and Mobility sections.=20 =20 For security, I think we can give some clear guidance on what = applications should do. For security, I think the guidance should be to = use only DTLS + TLS, if both are available, with fallback to UDP or TCP = if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend this. =20 This relates to the Authentication section - but I think any failures to = authenticate the server cert should cause the TURN allocation to fail. = This is just like any other misconfiguration on the TURN server - = there's no reason we should even allow use of TURN servers whose cert = chains don't validate. So, this section could probably be removed. =20 Lastly, the Mobility section says that if "all other parameters [are] = equal", a TURN server with mobility should be used. Clearly, all other = parameters will not be equal (e.g. RTT), and even if they were, the = client has no way to know if a server is mobility-capable a priori. So I = think this recommendation ought to be removed, or perhaps turned into = some sort of recommendation for TURN server developers (e.g. TURN = servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support = redirect), probably in a separate doc. =20 These recommendations should reduce the size of this document and = provide much clearer advice to app developers. =20 =20 ------=_NextPart_000_002B_01D02F11.5A297400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Justin:

 

Please refer to the reply below.

 

 

From:= Justin = Uberti [mailto:juberti@google.com]
Sent: Tuesday, January 13, = 2015 4:23 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy = (tireddy); tram@ietf.org
Subject: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

=

 

 

 

On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi,

 

Do you refer to the draft http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.= txt as RETURN draft? This draft describes only TURN-in-TURN, not = TURN-to-TURN. It does not describe the situation that the communication = peers select the different public TURN server, and need the TURN server = to relay the app data(TURN to TURN).

 

That is just normal = UDP. 

 

[Aijun]: For TURN to TURN situation, I am discussing it with the = Brandon, please refer to that thread. =C2=A0We should consider carefully = for the transport mechanism between A/TURN Server A; TURN Server A/TURN = Server B and TURN Server B/B when peer A want to talk to B via the two = TURN Server A/B.

 

In situation that mentioned in RETURN draft, Why not to let ICE or = App Server to select the appropriate TURN server(corporate private TURN = server or public TURN server) based on the information of the two = communication parts? This can even eliminate the solution of  = RETURN:  two peer will use the corporate TURN server when they are = both within corporate, and will use the public TURN server when one of = them is located outside the corporation?

 

a) The TURN server isn't needed = when both endpoints are within the enterprise. The TURN server sits on = the enterprise border, and is used for inter-enterprise = traffic.

b) The public TURN server may not be reachable from the = enterprise. This is why the corporate TURN server is needed on the = border.

c) The app may require use of its own TURN server for = location privacy purposes, so both TURN servers may be used in this = case.

 

This is all spelled out in https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section= -1.

 

[Aijun] Would you like to explain more detail about =
=E2=80=9Cbut using =
only the enterprise's TURN server reveals information about the user =
(e.g. organizational affiliation)=E2=80=9D,=C2=A0 and how do you achieve this goal via the RETURN =
mechanism?

 

Best Regards.

 

 

From:= = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, = January 12, 2015 1:35 PM
To: Aijun Wang; 'Justin = Uberti'
Cc: tram@ietf.org
Subject: RE: [tram] = Comments on draft-patil-tram-turn-serv-selection-00

 

As Justin has pointed out we will be updating the draft with more = details on the decisions that could be made by ICE and the application = to select the TURN server. TURN-in-TURN communication is already = explained in RETURN draft.

 

-Tiru

 

From:= tram [mailto:tram-bounces@ietf.org] On Behalf Of = Aijun Wang
Sent: Monday, January 12, 2015 7:08 = AM
To: Tirumaleswar Reddy (tireddy); 'Justin = Uberti'
Cc: tram@ietf.org
Subject: Re: [tram] = Comments on draft-patil-tram-turn-serv-selection-00

 

Hi, Reddy and Justin:

 

I suggest the TURN server selection should be made by ICE, not the = client itself.  This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision.

 

There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc.

 

Best Regards.

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, = January 11, 2015 1:40 PM
To: Justin Uberti
Cc: = tram@ietf.or= g
Subje= ct: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

Inline [TR]

 

From:= Justin = Uberti [mailto:juber= ti@google.com] =
Sent: Sunday, January 11, 2015 2:17 AM
To: = Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.or= g
Subje= ct: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

 

 

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy = (tireddy) <tireddy@cisco.com> = wrote:

Hi Justin,

 

Enterprise-provided TURN server cannot provide location privacy may = not be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.

 

We will have to discuss if TURN server can advertise that it can = provide location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC). 

 

The other problem not discussed in the draft is, what if the user = wants privacy against the calling site and let=E2=80=99s say uses Tor = for privacy. In this scenario app TURN server must not be = selected.

 

RETURN handles this situation fine, since the traffic will = be routed through the network-provided TURN server before being routed = to the app TURN server. Of course, if the application does not try to = provide location privacy, only the network-provided TURN server will be = used.

 

[TR] But the problem is how will the endpoint how if = network-provided TURN server can provide location privacy or not = ?

         TURN = server can convey this information in a new STUN attribute to the = client.

 

However, I think the user is much more likely to trust the = application than its network provider to provide privacy = protection.

 

[TR] User may or may not trust the application server. https://tools.ietf.org/html/draft-ietf-rtcweb-security-= arch-10 discusses users using privacy techniques like Tor so that = app server does not learn the user's IP address. The Poker example given = in the above draft explains that the users in the call do not trust the = calling service. In this case IdP ensures that even if malicious calling = service replaces the media addresses with its own addresses  and = replaces the certificate fingerprint in SDP with its own certificate, = IdP assertion would ensure that the Poker site cannot act as =  man-in-middle device. In this scenario user may not want to pick = app provided TURN server.

 

-Tiru

 

 

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 = 4:04 AM
To: tram@ietf.or= g
Subje= ct: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

At IETF 91, I promised to send feedback on this document, = so here goes.

 

Generally, I think many of the issues mentioned in this = document are important, but the recommendations are confusing and = possibly contradictory; a developer with little knowledge of TURN will = have a hard time figuring out exactly what to do. Furthermore, many of = the properties discussed in this document are dynamic, and should be = handled by the ICE process, rather than in TURN server selection (for = example, the notion of RTT as it relates to user = experience).

 

Therefore, I think this document should take a stronger = stance and put forth explicit best practices for selection (as opposed = to "things to consider"), for non-dynamic properties, and = leave the decisions on dynamic properties to be resolved by = ICE. 

 

For example, I think we should omit the text in Section 3 = about what to do with non-working TURN servers, and measuring RTT. Same = for Section 3.3, which also discusses RTT, and Section 3.4, which talks = about multiple interfaces. This can all be handled by = ICE.

 

In addition, the sections on local config and location = privacy are unnecessary when RETURN is used. When RETURN is used, the = application can always use the app TURN server for location privacy, and = the relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide = on.

 

This leaves only the Security, Authentication, and Mobility = sections. 

 

For security, I think we can give some clear guidance on = what applications should do. For security, I think the guidance should = be to use only DTLS + TLS, if both are available, with fallback to UDP = or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend = this.

 

This relates to the Authentication section - but I think = any failures to authenticate the server cert should cause the TURN = allocation to fail. This is just like any other misconfiguration on the = TURN server - there's no reason we should even allow use of TURN servers = whose cert chains don't validate. So, this section could probably be = removed.

 

Lastly, the Mobility section says that if "all other = parameters [are] equal", a TURN server with mobility should be = used. Clearly, all other parameters will not be equal (e.g. RTT), and = even if they were, the client has no way to know if a server is = mobility-capable a priori. So I think this recommendation ought to be = removed, or perhaps turned into some sort of recommendation for TURN = server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD = support mobility, SHOULD support redirect), probably in a separate = doc.

 

These recommendations should reduce the size of this = document and provide much clearer advice to app = developers.

 

 

<= /html> ------=_NextPart_000_002B_01D02F11.5A297400-- From nobody Mon Jan 12 17:29:29 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120BB1A883A for ; Mon, 12 Jan 2015 17:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 9vupz0Km4oDG for ; Mon, 12 Jan 2015 17:29:25 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 438001A8832 for ; Mon, 12 Jan 2015 17:29:24 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BL6QN8X7RUXTzLAA==.18380S4; Tue, 13 Jan 2015 07:58:05 +0800 (CST) From: "Aijun Wang" To: "'Pal Martinsen \(palmarti\)'" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <945F0E46-220B-4D09-95B5-E933043CCD09@cisco.com> In-Reply-To: <945F0E46-220B-4D09-95B5-E933043CCD09@cisco.com> Date: Tue, 13 Jan 2015 09:28:59 +0800 Message-ID: <003c01d02ed0$56ebbeb0$04c33c10$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQLlYD1vVpMOw2XUifqgCvgED9WZy9QI/Q Content-Language: zh-cn X-CM-TRANSID: Z0GX06BL6QN8X7RUXTzLAA==.18380S4 X-Coremail-Antispam: 1U3129KBjvJXoW3GFyxJw17Kr4UJFW8WF17ZFb_yoW7WrWrpr WFqFW3KF4kJr17Cw4ktw4xuF1Y93ykXrW7Wr15tr97Za90gF1ayF42gw15WryDGr4rWa4j vr4j93W7u3ZYyrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjllb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY 1x0267AKxVWUJVW8JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4U0xZFpf9x0JUCD73UUUUU= Archived-At: Cc: tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:29:27 -0000 Hi, Pal: Please see the reply inline. Best Regards. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen > (palmarti) > Sent: Monday, January 12, 2015 6:54 PM > To: Aijun Wang > Cc: tram@ietf.org; Brandon Williams > Subject: Re: [tram] New Version Notification for > draft-williams-peer-redirect-02.txt >=20 > Hi Aijun, >=20 > TURN was originally written as a backup service when ICE fails. It = also did > provide fallback when ICE clients wanted to talk to non-ICE clients = (But then the > default candidate must be set to the relay address. The point is that = the > allocated public RELAY address on the turn server works as a normal = UDP (or > TCP if that is in use) port. That means that any client can send its = RTP packet or > whatever as normal without any knowledge regarding TURN.As long as the > client have installed the necessary permissions. [Aijun]: I agree with it. This is also the mechanism used by current = TURN solution.=20 >=20 > If the to TURN servers are needed due to restricting FWs the traffic = between > the two public RELAY addresses will be pure UDP or TCP. No need for = any > additional information. [Aijun]: We should consider not only the communication between the two = TURN Servers, but also the procedures from the second TURN server to the = destination peer. For more detail discuss, please refer to my previous = mail to Brandon, we can discuss it together with that thread. >=20 > With ICE it might be possible to end up with asymmetrical routing. Not = sure > how common that is. I am inclined to blame the network if that occurs, = ICE only > probes and ties to get the packets through. >=20 [Aijun]: The problem of asymmetrical routing is raised by the current = ICE/TURN solution, not the fault of network. > I do not understand what you are trying to solve below. [Aijun]: Brandon illustrates one good graph for the possible problem = that I mentioned here, please refer to it for our ongoing discussion. >=20 > .-. > P=C3=A5l-Erik >=20 > > On 12 Jan 2015, at 01:43, Aijun Wang = wrote: > > > > Hi, Brandon: > > > > In = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, > > it is described as below: > > > > When forming a Send indication, the client MUST include an XOR-PEER- > > ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS > > attribute contains the transport address of the peer to which the > > data is to be sent, and the DATA attribute contains the actual > > application data to be sent to the peer. > > > > So, there is no XOR-RELAYED-ADDRESS attribute included to identify = the > > peer's allocated relay address. On the other hand, = XOR-RELAYED-ADDRESS > > is mainly refer to the requester's allocated relay address, not the > > corresponding peer. Will we define again one new attribute, such as > > XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's > information? > > > > Even if so, what will be the source address for the packet from the > > second TURN server to destination peer? If we use the > > XOR-RELAYED-ADDRESS, then the return packet from the peer will be > > passed back directly to the first TURN server, results in > > non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what = is > > the source address for the packet from the second TURN server back = to the > first TURN server? > > > > Best Regards. > > > >> -----Original Message----- > >> From: Brandon Williams [mailto:bowill@akamai.com] > >> Sent: Saturday, January 10, 2015 1:09 AM > >> To: Aijun Wang; tram@ietf.org > >> Subject: Re: [tram] Fwd: New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> > >> By relay address, I mean the XOR-RELAYED-ADDRESS returned in the > > allocation > >> request. This clearly identifies the true source and destination = for > >> the > > data in > >> the packet as well as the two relay servers involved. If both = relayed > > addresses > >> are on the same server, it will of course know that and be able to > > optimize as > >> Simon indicated in an earlier e-mail. > >> > >> --Brandon > >> > >> On 01/08/2015 09:40 PM, Aijun Wang wrote: > >>> > >>> [Aijun]: There are two relay address, one is the TURN server > >>> well-known address, another is the relay address that allocated to > >>> each client. Which one should be used then? On the other hand, = when > >>> client want to send traffic to other peer, it does not know = whether > >>> the other part is under the same TURN server or not, how do it > >>> select > > this > >> information? > >>> > >> > >>> > >>> [Aijun]: as the definition in > >>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3, > >>> the XOR-PEER-ADDRESS is the address seen from the TURN server, so = it > >>> can't be used to find the relay address of the remote peer, and = then > >>> can't be used to direct traffic to downstream relay. > >>> > >>> > >> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jan 13 00:38:59 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863C01A8A08 for ; Tue, 13 Jan 2015 00:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4OMycmlUaaGk for ; Tue, 13 Jan 2015 00:38:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7481A8984 for ; Tue, 13 Jan 2015 00:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9180; q=dns/txt; s=iport; t=1421138336; x=1422347936; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FNiquXoI10hK9mM6nXWq7lpY9wa2joCatxQzw9KIw8M=; b=e3QNYh5N+Cwo/a4S00Dz24qzA5nC8GePlCr3EjmlTREaQxpGorG/iJxM GD9Bs8T4tWu9KvziMgkKGvPJj9HbIFT5+lBhReSLWW6YX+563pqfxs8BX DSwYCNGk6ZyvFMw1N8bECSJ/I5JgwRxCC3LaL3qXr4uijVyy8Z3Vd8n1H 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4HAEnYtFStJA2G/2dsb2JhbABRCoMGUlgEgwHDAQqFcQIcdkMBAQEBAX2EDAEBAQMBAQEBIAQNOgkCBQcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQKBAWIJAgNuSKTaQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIY18KRgbBwaCYi6BEwWOPYNFhUiBDzCMf4M6IoNubwGBAgc7fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,748,1413244800"; d="scan'208";a="386490477" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 13 Jan 2015 08:38:54 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0D8crVa025988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 08:38:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 02:38:53 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] New Version Notification for draft-williams-peer-redirect-02.txt Thread-Index: AQHQLwxct8FzPZ1uJUeScTzmsc+WHA== Date: Tue, 13 Jan 2015 08:38:53 +0000 Message-ID: <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> In-Reply-To: <002901d02eca$f8d75f00$ea861d00$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.136] Content-Type: text/plain; charset="utf-8" Content-ID: <71B624A0DAE62C45AABCE43E75D32C1D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:38:58 -0000 DQo+IE9uIDEzIEphbiAyMDE1LCBhdCAwMTo1MCwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4gd3JvdGU6DQo+IA0KPiBIaSwgQnJhbmRvbg0KPiANCj4gVGhhbmtzIGZvciB5 b3VyIHZpdmlkIGdyYXBoIGZvciBvdXIgZGlzY3Vzc2lvbi4gVHdvIHF1ZXN0aW9ucyBhcmUgcmFp c2VkDQo+IGhlcmU6DQo+IA0KPiAxLiBIb3cgZG9lcyBUVVJOIHNlcnZlciBBIGRlY2lkZSB3aGVu IHRvIHVzZSBVRFAgdG8gc2VuZCBhcHAgZGF0YSwgYW5kIHdoZW4NCj4gdG8gdXNlIFRVUk4gdG8g c2VuZCBhcHAgZGF0YT8gV2hpY2ggY3JpdGVyaWEgY2FuIGFzc2lzdGFudCB0aGUgVFVSTiBzZXJ2 ZXIgQQ0KPiB0byBtYWtlIHRoaXMgZGVjaXNpb24/DQo+IEluIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTAuMiwgaXQNCj4gZGVz Y3JpYmVzIHRoZSBUVVJOIHNlcnZlciB3aWxsIHNlbmQgVURQIHJhdyBwYWNrZXQgdG8gdGhlIHBl ZXIsIHJlZ2FyZGxlc3MNCj4gdGhlIHBlZXIgaXMgYXdhcmVuZXNzIG9yIHVuYXdhcmVuZXNzIHRo ZSBleGlzdGVuY2Ugb2YgVFVSTi4NCj4gDQoNClRVUk4gc2V2ZXIgQSBzZW5kcyDigJxhcHAgZGF0 YeKAnSB0byBjbGllbnQgQS4gVGhpcyBpcyB0aGUg4oCccHJpdmF0ZeKAnSBzaWRlIG9mIHRoZSBU VVJOIHNlcnZlci4gVFVSTiBzZXJ2ZXIgQSBzZW5kcyBUVVJOIGVuY2Fwc3VsYXRlZCBkYXRhIChk YXRhIGluZCBvciBjaGFubmVsKSBiYWNrIHRvIGNsaWVudCBBIHVzaW5nIHRoZSBzYW1lIDUgdHVw bGUgY2xpZW50IEEgdXNlZCB0byBzZW5kIGhpcyBhbGxvY2F0ZSByZXF1ZXN0LiBUVVJOIGFsbG93 cyB0aGUgY2xpZW50IHRvIHVzZSBVRFAsIFRDUCBvciBUTFMgdG8gZG8gdGhpcy4gDQoNCldoYXQg aGFwcGVucyBvbiB0aGUg4oCccHVibGlj4oCdIHNpZGUgb2YgdGhlIFRVUk4gc2VydmVyIGlzIGFs d2F5cyBVRFAgKFVubGVzcyB0aGUgVFVSTiBzZXJ2ZXIgc3VwcG9ydHMgVFVSTi1UQ1AgYW5kIHRo ZSBjbGllbnQgaGF2ZSBhc2tlZCBmb3IgYSBUQ1AgcG9ydCBhbGxvY2F0aW9uKS4gDQoNClRoZSBy ZW1vdGUgc2lkZSBkbyBub3QgbmVlZCB0byBrbm93IHRoYXQgaXQgaXMgc2VuZGluZyBwYWNrZXRz IHRvIGEgVFVSTiBzZXJ2ZXIsIGFuZCB0aGF0IHRoZSBwYWNrZXRzIHdvdWxkIOKAnG1hZ2ljYWxs eeKAnSBiZSBzZW50IHRvIHRoZSBjbGllbnQgdGhhdCBhbGxvY2F0ZWQgdGhhdCBwb3J0LiBUaGlu ayBvZiBUVVJOIGFzIGEgbWVjaGFuaXNtIHRvIG1vdmUgeW91ciBib3ggb3V0IG9uIHRoZSBJbnRl cm5ldCBhbmQgb2J0YWluaW5nIHB1YmxpYyByb3V0YWJsZSBJUC4gIA0KDQoNCj4gMi4gSW4geW91 ciBleGFtcGxlLCBpZiBUVVJOIEIgdXNlIHRoZSBEQVRBIGluZGljYXRpb24gdG8gQiwgd2hhdCB3 aWxsIEIgZG8NCj4gaWYgaXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgVFVSTiBlbmNhcHN1bGF0aW9u Pw0KPiANClRoZXJlIGlzIG5vIHdheSBhIFRVUk4gc2VydmVyIHdvdWxkIHNlbmQgZGF0YSBpbmQg dG8gYSBjbGllbnQgd2l0aG91dCB0aGUgY2xpZW50IGhhdmluZyBhbGxvY2F0ZWQgYSBwb3J0Lg0K V2l0aG91dCBjbGllbnQgQiBzZW5kaW5nIHRoZSBhbGxvY2F0ZSByZXF1ZXN0IHRoZXJlIHdvdWxk IG5vdCBiZSBhIGJpbmRpbmcgaW4gdGhlIE5BVCBlaXRoZXIuIA0KDQouLS4NClDDpWwtRXJpaw0K DQoNCj4gQmVzdCBSZWdhcmRzLiANCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IEJyYW5kb24gV2lsbGlhbXMgW21haWx0bzpicmFuZG9uLndpbGxpYW1zQGFr YW1haS5jb21dDQo+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMTIsIDIwMTUgMTE6NDUgUE0NCj4+ IFRvOiBBaWp1biBXYW5nOyB0cmFtQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3RyYW1dIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4gZHJhZnQtd2lsbGlhbXMtcGVlci1y ZWRpcmVjdC0wMi50eHQNCj4+IA0KPj4gWE9SLVBFRVItQUREUkVTUyBjb250YWlucyAidGhlIHRy YW5zcG9ydCBhZGRyZXNzIG9mIHRoZSBwZWVyIi4gSXQgaXMgbm90DQo+PiByZXF1aXJlZCB0byBi ZSBhIHNwZWNpZmljIHR5cGUgb2YgYWRkcmVzcyAoaG9zdCwgcmVmbGV4aXZlLCBvciByZWxheSku DQo+PiBJdCB3aWxsIGJlIGFueSBhZGRyZXNzIHRoYXQgY2FuIGJlIHVzZWQgdG8gZGVsaXZlciBk YXRhIHRvIHRoZSByZW1vdGUNCj4gcGVlci4gSWYNCj4+IHR3byBUVVJOIHJlbGF5cyBhcmUgdXNl ZCwgdGhlbiB0aGUgWE9SLVBFRVItQUREUkVTUyBhdHRyaWJ1dGUgaW4gU2VuZCBhbmQNCj4+IERh dGEgaW5kaWNhdGlvbnMgd2lsbCBjb250YWluIHRoZSByZW1vdGUgcGVlcidzIGFsbG9jYXRlZCBy ZWxheSBhZGRyZXNzLg0KPiBUaGVyZQ0KPj4gaXMgbm8gbmVlZCB0aGUgZm9yIGVpdGhlciBvZiB0 aGUgcmVsYXlzIHRvIGV2ZW4gYmUgYXdhcmUgdGhhdCB0aGUNCj4gdHJhbnNwb3J0DQo+PiBhZGRy ZXNzIGlzIGEgcmVsYXkgYWRkcmVzcy4NCj4+IA0KPj4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZzoN Cj4+IA0KPj4gQSA8LT4gWEEgPC0+IFRBfFJBIDwtPiBSQnxUQiA8LT4gWEIgPC0+IEINCj4+IHwg ICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+PiB8LS0tLSBUVVJOIC0t LS18LS0gVURQIC0tfC0tLS0gVFVSTiAtLS0tfA0KPj4gDQo+PiBBIGFuZCBCIGFyZSB0aGUgdHdv IHBlZXJzJyBob3N0IGFkZHJlc3Nlcy4NCj4+IFhBIGFuZCBYQiBhcmUgdGhlIHR3byBwZWVycycg cmVmbGV4aXZlIGFkZHJlc3Nlcy4NCj4+IFRBIGFuZCBUQiBhcmUgdGhlIHJlbGF5IHNlcnZlcnMn IGFkZHJlc3NlcyB1c2VkIGFzIHRoZSBUVVJOIHNlc3Npb24NCj4+IGVuZHBvaW50cy4NCj4+IFJB IGFuZCBSQiBhcmUgdGhlIHR3byBwZWVycycgYWxsb2NhdGVkIHJlbGF5IGFkZHJlc3Nlcy4NCj4+ IA0KPj4gQSBTZW5kIGluZGljYXRpb24gZnJvbSBBIHRvIFRBIHVzZXMgUkIgYXMgdGhlIFhPUi1Q RUVSLUFERFJFU1MuIFdoZW4gQSdzDQo+PiByZWxheSByZWNlaXZlcyB0aGUgU2VuZCBpbmRpY2F0 aW9uLCBpdCBzZW5kcyB0aGUgZGF0YSBpbiBhIHBsYWluIFVEUA0KPiBkYXRhZ3JhbQ0KPj4gd2l0 aCBSQSBhcyB0aGUgc291cmNlIGFuZCBSQiBhcyB0aGUgZGVzdGluYXRpb24uIFdoZW4gQidzIHJl bGF5IHJlY2VpdmVzDQo+IHRoZQ0KPj4gVURQIGRhdGFncmFtLCBpdCBzZW5kcyBhIERhdGEgaW5k aWNhdGlvbiBmcm9tIFRCIHRvIEIgd2l0aCBSQSBhcyB0aGUNCj4+IFhPUi1QRUVSLUFERFJFU1Mu DQo+PiANCj4+IC0tQnJhbmRvbg0KPj4gDQo+PiBPbiAwMS8xMS8yMDE1IDA3OjQzIFBNLCBBaWp1 biBXYW5nIHdyb3RlOg0KPj4+IEhpLCBCcmFuZG9uOg0KPj4+IA0KPj4+IEluIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTAuMSwN Cj4+PiBpdCBpcyBkZXNjcmliZWQgYXMgYmVsb3c6DQo+Pj4gDQo+Pj4gV2hlbiBmb3JtaW5nIGEg U2VuZCBpbmRpY2F0aW9uLCB0aGUgY2xpZW50IE1VU1QgaW5jbHVkZSBhbiBYT1ItUEVFUi0NCj4+ PiAgICBBRERSRVNTIGF0dHJpYnV0ZSBhbmQgYSBEQVRBIGF0dHJpYnV0ZS4gIFRoZSBYT1ItUEVF Ui1BRERSRVNTDQo+Pj4gICAgYXR0cmlidXRlIGNvbnRhaW5zIHRoZSB0cmFuc3BvcnQgYWRkcmVz cyBvZiB0aGUgcGVlciB0byB3aGljaCB0aGUNCj4+PiAgICBkYXRhIGlzIHRvIGJlIHNlbnQsIGFu ZCB0aGUgREFUQSBhdHRyaWJ1dGUgY29udGFpbnMgdGhlIGFjdHVhbA0KPj4+ICAgIGFwcGxpY2F0 aW9uIGRhdGEgdG8gYmUgc2VudCB0byB0aGUgcGVlci4NCj4+PiANCj4+PiBTbywgdGhlcmUgaXMg bm8gWE9SLVJFTEFZRUQtQUREUkVTUyBhdHRyaWJ1dGUgaW5jbHVkZWQgdG8gaWRlbnRpZnkgdGhl DQo+Pj4gcGVlcidzIGFsbG9jYXRlZCByZWxheSBhZGRyZXNzLiBPbiB0aGUgb3RoZXIgaGFuZCwg WE9SLVJFTEFZRUQtQUREUkVTUw0KPj4+IGlzIG1haW5seSByZWZlciB0byB0aGUgcmVxdWVzdGVy J3MgYWxsb2NhdGVkIHJlbGF5IGFkZHJlc3MsIG5vdCB0aGUNCj4+PiBjb3JyZXNwb25kaW5nIHBl ZXIuIFdpbGwgd2UgZGVmaW5lIGFnYWluIG9uZSBuZXcgYXR0cmlidXRlLCBzdWNoIGFzDQo+Pj4g WE9SLVBFRVItUkVMQVlFRC1BRERSRVNTIHRvIHRyYW5zZmVyIHRoZSBuZXh0IFRVUk4gc2VydmVy J3MNCj4+IGluZm9ybWF0aW9uPw0KPj4+IA0KPj4+IEV2ZW4gaWYgc28sIHdoYXQgd2lsbCBiZSB0 aGUgc291cmNlIGFkZHJlc3MgZm9yIHRoZSBwYWNrZXQgZnJvbSB0aGUNCj4+PiBzZWNvbmQgVFVS TiBzZXJ2ZXIgdG8gZGVzdGluYXRpb24gcGVlcj8gSWYgd2UgdXNlIHRoZQ0KPj4+IFhPUi1SRUxB WUVELUFERFJFU1MsIHRoZW4gdGhlIHJldHVybiBwYWNrZXQgZnJvbSB0aGUgcGVlciB3aWxsIGJl DQo+Pj4gcGFzc2VkIGJhY2sgZGlyZWN0bHkgdG8gdGhlIGZpcnN0IFRVUk4gc2VydmVyLCByZXN1 bHRzIGluDQo+Pj4gbm9uLXN5bW1ldHJpYyByb3V0ZS4gSWYgd2UgdXNlIFhPUi1QRUVSLVJFTEFZ RUQtQUREUkVTUywgdGhlbiB3aGF0IGlzDQo+Pj4gdGhlIHNvdXJjZSBhZGRyZXNzIGZvciB0aGUg cGFja2V0IGZyb20gdGhlIHNlY29uZCBUVVJOIHNlcnZlciBiYWNrIHRvDQo+IHRoZQ0KPj4gZmly c3QgVFVSTiBzZXJ2ZXI/DQo+Pj4gDQo+Pj4gQmVzdCBSZWdhcmRzLg0KPj4+IA0KPj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFttYWls dG86Ym93aWxsQGFrYW1haS5jb21dDQo+Pj4+IFNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEwLCAy MDE1IDE6MDkgQU0NCj4+Pj4gVG86IEFpanVuIFdhbmc7IHRyYW1AaWV0Zi5vcmcNCj4+Pj4gU3Vi amVjdDogUmU6IFt0cmFtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+Pj4g ZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRpcmVjdC0wMi50eHQNCj4+Pj4gDQo+Pj4+IEJ5IHJlbGF5 IGFkZHJlc3MsIEkgbWVhbiB0aGUgWE9SLVJFTEFZRUQtQUREUkVTUyByZXR1cm5lZCBpbiB0aGUN Cj4+PiBhbGxvY2F0aW9uDQo+Pj4+IHJlcXVlc3QuIFRoaXMgY2xlYXJseSBpZGVudGlmaWVzIHRo ZSB0cnVlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gZm9yDQo+Pj4+IHRoZQ0KPj4+IGRhdGEgaW4N Cj4+Pj4gdGhlIHBhY2tldCBhcyB3ZWxsIGFzIHRoZSB0d28gcmVsYXkgc2VydmVycyBpbnZvbHZl ZC4gSWYgYm90aCByZWxheWVkDQo+Pj4gYWRkcmVzc2VzDQo+Pj4+IGFyZSBvbiB0aGUgc2FtZSBz ZXJ2ZXIsIGl0IHdpbGwgb2YgY291cnNlIGtub3cgdGhhdCBhbmQgYmUgYWJsZSB0bw0KPj4+IG9w dGltaXplIGFzDQo+Pj4+IFNpbW9uIGluZGljYXRlZCBpbiBhbiBlYXJsaWVyIGUtbWFpbC4NCj4+ Pj4gDQo+Pj4+IC0tQnJhbmRvbg0KPj4+PiANCj4+Pj4gT24gMDEvMDgvMjAxNSAwOTo0MCBQTSwg QWlqdW4gV2FuZyB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gW0FpanVuXTogVGhlcmUgYXJlIHR3byBy ZWxheSBhZGRyZXNzLCBvbmUgaXMgdGhlIFRVUk4gc2VydmVyDQo+Pj4+PiB3ZWxsLWtub3duIGFk ZHJlc3MsIGFub3RoZXIgaXMgdGhlIHJlbGF5IGFkZHJlc3MgdGhhdCBhbGxvY2F0ZWQgdG8NCj4+ Pj4+IGVhY2ggY2xpZW50LiBXaGljaCBvbmUgc2hvdWxkIGJlIHVzZWQgdGhlbj8gT24gdGhlIG90 aGVyIGhhbmQsIHdoZW4NCj4+Pj4+IGNsaWVudCB3YW50IHRvIHNlbmQgdHJhZmZpYyB0byBvdGhl ciBwZWVyLCBpdCBkb2VzIG5vdCBrbm93IHdoZXRoZXINCj4+Pj4+IHRoZSBvdGhlciBwYXJ0IGlz IHVuZGVyIHRoZSBzYW1lIFRVUk4gc2VydmVyIG9yIG5vdCwgaG93IGRvIGl0DQo+Pj4+PiBzZWxl Y3QNCj4+PiB0aGlzDQo+Pj4+IGluZm9ybWF0aW9uPw0KPj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiBbQWlqdW5dOiBhcyB0aGUgZGVmaW5pdGlvbiBpbg0KPj4+Pj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbi0xNC4zLA0KPj4+ Pj4gdGhlIFhPUi1QRUVSLUFERFJFU1MgaXMgdGhlIGFkZHJlc3Mgc2VlbiBmcm9tIHRoZSBUVVJO IHNlcnZlciwgc28gaXQNCj4+Pj4+IGNhbid0IGJlIHVzZWQgdG8gZmluZCB0aGUgcmVsYXkgYWRk cmVzcyBvZiB0aGUgcmVtb3RlIHBlZXIsIGFuZCB0aGVuDQo+Pj4+PiBjYW4ndCBiZSB1c2VkIHRv IGRpcmVjdCB0cmFmZmljIHRvIGRvd25zdHJlYW0gcmVsYXkuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ PiANCj4+Pj4gDQo+Pj4+IC0tDQo+Pj4+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lw YWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4+Pj4gUHJvZHVjdHMgRW5naW5lZXJpbmc7 IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiAtLQ0K Pj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBF bWVyZ2luZyBQcm9kdWN0cw0KPj4gRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5j Lg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= From nobody Tue Jan 13 01:29:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8E1ACDDE for ; Tue, 13 Jan 2015 01:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 PldoG68A4Em2 for ; Tue, 13 Jan 2015 01:29:13 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id AAAD81A1B37 for ; Tue, 13 Jan 2015 01:29:11 -0800 (PST) Received: from ctbriwangaij (unknown [106.120.0.77]) by app1 (Coremail) with SMTP id Z0GX06C73wHgz7RUUmzMAA==.35013S4; Tue, 13 Jan 2015 15:57:40 +0800 (CST) From: "Aijun Wang" To: "'Pal Martinsen \(palmarti\)'" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> In-Reply-To: <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> Date: Tue, 13 Jan 2015 17:28:36 +0800 Message-ID: <00a101d02f13$575f1e80$061d5b80$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQLwxct8FzPZ1uJUeScTzmsc+WHJy9wL9A Content-Language: zh-cn X-CM-TRANSID: Z0GX06C73wHgz7RUUmzMAA==.35013S4 X-Coremail-Antispam: 1U3129KBjvJXoW3Gr4kAryrCF13uFW7uw48Zwb_yoW3Aw43pr WaqFW3K3WDJr17Jws2qr1j9F1Y9395Xry3Wrn8tr1xua9IqF12yF12kw1rua4UGr1rWa4j vr1j9a47uFn8ArJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: Cc: tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 09:29:15 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen > (palmarti) > Sent: Tuesday, January 13, 2015 4:39 PM > To: Aijun Wang > Cc: tram@ietf.org; Brandon Williams > Subject: Re: [tram] New Version Notification for > draft-williams-peer-redirect-02.txt >=20 >=20 > > On 13 Jan 2015, at 01:50, Aijun Wang = wrote: > > > > Hi, Brandon > > > > Thanks for your vivid graph for our discussion. Two questions are > > raised > > here: > > > > 1. How does TURN server A decide when to use UDP to send app data, = and > > when to use TURN to send app data? Which criteria can assistant the > > TURN server A to make this decision? > > In = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2, > > it describes the TURN server will send UDP raw packet to the peer, > > regardless the peer is awareness or unawareness the existence of = TURN. > > >=20 > TURN sever A sends =E2=80=9Capp data=E2=80=9D to client A. This is the = =E2=80=9Cprivate=E2=80=9D side of the > TURN server. TURN server A sends TURN encapsulated data (data ind or > channel) back to client A using the same 5 tuple client A used to send = his > allocate request. TURN allows the client to use UDP, TCP or TLS to do = this. >=20 > What happens on the =E2=80=9Cpublic=E2=80=9D side of the TURN server = is always UDP (Unless > the TURN server supports TURN-TCP and the client have asked for a TCP = port > allocation). >=20 > The remote side do not need to know that it is sending packets to a = TURN > server, and that the packets would =E2=80=9Cmagically=E2=80=9D be sent = to the client that > allocated that port. Think of TURN as a mechanism to move your box out = on the > Internet and obtaining public routable IP. >=20 I agree with you at these points. But my concern focus on the = communication channel between TURN Server A/TURN Server B and TURN = B/Peer B. In current TURN draft, they all use the pure UDP packet. But = in Brandon's graph, they are different: the previous pair use pure UDP = datagram, but the latter pair use DATA indication, which is not = described in current TURN draft, and will lead the TURN server A be = confused, because it might face the TURN Server B and other = communication peer, such as peer C that directly connected on the TURN = server A. Which encapsulation method will be used then? >=20 > > 2. In your example, if TURN B use the DATA indication to B, what = will > > B do if it does not support the TURN encapsulation? > > > There is no way a TURN server would send data ind to a client without = the > client having allocated a port. > Without client B sending the allocate request there would not be a = binding in > the NAT either. >=20 Actually true. But my concern here focus still on the data forwarding = plane, not the control plane of TURN solution.=20 > .-. > P=C3=A5l-Erik >=20 >=20 > > Best Regards. > > > > > >> -----Original Message----- > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >> Sent: Monday, January 12, 2015 11:45 PM > >> To: Aijun Wang; tram@ietf.org > >> Subject: Re: [tram] Fwd: New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> > >> XOR-PEER-ADDRESS contains "the transport address of the peer". It = is > >> not required to be a specific type of address (host, reflexive, or = relay). > >> It will be any address that can be used to deliver data to the = remote > > peer. If > >> two TURN relays are used, then the XOR-PEER-ADDRESS attribute in = Send > >> and Data indications will contain the remote peer's allocated relay = address. > > There > >> is no need the for either of the relays to even be aware that the > > transport > >> address is a relay address. > >> > >> Consider the following: > >> > >> A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B > >> | | | | > >> |---- TURN ----|-- UDP --|---- TURN ----| > >> > >> A and B are the two peers' host addresses. > >> XA and XB are the two peers' reflexive addresses. > >> TA and TB are the relay servers' addresses used as the TURN session > >> endpoints. > >> RA and RB are the two peers' allocated relay addresses. > >> > >> A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. = When > >> A's relay receives the Send indication, it sends the data in a = plain > >> UDP > > datagram > >> with RA as the source and RB as the destination. When B's relay > >> receives > > the > >> UDP datagram, it sends a Data indication from TB to B with RA as = the > >> XOR-PEER-ADDRESS. > >> > >> --Brandon > >> > >> On 01/11/2015 07:43 PM, Aijun Wang wrote: > >>> Hi, Brandon: > >>> > >>> In > >>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, > >>> it is described as below: > >>> > >>> When forming a Send indication, the client MUST include an = XOR-PEER- > >>> ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS > >>> attribute contains the transport address of the peer to which = the > >>> data is to be sent, and the DATA attribute contains the actual > >>> application data to be sent to the peer. > >>> > >>> So, there is no XOR-RELAYED-ADDRESS attribute included to identify > >>> the peer's allocated relay address. On the other hand, > >>> XOR-RELAYED-ADDRESS is mainly refer to the requester's allocated > >>> relay address, not the corresponding peer. Will we define again = one > >>> new attribute, such as XOR-PEER-RELAYED-ADDRESS to transfer the = next > >>> TURN server's > >> information? > >>> > >>> Even if so, what will be the source address for the packet from = the > >>> second TURN server to destination peer? If we use the > >>> XOR-RELAYED-ADDRESS, then the return packet from the peer will be > >>> passed back directly to the first TURN server, results in > >>> non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what > >>> is the source address for the packet from the second TURN server > >>> back to > > the > >> first TURN server? > >>> > >>> Best Regards. > >>> > >>>> -----Original Message----- > >>>> From: Brandon Williams [mailto:bowill@akamai.com] > >>>> Sent: Saturday, January 10, 2015 1:09 AM > >>>> To: Aijun Wang; tram@ietf.org > >>>> Subject: Re: [tram] Fwd: New Version Notification for > >>>> draft-williams-peer-redirect-02.txt > >>>> > >>>> By relay address, I mean the XOR-RELAYED-ADDRESS returned in the > >>> allocation > >>>> request. This clearly identifies the true source and destination > >>>> for the > >>> data in > >>>> the packet as well as the two relay servers involved. If both > >>>> relayed > >>> addresses > >>>> are on the same server, it will of course know that and be able = to > >>> optimize as > >>>> Simon indicated in an earlier e-mail. > >>>> > >>>> --Brandon > >>>> > >>>> On 01/08/2015 09:40 PM, Aijun Wang wrote: > >>>>> > >>>>> [Aijun]: There are two relay address, one is the TURN server > >>>>> well-known address, another is the relay address that allocated = to > >>>>> each client. Which one should be used then? On the other hand, > >>>>> when client want to send traffic to other peer, it does not know > >>>>> whether the other part is under the same TURN server or not, how > >>>>> do it select > >>> this > >>>> information? > >>>>> > >>>> > >>>>> > >>>>> [Aijun]: as the definition in > >>>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3 > >>>>> , the XOR-PEER-ADDRESS is the address seen from the TURN server, > >>>>> so it can't be used to find the relay address of the remote = peer, > >>>>> and then can't be used to direct traffic to downstream relay. > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Brandon Williams; Senior Principal Software Engineer Emerging > >>>> Products Engineering; Akamai Technologies Inc. > >>> > >>> > >>> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jan 13 07:18:30 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619461A8AA9 for ; Tue, 13 Jan 2015 07:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OO1Qw-HVklmC for ; Tue, 13 Jan 2015 07:18:25 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 79AB71A1EF2 for ; Tue, 13 Jan 2015 07:18:25 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 1DD7723F04E7; Tue, 13 Jan 2015 16:18:24 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.138]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 16:18:23 +0100 From: "Hutton, Andrew" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] TURN over WebSocket Thread-Index: AQHQLBm4lcIv0Bx07EWTTt3vkrz2jpy+L7Dg Date: Tue, 13 Jan 2015 15:18:22 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E66A5A9@MCHP04MSX.global-ad.net> References: <54AFE781.5060804@akamai.com> In-Reply-To: <54AFE781.5060804@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] TURN over WebSocket X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 15:18:27 -0000 Also sounds good to me and I am in agreement with Brendon and Justin that t= he problem statement needs to be clearer. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: 09 January 2015 14:37 > To: tram@ietf.org > Subject: Re: [tram] TURN over WebSocket >=20 > Sounds good. >=20 > On 01/08/2015 03:05 PM, Simon Perreault wrote: > > Justin, Brandon, TRAMsters, > > > > I started writing a long response but erased all of it in favour of > this > > happy, shorter one: > > > > Would anyone scream if the draft went through another revision > focusing > > on the problem statement before getting adopted? Work needs to be > done > > on the problem statement at one point or another, so it doesn't > really > > change anything from an end-goal perspective. > > > > Hoping we can get back to technical arguments soon... > > Simon >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jan 13 09:38:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4118C1A8FD7 for ; Tue, 13 Jan 2015 09:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 3_FG6t0Loacb for ; Tue, 13 Jan 2015 09:38:40 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52981A6FF7 for ; Tue, 13 Jan 2015 09:38:39 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id vy18so4097679iec.9 for ; Tue, 13 Jan 2015 09:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2nFbOL+crNgyV2L+PPtYNTpcS9lA5A+S2sLKr6nBs6Q=; b=ZWN7BxGRf6m/DpHAT9bp/+ECRn+yFzEx1h44V7PwvTWgkkBkZp6R7hnTlkfD5fzFlN /dDM8O0pU0ouaY5yCf730+v/GtmLwixlnTQ6DQW8Lvl8MxO4HoqkQ3kFdgddBMJ9C5M3 ebD0LYLsfmgDUhALkAau2enjyQvNYISet8zN36gnPEk/449ASqDHeuyoXWK3wcswtIEi VZbHgUIgxxKupWSPymAa/t2Zx5t6lYiawATJweEFHdmpgz5kSZpbg+xTsVwWcG6HnlTw VvZrZShEr1YwOupHe/kPqpfjUzQaoP+3MuZlHEVXvsKzQ/Z2Km0FVTLhJoHwCyR5NKLP QpSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2nFbOL+crNgyV2L+PPtYNTpcS9lA5A+S2sLKr6nBs6Q=; b=gXYmROAde+yoUbAclJbXgu1rhOjqHHasAQ+rOuZJAsEnmBR8L/rdSCX6x1Us5UX2ez 2t8BydpPTw9mVI0hzJPr3FD393cMeY+cIQzI6vJrVOADLrITA+9JG/JBvATMPkhM/6lR Fo8TmNLEiZ6PNjs0Ww7oBAqF1eOR5haZm0+cmfz26HnclZqC5CRuSeXKSlDiHpySyJuM AQZYjiFrwkTDeVF/VFgf6JikNNajVRjTDD5iRxpFsH13QwAKU1G9Kl3V4t4ONsGorcFn 5MVnc66yRk1lSSoR0iUQAR90kqojbYxaqjbIS7IHydObccOJWgKB4dIbXf2DjkyB4zfc zJoA== X-Gm-Message-State: ALoCoQkd9dPAc0dvaJQKT/68yfvDlp3UPL8vxNOVynhlQgWFe1z3rxKQIbufIH6jm2Yz9DX6+Wr5 X-Received: by 10.50.66.198 with SMTP id h6mr681974igt.22.1421170718711; Tue, 13 Jan 2015 09:38:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Tue, 13 Jan 2015 09:38:18 -0800 (PST) In-Reply-To: <002a01d02ece$4c063400$e4129c00$@org.cn> References: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> <002a01d02ece$4c063400$e4129c00$@org.cn> From: Justin Uberti Date: Tue, 13 Jan 2015 09:38:18 -0800 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary=047d7bdc131adad4eb050c8c1707 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 17:38:48 -0000 --047d7bdc131adad4eb050c8c1707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2015 at 5:14 PM, Aijun Wang wrote: > Hi, Justin: > > > > Please refer to the reply below. > > > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Tuesday, January 13, 2015 4:23 AM > *To:* Aijun Wang > *Cc:* Tirumaleswar Reddy (tireddy); tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang > wrote: > > Hi, > > > > Do you refer to the draft > http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN > draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does > not describe the situation that the communication peers select the > different public TURN server, and need the TURN server to relay the app > data(TURN to TURN). > > > > That is just normal UDP. > > > > [Aijun]: For TURN to TURN situation, I am discussing it with the Brandon, > please refer to that thread. We should consider carefully for the > transport mechanism between A/TURN Server A; TURN Server A/TURN Server B > and TURN Server B/B when peer A want to talk to B via the two TURN Server > A/B. > > > In situation that mentioned in RETURN draft, Why not to let ICE or App > Server to select the appropriate TURN server(corporate private TURN serve= r > or public TURN server) based on the information of the two communication > parts? This can even eliminate the solution of RETURN: two peer will us= e > the corporate TURN server when they are both within corporate, and will u= se > the public TURN server when one of them is located outside the corporatio= n? > > > > a) The TURN server isn't needed when both endpoints are within the > enterprise. The TURN server sits on the enterprise border, and is used fo= r > inter-enterprise traffic. > > b) The public TURN server may not be reachable from the enterprise. This > is why the corporate TURN server is needed on the border. > > c) The app may require use of its own TURN server for location privacy > purposes, so both TURN servers may be used in this case. > > > > This is all spelled out in > https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-1. > > > > [Aijun] Would you like to explain more detail about =E2=80=9Cbut using on= ly the enterprise's TURN server reveals information about the user (e.g. or= ganizational affiliation)=E2=80=9D, and how do you achieve this goal via t= he RETURN mechanism? > > If only the enterprise TURN server is used, and this server is on-premises, then the remote party can determine the location of the caller via IP geolocation of the relay candidates (as well as organization affiliation, by seeing who owns that IP). This is similar to the case where the remote party determines the location of a non-enterprise caller via their host/srflx candidates, although in this case applications can protect against this by forcing all traffic through an application-provided relay server, which provides some amount of location ambiguity. RETURN attempts to provide this same functionality for the enterprise TURN server case, and to do so it defines how traffic can transit both the enterprise TURN server as well as the application TURN server. e.g. [client] -------- [ETURN] ------------ [ATURN] -------------- [remote party= ] > > > Best Regards. > > > > > > *From:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Monday, January 12, 2015 1:35 PM > *To:* Aijun Wang; 'Justin Uberti' > *Cc:* tram@ietf.org > *Subject:* RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > As Justin has pointed out we will be updating the draft with more details > on the decisions that could be made by ICE and the application to select > the TURN server. TURN-in-TURN communication is already explained in RETUR= N > draft. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Aijun Wang > *Sent:* Monday, January 12, 2015 7:08 AM > *To:* Tirumaleswar Reddy (tireddy); 'Justin Uberti' > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Hi, Reddy and Justin: > > > > I suggest the TURN server selection should be made by ICE, not the client > itself. This can eliminate the needs for the communication between > different TURN server that selected by communication peer. ICE has more > information about the communication situation, and is suitable to make th= is > decision. > > > > There are several issues needed to be solved when the communication peers > select the different TURN server, for example, how to find the second TUR= N > server, what is the communication mechanism between different TURN server= s, > the channel connection among different data segments: client/first TURN > server, first TURN server/second TURN server, and second TURN server/peer > etc. > > > > Best Regards. > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Tirumaleswar Reddy (tireddy) > *Sent:* Sunday, January 11, 2015 1:40 PM > *To:* Justin Uberti > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Inline [TR] > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Sunday, January 11, 2015 2:17 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > Enterprise-provided TURN server cannot provide location privacy may not b= e > always true. For example Enterprise network could use TURN server provide= d > by a cloud service and the user needs to know that the Enterprise TURN > server can provide location privacy and not proceed with TURN-in-TURN. > > > > We will have to discuss if TURN server can advertise that it can provide > location privacy in a new attribute or this info can be conveyed > out-of-band (e.g. PAC). > > > > The other problem not discussed in the draft is, what if the user wants > privacy against the calling site and let=E2=80=99s say uses Tor for priva= cy. In > this scenario app TURN server must not be selected. > > > > RETURN handles this situation fine, since the traffic will be routed > through the network-provided TURN server before being routed to the app > TURN server. Of course, if the application does not try to provide locati= on > privacy, only the network-provided TURN server will be used. > > > > [TR] But the problem is how will the endpoint how if network-provided TUR= N > server can provide location privacy or not ? > > TURN server can convey this information in a new STUN attribute > to the client. > > > > However, I think the user is much more likely to trust the application > than its network provider to provide privacy protection. > > > > [TR] User may or may not trust the application server. > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses > users using privacy techniques like Tor so that app server does not learn > the user's IP address. The Poker example given in the above draft explain= s > that the users in the call do not trust the calling service. In this case > IdP ensures that even if malicious calling service replaces the media > addresses with its own addresses and replaces the certificate fingerprin= t > in SDP with its own certificate, IdP assertion would ensure that the Poke= r > site cannot act as man-in-middle device. In this scenario user may not > want to pick app provided TURN server. > > > > -Tiru > > > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Friday, January 09, 2015 4:04 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > At IETF 91, I promised to send feedback on this document, so here goes. > > > > Generally, I think many of the issues mentioned in this document are > important, but the recommendations are confusing and possibly > contradictory; a developer with little knowledge of TURN will have a hard > time figuring out exactly what to do. Furthermore, many of the properties > discussed in this document are dynamic, and should be handled by the ICE > process, rather than in TURN server selection (for example, the notion of > RTT as it relates to user experience). > > > > Therefore, I think this document should take a stronger stance and put > forth explicit best practices for selection (as opposed to "things to > consider"), for non-dynamic properties, and leave the decisions on dynami= c > properties to be resolved by ICE. > > > > For example, I think we should omit the text in Section 3 about what to d= o > with non-working TURN servers, and measuring RTT. Same for Section 3.3, > which also discusses RTT, and Section 3.4, which talks about multiple > interfaces. This can all be handled by ICE. > > > > In addition, the sections on local config and location privacy are > unnecessary when RETURN is used. When RETURN is used, the application can > always use the app TURN server for location privacy, and the relationship > between local TURN server and app TURN server is fully spelled out, so > there is nothing for the application to decide on. > > > > This leaves only the Security, Authentication, and Mobility sections. > > > > For security, I think we can give some clear guidance on what application= s > should do. For security, I think the guidance should be to use only DTLS = + > TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS > aren't available. If privacy is paramount, UDP/TCP fallback may be > contraindicated, but at this point in time, DTLS deployment isn't > widespread enough to truly recommend this. > > > > This relates to the Authentication section - but I think any failures to > authenticate the server cert should cause the TURN allocation to fail. Th= is > is just like any other misconfiguration on the TURN server - there's no > reason we should even allow use of TURN servers whose cert chains don't > validate. So, this section could probably be removed. > > > > Lastly, the Mobility section says that if "all other parameters [are] > equal", a TURN server with mobility should be used. Clearly, all other > parameters will not be equal (e.g. RTT), and even if they were, the clien= t > has no way to know if a server is mobility-capable a priori. So I think > this recommendation ought to be removed, or perhaps turned into some sort > of recommendation for TURN server developers (e.g. TURN servers SHOULD > support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), > probably in a separate doc. > > > > These recommendations should reduce the size of this document and provide > much clearer advice to app developers. > > > > > --047d7bdc131adad4eb050c8c1707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 12, 2015 at 5:14 PM, Aijun Wang <wangaijun@tsinghu= a.org.cn> wrote:

Hi, Justin:

<= p class=3D"MsoNormal">=C2= =A0

Please refer to the reply below.

=C2=A0<= /u>

=C2=A0

From: Justin Uberti [mailto:juberti@google.com]
Sent: Tuesday, January 13, 2015 4:= 23 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); = tram@ietf.org
Subject: Re: [tram] Comments on draft-patil-tram-turn-= serv-selection-00

=C2=A0

=C2=A0

=C2=A0

On Sun, Jan 11, 2015 at 10:32= PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:

Hi,

=C2=A0

Do you refer to the draft http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN = draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does no= t describe the situation that the communication peers select the different = public TURN server, and need the TURN server to relay the app data(TURN to = TURN).

=C2=A0

That is just normal UDP.=C2=A0

=C2=A0

[Aijun]: For TURN to TURN situation, I am discussing it with the Brandon= , please refer to that thread.=C2=A0 We should consider carefully for the t= ransport mechanism between A/TURN Server A; TURN Server A/TURN Server B and= TURN Server B/B when peer A want to talk to B via the two TURN Server A/B.= =C2=A0

<= blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0cm= 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">

=C2=A0

In situation that mentioned in RETURN draft, Why = not to let ICE or App Server to select the appropriate TURN server(corporat= e private TURN server or public TURN server) based on the information of th= e two communication parts? This can even eliminate the solution of=C2=A0 RE= TURN: =C2=A0two peer will use the corporate TURN server when they are both = within corporate, and will use the public TURN server when one of them is l= ocated outside the corporation?

=C2=A0

a) The TURN server isn't needed when both endpoints = are within the enterprise. The TURN server sits on the enterprise border, a= nd is used for inter-enterprise traffic.

b) The public TURN server may = not be reachable from the enterprise. This is why the corporate TURN server= is needed on the border.

c) The app may require use of its own TURN se= rver for location privacy purposes, so both TURN servers may be used in thi= s case.

=C2=A0

This is all spelled out in= =C2=A0https://tools.ietf.org/html/draft-schwartz-r= tcweb-return-04#section-1.

=C2=A0

[Aijun] Would you li=
ke to explain more detail about =E2=80=9Cbut using only the enterprise's TURN server reveals i=
nformation about the user (e.g. organizational affiliation)=E2=80=9D,=C2=A0 and how do you achieve th=
is goal via the RETURN mechanism?

If only the enterprise TURN s= erver is used, and this server is on-premises, then the remote party can de= termine the location of the caller via IP geolocation of the relay candidat= es (as well as organization affiliation, by seeing who owns that IP). This = is similar to the case where the remote party determines the location of a = non-enterprise caller via their host/srflx candidates, although in this cas= e applications can protect against this by forcing all traffic through an a= pplication-provided relay server, which provides some amount of location am= biguity.=C2=A0

RETURN attempts to provide this sam= e functionality for the enterprise TURN server case, and to do so it define= s how traffic can transit both the enterprise TURN server as well as the ap= plication TURN server.

e.g.

[client] -------- [ETURN] ------------ [ATURN] -------------- [remote pa= rty]

=C2=A0

Best Regards.

=C2=A0

=C2=A0

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, = January 12, 2015 1:35 PM
To: Aijun Wang; 'Justin Uberti'<= br>Cc: tram@ietf.= org
Subject: RE: [tram] Comments on draft-patil-tram-turn-ser= v-selection-00

=C2=A0<= /u>

As Justin has pointed out we will be updating the draft with more detai= ls on the decisions that could be made by ICE and the application to select= the TURN server. TURN-in-TURN communication is already explained in RETURN= draft.

=C2=A0

-Tiru

= =C2=A0

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif""> tram [mailto:tram-bounces@ietf.org] On Behalf Of Aiju= n Wang
Sent: Monday, January 12, 2015 7:08 AM
To: Tirum= aleswar Reddy (tireddy); 'Justin Uberti'
Cc: tram@ietf.org
Subject:= Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

Hi, Reddy and Justin:

=C2=A0

I suggest the TURN server selection should be made by ICE, not the cl= ient itself.=C2=A0 This can eliminate the needs for the communication betwe= en different TURN server that selected by communication peer. ICE has more = information about the communication situation, and is suitable to make this= decision.

=C2=A0

There are several issues needed to be solved whe= n the communication peers select the different TURN server, for example, ho= w to find the second TURN server, what is the communication mechanism betwe= en different TURN servers, the channel connection among different data segm= ents: client/first TURN server, first TURN server/second TURN server, and s= econd TURN server/peer etc.

=C2= =A0

Best Regards.

=C2=A0=

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: S= unday, January 11, 2015 1:40 PM
To: Justin Uberti
Cc: <= /span>tram@ietf.orgSubject: Re: [tram] Comments on draft-patil-tram-turn-serv-selecti= on-00

=C2=A0

Inline [TR]

=C2=A0

From: Justin Ub= erti [mailto:juberti@google.com]
Sent: Sunday, January 11, 2015 2:17 AMTo: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject:<= /b> Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 7:38 PM, Ti= rumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

<= div>

Hi Jus= tin,

=C2=A0

Enterprise-provided TURN server cannot provide locatio= n privacy may not be always true. For example Enterprise network could use = TURN server provided by a cloud service and the user needs to know that the= Enterprise TURN server can provide location privacy and not proceed with T= URN-in-TURN.

=C2=A0

We will have to discuss if TURN server can = advertise that it can provide location privacy in a new attribute or this i= nfo can be conveyed out-of-band (e.g. PAC).=C2= =A0

=C2=A0

The other problem not discussed in the draft is= , what if the user wants privacy against the calling site and let=E2=80=99s= say uses Tor for privacy. In this scenario app TURN server must not be sel= ected.

=C2=A0<= /u>

RETURN= handles this situation fine, since the traffic will be routed through the = network-provided TURN server before being routed to the app TURN server. Of= course, if the application does not try to provide location privacy, only = the network-provided TURN server will be used.

=C2=A0<= span lang=3D"EN-US">

[TR] But the problem is how will the endpoint how if network-= provided TURN server can provide location privacy or not ?

=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0TURN server can convey this information in a new= STUN attribute to the client.

=C2=A0

However, I think the user is= much more likely to trust the application than its network provider to pro= vide privacy protection.

=C2=A0

[TR] Use= r may or may not trust the application server. https://to= ols.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses users us= ing privacy techniques like Tor so that app server does not learn the user&= #39;s IP address. The Poker example given in the above draft explains that = the users in the call do not trust the calling service. In this case IdP en= sures that even if malicious calling service replaces the media addresses w= ith its own addresses=C2=A0 and replaces the certificate fingerprint in SDP= with its own certificate, IdP assertion would ensure that the Poker site c= annot act as =C2=A0man-in-middle device. In this scenario user may not want= to pick app provided TURN server.

=C2=A0

-Tiru

=C2=A0

=C2=A0

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
S= ent: Friday, January 09, 2015 4:04 AM
To: tram@ietf.org
Subject:<= /b> [tram] Comments on draft-patil-tram-turn-serv-selection-00

= =C2=A0

At IETF 91, I promised to send feedback on this d= ocument, so here goes.

= =C2=A0

Generally, I think many of the issues menti= oned in this document are important, but the recommendations are confusing = and possibly contradictory; a developer with little knowledge of TURN will = have a hard time figuring out exactly what to do. Furthermore, many of the = properties discussed in this document are dynamic, and should be handled by= the ICE process, rather than in TURN server selection (for example, the no= tion of RTT as it relates to user experience).

=C2=A0

Therefore, I = think this document should take a stronger stance and put forth explicit be= st practices for selection (as opposed to "things to consider"), = for non-dynamic properties, and leave the decisions on dynamic properties t= o be resolved by ICE.=C2=A0

=C2=A0

<= p class=3D"MsoNormal">For example, I think we should o= mit the text in Section 3 about what to do with non-working TURN servers, a= nd measuring RTT. Same for Section 3.3, which also discusses RTT, and Secti= on 3.4, which talks about multiple interfaces. This can all be handled by I= CE.

=C2=A0

In addition, the sections on local config and location p= rivacy are unnecessary when RETURN is used. When RETURN is used, the applic= ation can always use the app TURN server for location privacy, and the rela= tionship between local TURN server and app TURN server is fully spelled out= , so there is nothing for the application to decide on.

=C2=A0

This= leaves only the Security, Authentication, and Mobility sections.=C2=A0<= /u>

=C2=A0

For security, I think we can give some clear guidance on what a= pplications should do. For security, I think the guidance should be to use = only DTLS + TLS, if both are available, with fallback to UDP or TCP if DTLS= or TLS aren't available. If privacy is paramount, UDP/TCP fallback may= be contraindicated, but at this point in time, DTLS deployment isn't w= idespread enough to truly recommend this.

=C2=A0

This relates to th= e Authentication section - but I think any failures to authenticate the ser= ver cert should cause the TURN allocation to fail. This is just like any ot= her misconfiguration on the TURN server - there's no reason we should e= ven allow use of TURN servers whose cert chains don't validate. So, thi= s section could probably be removed.

=C2=A0

Lastly, the Mobility se= ction says that if "all other parameters [are] equal", a TURN ser= ver with mobility should be used. Clearly, all other parameters will not be= equal (e.g. RTT), and even if they were, the client has no way to know if = a server is mobility-capable a priori. So I think this recommendation ought= to be removed, or perhaps turned into some sort of recommendation for TURN= server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD suppo= rt mobility, SHOULD support redirect), probably in a separate doc.

=C2= =A0

These recommendations should reduce the size of this document and p= rovide much clearer advice to app developers.

=C2=A0

<= /div>

=C2=A0


--047d7bdc131adad4eb050c8c1707-- From nobody Tue Jan 13 10:54:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0869E1A90F0 for ; Tue, 13 Jan 2015 10:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Nid8l3z9_IC6 for ; Tue, 13 Jan 2015 10:54:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EAA1A90D9 for ; Tue, 13 Jan 2015 10:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41914; q=dns/txt; s=iport; t=1421175271; x=1422384871; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0bXsrsH9MkK0DVNxPlItkstka74VXHSthoWcJZGCUgc=; b=D1b7CyouiJy4NI3p2f+2qNT5hv0RRcoS3iMT29dgqVT6dsBIb5++tLuI thLYx4w3sFp1I8/Xe33T88Eb9f7IIM1msIj1Vj7oXf+cOe/+kibjFQ2/L xrO5tcNvsoah/hLDzZqg6rZMkCbPirVAXKy2bieJXv4/MO3ECALJiQ778 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0HAJJptVStJV2Y/2dsb2JhbABRCoJDQ1JYBIMBwSaBXwEJhXECHH5DAQEBAQF9hAwBAQEEAQEBIARHCQIMBAIBCBEEAQEhAQYDAgICJQsUCQgCBAoEBRuIEQ28IpN5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF48dQRcEBwaCYi6BEwWBSosdgVuDRYVIgQ8wjQCDPSKDbm8BgQIHO34BAQE X-IronPort-AV: E=Sophos;i="5.07,750,1413244800"; d="scan'208,217";a="386685167" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 13 Jan 2015 18:54:30 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0DIsTQA005118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 18:54:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 12:54:29 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] New Version Notification for draft-williams-peer-redirect-02.txt Thread-Index: AQHQLwxct8FzPZ1uJUeScTzmsc+WHJy9wL9AgAEKcQA= Date: Tue, 13 Jan 2015 18:54:28 +0000 Message-ID: <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> In-Reply-To: <00a101d02f13$575f1e80$061d5b80$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.210.57] Content-Type: multipart/alternative; boundary="_000_5A8F6D13C1C747F1AE5B7BFBE25DC052ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:54:35 -0000 --_000_5A8F6D13C1C747F1AE5B7BFBE25DC052ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxMyBKYW4gMjAxNSwgYXQgMTA6MjgsIEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1 YS5vcmcuY248bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYWwgTWFydGluc2VuDQoocGFsbWFydGkpDQpTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDEzLCAyMDE1IDQ6MzkgUE0NClRvOiBBaWp1biBXYW5nDQpDYzogdHJh bUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IEJyYW5kb24gV2lsbGlhbXMNClN1Ympl Y3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtd2lsbGlh bXMtcGVlci1yZWRpcmVjdC0wMi50eHQNCg0KDQpPbiAxMyBKYW4gMjAxNSwgYXQgMDE6NTAsIEFp anVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248bWFpbHRvOndhbmdhaWp1bkB0c2lu Z2h1YS5vcmcuY24+PiB3cm90ZToNCg0KSGksIEJyYW5kb24NCg0KVGhhbmtzIGZvciB5b3VyIHZp dmlkIGdyYXBoIGZvciBvdXIgZGlzY3Vzc2lvbi4gVHdvIHF1ZXN0aW9ucyBhcmUNCnJhaXNlZA0K aGVyZToNCg0KMS4gSG93IGRvZXMgVFVSTiBzZXJ2ZXIgQSBkZWNpZGUgd2hlbiB0byB1c2UgVURQ IHRvIHNlbmQgYXBwIGRhdGEsIGFuZA0Kd2hlbiB0byB1c2UgVFVSTiB0byBzZW5kIGFwcCBkYXRh PyBXaGljaCBjcml0ZXJpYSBjYW4gYXNzaXN0YW50IHRoZQ0KVFVSTiBzZXJ2ZXIgQSB0byBtYWtl IHRoaXMgZGVjaXNpb24/DQpJbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0wMCNzZWN0aW9uLTEwLjIsDQppdCBkZXNjcmliZXMgdGhlIFRVUk4gc2Vy dmVyIHdpbGwgc2VuZCBVRFAgcmF3IHBhY2tldCB0byB0aGUgcGVlciwNCnJlZ2FyZGxlc3MgdGhl IHBlZXIgaXMgYXdhcmVuZXNzIG9yIHVuYXdhcmVuZXNzIHRoZSBleGlzdGVuY2Ugb2YgVFVSTi4N Cg0KDQpUVVJOIHNldmVyIEEgc2VuZHMg4oCcYXBwIGRhdGHigJ0gdG8gY2xpZW50IEEuIFRoaXMg aXMgdGhlIOKAnHByaXZhdGXigJ0gc2lkZSBvZiB0aGUNClRVUk4gc2VydmVyLiBUVVJOIHNlcnZl ciBBIHNlbmRzIFRVUk4gZW5jYXBzdWxhdGVkIGRhdGEgKGRhdGEgaW5kIG9yDQpjaGFubmVsKSBi YWNrIHRvIGNsaWVudCBBIHVzaW5nIHRoZSBzYW1lIDUgdHVwbGUgY2xpZW50IEEgdXNlZCB0byBz ZW5kIGhpcw0KYWxsb2NhdGUgcmVxdWVzdC4gVFVSTiBhbGxvd3MgdGhlIGNsaWVudCB0byB1c2Ug VURQLCBUQ1Agb3IgVExTIHRvIGRvIHRoaXMuDQoNCldoYXQgaGFwcGVucyBvbiB0aGUg4oCccHVi bGlj4oCdIHNpZGUgb2YgdGhlIFRVUk4gc2VydmVyIGlzIGFsd2F5cyBVRFAgKFVubGVzcw0KdGhl IFRVUk4gc2VydmVyIHN1cHBvcnRzIFRVUk4tVENQIGFuZCB0aGUgY2xpZW50IGhhdmUgYXNrZWQg Zm9yIGEgVENQIHBvcnQNCmFsbG9jYXRpb24pLg0KDQpUaGUgcmVtb3RlIHNpZGUgZG8gbm90IG5l ZWQgdG8ga25vdyB0aGF0IGl0IGlzIHNlbmRpbmcgcGFja2V0cyB0byBhIFRVUk4NCnNlcnZlciwg YW5kIHRoYXQgdGhlIHBhY2tldHMgd291bGQg4oCcbWFnaWNhbGx54oCdIGJlIHNlbnQgdG8gdGhl IGNsaWVudCB0aGF0DQphbGxvY2F0ZWQgdGhhdCBwb3J0LiBUaGluayBvZiBUVVJOIGFzIGEgbWVj aGFuaXNtIHRvIG1vdmUgeW91ciBib3ggb3V0IG9uIHRoZQ0KSW50ZXJuZXQgYW5kIG9idGFpbmlu ZyBwdWJsaWMgcm91dGFibGUgSVAuDQoNCg0KSSBhZ3JlZSB3aXRoIHlvdSBhdCB0aGVzZSBwb2lu dHMuIEJ1dCBteSBjb25jZXJuIGZvY3VzIG9uIHRoZSBjb21tdW5pY2F0aW9uIGNoYW5uZWwgYmV0 d2VlbiBUVVJOIFNlcnZlciBBL1RVUk4gU2VydmVyIEIgYW5kIFRVUk4gQi9QZWVyIEIuIEluIGN1 cnJlbnQgVFVSTiBkcmFmdCwgdGhleSBhbGwgdXNlIHRoZSBwdXJlIFVEUCBwYWNrZXQuIEJ1dCBp biBCcmFuZG9u4oCZcyBncmFwaCwgdGhleSBhcmUgZGlmZmVyZW50OiB0aGUgcHJldmlvdXMgcGFp ciB1c2UgcHVyZSBVRFAgZGF0YWdyYW0sIGJ1dCB0aGUgbGF0dGVyIHBhaXIgdXNlIERBVEEgaW5k aWNhdGlvbiwgd2hpY2ggaXMgbm90IGRlc2NyaWJlZCBpbiBjdXJyZW50IFRVUk4gZHJhZnQsDQoN ClVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIHRoaXMgaXMgZGVzY3JpYmVkIGluIHNlY3Rp b24gMTAuMy4NCg0KDQphbmQgd2lsbCBsZWFkIHRoZSBUVVJOIHNlcnZlciBBIGJlIGNvbmZ1c2Vk LCBiZWNhdXNlIGl0IG1pZ2h0IGZhY2UgdGhlIFRVUk4gU2VydmVyIEIgYW5kIG90aGVyIGNvbW11 bmljYXRpb24gcGVlciwgc3VjaCBhcyBwZWVyIEMgdGhhdCBkaXJlY3RseSBjb25uZWN0ZWQgb24g dGhlIFRVUk4gc2VydmVyIEEuICBXaGljaCBlbmNhcHN1bGF0aW9uIG1ldGhvZCB3aWxsIGJlIHVz ZWQgdGhlbj8NCg0KDQpVRFAuIEJ1dCB0aGF0IHJlcXVpcmVzIGNsaWVudCBhIHRvIHNldCB0aGUg Y29ycmVjdCBwZXJtaXNzaW9ucyB0byBhbGxvdyB0cmFmZmljIGZyb20gQyB0byBiZSByZWxheWVk IHRvIEEuDQoNCldlIGFyZSBkaXNjdXNzaW5nIG5vcm1hbCBUVVJOIG9wZXJhdGlvbiBoZXJlPyBJ ZiBub3QgSSBhcG9sb2dpc2UgaWYgSSBoYXZlIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhlIGRpc2N1 c3Npb24uDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KDQoNCg0KDQoyLiBJbiB5b3VyIGV4YW1wbGUs IGlmIFRVUk4gQiB1c2UgdGhlIERBVEEgaW5kaWNhdGlvbiB0byBCLCB3aGF0IHdpbGwNCkIgZG8g aWYgaXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgVFVSTiBlbmNhcHN1bGF0aW9uPw0KDQpUaGVyZSBp cyBubyB3YXkgYSBUVVJOIHNlcnZlciB3b3VsZCBzZW5kIGRhdGEgaW5kIHRvIGEgY2xpZW50IHdp dGhvdXQgdGhlDQpjbGllbnQgaGF2aW5nIGFsbG9jYXRlZCBhIHBvcnQuDQpXaXRob3V0IGNsaWVu dCBCIHNlbmRpbmcgdGhlIGFsbG9jYXRlIHJlcXVlc3QgdGhlcmUgd291bGQgbm90IGJlIGEgYmlu ZGluZyBpbg0KdGhlIE5BVCBlaXRoZXIuDQoNCg0KQWN0dWFsbHkgdHJ1ZS4gQnV0IG15IGNvbmNl cm4gaGVyZSBmb2N1cyBzdGlsbCBvbiB0aGUgZGF0YSBmb3J3YXJkaW5nIHBsYW5lLCBub3QgdGhl IGNvbnRyb2wgcGxhbmUgb2YgVFVSTiBzb2x1dGlvbi4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KDQpC ZXN0IFJlZ2FyZHMuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyYW5k b24gV2lsbGlhbXMgW21haWx0bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb21dDQpTZW50OiBN b25kYXksIEphbnVhcnkgMTIsIDIwMTUgMTE6NDUgUE0NClRvOiBBaWp1biBXYW5nOyB0cmFtQGll dGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmFtXSBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3Qt MDIudHh0DQoNClhPUi1QRUVSLUFERFJFU1MgY29udGFpbnMgInRoZSB0cmFuc3BvcnQgYWRkcmVz cyBvZiB0aGUgcGVlciIuIEl0IGlzDQpub3QgcmVxdWlyZWQgdG8gYmUgYSBzcGVjaWZpYyB0eXBl IG9mIGFkZHJlc3MgKGhvc3QsIHJlZmxleGl2ZSwgb3IgcmVsYXkpLg0KSXQgd2lsbCBiZSBhbnkg YWRkcmVzcyB0aGF0IGNhbiBiZSB1c2VkIHRvIGRlbGl2ZXIgZGF0YSB0byB0aGUgcmVtb3RlDQpw ZWVyLiBJZg0KdHdvIFRVUk4gcmVsYXlzIGFyZSB1c2VkLCB0aGVuIHRoZSBYT1ItUEVFUi1BRERS RVNTIGF0dHJpYnV0ZSBpbiBTZW5kDQphbmQgRGF0YSBpbmRpY2F0aW9ucyB3aWxsIGNvbnRhaW4g dGhlIHJlbW90ZSBwZWVyJ3MgYWxsb2NhdGVkIHJlbGF5IGFkZHJlc3MuDQpUaGVyZQ0KaXMgbm8g bmVlZCB0aGUgZm9yIGVpdGhlciBvZiB0aGUgcmVsYXlzIHRvIGV2ZW4gYmUgYXdhcmUgdGhhdCB0 aGUNCnRyYW5zcG9ydA0KYWRkcmVzcyBpcyBhIHJlbGF5IGFkZHJlc3MuDQoNCkNvbnNpZGVyIHRo ZSBmb2xsb3dpbmc6DQoNCkEgPC0+IFhBIDwtPiBUQXxSQSA8LT4gUkJ8VEIgPC0+IFhCIDwtPiBC DQp8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfA0KfC0tLS0gVFVSTiAt LS0tfC0tIFVEUCAtLXwtLS0tIFRVUk4gLS0tLXwNCg0KQSBhbmQgQiBhcmUgdGhlIHR3byBwZWVy cycgaG9zdCBhZGRyZXNzZXMuDQpYQSBhbmQgWEIgYXJlIHRoZSB0d28gcGVlcnMnIHJlZmxleGl2 ZSBhZGRyZXNzZXMuDQpUQSBhbmQgVEIgYXJlIHRoZSByZWxheSBzZXJ2ZXJzJyBhZGRyZXNzZXMg dXNlZCBhcyB0aGUgVFVSTiBzZXNzaW9uDQplbmRwb2ludHMuDQpSQSBhbmQgUkIgYXJlIHRoZSB0 d28gcGVlcnMnIGFsbG9jYXRlZCByZWxheSBhZGRyZXNzZXMuDQoNCkEgU2VuZCBpbmRpY2F0aW9u IGZyb20gQSB0byBUQSB1c2VzIFJCIGFzIHRoZSBYT1ItUEVFUi1BRERSRVNTLiBXaGVuDQpBJ3Mg cmVsYXkgcmVjZWl2ZXMgdGhlIFNlbmQgaW5kaWNhdGlvbiwgaXQgc2VuZHMgdGhlIGRhdGEgaW4g YSBwbGFpbg0KVURQDQpkYXRhZ3JhbQ0Kd2l0aCBSQSBhcyB0aGUgc291cmNlIGFuZCBSQiBhcyB0 aGUgZGVzdGluYXRpb24uIFdoZW4gQidzIHJlbGF5DQpyZWNlaXZlcw0KdGhlDQpVRFAgZGF0YWdy YW0sIGl0IHNlbmRzIGEgRGF0YSBpbmRpY2F0aW9uIGZyb20gVEIgdG8gQiB3aXRoIFJBIGFzIHRo ZQ0KWE9SLVBFRVItQUREUkVTUy4NCg0KLS1CcmFuZG9uDQoNCk9uIDAxLzExLzIwMTUgMDc6NDMg UE0sIEFpanVuIFdhbmcgd3JvdGU6DQpIaSwgQnJhbmRvbjoNCg0KSW4NCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTAuMSwNCml0 IGlzIGRlc2NyaWJlZCBhcyBiZWxvdzoNCg0KV2hlbiBmb3JtaW5nIGEgU2VuZCBpbmRpY2F0aW9u LCB0aGUgY2xpZW50IE1VU1QgaW5jbHVkZSBhbiBYT1ItUEVFUi0NCiAgQUREUkVTUyBhdHRyaWJ1 dGUgYW5kIGEgREFUQSBhdHRyaWJ1dGUuICBUaGUgWE9SLVBFRVItQUREUkVTUw0KICBhdHRyaWJ1 dGUgY29udGFpbnMgdGhlIHRyYW5zcG9ydCBhZGRyZXNzIG9mIHRoZSBwZWVyIHRvIHdoaWNoIHRo ZQ0KICBkYXRhIGlzIHRvIGJlIHNlbnQsIGFuZCB0aGUgREFUQSBhdHRyaWJ1dGUgY29udGFpbnMg dGhlIGFjdHVhbA0KICBhcHBsaWNhdGlvbiBkYXRhIHRvIGJlIHNlbnQgdG8gdGhlIHBlZXIuDQoN ClNvLCB0aGVyZSBpcyBubyBYT1ItUkVMQVlFRC1BRERSRVNTIGF0dHJpYnV0ZSBpbmNsdWRlZCB0 byBpZGVudGlmeQ0KdGhlIHBlZXIncyBhbGxvY2F0ZWQgcmVsYXkgYWRkcmVzcy4gT24gdGhlIG90 aGVyIGhhbmQsDQpYT1ItUkVMQVlFRC1BRERSRVNTIGlzIG1haW5seSByZWZlciB0byB0aGUgcmVx dWVzdGVyJ3MgYWxsb2NhdGVkDQpyZWxheSBhZGRyZXNzLCBub3QgdGhlIGNvcnJlc3BvbmRpbmcg cGVlci4gV2lsbCB3ZSBkZWZpbmUgYWdhaW4gb25lDQpuZXcgYXR0cmlidXRlLCBzdWNoIGFzIFhP Ui1QRUVSLVJFTEFZRUQtQUREUkVTUyB0byB0cmFuc2ZlciB0aGUgbmV4dA0KVFVSTiBzZXJ2ZXIn cw0KaW5mb3JtYXRpb24/DQoNCkV2ZW4gaWYgc28sIHdoYXQgd2lsbCBiZSB0aGUgc291cmNlIGFk ZHJlc3MgZm9yIHRoZSBwYWNrZXQgZnJvbSB0aGUNCnNlY29uZCBUVVJOIHNlcnZlciB0byBkZXN0 aW5hdGlvbiBwZWVyPyBJZiB3ZSB1c2UgdGhlDQpYT1ItUkVMQVlFRC1BRERSRVNTLCB0aGVuIHRo ZSByZXR1cm4gcGFja2V0IGZyb20gdGhlIHBlZXIgd2lsbCBiZQ0KcGFzc2VkIGJhY2sgZGlyZWN0 bHkgdG8gdGhlIGZpcnN0IFRVUk4gc2VydmVyLCByZXN1bHRzIGluDQpub24tc3ltbWV0cmljIHJv dXRlLiBJZiB3ZSB1c2UgWE9SLVBFRVItUkVMQVlFRC1BRERSRVNTLCB0aGVuIHdoYXQNCmlzIHRo ZSBzb3VyY2UgYWRkcmVzcyBmb3IgdGhlIHBhY2tldCBmcm9tIHRoZSBzZWNvbmQgVFVSTiBzZXJ2 ZXINCmJhY2sgdG8NCnRoZQ0KZmlyc3QgVFVSTiBzZXJ2ZXI/DQoNCkJlc3QgUmVnYXJkcy4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyYW5kb24gV2lsbGlhbXMgW21haWx0 bzpib3dpbGxAYWthbWFpLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEwLCAyMDE1IDE6 MDkgQU0NClRvOiBBaWp1biBXYW5nOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt0cmFtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IN CmRyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3QtMDIudHh0DQoNCkJ5IHJlbGF5IGFkZHJlc3Ms IEkgbWVhbiB0aGUgWE9SLVJFTEFZRUQtQUREUkVTUyByZXR1cm5lZCBpbiB0aGUNCmFsbG9jYXRp b24NCnJlcXVlc3QuIFRoaXMgY2xlYXJseSBpZGVudGlmaWVzIHRoZSB0cnVlIHNvdXJjZSBhbmQg ZGVzdGluYXRpb24NCmZvciB0aGUNCmRhdGEgaW4NCnRoZSBwYWNrZXQgYXMgd2VsbCBhcyB0aGUg dHdvIHJlbGF5IHNlcnZlcnMgaW52b2x2ZWQuIElmIGJvdGgNCnJlbGF5ZWQNCmFkZHJlc3Nlcw0K YXJlIG9uIHRoZSBzYW1lIHNlcnZlciwgaXQgd2lsbCBvZiBjb3Vyc2Uga25vdyB0aGF0IGFuZCBi ZSBhYmxlIHRvDQpvcHRpbWl6ZSBhcw0KU2ltb24gaW5kaWNhdGVkIGluIGFuIGVhcmxpZXIgZS1t YWlsLg0KDQotLUJyYW5kb24NCg0KT24gMDEvMDgvMjAxNSAwOTo0MCBQTSwgQWlqdW4gV2FuZyB3 cm90ZToNCg0KW0FpanVuXTogVGhlcmUgYXJlIHR3byByZWxheSBhZGRyZXNzLCBvbmUgaXMgdGhl IFRVUk4gc2VydmVyDQp3ZWxsLWtub3duIGFkZHJlc3MsIGFub3RoZXIgaXMgdGhlIHJlbGF5IGFk ZHJlc3MgdGhhdCBhbGxvY2F0ZWQgdG8NCmVhY2ggY2xpZW50LiBXaGljaCBvbmUgc2hvdWxkIGJl IHVzZWQgdGhlbj8gT24gdGhlIG90aGVyIGhhbmQsDQp3aGVuIGNsaWVudCB3YW50IHRvIHNlbmQg dHJhZmZpYyB0byBvdGhlciBwZWVyLCBpdCBkb2VzIG5vdCBrbm93DQp3aGV0aGVyIHRoZSBvdGhl ciBwYXJ0IGlzIHVuZGVyIHRoZSBzYW1lIFRVUk4gc2VydmVyIG9yIG5vdCwgaG93DQpkbyBpdCBz ZWxlY3QNCnRoaXMNCmluZm9ybWF0aW9uPw0KDQoNCg0KW0FpanVuXTogYXMgdGhlIGRlZmluaXRp b24gaW4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlz LTAwI3NlY3Rpb24tMTQuMw0KLCB0aGUgWE9SLVBFRVItQUREUkVTUyBpcyB0aGUgYWRkcmVzcyBz ZWVuIGZyb20gdGhlIFRVUk4gc2VydmVyLA0Kc28gaXQgY2FuJ3QgYmUgdXNlZCB0byBmaW5kIHRo ZSByZWxheSBhZGRyZXNzIG9mIHRoZSByZW1vdGUgcGVlciwNCmFuZCB0aGVuIGNhbid0IGJlIHVz ZWQgdG8gZGlyZWN0IHRyYWZmaWMgdG8gZG93bnN0cmVhbSByZWxheS4NCg0KDQoNCg0KLS0NCkJy YW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdp bmcNClByb2R1Y3RzIEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCg0KDQoN Cg0KLS0NCkJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5l ZXIgRW1lcmdpbmcNClByb2R1Y3RzIEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIElu Yy4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QN CnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxt YWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbQ0KDQo= --_000_5A8F6D13C1C747F1AE5B7BFBE25DC052ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6135692798CED941AEBC303F072DE3C8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxMyBK YW4gMjAxNSwgYXQgMTA6MjgsIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlq dW5AdHNpbmdodWEub3JnLmNuIiBjbGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IiIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiB0cmFtIFs8YSBocmVm PSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFBhbCBNYXJ0aW5zZW48YnIgY2xhc3M9IiI+ DQoocGFsbWFydGkpPGJyIGNsYXNzPSIiPg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxMywgMjAx NSA0OjM5IFBNPGJyIGNsYXNzPSIiPg0KVG86IEFpanVuIFdhbmc8YnIgY2xhc3M9IiI+DQpDYzo8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8L2E+OyBCcmFuZG9u IFdpbGxpYW1zPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFt0cmFtXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRpcmVj dC0wMi50eHQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAxMyBKYW4gMjAxNSwgYXQgMDE6NTAsIEFp anVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuIiBj bGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSGksIEJyYW5kb248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGFua3MgZm9yIHlvdXIgdml2aWQgZ3JhcGggZm9yIG91ciBkaXNjdXNzaW9uLiBUd28g cXVlc3Rpb25zIGFyZTxiciBjbGFzcz0iIj4NCnJhaXNlZDxiciBjbGFzcz0iIj4NCmhlcmU6PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KMS4gSG93IGRvZXMgVFVSTiBzZXJ2ZXIgQSBkZWNp ZGUgd2hlbiB0byB1c2UgVURQIHRvIHNlbmQgYXBwIGRhdGEsIGFuZDxiciBjbGFzcz0iIj4NCndo ZW4gdG8gdXNlIFRVUk4gdG8gc2VuZCBhcHAgZGF0YT8gV2hpY2ggY3JpdGVyaWEgY2FuIGFzc2lz dGFudCB0aGU8YnIgY2xhc3M9IiI+DQpUVVJOIHNlcnZlciBBIHRvIG1ha2UgdGhpcyBkZWNpc2lv bj88YnIgY2xhc3M9IiI+DQpJbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMCNzZWN0aW9uLTEwLjIiIGNsYXNzPSIiPg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbi0x MC4yPC9hPiw8YnIgY2xhc3M9IiI+DQppdCBkZXNjcmliZXMgdGhlIFRVUk4gc2VydmVyIHdpbGwg c2VuZCBVRFAgcmF3IHBhY2tldCB0byB0aGUgcGVlciw8YnIgY2xhc3M9IiI+DQpyZWdhcmRsZXNz IHRoZSBwZWVyIGlzIGF3YXJlbmVzcyBvciB1bmF3YXJlbmVzcyB0aGUgZXhpc3RlbmNlIG9mIFRV Uk4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNz PSIiPg0KVFVSTiBzZXZlciBBIHNlbmRzIOKAnGFwcCBkYXRh4oCdIHRvIGNsaWVudCBBLiBUaGlz IGlzIHRoZSDigJxwcml2YXRl4oCdIHNpZGUgb2YgdGhlPGJyIGNsYXNzPSIiPg0KVFVSTiBzZXJ2 ZXIuIFRVUk4gc2VydmVyIEEgc2VuZHMgVFVSTiBlbmNhcHN1bGF0ZWQgZGF0YSAoZGF0YSBpbmQg b3I8YnIgY2xhc3M9IiI+DQpjaGFubmVsKSBiYWNrIHRvIGNsaWVudCBBIHVzaW5nIHRoZSBzYW1l IDUgdHVwbGUgY2xpZW50IEEgdXNlZCB0byBzZW5kIGhpczxiciBjbGFzcz0iIj4NCmFsbG9jYXRl IHJlcXVlc3QuIFRVUk4gYWxsb3dzIHRoZSBjbGllbnQgdG8gdXNlIFVEUCwgVENQIG9yIFRMUyB0 byBkbyB0aGlzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoYXQgaGFwcGVucyBvbiB0 aGUg4oCccHVibGlj4oCdIHNpZGUgb2YgdGhlIFRVUk4gc2VydmVyIGlzIGFsd2F5cyBVRFAgKFVu bGVzczxiciBjbGFzcz0iIj4NCnRoZSBUVVJOIHNlcnZlciBzdXBwb3J0cyBUVVJOLVRDUCBhbmQg dGhlIGNsaWVudCBoYXZlIGFza2VkIGZvciBhIFRDUCBwb3J0PGJyIGNsYXNzPSIiPg0KYWxsb2Nh dGlvbikuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHJlbW90ZSBzaWRlIGRvIG5v dCBuZWVkIHRvIGtub3cgdGhhdCBpdCBpcyBzZW5kaW5nIHBhY2tldHMgdG8gYSBUVVJOPGJyIGNs YXNzPSIiPg0Kc2VydmVyLCBhbmQgdGhhdCB0aGUgcGFja2V0cyB3b3VsZCDigJxtYWdpY2FsbHni gJ0gYmUgc2VudCB0byB0aGUgY2xpZW50IHRoYXQ8YnIgY2xhc3M9IiI+DQphbGxvY2F0ZWQgdGhh dCBwb3J0LiBUaGluayBvZiBUVVJOIGFzIGEgbWVjaGFuaXNtIHRvIG1vdmUgeW91ciBib3ggb3V0 IG9uIHRoZTxiciBjbGFzcz0iIj4NCkludGVybmV0IGFuZCBvYnRhaW5pbmcgcHVibGljIHJvdXRh YmxlIElQLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPkkNCiBhZ3JlZSB3aXRoIHlvdSBhdCB0aGVzZSBwb2ludHMuIEJ1dCBt eSBjb25jZXJuIGZvY3VzIG9uIHRoZSBjb21tdW5pY2F0aW9uIGNoYW5uZWwgYmV0d2VlbiBUVVJO IFNlcnZlciBBL1RVUk4gU2VydmVyIEIgYW5kIFRVUk4gQi9QZWVyIEIuIEluIGN1cnJlbnQgVFVS TiBkcmFmdCwgdGhleSBhbGwgdXNlIHRoZSBwdXJlIFVEUCBwYWNrZXQuIEJ1dCBpbiBCcmFuZG9u 4oCZcyBncmFwaCwgdGhleSBhcmUgZGlmZmVyZW50OiB0aGUgcHJldmlvdXMgcGFpcg0KIHVzZSBw dXJlIFVEUCBkYXRhZ3JhbSwgYnV0IHRoZSBsYXR0ZXIgcGFpciB1c2UgREFUQSBpbmRpY2F0aW9u LCB3aGljaCBpcyBub3QgZGVzY3JpYmVkIGluIGN1cnJlbnQgVFVSTiBkcmFmdCwNCjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+VW5sZXNzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgdGhpcyBpcyBkZXNjcmliZWQgaW4g c2VjdGlvbiAxMC4zLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9IiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmFu ZA0KIHdpbGwgbGVhZCB0aGUgVFVSTiBzZXJ2ZXIgQSBiZSBjb25mdXNlZCwgYmVjYXVzZSBpdCBt aWdodCBmYWNlIHRoZSBUVVJOIFNlcnZlciBCIGFuZCBvdGhlciBjb21tdW5pY2F0aW9uIHBlZXIs IHN1Y2ggYXMgcGVlciBDIHRoYXQgZGlyZWN0bHkgY29ubmVjdGVkIG9uIHRoZSBUVVJOIHNlcnZl ciBBLiAmbmJzcDtXaGljaCBlbmNhcHN1bGF0aW9uIG1ldGhvZCB3aWxsIGJlIHVzZWQgdGhlbj88 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5VRFAuIEJ1 dCB0aGF0IHJlcXVpcmVzIGNsaWVudCBhIHRvIHNldCB0aGUgY29ycmVjdCBwZXJtaXNzaW9ucyB0 byBhbGxvdyB0cmFmZmljIGZyb20gQyB0byBiZSByZWxheWVkIHRvIEEuPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5XZSBhcmUgZGlzY3Vzc2luZyBub3JtYWwgVFVSTiBv cGVyYXRpb24gaGVyZT8gSWYgbm90IEkgYXBvbG9naXNlIGlmIEkgaGF2ZSBtaXNzZWQgc29tZXRo aW5nIGluIHRoZSBkaXNjdXNzaW9uLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8ZGl2PlDDpWwtRXJpazwvZGl2Pg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSIiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Mi4gSW4geW91ciBleGFtcGxlLCBpZiBUVVJOIEIg dXNlIHRoZSBEQVRBIGluZGljYXRpb24gdG8gQiwgd2hhdCB3aWxsPGJyIGNsYXNzPSIiPg0KQiBk byBpZiBpdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBUVVJOIGVuY2Fwc3VsYXRpb24/PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlcmUgaXMgbm8gd2F5IGEgVFVS TiBzZXJ2ZXIgd291bGQgc2VuZCBkYXRhIGluZCB0byBhIGNsaWVudCB3aXRob3V0IHRoZTxiciBj bGFzcz0iIj4NCmNsaWVudCBoYXZpbmcgYWxsb2NhdGVkIGEgcG9ydC48YnIgY2xhc3M9IiI+DQpX aXRob3V0IGNsaWVudCBCIHNlbmRpbmcgdGhlIGFsbG9jYXRlIHJlcXVlc3QgdGhlcmUgd291bGQg bm90IGJlIGEgYmluZGluZyBpbjxiciBjbGFzcz0iIj4NCnRoZSBOQVQgZWl0aGVyLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi PkFjdHVhbGx5DQogdHJ1ZS4gQnV0IG15IGNvbmNlcm4gaGVyZSBmb2N1cyBzdGlsbCBvbiB0aGUg ZGF0YSBmb3J3YXJkaW5nIHBsYW5lLCBub3QgdGhlIGNvbnRyb2wgcGxhbmUgb2YgVFVSTiBzb2x1 dGlvbi48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KLi0uPGJy IGNsYXNzPSIiPg0KUMOlbC1FcmlrPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QmVzdCBSZWdhcmRzLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNsYXNzPSIi Pg0KRnJvbTogQnJhbmRvbiBXaWxsaWFtcyBbPGEgaHJlZj0ibWFpbHRvOmJyYW5kb24ud2lsbGlh bXNAYWthbWFpLmNvbSIgY2xhc3M9IiI+bWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNv bTwvYT5dPGJyIGNsYXNzPSIiPg0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDEyLCAyMDE1IDExOjQ1 IFBNPGJyIGNsYXNzPSIiPg0KVG86IEFpanVuIFdhbmc7IDxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NClN1YmplY3Q6 IFJlOiBbdHJhbV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyIGNsYXNzPSIi Pg0KZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRpcmVjdC0wMi50eHQ8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpYT1ItUEVFUi1BRERSRVNTIGNvbnRhaW5zICZxdW90O3RoZSB0cmFuc3BvcnQg YWRkcmVzcyBvZiB0aGUgcGVlciZxdW90Oy4gSXQgaXM8YnIgY2xhc3M9IiI+DQpub3QgcmVxdWly ZWQgdG8gYmUgYSBzcGVjaWZpYyB0eXBlIG9mIGFkZHJlc3MgKGhvc3QsIHJlZmxleGl2ZSwgb3Ig cmVsYXkpLjxiciBjbGFzcz0iIj4NCkl0IHdpbGwgYmUgYW55IGFkZHJlc3MgdGhhdCBjYW4gYmUg dXNlZCB0byBkZWxpdmVyIGRhdGEgdG8gdGhlIHJlbW90ZTxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCnBlZXIuIElmPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+dHdvIFRVUk4gcmVsYXlzIGFyZSB1c2VkLCB0aGVuIHRoZSBYT1ItUEVFUi1BRERSRVNT IGF0dHJpYnV0ZSBpbiBTZW5kPGJyIGNsYXNzPSIiPg0KYW5kIERhdGEgaW5kaWNhdGlvbnMgd2ls bCBjb250YWluIHRoZSByZW1vdGUgcGVlcidzIGFsbG9jYXRlZCByZWxheSBhZGRyZXNzLjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NClRoZXJlPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+aXMgbm8gbmVlZCB0aGUgZm9yIGVpdGhlciBvZiB0aGUgcmVs YXlzIHRvIGV2ZW4gYmUgYXdhcmUgdGhhdCB0aGU8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQp0cmFuc3BvcnQ8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij5hZGRyZXNzIGlzIGEgcmVsYXkgYWRkcmVzcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpDb25zaWRlciB0aGUgZm9sbG93aW5nOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEg Jmx0Oy0mZ3Q7IFhBICZsdDstJmd0OyBUQXxSQSAmbHQ7LSZndDsgUkJ8VEIgJmx0Oy0mZ3Q7IFhC ICZsdDstJmd0OyBCPGJyIGNsYXNzPSIiPg0KfCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fDxiciBjbGFzcz0iIj4NCnwtLS0tIFRVUk4gLS0tLXwtLSBVRFAgLS18LS0tLSBU VVJOIC0tLS18PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBhbmQgQiBhcmUgdGhlIHR3 byBwZWVycycgaG9zdCBhZGRyZXNzZXMuPGJyIGNsYXNzPSIiPg0KWEEgYW5kIFhCIGFyZSB0aGUg dHdvIHBlZXJzJyByZWZsZXhpdmUgYWRkcmVzc2VzLjxiciBjbGFzcz0iIj4NClRBIGFuZCBUQiBh cmUgdGhlIHJlbGF5IHNlcnZlcnMnIGFkZHJlc3NlcyB1c2VkIGFzIHRoZSBUVVJOIHNlc3Npb248 YnIgY2xhc3M9IiI+DQplbmRwb2ludHMuPGJyIGNsYXNzPSIiPg0KUkEgYW5kIFJCIGFyZSB0aGUg dHdvIHBlZXJzJyBhbGxvY2F0ZWQgcmVsYXkgYWRkcmVzc2VzLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkEgU2VuZCBpbmRpY2F0aW9uIGZyb20gQSB0byBUQSB1c2VzIFJCIGFzIHRoZSBY T1ItUEVFUi1BRERSRVNTLiBXaGVuPGJyIGNsYXNzPSIiPg0KQSdzIHJlbGF5IHJlY2VpdmVzIHRo ZSBTZW5kIGluZGljYXRpb24sIGl0IHNlbmRzIHRoZSBkYXRhIGluIGEgcGxhaW48YnIgY2xhc3M9 IiI+DQpVRFA8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpkYXRhZ3JhbTxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPndpdGggUkEgYXMgdGhlIHNvdXJj ZSBhbmQgUkIgYXMgdGhlIGRlc3RpbmF0aW9uLiBXaGVuIEIncyByZWxheTxiciBjbGFzcz0iIj4N CnJlY2VpdmVzPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KdGhlPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+VURQIGRhdGFncmFtLCBpdCBzZW5kcyBh IERhdGEgaW5kaWNhdGlvbiBmcm9tIFRCIHRvIEIgd2l0aCBSQSBhcyB0aGU8YnIgY2xhc3M9IiI+ DQpYT1ItUEVFUi1BRERSRVNTLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tQnJhbmRv bjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDAxLzExLzIwMTUgMDc6NDMgUE0sIEFp anVuIFdhbmcgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+SGksIEJyYW5kb246PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW48YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMCNzZWN0aW9uLTEwLjEiIGNsYXNzPSIiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTAuMTwvYT4sPGJyIGNs YXNzPSIiPg0KaXQgaXMgZGVzY3JpYmVkIGFzIGJlbG93OjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCldoZW4gZm9ybWluZyBhIFNlbmQgaW5kaWNhdGlvbiwgdGhlIGNsaWVudCBNVVNUIGlu Y2x1ZGUgYW4gWE9SLVBFRVItPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7QUREUkVTUyBhdHRy aWJ1dGUgYW5kIGEgREFUQSBhdHRyaWJ1dGUuICZuYnNwO1RoZSBYT1ItUEVFUi1BRERSRVNTPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YXR0cmlidXRlIGNvbnRhaW5zIHRoZSB0cmFuc3BvcnQg YWRkcmVzcyBvZiB0aGUgcGVlciB0byB3aGljaCB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDtkYXRhIGlzIHRvIGJlIHNlbnQsIGFuZCB0aGUgREFUQSBhdHRyaWJ1dGUgY29udGFpbnMgdGhl IGFjdHVhbDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2FwcGxpY2F0aW9uIGRhdGEgdG8gYmUg c2VudCB0byB0aGUgcGVlci48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTbywgdGhlcmUg aXMgbm8gWE9SLVJFTEFZRUQtQUREUkVTUyBhdHRyaWJ1dGUgaW5jbHVkZWQgdG8gaWRlbnRpZnk8 YnIgY2xhc3M9IiI+DQp0aGUgcGVlcidzIGFsbG9jYXRlZCByZWxheSBhZGRyZXNzLiBPbiB0aGUg b3RoZXIgaGFuZCw8YnIgY2xhc3M9IiI+DQpYT1ItUkVMQVlFRC1BRERSRVNTIGlzIG1haW5seSBy ZWZlciB0byB0aGUgcmVxdWVzdGVyJ3MgYWxsb2NhdGVkPGJyIGNsYXNzPSIiPg0KcmVsYXkgYWRk cmVzcywgbm90IHRoZSBjb3JyZXNwb25kaW5nIHBlZXIuIFdpbGwgd2UgZGVmaW5lIGFnYWluIG9u ZTxiciBjbGFzcz0iIj4NCm5ldyBhdHRyaWJ1dGUsIHN1Y2ggYXMgWE9SLVBFRVItUkVMQVlFRC1B RERSRVNTIHRvIHRyYW5zZmVyIHRoZSBuZXh0PGJyIGNsYXNzPSIiPg0KVFVSTiBzZXJ2ZXInczxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmluZm9ybWF0aW9uPzxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkV2ZW4gaWYgc28s IHdoYXQgd2lsbCBiZSB0aGUgc291cmNlIGFkZHJlc3MgZm9yIHRoZSBwYWNrZXQgZnJvbSB0aGU8 YnIgY2xhc3M9IiI+DQpzZWNvbmQgVFVSTiBzZXJ2ZXIgdG8gZGVzdGluYXRpb24gcGVlcj8gSWYg d2UgdXNlIHRoZTxiciBjbGFzcz0iIj4NClhPUi1SRUxBWUVELUFERFJFU1MsIHRoZW4gdGhlIHJl dHVybiBwYWNrZXQgZnJvbSB0aGUgcGVlciB3aWxsIGJlPGJyIGNsYXNzPSIiPg0KcGFzc2VkIGJh Y2sgZGlyZWN0bHkgdG8gdGhlIGZpcnN0IFRVUk4gc2VydmVyLCByZXN1bHRzIGluPGJyIGNsYXNz PSIiPg0Kbm9uLXN5bW1ldHJpYyByb3V0ZS4gSWYgd2UgdXNlIFhPUi1QRUVSLVJFTEFZRUQtQURE UkVTUywgdGhlbiB3aGF0PGJyIGNsYXNzPSIiPg0KaXMgdGhlIHNvdXJjZSBhZGRyZXNzIGZvciB0 aGUgcGFja2V0IGZyb20gdGhlIHNlY29uZCBUVVJOIHNlcnZlcjxiciBjbGFzcz0iIj4NCmJhY2sg dG88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQp0aGU8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5maXJzdCBUVVJOIHNlcnZl cj88YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQpCZXN0IFJlZ2FyZHMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIg Y2xhc3M9IiI+DQpGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFs8YSBocmVmPSJtYWlsdG86Ym93aWxs QGFrYW1haS5jb20iIGNsYXNzPSIiPm1haWx0bzpib3dpbGxAYWthbWFpLmNvbTwvYT5dPGJyIGNs YXNzPSIiPg0KU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTAsIDIwMTUgMTowOSBBTTxiciBjbGFz cz0iIj4NClRvOiBBaWp1biBXYW5nOyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xh c3M9IiI+dHJhbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBSZTogW3RyYW1d IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxiciBjbGFzcz0iIj4NCmRyYWZ0LXdp bGxpYW1zLXBlZXItcmVkaXJlY3QtMDIudHh0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K QnkgcmVsYXkgYWRkcmVzcywgSSBtZWFuIHRoZSBYT1ItUkVMQVlFRC1BRERSRVNTIHJldHVybmVk IGluIHRoZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmFsbG9jYXRpb248YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5yZXF1ZXN0LiBUaGlzIGNsZWFy bHkgaWRlbnRpZmllcyB0aGUgdHJ1ZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uPGJyIGNsYXNzPSIi Pg0KZm9yIHRoZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmRhdGEgaW48YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj50aGUgcGFja2V0IGFzIHdlbGwg YXMgdGhlIHR3byByZWxheSBzZXJ2ZXJzIGludm9sdmVkLiBJZiBib3RoPGJyIGNsYXNzPSIiPg0K cmVsYXllZDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmFkZHJlc3NlczxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmFyZSBvbiB0aGUgc2FtZSBzZXJ2 ZXIsIGl0IHdpbGwgb2YgY291cnNlIGtub3cgdGhhdCBhbmQgYmUgYWJsZSB0bzxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCm9wdGltaXplIGFzPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+U2ltb24gaW5kaWNhdGVkIGluIGFuIGVhcmxpZXIgZS1tYWls LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tQnJhbmRvbjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCk9uIDAxLzA4LzIwMTUgMDk6NDAgUE0sIEFpanVuIFdhbmcgd3JvdGU6PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KW0FpanVuXTogVGhlcmUgYXJlIHR3byByZWxheSBhZGRyZXNzLCBvbmUgaXMgdGhlIFRVUk4g c2VydmVyPGJyIGNsYXNzPSIiPg0Kd2VsbC1rbm93biBhZGRyZXNzLCBhbm90aGVyIGlzIHRoZSBy ZWxheSBhZGRyZXNzIHRoYXQgYWxsb2NhdGVkIHRvPGJyIGNsYXNzPSIiPg0KZWFjaCBjbGllbnQu IFdoaWNoIG9uZSBzaG91bGQgYmUgdXNlZCB0aGVuPyBPbiB0aGUgb3RoZXIgaGFuZCw8YnIgY2xh c3M9IiI+DQp3aGVuIGNsaWVudCB3YW50IHRvIHNlbmQgdHJhZmZpYyB0byBvdGhlciBwZWVyLCBp dCBkb2VzIG5vdCBrbm93PGJyIGNsYXNzPSIiPg0Kd2hldGhlciB0aGUgb3RoZXIgcGFydCBpcyB1 bmRlciB0aGUgc2FtZSBUVVJOIHNlcnZlciBvciBub3QsIGhvdzxiciBjbGFzcz0iIj4NCmRvIGl0 IHNlbGVjdDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCnRoaXM8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5pbmZvcm1hdGlv bj88YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpbQWlqdW5dOiBhcyB0aGUgZGVmaW5pdGlvbiBp bjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTQuMyIgY2xhc3M9IiI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbi0xNC4zPC9h PjxiciBjbGFzcz0iIj4NCiwgdGhlIFhPUi1QRUVSLUFERFJFU1MgaXMgdGhlIGFkZHJlc3Mgc2Vl biBmcm9tIHRoZSBUVVJOIHNlcnZlciw8YnIgY2xhc3M9IiI+DQpzbyBpdCBjYW4ndCBiZSB1c2Vk IHRvIGZpbmQgdGhlIHJlbGF5IGFkZHJlc3Mgb2YgdGhlIHJlbW90ZSBwZWVyLDxiciBjbGFzcz0i Ij4NCmFuZCB0aGVuIGNhbid0IGJlIHVzZWQgdG8gZGlyZWN0IHRyYWZmaWMgdG8gZG93bnN0cmVh bSByZWxheS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLTxiciBjbGFzcz0iIj4N CkJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1l cmdpbmc8YnIgY2xhc3M9IiI+DQpQcm9kdWN0cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xv Z2llcyBJbmMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K LS08YnIgY2xhc3M9IiI+DQpCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3 YXJlIEVuZ2luZWVyIEVtZXJnaW5nPGJyIGNsYXNzPSIiPg0KUHJvZHVjdHMgRW5naW5lZXJpbmc7 IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xh c3M9IiI+dHJhbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg Y2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i bWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+ PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnRyYW0NCiBt YWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_5A8F6D13C1C747F1AE5B7BFBE25DC052ciscocom_-- From nobody Tue Jan 13 15:09:52 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8821B2B66 for ; Tue, 13 Jan 2015 15:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nYwNGMuMl5zv for ; Tue, 13 Jan 2015 15:09:35 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9A1B2B65 for ; Tue, 13 Jan 2015 15:09:13 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 927D628522; Tue, 13 Jan 2015 23:09:12 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 78CD528521; Tue, 13 Jan 2015 23:09:12 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id DD5C8202E; Tue, 13 Jan 2015 23:09:11 +0000 (GMT) Message-ID: <54B5A597.8030801@akamai.com> Date: Tue, 13 Jan 2015 18:09:11 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aijun Wang References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> In-Reply-To: <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 23:09:45 -0000 I agree with Pål-Erik that we're discussing existing TURN functionality here. There is no outstanding problem with a use-case involving two TURN relay servers, one for each peer. The existing protocol supports this just fine. Maybe the lengthy back-and-forth discussion suggests that there could be some value in documenting this particular use case somewhere (turnbis? a separate draft?) to help clarify it for future implementers. --Brandon On 01/13/2015 01:54 PM, Pal Martinsen (palmarti) wrote: > >> On 13 Jan 2015, at 10:28, Aijun Wang > > wrote: >> >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen >>> (palmarti) >>> Sent: Tuesday, January 13, 2015 4:39 PM >>> To: Aijun Wang >>> Cc:tram@ietf.org ; Brandon Williams >>> Subject: Re: [tram] New Version Notification for >>> draft-williams-peer-redirect-02.txt >>> >>> >>>> On 13 Jan 2015, at 01:50, Aijun Wang >>> > wrote: >>>> >>>> Hi, Brandon >>>> >>>> Thanks for your vivid graph for our discussion. Two questions are >>>> raised >>>> here: >>>> >>>> 1. How does TURN server A decide when to use UDP to send app data, and >>>> when to use TURN to send app data? Which criteria can assistant the >>>> TURN server A to make this decision? >>>> In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2, >>>> it describes the TURN server will send UDP raw packet to the peer, >>>> regardless the peer is awareness or unawareness the existence of TURN. >>>> >>> >>> TURN sever A sends “app data” to client A. This is the “private” side >>> of the >>> TURN server. TURN server A sends TURN encapsulated data (data ind or >>> channel) back to client A using the same 5 tuple client A used to >>> send his >>> allocate request. TURN allows the client to use UDP, TCP or TLS to do >>> this. >>> >>> What happens on the “public” side of the TURN server is always UDP >>> (Unless >>> the TURN server supports TURN-TCP and the client have asked for a TCP >>> port >>> allocation). >>> >>> The remote side do not need to know that it is sending packets to a TURN >>> server, and that the packets would “magically” be sent to the client that >>> allocated that port. Think of TURN as a mechanism to move your box >>> out on the >>> Internet and obtaining public routable IP. >>> >> >> I agree with you at these points. But my concern focus on the >> communication channel between TURN Server A/TURN Server B and TURN >> B/Peer B. In current TURN draft, they all use the pure UDP packet. But >> in Brandon’s graph, they are different: the previous pair use pure UDP >> datagram, but the latter pair use DATA indication, which is not >> described in current TURN draft, > > Unless I am missing something this is described in section 10.3. > > >> and will lead the TURN server A be confused, because it might face the >> TURN Server B and other communication peer, such as peer C that >> directly connected on the TURN server A. Which encapsulation method >> will be used then? >> > > UDP. But that requires client a to set the correct permissions to allow > traffic from C to be relayed to A. > > We are discussing normal TURN operation here? If not I apologise if I > have missed something in the discussion. > > .-. > Pål-Erik > > > >>> >> >> >>>> 2. In your example, if TURN B use the DATA indication to B, what will >>>> B do if it does not support the TURN encapsulation? >>>> >>> There is no way a TURN server would send data ind to a client without the >>> client having allocated a port. >>> Without client B sending the allocate request there would not be a >>> binding in >>> the NAT either. >>> >> >> Actually true. But my concern here focus still on the data forwarding >> plane, not the control plane of TURN solution. >> >>> .-. >>> Pål-Erik >>> >>> >>>> Best Regards. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>>> Sent: Monday, January 12, 2015 11:45 PM >>>>> To: Aijun Wang; tram@ietf.org >>>>> Subject: Re: [tram] Fwd: New Version Notification for >>>>> draft-williams-peer-redirect-02.txt >>>>> >>>>> XOR-PEER-ADDRESS contains "the transport address of the peer". It is >>>>> not required to be a specific type of address (host, reflexive, or >>>>> relay). >>>>> It will be any address that can be used to deliver data to the remote >>>> peer. If >>>>> two TURN relays are used, then the XOR-PEER-ADDRESS attribute in Send >>>>> and Data indications will contain the remote peer's allocated relay >>>>> address. >>>> There >>>>> is no need the for either of the relays to even be aware that the >>>> transport >>>>> address is a relay address. >>>>> >>>>> Consider the following: >>>>> >>>>> A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B >>>>> | | | | >>>>> |---- TURN ----|-- UDP --|---- TURN ----| >>>>> >>>>> A and B are the two peers' host addresses. >>>>> XA and XB are the two peers' reflexive addresses. >>>>> TA and TB are the relay servers' addresses used as the TURN session >>>>> endpoints. >>>>> RA and RB are the two peers' allocated relay addresses. >>>>> >>>>> A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. When >>>>> A's relay receives the Send indication, it sends the data in a plain >>>>> UDP >>>> datagram >>>>> with RA as the source and RB as the destination. When B's relay >>>>> receives >>>> the >>>>> UDP datagram, it sends a Data indication from TB to B with RA as the >>>>> XOR-PEER-ADDRESS. >>>>> >>>>> --Brandon >>>>> >>>>> On 01/11/2015 07:43 PM, Aijun Wang wrote: >>>>>> Hi, Brandon: >>>>>> >>>>>> In >>>>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, >>>>>> it is described as below: >>>>>> >>>>>> When forming a Send indication, the client MUST include an XOR-PEER- >>>>>> ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS >>>>>> attribute contains the transport address of the peer to which the >>>>>> data is to be sent, and the DATA attribute contains the actual >>>>>> application data to be sent to the peer. >>>>>> >>>>>> So, there is no XOR-RELAYED-ADDRESS attribute included to identify >>>>>> the peer's allocated relay address. On the other hand, >>>>>> XOR-RELAYED-ADDRESS is mainly refer to the requester's allocated >>>>>> relay address, not the corresponding peer. Will we define again one >>>>>> new attribute, such as XOR-PEER-RELAYED-ADDRESS to transfer the next >>>>>> TURN server's >>>>> information? >>>>>> >>>>>> Even if so, what will be the source address for the packet from the >>>>>> second TURN server to destination peer? If we use the >>>>>> XOR-RELAYED-ADDRESS, then the return packet from the peer will be >>>>>> passed back directly to the first TURN server, results in >>>>>> non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then what >>>>>> is the source address for the packet from the second TURN server >>>>>> back to >>>> the >>>>> first TURN server? >>>>>> >>>>>> Best Regards. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Brandon Williams [mailto:bowill@akamai.com] >>>>>>> Sent: Saturday, January 10, 2015 1:09 AM >>>>>>> To: Aijun Wang; tram@ietf.org >>>>>>> Subject: Re: [tram] Fwd: New Version Notification for >>>>>>> draft-williams-peer-redirect-02.txt >>>>>>> >>>>>>> By relay address, I mean the XOR-RELAYED-ADDRESS returned in the >>>>>> allocation >>>>>>> request. This clearly identifies the true source and destination >>>>>>> for the >>>>>> data in >>>>>>> the packet as well as the two relay servers involved. If both >>>>>>> relayed >>>>>> addresses >>>>>>> are on the same server, it will of course know that and be able to >>>>>> optimize as >>>>>>> Simon indicated in an earlier e-mail. >>>>>>> >>>>>>> --Brandon >>>>>>> >>>>>>> On 01/08/2015 09:40 PM, Aijun Wang wrote: >>>>>>>> >>>>>>>> [Aijun]: There are two relay address, one is the TURN server >>>>>>>> well-known address, another is the relay address that allocated to >>>>>>>> each client. Which one should be used then? On the other hand, >>>>>>>> when client want to send traffic to other peer, it does not know >>>>>>>> whether the other part is under the same TURN server or not, how >>>>>>>> do it select >>>>>> this >>>>>>> information? >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> [Aijun]: as the definition in >>>>>>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3 >>>>>>>> , the XOR-PEER-ADDRESS is the address seen from the TURN server, >>>>>>>> so it can't be used to find the relay address of the remote peer, >>>>>>>> and then can't be used to direct traffic to downstream relay. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>>>>> Products Engineering; Akamai Technologies Inc. >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>>> Products Engineering; Akamai Technologies Inc. >>>> >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Jan 13 17:55:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF2D1B2A1B for ; Tue, 13 Jan 2015 17:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 49ppqRPKF3jW for ; Tue, 13 Jan 2015 17:55:44 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 60C391ACE52 for ; Tue, 13 Jan 2015 17:55:43 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CbQwEdt7VUSKHfAA==.9717S4; Wed, 14 Jan 2015 08:24:01 +0800 (CST) From: "Aijun Wang" To: "'Brandon Williams'" , References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> In-Reply-To: Date: Wed, 14 Jan 2015 09:55:24 +0800 Message-ID: <002a01d02f9d$29de2660$7d9a7320$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAveWg7OXWEAx+oTcGXGRKTVf4FMgAGZgpAAAIDd3A= Content-Language: zh-cn X-CM-TRANSID: Z0GX06CbQwEdt7VUSKHfAA==.9717S4 X-Coremail-Antispam: 1U3129KBjvJXoWfGr48CF1DAw1DAFyfKw1rWFg_yoWkXF4Upr W3JF47KF4DJr17Jws7tr1jqF1jv3ykJr1fXr15tr1xZas8tF17tF1UKr1ruFyUGr1rGw1j qr1Uua47Xr15ArDanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: Cc: tram@ietf.org Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 01:55:48 -0000 Hi, Brandon & pal: Let's consider the following graph: A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B | | | | | | | | | | | +----------XC<--->C | | | |---- TURN -----|--- UDP --|---- TURN --------| If there is another peer(peer C) connected directly to TURN Server A at = the same time, then TURN Server A will use also the pure UDP packet to = relay data from A to C. Then, how this packet pass through the EDM NAT = device that locates before peer C? Peer C only send request packet to = TURN Server A's TA address previously. Actually, I consider current TURN draft only consider the scenarios that = there exist only one TURN Server, and will lead more complex design if = it want to solve the TURN-to-TURN at the same time. Best Regards. Aijun Wang > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Wednesday, January 14, 2015 7:09 AM > To: Aijun Wang > Cc: tram@ietf.org > Subject: Re: [tram] New Version Notification for > draft-williams-peer-redirect-02.txt >=20 > I agree with P=C3=A5l-Erik that we're discussing existing TURN = functionality here. > There is no outstanding problem with a use-case involving two TURN = relay > servers, one for each peer. The existing protocol supports this just = fine. >=20 > Maybe the lengthy back-and-forth discussion suggests that there could = be > some value in documenting this particular use case somewhere (turnbis? = a > separate draft?) to help clarify it for future implementers. >=20 > --Brandon >=20 > On 01/13/2015 01:54 PM, Pal Martinsen (palmarti) wrote: > > > >> On 13 Jan 2015, at 10:28, Aijun Wang >> > wrote: > >> > >>> -----Original Message----- > >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal = Martinsen > >>> (palmarti) > >>> Sent: Tuesday, January 13, 2015 4:39 PM > >>> To: Aijun Wang > >>> Cc:tram@ietf.org ; Brandon Williams > >>> Subject: Re: [tram] New Version Notification for > >>> draft-williams-peer-redirect-02.txt > >>> > >>> > >>>> On 13 Jan 2015, at 01:50, Aijun Wang >>>> > wrote: > >>>> > >>>> Hi, Brandon > >>>> > >>>> Thanks for your vivid graph for our discussion. Two questions are > >>>> raised > >>>> here: > >>>> > >>>> 1. How does TURN server A decide when to use UDP to send app = data, > >>>> and when to use TURN to send app data? Which criteria can = assistant > >>>> the TURN server A to make this decision? > >>>> In > >>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.2, > >>>> it describes the TURN server will send UDP raw packet to the = peer, > >>>> regardless the peer is awareness or unawareness the existence of = TURN. > >>>> > >>> > >>> TURN sever A sends =E2=80=9Capp data=E2=80=9D to client A. This is = the =E2=80=9Cprivate=E2=80=9D > >>> side of the TURN server. TURN server A sends TURN encapsulated = data > >>> (data ind or > >>> channel) back to client A using the same 5 tuple client A used to > >>> send his allocate request. TURN allows the client to use UDP, TCP = or > >>> TLS to do this. > >>> > >>> What happens on the =E2=80=9Cpublic=E2=80=9D side of the TURN = server is always UDP > >>> (Unless the TURN server supports TURN-TCP and the client have = asked > >>> for a TCP port allocation). > >>> > >>> The remote side do not need to know that it is sending packets to = a > >>> TURN server, and that the packets would = =E2=80=9Cmagically=E2=80=9D be sent to the > >>> client that allocated that port. Think of TURN as a mechanism to > >>> move your box out on the Internet and obtaining public routable = IP. > >>> > >> > >> I agree with you at these points. But my concern focus on the > >> communication channel between TURN Server A/TURN Server B and TURN > >> B/Peer B. In current TURN draft, they all use the pure UDP packet. > >> But in Brandon=E2=80=99s graph, they are different: the previous = pair use > >> pure UDP datagram, but the latter pair use DATA indication, which = is > >> not described in current TURN draft, > > > > Unless I am missing something this is described in section 10.3. > > > > > >> and will lead the TURN server A be confused, because it might face > >> the TURN Server B and other communication peer, such as peer C that > >> directly connected on the TURN server A. Which encapsulation = method > >> will be used then? > >> > > > > UDP. But that requires client a to set the correct permissions to > > allow traffic from C to be relayed to A. > > > > We are discussing normal TURN operation here? If not I apologise if = I > > have missed something in the discussion. > > > > .-. > > P=C3=A5l-Erik > > > > > > > >>> > >> > >> > >>>> 2. In your example, if TURN B use the DATA indication to B, what > >>>> will B do if it does not support the TURN encapsulation? > >>>> > >>> There is no way a TURN server would send data ind to a client > >>> without the client having allocated a port. > >>> Without client B sending the allocate request there would not be a > >>> binding in the NAT either. > >>> > >> > >> Actually true. But my concern here focus still on the data = forwarding > >> plane, not the control plane of TURN solution. > >> > >>> .-. > >>> P=C3=A5l-Erik > >>> > >>> > >>>> Best Regards. > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >>>>> Sent: Monday, January 12, 2015 11:45 PM > >>>>> To: Aijun Wang; tram@ietf.org > >>>>> Subject: Re: [tram] Fwd: New Version Notification for > >>>>> draft-williams-peer-redirect-02.txt > >>>>> > >>>>> XOR-PEER-ADDRESS contains "the transport address of the peer". = It > >>>>> is not required to be a specific type of address (host, = reflexive, > >>>>> or relay). > >>>>> It will be any address that can be used to deliver data to the > >>>>> remote > >>>> peer. If > >>>>> two TURN relays are used, then the XOR-PEER-ADDRESS attribute in > >>>>> Send and Data indications will contain the remote peer's = allocated > >>>>> relay address. > >>>> There > >>>>> is no need the for either of the relays to even be aware that = the > >>>> transport > >>>>> address is a relay address. > >>>>> > >>>>> Consider the following: > >>>>> > >>>>> A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B > >>>>> | | | | > >>>>> |---- TURN ----|-- UDP --|---- TURN ----| > >>>>> > >>>>> A and B are the two peers' host addresses. > >>>>> XA and XB are the two peers' reflexive addresses. > >>>>> TA and TB are the relay servers' addresses used as the TURN > >>>>> session endpoints. > >>>>> RA and RB are the two peers' allocated relay addresses. > >>>>> > >>>>> A Send indication from A to TA uses RB as the XOR-PEER-ADDRESS. > >>>>> When A's relay receives the Send indication, it sends the data = in > >>>>> a plain UDP > >>>> datagram > >>>>> with RA as the source and RB as the destination. When B's relay > >>>>> receives > >>>> the > >>>>> UDP datagram, it sends a Data indication from TB to B with RA as > >>>>> the XOR-PEER-ADDRESS. > >>>>> > >>>>> --Brandon > >>>>> > >>>>> On 01/11/2015 07:43 PM, Aijun Wang wrote: > >>>>>> Hi, Brandon: > >>>>>> > >>>>>> In > >>>>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10. > >>>>>> 1, > >>>>>> it is described as below: > >>>>>> > >>>>>> When forming a Send indication, the client MUST include an = XOR-PEER- > >>>>>> ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS > >>>>>> attribute contains the transport address of the peer to which = the > >>>>>> data is to be sent, and the DATA attribute contains the = actual > >>>>>> application data to be sent to the peer. > >>>>>> > >>>>>> So, there is no XOR-RELAYED-ADDRESS attribute included to > >>>>>> identify the peer's allocated relay address. On the other hand, > >>>>>> XOR-RELAYED-ADDRESS is mainly refer to the requester's = allocated > >>>>>> relay address, not the corresponding peer. Will we define again > >>>>>> one new attribute, such as XOR-PEER-RELAYED-ADDRESS to transfer > >>>>>> the next TURN server's > >>>>> information? > >>>>>> > >>>>>> Even if so, what will be the source address for the packet from > >>>>>> the second TURN server to destination peer? If we use the > >>>>>> XOR-RELAYED-ADDRESS, then the return packet from the peer will = be > >>>>>> passed back directly to the first TURN server, results in > >>>>>> non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then > >>>>>> what is the source address for the packet from the second TURN > >>>>>> server back to > >>>> the > >>>>> first TURN server? > >>>>>> > >>>>>> Best Regards. > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Brandon Williams [mailto:bowill@akamai.com] > >>>>>>> Sent: Saturday, January 10, 2015 1:09 AM > >>>>>>> To: Aijun Wang; tram@ietf.org > >>>>>>> Subject: Re: [tram] Fwd: New Version Notification for > >>>>>>> draft-williams-peer-redirect-02.txt > >>>>>>> > >>>>>>> By relay address, I mean the XOR-RELAYED-ADDRESS returned in = the > >>>>>> allocation > >>>>>>> request. This clearly identifies the true source and = destination > >>>>>>> for the > >>>>>> data in > >>>>>>> the packet as well as the two relay servers involved. If both > >>>>>>> relayed > >>>>>> addresses > >>>>>>> are on the same server, it will of course know that and be = able > >>>>>>> to > >>>>>> optimize as > >>>>>>> Simon indicated in an earlier e-mail. > >>>>>>> > >>>>>>> --Brandon > >>>>>>> > >>>>>>> On 01/08/2015 09:40 PM, Aijun Wang wrote: > >>>>>>>> > >>>>>>>> [Aijun]: There are two relay address, one is the TURN server > >>>>>>>> well-known address, another is the relay address that = allocated > >>>>>>>> to each client. Which one should be used then? On the other > >>>>>>>> hand, when client want to send traffic to other peer, it does > >>>>>>>> not know whether the other part is under the same TURN server > >>>>>>>> or not, how do it select > >>>>>> this > >>>>>>> information? > >>>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> [Aijun]: as the definition in > >>>>>>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-1 > >>>>>>>> 4.3 , the XOR-PEER-ADDRESS is the address seen from the TURN > >>>>>>>> server, so it can't be used to find the relay address of the > >>>>>>>> remote peer, and then can't be used to direct traffic to > >>>>>>>> downstream relay. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Brandon Williams; Senior Principal Software Engineer Emerging > >>>>>>> Products Engineering; Akamai Technologies Inc. > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Brandon Williams; Senior Principal Software Engineer Emerging > >>>>> Products Engineering; Akamai Technologies Inc. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> tram mailing list > >>>> tram@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tram > >>> > >>> _______________________________________________ > >>> tram mailing list > >>> tram@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tram > >> > >> > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. From nobody Tue Jan 13 18:08:42 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBBC1ACE0F for ; Tue, 13 Jan 2015 18:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.391 X-Spam-Level: * X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 MvF0evrm4v5a for ; Tue, 13 Jan 2015 18:08:20 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5E1ACE2F for ; Tue, 13 Jan 2015 18:08:16 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06A79AMYurVU77TaAA==.10248S4; Wed, 14 Jan 2015 08:36:43 +0800 (CST) From: "Aijun Wang" To: "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> <002a01d02ece$4c063400$e4129c00$@org.cn> In-Reply-To: Date: Wed, 14 Jan 2015 10:08:07 +0800 Message-ID: <002e01d02f9e$f0669fa0$d133dee0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01D02FE1.FE89DFA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAvS0pWuKuob7IjTrqp+69rVGAeAwAUe3oA Content-Language: zh-cn X-CM-TRANSID: Z0GX06A79AMYurVU77TaAA==.10248S4 X-Coremail-Antispam: 1U3129KBjvJXoW3uFy3Wr4xGw1DCw18Cw1xKrg_yoWkAr1rpF W3urySy3WkJF1xAw15Zw40gF1fu395Wr9rJrn8Kr17Z393Ar1IvrnxK345CFW7Gr95GFyY vrWjv3WUZ3WrAFJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU U8F7k0a2IF6r1UMc02F40Eb7x2x7xS6r4j6ryUMc02F40E57IF67AEF4xIwI1l5I8CrVAK z4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xM7kC6x804xWl14x267AKxVW8JVW5Jw AFxVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE 17CEb7AF67AKxVWUXVWUAwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4U0xZFpf9x0JURE__UUUUU= Archived-At: Cc: tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 02:08:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002F_01D02FE1.FE89DFA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Justin: =20 As you described, the role of enterprise TURN is just let the inner user = to communicate with the outsider remote party when there is firewall at = the border of the enterprise network? You have said that when two users = are within the corporate, they will not the use the corporate TURN = server. =20 It is one common request that the inner user want to communicate with = the outside world, not limited on WebRTC application, so why not use = some tunnel protocol directly, such as L2TP, which rely on UDP datagram = and can eliminate the latency introduced by other tunnel protocol that = based on TCP? =20 RETURN maybe one available option, but I think the =E2=80=9CL2TP(or = other tunnel protocol)+TURN=E2=80=9D is a better solution. On the other = hand, RETURN is just another kind UDP tunnel technology? =20 Best Regards. Aijun Wang. =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, January 14, 2015 1:38 AM To: Aijun Wang Cc: tram@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Mon, Jan 12, 2015 at 5:14 PM, Aijun Wang = wrote: Hi, Justin: =20 Please refer to the reply below. =20 =20 From: Justin Uberti [mailto:juberti@google.com]=20 Sent: Tuesday, January 13, 2015 4:23 AM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang = wrote: Hi,=20 =20 Do you refer to the draft = http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN = draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does = not describe the situation that the communication peers select the = different public TURN server, and need the TURN server to relay the app = data(TURN to TURN). =20 That is just normal UDP.=20 =20 [Aijun]: For TURN to TURN situation, I am discussing it with the = Brandon, please refer to that thread. We should consider carefully for = the transport mechanism between A/TURN Server A; TURN Server A/TURN = Server B and TURN Server B/B when peer A want to talk to B via the two = TURN Server A/B.=20 =20 In situation that mentioned in RETURN draft, Why not to let ICE or App = Server to select the appropriate TURN server(corporate private TURN = server or public TURN server) based on the information of the two = communication parts? This can even eliminate the solution of RETURN: = two peer will use the corporate TURN server when they are both within = corporate, and will use the public TURN server when one of them is = located outside the corporation? =20 a) The TURN server isn't needed when both endpoints are within the = enterprise. The TURN server sits on the enterprise border, and is used = for inter-enterprise traffic. b) The public TURN server may not be reachable from the enterprise. This = is why the corporate TURN server is needed on the border. c) The app may require use of its own TURN server for location privacy = purposes, so both TURN servers may be used in this case. =20 This is all spelled out in = https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-1. =20 [Aijun] Would you like to explain more detail about =E2=80=9Cbut using = only the enterprise's TURN server reveals information about the user = (e.g. organizational affiliation)=E2=80=9D, and how do you achieve this = goal via the RETURN mechanism? =20 If only the enterprise TURN server is used, and this server is = on-premises, then the remote party can determine the location of the = caller via IP geolocation of the relay candidates (as well as = organization affiliation, by seeing who owns that IP). This is similar = to the case where the remote party determines the location of a = non-enterprise caller via their host/srflx candidates, although in this = case applications can protect against this by forcing all traffic = through an application-provided relay server, which provides some amount = of location ambiguity.=20 =20 RETURN attempts to provide this same functionality for the enterprise = TURN server case, and to do so it defines how traffic can transit both = the enterprise TURN server as well as the application TURN server. =20 e.g. =20 [client] -------- [ETURN] ------------ [ATURN] -------------- [remote = party] =20 Best Regards. =20 =20 From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Sent: Monday, January 12, 2015 1:35 PM To: Aijun Wang; 'Justin Uberti' Cc: tram@ietf.org Subject: RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 As Justin has pointed out we will be updating the draft with more = details on the decisions that could be made by ICE and the application = to select the TURN server. TURN-in-TURN communication is already = explained in RETURN draft. =20 -Tiru =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Monday, January 12, 2015 7:08 AM To: Tirumaleswar Reddy (tireddy); 'Justin Uberti' Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Hi, Reddy and Justin: =20 I suggest the TURN server selection should be made by ICE, not the = client itself. This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision. =20 There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc. =20 Best Regards. =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, January 11, 2015 1:40 PM To: Justin Uberti Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 Inline [TR] =20 From: Justin Uberti [ = mailto:juberti@google.com]=20 Sent: Sunday, January 11, 2015 2:17 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 =20 =20 On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) = wrote: Hi Justin, =20 Enterprise-provided TURN server cannot provide location privacy may not = be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.=20 =20 We will have to discuss if TURN server can advertise that it can provide = location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC).=20 =20 The other problem not discussed in the draft is, what if the user wants = privacy against the calling site and let=E2=80=99s say uses Tor for = privacy. In this scenario app TURN server must not be selected. =20 RETURN handles this situation fine, since the traffic will be routed = through the network-provided TURN server before being routed to the app = TURN server. Of course, if the application does not try to provide = location privacy, only the network-provided TURN server will be used. =20 [TR] But the problem is how will the endpoint how if network-provided = TURN server can provide location privacy or not ? TURN server can convey this information in a new STUN attribute = to the client. =20 However, I think the user is much more likely to trust the application = than its network provider to provide privacy protection. =20 [TR] User may or may not trust the application server. = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses = users using privacy techniques like Tor so that app server does not = learn the user's IP address. The Poker example given in the above draft = explains that the users in the call do not trust the calling service. In = this case IdP ensures that even if malicious calling service replaces = the media addresses with its own addresses and replaces the certificate = fingerprint in SDP with its own certificate, IdP assertion would ensure = that the Poker site cannot act as man-in-middle device. In this = scenario user may not want to pick app provided TURN server. =20 -Tiru =20 =20 =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Friday, January 09, 2015 4:04 AM To: tram@ietf.org Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00 =20 At IETF 91, I promised to send feedback on this document, so here goes. =20 Generally, I think many of the issues mentioned in this document are = important, but the recommendations are confusing and possibly = contradictory; a developer with little knowledge of TURN will have a = hard time figuring out exactly what to do. Furthermore, many of the = properties discussed in this document are dynamic, and should be handled = by the ICE process, rather than in TURN server selection (for example, = the notion of RTT as it relates to user experience). =20 Therefore, I think this document should take a stronger stance and put = forth explicit best practices for selection (as opposed to "things to = consider"), for non-dynamic properties, and leave the decisions on = dynamic properties to be resolved by ICE.=20 =20 For example, I think we should omit the text in Section 3 about what to = do with non-working TURN servers, and measuring RTT. Same for Section = 3.3, which also discusses RTT, and Section 3.4, which talks about = multiple interfaces. This can all be handled by ICE. =20 In addition, the sections on local config and location privacy are = unnecessary when RETURN is used. When RETURN is used, the application = can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide on. =20 This leaves only the Security, Authentication, and Mobility sections.=20 =20 For security, I think we can give some clear guidance on what = applications should do. For security, I think the guidance should be to = use only DTLS + TLS, if both are available, with fallback to UDP or TCP = if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend this. =20 This relates to the Authentication section - but I think any failures to = authenticate the server cert should cause the TURN allocation to fail. = This is just like any other misconfiguration on the TURN server - = there's no reason we should even allow use of TURN servers whose cert = chains don't validate. So, this section could probably be removed. =20 Lastly, the Mobility section says that if "all other parameters [are] = equal", a TURN server with mobility should be used. Clearly, all other = parameters will not be equal (e.g. RTT), and even if they were, the = client has no way to know if a server is mobility-capable a priori. So I = think this recommendation ought to be removed, or perhaps turned into = some sort of recommendation for TURN server developers (e.g. TURN = servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support = redirect), probably in a separate doc. =20 These recommendations should reduce the size of this document and = provide much clearer advice to app developers. =20 =20 =20 ------=_NextPart_000_002F_01D02FE1.FE89DFA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Justin:

 

As you described, the role of enterprise TURN is just let the inner = user to communicate with the outsider remote party when there is = firewall at the border of the enterprise network? You have said that = when two users are within the corporate, they will not the use the = corporate TURN server.

 

It is one common request that the inner user want to communicate with = the outside world, not limited on WebRTC application, so why not use = some tunnel protocol directly, such as L2TP, which rely on UDP datagram = and can eliminate the latency introduced by other tunnel protocol that = based on TCP?

 

RETURN maybe one available option, but I think the =E2=80=9CL2TP(or = other tunnel protocol)+TURN=E2=80=9D is a better solution. On the other = hand, RETURN is just another kind UDP tunnel = technology?

 

Best Regards.

Aijun Wang.

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, January 14, 2015 1:38 AM
To: = Aijun Wang
Cc: tram@ietf.org; Tirumaleswar Reddy = (tireddy)
Subject: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

=

 

 

 

On Mon, Jan 12, 2015 at 5:14 PM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi, Justin:

 

Please refer to the reply below.

 

 

From:= Justin = Uberti [mailto:juberti@google.com]
Sent: Tuesday, = January 13, 2015 4:23 AM
To: Aijun Wang
Cc: = Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] = Comments on draft-patil-tram-turn-serv-selection-00

 

 

 

On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi,

 

Do you refer to the draft http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.= txt as RETURN draft? This draft describes only TURN-in-TURN, not = TURN-to-TURN. It does not describe the situation that the communication = peers select the different public TURN server, and need the TURN server = to relay the app data(TURN to TURN).

 

That is just normal UDP. 

 

[Aijun]: For TURN to TURN situation, I am discussing it with the = Brandon, please refer to that thread.  We should consider carefully = for the transport mechanism between A/TURN Server A; TURN Server A/TURN = Server B and TURN Server B/B when peer A want to talk to B via the two = TURN Server A/B. 

 

In situation that mentioned in RETURN draft, Why not to let ICE or = App Server to select the appropriate TURN server(corporate private TURN = server or public TURN server) based on the information of the two = communication parts? This can even eliminate the solution of  = RETURN:  two peer will use the corporate TURN server when they are = both within corporate, and will use the public TURN server when one of = them is located outside the corporation?

 

a) The TURN server isn't needed when both endpoints are = within the enterprise. The TURN server sits on the enterprise border, = and is used for inter-enterprise = traffic.

b) The public TURN server may not be reachable from the = enterprise. This is why the corporate TURN server is needed on the = border.

c) The app may require use of its own TURN server for = location privacy purposes, so both TURN servers may be used in this = case.

 

This is all spelled out in https://tools.ietf.org/html/draft-schwartz-rtcweb-retur= n-04#section-1.

 

[Aijun] Would you like to explain more detail about =
=E2=80=9Cbut using =
only the enterprise's TURN server reveals information about the user =
(e.g. organizational affiliation)=E2=80=9D,  and how do you achieve this goal via the RETURN =
mechanism?
=

 

If only the enterprise TURN server = is used, and this server is on-premises, then the remote party can = determine the location of the caller via IP geolocation of the relay = candidates (as well as organization affiliation, by seeing who owns that = IP). This is similar to the case where the remote party determines the = location of a non-enterprise caller via their host/srflx candidates, = although in this case applications can protect against this by forcing = all traffic through an application-provided relay server, which provides = some amount of location = ambiguity. 

 

RETURN attempts to provide this = same functionality for the enterprise TURN server case, and to do so it = defines how traffic can transit both the enterprise TURN server as well = as the application TURN server.

 

e.g.

 

[client] -------- [ETURN] = ------------ [ATURN] -------------- [remote = party]

 

Best Regards.

 

 

From:= = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Monday, = January 12, 2015 1:35 PM
To: Aijun Wang; 'Justin = Uberti'
Cc: tram@ietf.org
Subject: RE: [tram] = Comments on draft-patil-tram-turn-serv-selection-00

 

As Justin has pointed out we will be updating the draft with more = details on the decisions that could be made by ICE and the application = to select the TURN server. TURN-in-TURN communication is already = explained in RETURN draft.

 

-Tiru

 

From:= tram [mailto:tram-bounces@ietf.org] On Behalf Of = Aijun Wang
Sent: Monday, January 12, 2015 7:08 = AM
To: Tirumaleswar Reddy (tireddy); 'Justin = Uberti'
Cc: tram@ietf.org
Subject: Re: [tram] = Comments on draft-patil-tram-turn-serv-selection-00

 

Hi, Reddy and Justin:

 

I suggest the TURN server selection should be made by ICE, not the = client itself.  This can eliminate the needs for the communication = between different TURN server that selected by communication peer. ICE = has more information about the communication situation, and is suitable = to make this decision.

 

There are several issues needed to be solved when the communication = peers select the different TURN server, for example, how to find the = second TURN server, what is the communication mechanism between = different TURN servers, the channel connection among different data = segments: client/first TURN server, first TURN server/second TURN = server, and second TURN server/peer etc.

 

Best Regards.

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, = January 11, 2015 1:40 PM
To: Justin Uberti
Cc: = tram@ietf.or= g
Subje= ct: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

Inline [TR]

 

From:= Justin = Uberti [mailto:juber= ti@google.com] =
Sent: Sunday, January 11, 2015 2:17 AM
To: = Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.or= g
Subje= ct: Re: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

 

 

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy = (tireddy) <tireddy@cisco.com> = wrote:

Hi Justin,

 

Enterprise-provided TURN server cannot provide location privacy may = not be always true. For example Enterprise network could use TURN server = provided by a cloud service and the user needs to know that the = Enterprise TURN server can provide location privacy and not proceed with = TURN-in-TURN.

 

We will have to discuss if TURN server can advertise that it can = provide location privacy in a new attribute or this info can be conveyed = out-of-band (e.g. PAC). 

 

The other problem not discussed in the draft is, what if the user = wants privacy against the calling site and let=E2=80=99s say uses Tor = for privacy. In this scenario app TURN server must not be = selected.

 

RETURN handles this situation fine, since the traffic will = be routed through the network-provided TURN server before being routed = to the app TURN server. Of course, if the application does not try to = provide location privacy, only the network-provided TURN server will be = used.

 

[TR] But the problem is how will the endpoint how if = network-provided TURN server can provide location privacy or not = ?

         TURN = server can convey this information in a new STUN attribute to the = client.

 

However, I think the user is much more likely to trust the = application than its network provider to provide privacy = protection.

 

[TR] User may or may not trust the application server. https://tools.ietf.org/html/draft-ietf-rtcweb-security-= arch-10 discusses users using privacy techniques like Tor so that = app server does not learn the user's IP address. The Poker example given = in the above draft explains that the users in the call do not trust the = calling service. In this case IdP ensures that even if malicious calling = service replaces the media addresses with its own addresses  and = replaces the certificate fingerprint in SDP with its own certificate, = IdP assertion would ensure that the Poker site cannot act as =  man-in-middle device. In this scenario user may not want to pick = app provided TURN server.

 

-Tiru

 

 

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 = 4:04 AM
To: tram@ietf.or= g
Subje= ct: [tram] Comments on = draft-patil-tram-turn-serv-selection-00

 

At IETF 91, I promised to send feedback on this document, = so here goes.

 

Generally, I think many of the issues mentioned in this = document are important, but the recommendations are confusing and = possibly contradictory; a developer with little knowledge of TURN will = have a hard time figuring out exactly what to do. Furthermore, many of = the properties discussed in this document are dynamic, and should be = handled by the ICE process, rather than in TURN server selection (for = example, the notion of RTT as it relates to user = experience).

 

Therefore, I think this document should take a stronger = stance and put forth explicit best practices for selection (as opposed = to "things to consider"), for non-dynamic properties, and = leave the decisions on dynamic properties to be resolved by = ICE. 

 

For example, I think we should omit the text in Section 3 = about what to do with non-working TURN servers, and measuring RTT. Same = for Section 3.3, which also discusses RTT, and Section 3.4, which talks = about multiple interfaces. This can all be handled by = ICE.

 

In addition, the sections on local config and location = privacy are unnecessary when RETURN is used. When RETURN is used, the = application can always use the app TURN server for location privacy, and = the relationship between local TURN server and app TURN server is fully = spelled out, so there is nothing for the application to decide = on.

 

This leaves only the Security, Authentication, and Mobility = sections. 

 

For security, I think we can give some clear guidance on = what applications should do. For security, I think the guidance should = be to use only DTLS + TLS, if both are available, with fallback to UDP = or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP = fallback may be contraindicated, but at this point in time, DTLS = deployment isn't widespread enough to truly recommend = this.

 

This relates to the Authentication section - but I think = any failures to authenticate the server cert should cause the TURN = allocation to fail. This is just like any other misconfiguration on the = TURN server - there's no reason we should even allow use of TURN servers = whose cert chains don't validate. So, this section could probably be = removed.

 

Lastly, the Mobility section says that if "all other = parameters [are] equal", a TURN server with mobility should be = used. Clearly, all other parameters will not be equal (e.g. RTT), and = even if they were, the client has no way to know if a server is = mobility-capable a priori. So I think this recommendation ought to be = removed, or perhaps turned into some sort of recommendation for TURN = server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD = support mobility, SHOULD support redirect), probably in a separate = doc.

 

These recommendations should reduce the size of this = document and provide much clearer advice to app = developers.

 

 

 

<= /html> ------=_NextPart_000_002F_01D02FE1.FE89DFA0-- From nobody Wed Jan 14 00:01:05 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2C01A8BB1 for ; Wed, 14 Jan 2015 00:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ei3sycb47RMm for ; Wed, 14 Jan 2015 00:01:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19011ACE42 for ; Wed, 14 Jan 2015 00:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17234; q=dns/txt; s=iport; t=1421222461; x=1422432061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EOPoeCN8AUa970JaqQJGiINuLTtuJ0Zadu6gchxilqM=; b=UFeMr85Yr8DAxFMB9o411ImQZnitV3b2/FfZExFtCxm6APuM2Vp7qaXC DrkAJt74bh3ollm+xHX3aGDjKVL42iClUfvcRu7pGeZAoa/xjihwFELBt ZX1Jc9jWZhwntNmdw+P9O6sq+Xs38EbW794jc7tDFpmZCdUSmvTM4kj91 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQIAN8gtlStJV2a/2dsb2JhbABRCoMGUlgEgwHDGAqFcQIcd0MBAQEBAX2EDAEBAQMBAQEBIAQNOgkCBQcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQKBAUbiAkIDbtdlBABAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGNfCkYGwcGgmIugRMFhTaJDINFhUiBDzCNAIM9IoNubwGBAgc7fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,754,1413244800"; d="scan'208";a="387195210" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jan 2015 08:01:00 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0E810VO012299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 08:01:00 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 02:01:00 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] New Version Notification for draft-williams-peer-redirect-02.txt Thread-Index: AQHQLwxct8FzPZ1uJUeScTzmsc+WHAAGZgpAAAIDd3Ccv2OoAA== Date: Wed, 14 Jan 2015 08:00:59 +0000 Message-ID: <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> <002a01d02f9d$29de2660$7d9a7320$@org.cn> In-Reply-To: <002a01d02f9d$29de2660$7d9a7320$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.219] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:01:05 -0000 DQo+IE9uIDE0IEphbiAyMDE1LCBhdCAwMjo1NSwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4gd3JvdGU6DQo+IA0KPiBIaSwgQnJhbmRvbiAmIHBhbDoNCj4gDQo+IExldCdz IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZ3JhcGg6DQo+IA0KPiBBIDwtPiBYQSA8LT4gVEF8UkEg PC0+IFJCfFRCIDwtPiBYQiA8LT4gQg0KPiB8ICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAg ICB8DQo+IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCj4gfCAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgfA0KPiB8ICAgICAgICAgICArLS0tLS0tLS0tLVhDPC0tLT5D ICAgICAgIHwNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiB8LS0tLSBU VVJOIC0tLS0tfC0tLSBVRFAgLS18LS0tLSBUVVJOIC0tLS0tLS0tfA0KPiANCj4gSWYgdGhlcmUg aXMgYW5vdGhlciBwZWVyKHBlZXIgQykgY29ubmVjdGVkIGRpcmVjdGx5IHRvIFRVUk4gU2VydmVy IEEgYXQgdGhlIHNhbWUgdGltZSwgdGhlbiBUVVJOIFNlcnZlciBBIHdpbGwgdXNlIGFsc28gdGhl IHB1cmUgVURQIHBhY2tldCB0byByZWxheSBkYXRhIGZyb20gQSB0byBDLg0KQ2xvc2UuIFRoZSBw YWNrZXQgd2lsbCBiZSBUVVJOIGVuY2Fwc3VsYXRlZCBmcm9tIEEgdG8gVEEsIGFuZCB0aGVuIGZy b20gVEEgdG8gQyBwdXJlIFVEUC4gDQoNCj4gVGhlbiwgaG93IHRoaXMgcGFja2V0IHBhc3MgdGhy b3VnaCB0aGUgRURNIE5BVCBkZXZpY2UgdGhhdCBsb2NhdGVzIGJlZm9yZSBwZWVyIEM/ICBQZWVy IEMgb25seSBzZW5kIHJlcXVlc3QgcGFja2V0IHRvIFRVUk4gU2VydmVyIEHigJlzDQo+IFRBIGFk ZHJlc3MgcHJldmlvdXNseS4NCj4gDQpUaGF0IGlzIGEgcHJvYmxlbSBjbGllbnQgQyBuZWVkcyB0 byBoYW5kbGUuIFByb2JhYmx5IGJ5IHVzaW5nIGl0cyBvd24gVFVSTiBzZXJ2ZXIuIElDRSB3aWxs IGFsc28gaGVscCBpbiB0aGlzIGNhc2UgYW5kIG1pZ2h0IHJlbmRlciBhbnkgb2YgdGhlIFRVUk4g c2VydmVycyByZWR1bmRhbnQuDQoNCj4gQWN0dWFsbHksIEkgY29uc2lkZXIgY3VycmVudCBUVVJO IGRyYWZ0IG9ubHkgY29uc2lkZXIgdGhlIHNjZW5hcmlvcyB0aGF0IHRoZXJlIGV4aXN0IG9ubHkg b25lIFRVUk4gU2VydmVyLCBhbmQgd2lsbCBsZWFkIG1vcmUgY29tcGxleCBkZXNpZ24gaWYgaXQg d2FudCB0byBzb2x2ZSB0aGUgVFVSTi10by1UVVJOIGF0IHRoZSBzYW1lIHRpbWUuDQo+IA0KDQpJ IGRpc2FncmVlLiBUaGUgY3VycmVudCBzdWl0ZSBvZiBJQ0UvVFVSTi9TVFVOIFJGQ3MgZG8gc3Vw cG9ydCB0aGlzIG5pY2VseS4gSSBkbyBub3QgdGhpbmsgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRo ZSBsaXN0IGlzIGFwcHJvcHJpYXRlLCBidXQgd2lsbCBiZSBoYXBweSB0byBoYXZlIGEgY2hhdCBk dXJpbmcgdGhlIG5leHQgSUVURiBtZWV0aW5nIGV4cGxhaW5pbmcgdGhpbmdzLiANCg0KLi0uDQpQ w6VsLUVyaWsNCg0KDQo+IEJlc3QgUmVnYXJkcy4NCj4gQWlqdW4gV2FuZw0KPiANCj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFttYWlsdG86 YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDE0LCAyMDE1IDc6MDkgQU0NCj4+IFRvOiBBaWp1biBXYW5nDQo+PiBDYzogdHJhbUBpZXRmLm9y Zw0KPj4gU3ViamVjdDogUmU6IFt0cmFtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ PiBkcmFmdC13aWxsaWFtcy1wZWVyLXJlZGlyZWN0LTAyLnR4dA0KPj4gDQo+PiBJIGFncmVlIHdp dGggUMOlbC1FcmlrIHRoYXQgd2UncmUgZGlzY3Vzc2luZyBleGlzdGluZyBUVVJOIGZ1bmN0aW9u YWxpdHkgaGVyZS4NCj4+IFRoZXJlIGlzIG5vIG91dHN0YW5kaW5nIHByb2JsZW0gd2l0aCBhIHVz ZS1jYXNlIGludm9sdmluZyB0d28gVFVSTiByZWxheQ0KPj4gc2VydmVycywgb25lIGZvciBlYWNo IHBlZXIuIFRoZSBleGlzdGluZyBwcm90b2NvbCBzdXBwb3J0cyB0aGlzIGp1c3QgZmluZS4NCj4+ IA0KPj4gTWF5YmUgdGhlIGxlbmd0aHkgYmFjay1hbmQtZm9ydGggZGlzY3Vzc2lvbiBzdWdnZXN0 cyB0aGF0IHRoZXJlIGNvdWxkIGJlDQo+PiBzb21lIHZhbHVlIGluIGRvY3VtZW50aW5nIHRoaXMg cGFydGljdWxhciB1c2UgY2FzZSBzb21ld2hlcmUgKHR1cm5iaXM/IGENCj4+IHNlcGFyYXRlIGRy YWZ0PykgdG8gaGVscCBjbGFyaWZ5IGl0IGZvciBmdXR1cmUgaW1wbGVtZW50ZXJzLg0KPj4gDQo+ PiAtLUJyYW5kb24NCj4+IA0KPj4gT24gMDEvMTMvMjAxNSAwMTo1NCBQTSwgUGFsIE1hcnRpbnNl biAocGFsbWFydGkpIHdyb3RlOg0KPj4+IA0KPj4+PiBPbiAxMyBKYW4gMjAxNSwgYXQgMTA6Mjgs IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24NCj4+Pj4gPG1haWx0bzp3YW5n YWlqdW5AdHNpbmdodWEub3JnLmNuPj4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBQYWwgTWFydGluc2VuDQo+Pj4+PiAocGFsbWFydGkpDQo+Pj4+ PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDEzLCAyMDE1IDQ6MzkgUE0NCj4+Pj4+IFRvOiBBaWp1 biBXYW5nDQo+Pj4+PiBDYzp0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz47IEJy YW5kb24gV2lsbGlhbXMNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbdHJhbV0gTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPj4+Pj4gZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRpcmVjdC0wMi50eHQN Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gT24gMTMgSmFuIDIwMTUsIGF0IDAxOjUwLCBBaWp1biBX YW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuDQo+Pj4+Pj4gPG1haWx0bzp3YW5nYWlqdW5A dHNpbmdodWEub3JnLmNuPj4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4gSGksIEJyYW5kb24NCj4+ Pj4+PiANCj4+Pj4+PiBUaGFua3MgZm9yIHlvdXIgdml2aWQgZ3JhcGggZm9yIG91ciBkaXNjdXNz aW9uLiBUd28gcXVlc3Rpb25zIGFyZQ0KPj4+Pj4+IHJhaXNlZA0KPj4+Pj4+IGhlcmU6DQo+Pj4+ Pj4gDQo+Pj4+Pj4gMS4gSG93IGRvZXMgVFVSTiBzZXJ2ZXIgQSBkZWNpZGUgd2hlbiB0byB1c2Ug VURQIHRvIHNlbmQgYXBwIGRhdGEsDQo+Pj4+Pj4gYW5kIHdoZW4gdG8gdXNlIFRVUk4gdG8gc2Vu ZCBhcHAgZGF0YT8gV2hpY2ggY3JpdGVyaWEgY2FuIGFzc2lzdGFudA0KPj4+Pj4+IHRoZSBUVVJO IHNlcnZlciBBIHRvIG1ha2UgdGhpcyBkZWNpc2lvbj8NCj4+Pj4+PiBJbg0KPj4+Pj4+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24t MTAuMiwNCj4+Pj4+PiBpdCBkZXNjcmliZXMgdGhlIFRVUk4gc2VydmVyIHdpbGwgc2VuZCBVRFAg cmF3IHBhY2tldCB0byB0aGUgcGVlciwNCj4+Pj4+PiByZWdhcmRsZXNzIHRoZSBwZWVyIGlzIGF3 YXJlbmVzcyBvciB1bmF3YXJlbmVzcyB0aGUgZXhpc3RlbmNlIG9mIFRVUk4uDQo+Pj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IFRVUk4gc2V2ZXIgQSBzZW5kcyDigJxhcHAgZGF0YeKAnSB0byBjbGllbnQg QS4gVGhpcyBpcyB0aGUg4oCccHJpdmF0ZeKAnQ0KPj4+Pj4gc2lkZSBvZiB0aGUgVFVSTiBzZXJ2 ZXIuIFRVUk4gc2VydmVyIEEgc2VuZHMgVFVSTiBlbmNhcHN1bGF0ZWQgZGF0YQ0KPj4+Pj4gKGRh dGEgaW5kIG9yDQo+Pj4+PiBjaGFubmVsKSBiYWNrIHRvIGNsaWVudCBBIHVzaW5nIHRoZSBzYW1l IDUgdHVwbGUgY2xpZW50IEEgdXNlZCB0bw0KPj4+Pj4gc2VuZCBoaXMgYWxsb2NhdGUgcmVxdWVz dC4gVFVSTiBhbGxvd3MgdGhlIGNsaWVudCB0byB1c2UgVURQLCBUQ1Agb3INCj4+Pj4+IFRMUyB0 byBkbyB0aGlzLg0KPj4+Pj4gDQo+Pj4+PiBXaGF0IGhhcHBlbnMgb24gdGhlIOKAnHB1YmxpY+KA nSBzaWRlIG9mIHRoZSBUVVJOIHNlcnZlciBpcyBhbHdheXMgVURQDQo+Pj4+PiAoVW5sZXNzIHRo ZSBUVVJOIHNlcnZlciBzdXBwb3J0cyBUVVJOLVRDUCBhbmQgdGhlIGNsaWVudCBoYXZlIGFza2Vk DQo+Pj4+PiBmb3IgYSBUQ1AgcG9ydCBhbGxvY2F0aW9uKS4NCj4+Pj4+IA0KPj4+Pj4gVGhlIHJl bW90ZSBzaWRlIGRvIG5vdCBuZWVkIHRvIGtub3cgdGhhdCBpdCBpcyBzZW5kaW5nIHBhY2tldHMg dG8gYQ0KPj4+Pj4gVFVSTiBzZXJ2ZXIsIGFuZCB0aGF0IHRoZSBwYWNrZXRzIHdvdWxkIOKAnG1h Z2ljYWxseeKAnSBiZSBzZW50IHRvIHRoZQ0KPj4+Pj4gY2xpZW50IHRoYXQgYWxsb2NhdGVkIHRo YXQgcG9ydC4gVGhpbmsgb2YgVFVSTiBhcyBhIG1lY2hhbmlzbSB0bw0KPj4+Pj4gbW92ZSB5b3Vy IGJveCBvdXQgb24gdGhlIEludGVybmV0IGFuZCBvYnRhaW5pbmcgcHVibGljIHJvdXRhYmxlIElQ Lg0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBJIGFncmVlIHdpdGggeW91IGF0IHRoZXNlIHBvaW50cy4g QnV0IG15IGNvbmNlcm4gZm9jdXMgb24gdGhlDQo+Pj4+IGNvbW11bmljYXRpb24gY2hhbm5lbCBi ZXR3ZWVuIFRVUk4gU2VydmVyIEEvVFVSTiBTZXJ2ZXIgQiBhbmQgVFVSTg0KPj4+PiBCL1BlZXIg Qi4gSW4gY3VycmVudCBUVVJOIGRyYWZ0LCB0aGV5IGFsbCB1c2UgdGhlIHB1cmUgVURQIHBhY2tl dC4NCj4+Pj4gQnV0IGluIEJyYW5kb27igJlzIGdyYXBoLCB0aGV5IGFyZSBkaWZmZXJlbnQ6IHRo ZSBwcmV2aW91cyBwYWlyIHVzZQ0KPj4+PiBwdXJlIFVEUCBkYXRhZ3JhbSwgYnV0IHRoZSBsYXR0 ZXIgcGFpciB1c2UgREFUQSBpbmRpY2F0aW9uLCB3aGljaCBpcw0KPj4+PiBub3QgZGVzY3JpYmVk IGluIGN1cnJlbnQgVFVSTiBkcmFmdCwNCj4+PiANCj4+PiBVbmxlc3MgSSBhbSBtaXNzaW5nIHNv bWV0aGluZyB0aGlzIGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEwLjMuDQo+Pj4gDQo+Pj4gDQo+ Pj4+IGFuZCB3aWxsIGxlYWQgdGhlIFRVUk4gc2VydmVyIEEgYmUgY29uZnVzZWQsIGJlY2F1c2Ug aXQgbWlnaHQgZmFjZQ0KPj4+PiB0aGUgVFVSTiBTZXJ2ZXIgQiBhbmQgb3RoZXIgY29tbXVuaWNh dGlvbiBwZWVyLCBzdWNoIGFzIHBlZXIgQyB0aGF0DQo+Pj4+IGRpcmVjdGx5IGNvbm5lY3RlZCBv biB0aGUgVFVSTiBzZXJ2ZXIgQS4gIFdoaWNoIGVuY2Fwc3VsYXRpb24gbWV0aG9kDQo+Pj4+IHdp bGwgYmUgdXNlZCB0aGVuPw0KPj4+PiANCj4+PiANCj4+PiBVRFAuIEJ1dCB0aGF0IHJlcXVpcmVz IGNsaWVudCBhIHRvIHNldCB0aGUgY29ycmVjdCBwZXJtaXNzaW9ucyB0bw0KPj4+IGFsbG93IHRy YWZmaWMgZnJvbSBDIHRvIGJlIHJlbGF5ZWQgdG8gQS4NCj4+PiANCj4+PiBXZSBhcmUgZGlzY3Vz c2luZyBub3JtYWwgVFVSTiBvcGVyYXRpb24gaGVyZT8gSWYgbm90IEkgYXBvbG9naXNlIGlmIEkN Cj4+PiBoYXZlIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhlIGRpc2N1c3Npb24uDQo+Pj4gDQo+Pj4g Li0uDQo+Pj4gUMOlbC1FcmlrDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+ IA0KPj4+Pj4+IDIuIEluIHlvdXIgZXhhbXBsZSwgaWYgVFVSTiBCIHVzZSB0aGUgREFUQSBpbmRp Y2F0aW9uIHRvIEIsIHdoYXQNCj4+Pj4+PiB3aWxsIEIgZG8gaWYgaXQgZG9lcyBub3Qgc3VwcG9y dCB0aGUgVFVSTiBlbmNhcHN1bGF0aW9uPw0KPj4+Pj4+IA0KPj4+Pj4gVGhlcmUgaXMgbm8gd2F5 IGEgVFVSTiBzZXJ2ZXIgd291bGQgc2VuZCBkYXRhIGluZCB0byBhIGNsaWVudA0KPj4+Pj4gd2l0 aG91dCB0aGUgY2xpZW50IGhhdmluZyBhbGxvY2F0ZWQgYSBwb3J0Lg0KPj4+Pj4gV2l0aG91dCBj bGllbnQgQiBzZW5kaW5nIHRoZSBhbGxvY2F0ZSByZXF1ZXN0IHRoZXJlIHdvdWxkIG5vdCBiZSBh DQo+Pj4+PiBiaW5kaW5nIGluIHRoZSBOQVQgZWl0aGVyLg0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBB Y3R1YWxseSB0cnVlLiBCdXQgbXkgY29uY2VybiBoZXJlIGZvY3VzIHN0aWxsIG9uIHRoZSBkYXRh IGZvcndhcmRpbmcNCj4+Pj4gcGxhbmUsIG5vdCB0aGUgY29udHJvbCBwbGFuZSBvZiBUVVJOIHNv bHV0aW9uLg0KPj4+PiANCj4+Pj4+IC4tLg0KPj4+Pj4gUMOlbC1FcmlrDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4+IEJlc3QgUmVnYXJkcy4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogQnJhbmRvbiBXaWxsaWFtcyBbbWFp bHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbV0NCj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBK YW51YXJ5IDEyLCAyMDE1IDExOjQ1IFBNDQo+Pj4+Pj4+IFRvOiBBaWp1biBXYW5nOyB0cmFtQGll dGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFt0cmFt XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+Pj4+Pj4gZHJhZnQtd2lsbGlh bXMtcGVlci1yZWRpcmVjdC0wMi50eHQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFhPUi1QRUVSLUFERFJF U1MgY29udGFpbnMgInRoZSB0cmFuc3BvcnQgYWRkcmVzcyBvZiB0aGUgcGVlciIuIEl0DQo+Pj4+ Pj4+IGlzIG5vdCByZXF1aXJlZCB0byBiZSBhIHNwZWNpZmljIHR5cGUgb2YgYWRkcmVzcyAoaG9z dCwgcmVmbGV4aXZlLA0KPj4+Pj4+PiBvciByZWxheSkuDQo+Pj4+Pj4+IEl0IHdpbGwgYmUgYW55 IGFkZHJlc3MgdGhhdCBjYW4gYmUgdXNlZCB0byBkZWxpdmVyIGRhdGEgdG8gdGhlDQo+Pj4+Pj4+ IHJlbW90ZQ0KPj4+Pj4+IHBlZXIuIElmDQo+Pj4+Pj4+IHR3byBUVVJOIHJlbGF5cyBhcmUgdXNl ZCwgdGhlbiB0aGUgWE9SLVBFRVItQUREUkVTUyBhdHRyaWJ1dGUgaW4NCj4+Pj4+Pj4gU2VuZCBh bmQgRGF0YSBpbmRpY2F0aW9ucyB3aWxsIGNvbnRhaW4gdGhlIHJlbW90ZSBwZWVyJ3MgYWxsb2Nh dGVkDQo+Pj4+Pj4+IHJlbGF5IGFkZHJlc3MuDQo+Pj4+Pj4gVGhlcmUNCj4+Pj4+Pj4gaXMgbm8g bmVlZCB0aGUgZm9yIGVpdGhlciBvZiB0aGUgcmVsYXlzIHRvIGV2ZW4gYmUgYXdhcmUgdGhhdCB0 aGUNCj4+Pj4+PiB0cmFuc3BvcnQNCj4+Pj4+Pj4gYWRkcmVzcyBpcyBhIHJlbGF5IGFkZHJlc3Mu DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBDb25zaWRlciB0aGUgZm9sbG93aW5nOg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gQSA8LT4gWEEgPC0+IFRBfFJBIDwtPiBSQnxUQiA8LT4gWEIgPC0+IEINCj4+Pj4+Pj4g fCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4+Pj4+Pj4gfC0tLS0g VFVSTiAtLS0tfC0tIFVEUCAtLXwtLS0tIFRVUk4gLS0tLXwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEEg YW5kIEIgYXJlIHRoZSB0d28gcGVlcnMnIGhvc3QgYWRkcmVzc2VzLg0KPj4+Pj4+PiBYQSBhbmQg WEIgYXJlIHRoZSB0d28gcGVlcnMnIHJlZmxleGl2ZSBhZGRyZXNzZXMuDQo+Pj4+Pj4+IFRBIGFu ZCBUQiBhcmUgdGhlIHJlbGF5IHNlcnZlcnMnIGFkZHJlc3NlcyB1c2VkIGFzIHRoZSBUVVJODQo+ Pj4+Pj4+IHNlc3Npb24gZW5kcG9pbnRzLg0KPj4+Pj4+PiBSQSBhbmQgUkIgYXJlIHRoZSB0d28g cGVlcnMnIGFsbG9jYXRlZCByZWxheSBhZGRyZXNzZXMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIFNl bmQgaW5kaWNhdGlvbiBmcm9tIEEgdG8gVEEgdXNlcyBSQiBhcyB0aGUgWE9SLVBFRVItQUREUkVT Uy4NCj4+Pj4+Pj4gV2hlbiBBJ3MgcmVsYXkgcmVjZWl2ZXMgdGhlIFNlbmQgaW5kaWNhdGlvbiwg aXQgc2VuZHMgdGhlIGRhdGEgaW4NCj4+Pj4+Pj4gYSBwbGFpbiBVRFANCj4+Pj4+PiBkYXRhZ3Jh bQ0KPj4+Pj4+PiB3aXRoIFJBIGFzIHRoZSBzb3VyY2UgYW5kIFJCIGFzIHRoZSBkZXN0aW5hdGlv bi4gV2hlbiBCJ3MgcmVsYXkNCj4+Pj4+Pj4gcmVjZWl2ZXMNCj4+Pj4+PiB0aGUNCj4+Pj4+Pj4g VURQIGRhdGFncmFtLCBpdCBzZW5kcyBhIERhdGEgaW5kaWNhdGlvbiBmcm9tIFRCIHRvIEIgd2l0 aCBSQSBhcw0KPj4+Pj4+PiB0aGUgWE9SLVBFRVItQUREUkVTUy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IC0tQnJhbmRvbg0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gMDEvMTEvMjAxNSAwNzo0MyBQTSwgQWlq dW4gV2FuZyB3cm90ZToNCj4+Pj4+Pj4+IEhpLCBCcmFuZG9uOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBJbg0KPj4+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFt LXR1cm5iaXMtMDAjc2VjdGlvbi0xMC4NCj4+Pj4+Pj4+IDEsDQo+Pj4+Pj4+PiBpdCBpcyBkZXNj cmliZWQgYXMgYmVsb3c6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFdoZW4gZm9ybWluZyBhIFNlbmQg aW5kaWNhdGlvbiwgdGhlIGNsaWVudCBNVVNUIGluY2x1ZGUgYW4gWE9SLVBFRVItDQo+Pj4+Pj4+ PiAgQUREUkVTUyBhdHRyaWJ1dGUgYW5kIGEgREFUQSBhdHRyaWJ1dGUuICBUaGUgWE9SLVBFRVIt QUREUkVTUw0KPj4+Pj4+Pj4gIGF0dHJpYnV0ZSBjb250YWlucyB0aGUgdHJhbnNwb3J0IGFkZHJl c3Mgb2YgdGhlIHBlZXIgdG8gd2hpY2ggdGhlDQo+Pj4+Pj4+PiAgZGF0YSBpcyB0byBiZSBzZW50 LCBhbmQgdGhlIERBVEEgYXR0cmlidXRlIGNvbnRhaW5zIHRoZSBhY3R1YWwNCj4+Pj4+Pj4+ICBh cHBsaWNhdGlvbiBkYXRhIHRvIGJlIHNlbnQgdG8gdGhlIHBlZXIuDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IFNvLCB0aGVyZSBpcyBubyBYT1ItUkVMQVlFRC1BRERSRVNTIGF0dHJpYnV0ZSBpbmNsdWRl ZCB0bw0KPj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHBlZXIncyBhbGxvY2F0ZWQgcmVsYXkgYWRkcmVz cy4gT24gdGhlIG90aGVyIGhhbmQsDQo+Pj4+Pj4+PiBYT1ItUkVMQVlFRC1BRERSRVNTIGlzIG1h aW5seSByZWZlciB0byB0aGUgcmVxdWVzdGVyJ3MgYWxsb2NhdGVkDQo+Pj4+Pj4+PiByZWxheSBh ZGRyZXNzLCBub3QgdGhlIGNvcnJlc3BvbmRpbmcgcGVlci4gV2lsbCB3ZSBkZWZpbmUgYWdhaW4N Cj4+Pj4+Pj4+IG9uZSBuZXcgYXR0cmlidXRlLCBzdWNoIGFzIFhPUi1QRUVSLVJFTEFZRUQtQURE UkVTUyB0byB0cmFuc2Zlcg0KPj4+Pj4+Pj4gdGhlIG5leHQgVFVSTiBzZXJ2ZXIncw0KPj4+Pj4+ PiBpbmZvcm1hdGlvbj8NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRXZlbiBpZiBzbywgd2hhdCB3aWxs IGJlIHRoZSBzb3VyY2UgYWRkcmVzcyBmb3IgdGhlIHBhY2tldCBmcm9tDQo+Pj4+Pj4+PiB0aGUg c2Vjb25kIFRVUk4gc2VydmVyIHRvIGRlc3RpbmF0aW9uIHBlZXI/IElmIHdlIHVzZSB0aGUNCj4+ Pj4+Pj4+IFhPUi1SRUxBWUVELUFERFJFU1MsIHRoZW4gdGhlIHJldHVybiBwYWNrZXQgZnJvbSB0 aGUgcGVlciB3aWxsIGJlDQo+Pj4+Pj4+PiBwYXNzZWQgYmFjayBkaXJlY3RseSB0byB0aGUgZmly c3QgVFVSTiBzZXJ2ZXIsIHJlc3VsdHMgaW4NCj4+Pj4+Pj4+IG5vbi1zeW1tZXRyaWMgcm91dGUu IElmIHdlIHVzZSBYT1ItUEVFUi1SRUxBWUVELUFERFJFU1MsIHRoZW4NCj4+Pj4+Pj4+IHdoYXQg aXMgdGhlIHNvdXJjZSBhZGRyZXNzIGZvciB0aGUgcGFja2V0IGZyb20gdGhlIHNlY29uZCBUVVJO DQo+Pj4+Pj4+PiBzZXJ2ZXIgYmFjayB0bw0KPj4+Pj4+IHRoZQ0KPj4+Pj4+PiBmaXJzdCBUVVJO IHNlcnZlcj8NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQmVzdCBSZWdhcmRzLg0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiBGcm9tOiBCcmFu ZG9uIFdpbGxpYW1zIFttYWlsdG86Ym93aWxsQGFrYW1haS5jb21dDQo+Pj4+Pj4+Pj4gU2VudDog U2F0dXJkYXksIEphbnVhcnkgMTAsIDIwMTUgMTowOSBBTQ0KPj4+Pj4+Pj4+IFRvOiBBaWp1biBX YW5nOyB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4+Pj4+Pj4+PiBTdWJq ZWN0OiBSZTogW3RyYW1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4+Pj4+ Pj4+IGRyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3QtMDIudHh0DQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gQnkgcmVsYXkgYWRkcmVzcywgSSBtZWFuIHRoZSBYT1ItUkVMQVlFRC1BRERSRVNTIHJl dHVybmVkIGluIHRoZQ0KPj4+Pj4+Pj4gYWxsb2NhdGlvbg0KPj4+Pj4+Pj4+IHJlcXVlc3QuIFRo aXMgY2xlYXJseSBpZGVudGlmaWVzIHRoZSB0cnVlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24NCj4+ Pj4+Pj4+PiBmb3IgdGhlDQo+Pj4+Pj4+PiBkYXRhIGluDQo+Pj4+Pj4+Pj4gdGhlIHBhY2tldCBh cyB3ZWxsIGFzIHRoZSB0d28gcmVsYXkgc2VydmVycyBpbnZvbHZlZC4gSWYgYm90aA0KPj4+Pj4+ Pj4+IHJlbGF5ZWQNCj4+Pj4+Pj4+IGFkZHJlc3Nlcw0KPj4+Pj4+Pj4+IGFyZSBvbiB0aGUgc2Ft ZSBzZXJ2ZXIsIGl0IHdpbGwgb2YgY291cnNlIGtub3cgdGhhdCBhbmQgYmUgYWJsZQ0KPj4+Pj4+ Pj4+IHRvDQo+Pj4+Pj4+PiBvcHRpbWl6ZSBhcw0KPj4+Pj4+Pj4+IFNpbW9uIGluZGljYXRlZCBp biBhbiBlYXJsaWVyIGUtbWFpbC4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAtLUJyYW5kb24NCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBPbiAwMS8wOC8yMDE1IDA5OjQwIFBNLCBBaWp1biBXYW5nIHdy b3RlOg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gW0FpanVuXTogVGhlcmUgYXJlIHR3byByZWxh eSBhZGRyZXNzLCBvbmUgaXMgdGhlIFRVUk4gc2VydmVyDQo+Pj4+Pj4+Pj4+IHdlbGwta25vd24g YWRkcmVzcywgYW5vdGhlciBpcyB0aGUgcmVsYXkgYWRkcmVzcyB0aGF0IGFsbG9jYXRlZA0KPj4+ Pj4+Pj4+PiB0byBlYWNoIGNsaWVudC4gV2hpY2ggb25lIHNob3VsZCBiZSB1c2VkIHRoZW4/IE9u IHRoZSBvdGhlcg0KPj4+Pj4+Pj4+PiBoYW5kLCB3aGVuIGNsaWVudCB3YW50IHRvIHNlbmQgdHJh ZmZpYyB0byBvdGhlciBwZWVyLCBpdCBkb2VzDQo+Pj4+Pj4+Pj4+IG5vdCBrbm93IHdoZXRoZXIg dGhlIG90aGVyIHBhcnQgaXMgdW5kZXIgdGhlIHNhbWUgVFVSTiBzZXJ2ZXINCj4+Pj4+Pj4+Pj4g b3Igbm90LCBob3cgZG8gaXQgc2VsZWN0DQo+Pj4+Pj4+PiB0aGlzDQo+Pj4+Pj4+Pj4gaW5mb3Jt YXRpb24/DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4g W0FpanVuXTogYXMgdGhlIGRlZmluaXRpb24gaW4NCj4+Pj4+Pj4+Pj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbi0xDQo+Pj4+Pj4+ Pj4+IDQuMyAsIHRoZSBYT1ItUEVFUi1BRERSRVNTIGlzIHRoZSBhZGRyZXNzIHNlZW4gZnJvbSB0 aGUgVFVSTg0KPj4+Pj4+Pj4+PiBzZXJ2ZXIsIHNvIGl0IGNhbid0IGJlIHVzZWQgdG8gZmluZCB0 aGUgcmVsYXkgYWRkcmVzcyBvZiB0aGUNCj4+Pj4+Pj4+Pj4gcmVtb3RlIHBlZXIsIGFuZCB0aGVu IGNhbid0IGJlIHVzZWQgdG8gZGlyZWN0IHRyYWZmaWMgdG8NCj4+Pj4+Pj4+Pj4gZG93bnN0cmVh bSByZWxheS4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IC0tDQo+Pj4+Pj4+Pj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5j aXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZw0KPj4+Pj4+Pj4+IFByb2R1Y3RzIEVuZ2lu ZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IC0tDQo+Pj4+Pj4+IEJyYW5kb24gV2lsbGlhbXM7 IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4+Pj4+Pj4gUHJv ZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+Pj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4+Pj4+PiB0cmFtQGlldGYu b3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHRyYW0gbWFpbGluZyBsaXN0DQo+Pj4+ PiB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiB0 cmFtIG1haWxpbmcgbGlzdA0KPj4+PiB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9y Zz4NCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+Pj4g DQo+PiANCj4+IC0tDQo+PiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3 YXJlIEVuZ2luZWVyIEVtZXJnaW5nIFByb2R1Y3RzDQo+PiBFbmdpbmVlcmluZzsgQWthbWFpIFRl Y2hub2xvZ2llcyBJbmMuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== From nobody Wed Jan 14 00:54:17 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6967F1A8A42 for ; Wed, 14 Jan 2015 00:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.311 X-Spam-Level: ** X-Spam-Status: No, score=2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_PSBL=2.7] autolearn=no 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 kxENq7uuYc4H for ; Wed, 14 Jan 2015 00:54:11 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id BDEF11A6F96 for ; Wed, 14 Jan 2015 00:54:09 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06ArVQMlGbZUrlfWAA==.28212S4; Wed, 14 Jan 2015 15:22:16 +0800 (CST) From: "Aijun Wang" To: "'Pal Martinsen \(palmarti\)'" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> <002a01d02f9d$29de2660$7d9a7320$@org.cn> <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> In-Reply-To: <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> Date: Wed, 14 Jan 2015 16:53:45 +0800 Message-ID: <005501d02fd7$9aead620$d0c08260$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQLwxct8FzPZ1uJUeScTzmsc+WHAAGZgpAAAIDd3Ccv2OoAP//qDBQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06ArVQMlGbZUrlfWAA==.28212S4 X-Coremail-Antispam: 1U3129KBjvAXoW3tr17AryrXF13GF13Wr47XFb_yoW8Gr4fWo WrJr1fAw48Jr1UAr1vkw1UJry7Ja4rtr1UAryUXw1UJF13tw1UAw1UJw1UWFW5Jr4UXr4D J34UJFsxAryUJF15n29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJaK7 k0a2IF6r1UMc02F40EFcxC0VAKzVAqx4xG6I80ewAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l 1I0E4x80FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4ylYx0E74AGY7Cv6cx26r47MI8E67 AF67kF1VAFwI0_Jrv_JFUI43ZEXa7VU1sjjDUUUUU== Archived-At: Cc: tram@ietf.org, 'Brandon Williams' Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:54:15 -0000 Hi, Pal: > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen > (palmarti) > Sent: Wednesday, January 14, 2015 4:01 PM > To: Aijun Wang > Cc: tram@ietf.org; Brandon Williams > Subject: Re: [tram] New Version Notification for > draft-williams-peer-redirect-02.txt >=20 >=20 > > On 14 Jan 2015, at 02:55, Aijun Wang = wrote: > > > > Hi, Brandon & pal: > > > > Let's consider the following graph: > > > > A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B > > | | | | > > | | | > > | | | > > | +----------XC<--->C | > > | | > > |---- TURN -----|--- UDP --|---- TURN --------| > > > > If there is another peer(peer C) connected directly to TURN Server A = at the > same time, then TURN Server A will use also the pure UDP packet to = relay data > from A to C. > Close. The packet will be TURN encapsulated from A to TA, and then = from TA to > C pure UDP. Why TURN Server A send packet to C via TA, but send packet to TURN = Server B via RA? This problem may be subtle, but it influence the = solution of several scenarios. >=20 > > Then, how this packet pass through the EDM NAT device that locates > > before peer C? Peer C only send request packet to TURN Server = A=E2=80=99s TA > address previously. > > > That is a problem client C needs to handle. Probably by using its own = TURN > server. ICE will also help in this case and might render any of the = TURN servers > redundant. >=20 > > Actually, I consider current TURN draft only consider the scenarios = that there > exist only one TURN Server, and will lead more complex design if it = want to > solve the TURN-to-TURN at the same time. > > >=20 > I disagree. The current suite of ICE/TURN/STUN RFCs do support this = nicely. I > do not think further discussion on the list is appropriate, but will = be happy to > have a chat during the next IETF meeting explaining things. Ok, If possible, we can discuss this more detail face to face, but the = mail exchange is also one channel to think it deeply and can assist us = design one more lightweight solution. >=20 > .-. > P=C3=A5l-Erik >=20 >=20 > > Best Regards. > > Aijun Wang > > > >> -----Original Message----- > >> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >> Sent: Wednesday, January 14, 2015 7:09 AM > >> To: Aijun Wang > >> Cc: tram@ietf.org > >> Subject: Re: [tram] New Version Notification for > >> draft-williams-peer-redirect-02.txt > >> > >> I agree with P=C3=A5l-Erik that we're discussing existing TURN = functionality here. > >> There is no outstanding problem with a use-case involving two TURN > >> relay servers, one for each peer. The existing protocol supports = this just fine. > >> > >> Maybe the lengthy back-and-forth discussion suggests that there = could > >> be some value in documenting this particular use case somewhere > >> (turnbis? a separate draft?) to help clarify it for future = implementers. > >> > >> --Brandon > >> > >> On 01/13/2015 01:54 PM, Pal Martinsen (palmarti) wrote: > >>> > >>>> On 13 Jan 2015, at 10:28, Aijun Wang >>>> > wrote: > >>>> > >>>>> -----Original Message----- > >>>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal > >>>>> Martinsen > >>>>> (palmarti) > >>>>> Sent: Tuesday, January 13, 2015 4:39 PM > >>>>> To: Aijun Wang > >>>>> Cc:tram@ietf.org ; Brandon Williams > >>>>> Subject: Re: [tram] New Version Notification for > >>>>> draft-williams-peer-redirect-02.txt > >>>>> > >>>>> > >>>>>> On 13 Jan 2015, at 01:50, Aijun Wang >>>>>> > wrote: > >>>>>> > >>>>>> Hi, Brandon > >>>>>> > >>>>>> Thanks for your vivid graph for our discussion. Two questions = are > >>>>>> raised > >>>>>> here: > >>>>>> > >>>>>> 1. How does TURN server A decide when to use UDP to send app > >>>>>> data, and when to use TURN to send app data? Which criteria can > >>>>>> assistant the TURN server A to make this decision? > >>>>>> In > >>>>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10. > >>>>>> 2, it describes the TURN server will send UDP raw packet to the > >>>>>> peer, regardless the peer is awareness or unawareness the > >>>>>> existence of TURN. > >>>>>> > >>>>> > >>>>> TURN sever A sends =E2=80=9Capp data=E2=80=9D to client A. This = is the =E2=80=9Cprivate=E2=80=9D > >>>>> side of the TURN server. TURN server A sends TURN encapsulated > >>>>> data (data ind or > >>>>> channel) back to client A using the same 5 tuple client A used = to > >>>>> send his allocate request. TURN allows the client to use UDP, = TCP > >>>>> or TLS to do this. > >>>>> > >>>>> What happens on the =E2=80=9Cpublic=E2=80=9D side of the TURN = server is always UDP > >>>>> (Unless the TURN server supports TURN-TCP and the client have > >>>>> asked for a TCP port allocation). > >>>>> > >>>>> The remote side do not need to know that it is sending packets = to > >>>>> a TURN server, and that the packets would = =E2=80=9Cmagically=E2=80=9D be sent to > >>>>> the client that allocated that port. Think of TURN as a = mechanism > >>>>> to move your box out on the Internet and obtaining public = routable IP. > >>>>> > >>>> > >>>> I agree with you at these points. But my concern focus on the > >>>> communication channel between TURN Server A/TURN Server B and > TURN > >>>> B/Peer B. In current TURN draft, they all use the pure UDP = packet. > >>>> But in Brandon=E2=80=99s graph, they are different: the previous = pair use > >>>> pure UDP datagram, but the latter pair use DATA indication, which > >>>> is not described in current TURN draft, > >>> > >>> Unless I am missing something this is described in section 10.3. > >>> > >>> > >>>> and will lead the TURN server A be confused, because it might = face > >>>> the TURN Server B and other communication peer, such as peer C = that > >>>> directly connected on the TURN server A. Which encapsulation > >>>> method will be used then? > >>>> > >>> > >>> UDP. But that requires client a to set the correct permissions to > >>> allow traffic from C to be relayed to A. > >>> > >>> We are discussing normal TURN operation here? If not I apologise = if > >>> I have missed something in the discussion. > >>> > >>> .-. > >>> P=C3=A5l-Erik > >>> > >>> > >>> > >>>>> > >>>> > >>>> > >>>>>> 2. In your example, if TURN B use the DATA indication to B, = what > >>>>>> will B do if it does not support the TURN encapsulation? > >>>>>> > >>>>> There is no way a TURN server would send data ind to a client > >>>>> without the client having allocated a port. > >>>>> Without client B sending the allocate request there would not be = a > >>>>> binding in the NAT either. > >>>>> > >>>> > >>>> Actually true. But my concern here focus still on the data > >>>> forwarding plane, not the control plane of TURN solution. > >>>> > >>>>> .-. > >>>>> P=C3=A5l-Erik > >>>>> > >>>>> > >>>>>> Best Regards. > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] > >>>>>>> Sent: Monday, January 12, 2015 11:45 PM > >>>>>>> To: Aijun Wang; tram@ietf.org > >>>>>>> Subject: Re: [tram] Fwd: New Version Notification for > >>>>>>> draft-williams-peer-redirect-02.txt > >>>>>>> > >>>>>>> XOR-PEER-ADDRESS contains "the transport address of the peer". > >>>>>>> It is not required to be a specific type of address (host, > >>>>>>> reflexive, or relay). > >>>>>>> It will be any address that can be used to deliver data to the > >>>>>>> remote > >>>>>> peer. If > >>>>>>> two TURN relays are used, then the XOR-PEER-ADDRESS attribute = in > >>>>>>> Send and Data indications will contain the remote peer's > >>>>>>> allocated relay address. > >>>>>> There > >>>>>>> is no need the for either of the relays to even be aware that > >>>>>>> the > >>>>>> transport > >>>>>>> address is a relay address. > >>>>>>> > >>>>>>> Consider the following: > >>>>>>> > >>>>>>> A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B > >>>>>>> | | | | > >>>>>>> |---- TURN ----|-- UDP --|---- TURN ----| > >>>>>>> > >>>>>>> A and B are the two peers' host addresses. > >>>>>>> XA and XB are the two peers' reflexive addresses. > >>>>>>> TA and TB are the relay servers' addresses used as the TURN > >>>>>>> session endpoints. > >>>>>>> RA and RB are the two peers' allocated relay addresses. > >>>>>>> > >>>>>>> A Send indication from A to TA uses RB as the = XOR-PEER-ADDRESS. > >>>>>>> When A's relay receives the Send indication, it sends the data > >>>>>>> in a plain UDP > >>>>>> datagram > >>>>>>> with RA as the source and RB as the destination. When B's = relay > >>>>>>> receives > >>>>>> the > >>>>>>> UDP datagram, it sends a Data indication from TB to B with RA = as > >>>>>>> the XOR-PEER-ADDRESS. > >>>>>>> > >>>>>>> --Brandon > >>>>>>> > >>>>>>> On 01/11/2015 07:43 PM, Aijun Wang wrote: > >>>>>>>> Hi, Brandon: > >>>>>>>> > >>>>>>>> In > >>>>>>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10. > >>>>>>>> 1, > >>>>>>>> it is described as below: > >>>>>>>> > >>>>>>>> When forming a Send indication, the client MUST include an > >>>>>>>> XOR-PEER- ADDRESS attribute and a DATA attribute. The > >>>>>>>> XOR-PEER-ADDRESS attribute contains the transport address of > >>>>>>>> the peer to which the data is to be sent, and the DATA > >>>>>>>> attribute contains the actual application data to be sent to = the > peer. > >>>>>>>> > >>>>>>>> So, there is no XOR-RELAYED-ADDRESS attribute included to > >>>>>>>> identify the peer's allocated relay address. On the other = hand, > >>>>>>>> XOR-RELAYED-ADDRESS is mainly refer to the requester's > >>>>>>>> allocated relay address, not the corresponding peer. Will we > >>>>>>>> define again one new attribute, such as > >>>>>>>> XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's > >>>>>>> information? > >>>>>>>> > >>>>>>>> Even if so, what will be the source address for the packet = from > >>>>>>>> the second TURN server to destination peer? If we use the > >>>>>>>> XOR-RELAYED-ADDRESS, then the return packet from the peer = will > >>>>>>>> be passed back directly to the first TURN server, results in > >>>>>>>> non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS, then > >>>>>>>> what is the source address for the packet from the second = TURN > >>>>>>>> server back to > >>>>>> the > >>>>>>> first TURN server? > >>>>>>>> > >>>>>>>> Best Regards. > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Brandon Williams [mailto:bowill@akamai.com] > >>>>>>>>> Sent: Saturday, January 10, 2015 1:09 AM > >>>>>>>>> To: Aijun Wang; tram@ietf.org > >>>>>>>>> Subject: Re: [tram] Fwd: New Version Notification for > >>>>>>>>> draft-williams-peer-redirect-02.txt > >>>>>>>>> > >>>>>>>>> By relay address, I mean the XOR-RELAYED-ADDRESS returned in > >>>>>>>>> the > >>>>>>>> allocation > >>>>>>>>> request. This clearly identifies the true source and > >>>>>>>>> destination for the > >>>>>>>> data in > >>>>>>>>> the packet as well as the two relay servers involved. If = both > >>>>>>>>> relayed > >>>>>>>> addresses > >>>>>>>>> are on the same server, it will of course know that and be > >>>>>>>>> able to > >>>>>>>> optimize as > >>>>>>>>> Simon indicated in an earlier e-mail. > >>>>>>>>> > >>>>>>>>> --Brandon > >>>>>>>>> > >>>>>>>>> On 01/08/2015 09:40 PM, Aijun Wang wrote: > >>>>>>>>>> > >>>>>>>>>> [Aijun]: There are two relay address, one is the TURN = server > >>>>>>>>>> well-known address, another is the relay address that > >>>>>>>>>> allocated to each client. Which one should be used then? On > >>>>>>>>>> the other hand, when client want to send traffic to other > >>>>>>>>>> peer, it does not know whether the other part is under the > >>>>>>>>>> same TURN server or not, how do it select > >>>>>>>> this > >>>>>>>>> information? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> [Aijun]: as the definition in > >>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section > >>>>>>>>>> -1 > >>>>>>>>>> 4.3 , the XOR-PEER-ADDRESS is the address seen from the = TURN > >>>>>>>>>> server, so it can't be used to find the relay address of = the > >>>>>>>>>> remote peer, and then can't be used to direct traffic to > >>>>>>>>>> downstream relay. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Brandon Williams; Senior Principal Software Engineer = Emerging > >>>>>>>>> Products Engineering; Akamai Technologies Inc. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Brandon Williams; Senior Principal Software Engineer Emerging > >>>>>>> Products Engineering; Akamai Technologies Inc. > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> tram mailing list > >>>>>> tram@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/tram > >>>>> > >>>>> _______________________________________________ > >>>>> tram mailing list > >>>>> tram@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tram > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> tram mailing list > >>>> tram@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tram > >>> > >> > >> -- > >> Brandon Williams; Senior Principal Software Engineer Emerging > >> Products Engineering; Akamai Technologies Inc. > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jan 14 02:36:49 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919A11ACE4D for ; Wed, 14 Jan 2015 02:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 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, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 33w7aW2Poap9 for ; Wed, 14 Jan 2015 02:36:42 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C611ACDF4 for ; Wed, 14 Jan 2015 02:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60420; q=dns/txt; s=iport; t=1421231802; x=1422441402; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vgOqto9pwlEDB+OJRgyJQV5aSV6uWitPLo9RU99jmiE=; b=DJ9N0oEhvGlCIpBk1CK+xj9xdfcuEj8Rdx9+BqZ+yhm6hHtIQBzSjNi/ NpDh9Tx4nCHxAgqsbZZMjdnv5ey+3scEniRThANV8EEPQGVSazp6O8LoT 80vHypVPvaba0xjyR1vcgitPSwOu3eW4mJPglZfDEUof3f/kQmQ+L9lt8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkIAHJFtlStJA2L/2dsb2JhbABRCoJDQ1JYBIMBwRiBRhkBCYVxAhx4QwEBAQEBfYQMAQEBBAEBARcJBEcJAgwEAgEIEQQBASEBBgMCAgIlCxQJCAIECgQFG4gRDbwClBsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjx0LAQE0FwQHBgOCXy6BEwWBSoNshzGBW4NFhUiBDzCNAIM9IoNub4EDBwIXIn4BAQE X-IronPort-AV: E=Sophos;i="5.07,755,1413244800"; d="scan'208,217";a="386949376" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jan 2015 10:36:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0EAaeft001522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 10:36:40 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 04:36:40 -0600 From: "Pal Martinsen (palmarti)" To: Aijun Wang Thread-Topic: [tram] New Version Notification for draft-williams-peer-redirect-02.txt Thread-Index: AQHQLwxct8FzPZ1uJUeScTzmsc+WHAAGZgpAAAIDd3Ccv2OoAP//qDBQgACDTgA= Date: Wed, 14 Jan 2015 10:36:39 +0000 Message-ID: <37A39641-BA2A-439C-9602-035250015DB5@cisco.com> References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> <002a01d02f9d$29de2660$7d9a7320$@org.cn> <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> <005501d02fd7$9aead620$d0c08260$@org.cn> In-Reply-To: <005501d02fd7$9aead620$d0c08260$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.219] Content-Type: multipart/alternative; boundary="_000_37A39641BA2A439C9602035250015DB5ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 10:36:47 -0000 --_000_37A39641BA2A439C9602035250015DB5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxNCBKYW4gMjAxNSwgYXQgMDk6NTMsIEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1 YS5vcmcuY248bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCg0KSGks IFBhbDoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRyYW0gW21haWx0bzp0 cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYWwgTWFydGluc2VuDQoocGFsbWFy dGkpDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTQsIDIwMTUgNDowMSBQTQ0KVG86IEFpanVu IFdhbmcNCkNjOiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgQnJhbmRvbiBX aWxsaWFtcw0KU3ViamVjdDogUmU6IFt0cmFtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y DQpkcmFmdC13aWxsaWFtcy1wZWVyLXJlZGlyZWN0LTAyLnR4dA0KDQoNCk9uIDE0IEphbiAyMDE1 LCBhdCAwMjo1NSwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWlsdG86 d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+IHdyb3RlOg0KDQpIaSwgQnJhbmRvbiAmIHBhbDoN Cg0KTGV0J3MgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBncmFwaDoNCg0KQSA8LT4gWEEgPC0+IFRB fFJBIDwtPiBSQnxUQiA8LT4gWEIgPC0+IEINCnwgICAgICAgICAgIHwgICAgICAgIHwgICAgICAg ICAgIHwNCnwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgICAgICstLS0tLS0tLS0tWEM8LS0tPkMgICAg ICAgfA0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KfC0tLS0gVFVSTiAtLS0t LXwtLS0gVURQIC0tfC0tLS0gVFVSTiAtLS0tLS0tLXwNCg0KSWYgdGhlcmUgaXMgYW5vdGhlciBw ZWVyKHBlZXIgQykgY29ubmVjdGVkIGRpcmVjdGx5IHRvIFRVUk4gU2VydmVyIEEgYXQgdGhlDQpz YW1lIHRpbWUsIHRoZW4gVFVSTiBTZXJ2ZXIgQSB3aWxsIHVzZSBhbHNvIHRoZSBwdXJlIFVEUCBw YWNrZXQgdG8gcmVsYXkgZGF0YQ0KZnJvbSBBIHRvIEMuDQpDbG9zZS4gVGhlIHBhY2tldCB3aWxs IGJlIFRVUk4gZW5jYXBzdWxhdGVkIGZyb20gQSB0byBUQSwgYW5kIHRoZW4gZnJvbSBUQSB0bw0K QyBwdXJlIFVEUC4NCg0KV2h5IFRVUk4gU2VydmVyIEEgc2VuZCBwYWNrZXQgdG8gQyB2aWEgVEEs IGJ1dCBzZW5kIHBhY2tldCB0byBUVVJOIFNlcnZlciBCIHZpYSBSQT8gVGhpcyBwcm9ibGVtIG1h eSBiZSBzdWJ0bGUsIGJ1dCBpdCBpbmZsdWVuY2UgdGhlIHNvbHV0aW9uIG9mIHNldmVyYWwgc2Nl bmFyaW9zLg0KDQpNeSBtaXN0YWtlLiBQYWNrZXRzIHRvIEMgZ29lcyBmcm9tIFJBLg0KDQpBc3N1 bWluZyBUQSBpcyB0aGUg4oCccHJpdmF0ZeKAnSBzaWRlIG9mIHRoZSBUVVJOIHNlcnZlciBhbiBS QSBpcyB0aGUg4oCccHVibGlj4oCdLg0KDQpUaGUgb25seSBvbmUgdGhhdCBpcyBhYmxlIOKAnHNw ZWFr4oCdIHRvIHRoZSA1LXR1cGxlIFRBIGlzIEEgdGhhdCBkaWQgc2VuZCB0aGUgYWxsb2NhdGUg cmVxdWVzdC4NCg0KDQoNCg0KVGhlbiwgaG93IHRoaXMgcGFja2V0IHBhc3MgdGhyb3VnaCB0aGUg RURNIE5BVCBkZXZpY2UgdGhhdCBsb2NhdGVzDQpiZWZvcmUgcGVlciBDPyAgUGVlciBDIG9ubHkg c2VuZCByZXF1ZXN0IHBhY2tldCB0byBUVVJOIFNlcnZlciBB4oCZcyBUQQ0KYWRkcmVzcyBwcmV2 aW91c2x5Lg0KDQpUaGF0IGlzIGEgcHJvYmxlbSBjbGllbnQgQyBuZWVkcyB0byBoYW5kbGUuIFBy b2JhYmx5IGJ5IHVzaW5nIGl0cyBvd24gVFVSTg0Kc2VydmVyLiBJQ0Ugd2lsbCBhbHNvIGhlbHAg aW4gdGhpcyBjYXNlIGFuZCBtaWdodCByZW5kZXIgYW55IG9mIHRoZSBUVVJOIHNlcnZlcnMNCnJl ZHVuZGFudC4NCg0KQWN0dWFsbHksIEkgY29uc2lkZXIgY3VycmVudCBUVVJOIGRyYWZ0IG9ubHkg Y29uc2lkZXIgdGhlIHNjZW5hcmlvcyB0aGF0IHRoZXJlDQpleGlzdCBvbmx5IG9uZSBUVVJOIFNl cnZlciwgYW5kIHdpbGwgbGVhZCBtb3JlIGNvbXBsZXggZGVzaWduIGlmIGl0IHdhbnQgdG8NCnNv bHZlIHRoZSBUVVJOLXRvLVRVUk4gYXQgdGhlIHNhbWUgdGltZS4NCg0KDQpJIGRpc2FncmVlLiBU aGUgY3VycmVudCBzdWl0ZSBvZiBJQ0UvVFVSTi9TVFVOIFJGQ3MgZG8gc3VwcG9ydCB0aGlzIG5p Y2VseS4gSQ0KZG8gbm90IHRoaW5rIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBpcyBh cHByb3ByaWF0ZSwgYnV0IHdpbGwgYmUgaGFwcHkgdG8NCmhhdmUgYSBjaGF0IGR1cmluZyB0aGUg bmV4dCBJRVRGIG1lZXRpbmcgZXhwbGFpbmluZyB0aGluZ3MuDQoNCk9rLCBJZiBwb3NzaWJsZSwg d2UgY2FuIGRpc2N1c3MgdGhpcyBtb3JlIGRldGFpbCBmYWNlIHRvIGZhY2UsIGJ1dCB0aGUgbWFp bCBleGNoYW5nZSBpcyBhbHNvIG9uZSBjaGFubmVsIHRvIHRoaW5rIGl0IGRlZXBseSBhbmQgY2Fu IGFzc2lzdCB1cyBkZXNpZ24gb25lIG1vcmUgbGlnaHR3ZWlnaHQgc29sdXRpb24uDQoNClRoZSBw cm9ibGVtIGlzIHdlIGFyZSBub3QgZGlzY3Vzc2luZy4gV2UgYXJlIHRyeWluZyB0byB0ZWxsIHlv dSB0aGF0IHRoaXMgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBleGlzdGluZyBzdWl0ZSBvZiBS RkNzLg0KDQouLS4NClDDpWwtRXJpaw0KDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KQmVzdCBSZWdh cmRzLg0KQWlqdW4gV2FuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJh bmRvbiBXaWxsaWFtcyBbbWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgSmFudWFyeSAxNCwgMjAxNSA3OjA5IEFNDQpUbzogQWlqdW4gV2FuZw0KQ2M6 IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RyYW1d IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJl Y3QtMDIudHh0DQoNCkkgYWdyZWUgd2l0aCBQw6VsLUVyaWsgdGhhdCB3ZSdyZSBkaXNjdXNzaW5n IGV4aXN0aW5nIFRVUk4gZnVuY3Rpb25hbGl0eSBoZXJlLg0KVGhlcmUgaXMgbm8gb3V0c3RhbmRp bmcgcHJvYmxlbSB3aXRoIGEgdXNlLWNhc2UgaW52b2x2aW5nIHR3byBUVVJODQpyZWxheSBzZXJ2 ZXJzLCBvbmUgZm9yIGVhY2ggcGVlci4gVGhlIGV4aXN0aW5nIHByb3RvY29sIHN1cHBvcnRzIHRo aXMganVzdCBmaW5lLg0KDQpNYXliZSB0aGUgbGVuZ3RoeSBiYWNrLWFuZC1mb3J0aCBkaXNjdXNz aW9uIHN1Z2dlc3RzIHRoYXQgdGhlcmUgY291bGQNCmJlIHNvbWUgdmFsdWUgaW4gZG9jdW1lbnRp bmcgdGhpcyBwYXJ0aWN1bGFyIHVzZSBjYXNlIHNvbWV3aGVyZQ0KKHR1cm5iaXM/IGEgc2VwYXJh dGUgZHJhZnQ/KSB0byBoZWxwIGNsYXJpZnkgaXQgZm9yIGZ1dHVyZSBpbXBsZW1lbnRlcnMuDQoN Ci0tQnJhbmRvbg0KDQpPbiAwMS8xMy8yMDE1IDAxOjU0IFBNLCBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSkgd3JvdGU6DQoNCk9uIDEzIEphbiAyMDE1LCBhdCAxMDoyOCwgQWlqdW4gV2FuZyA8d2Fu Z2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4N CjxtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+IHdyb3RlOg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFBhbA0KTWFydGluc2VuDQoocGFsbWFydGkpDQpTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDEzLCAyMDE1IDQ6MzkgUE0NClRvOiBBaWp1biBXYW5nDQpDYzp0cmFtQGlldGYu b3JnPGh0dHA6Ly9pZXRmLm9yZz4gPG1haWx0bzp0cmFtQGlldGYub3JnPjsgQnJhbmRvbiBXaWxs aWFtcw0KU3ViamVjdDogUmU6IFt0cmFtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpk cmFmdC13aWxsaWFtcy1wZWVyLXJlZGlyZWN0LTAyLnR4dA0KDQoNCk9uIDEzIEphbiAyMDE1LCBh dCAwMTo1MCwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWlsdG86d2Fu Z2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCjxtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5j bj4+IHdyb3RlOg0KDQpIaSwgQnJhbmRvbg0KDQpUaGFua3MgZm9yIHlvdXIgdml2aWQgZ3JhcGgg Zm9yIG91ciBkaXNjdXNzaW9uLiBUd28gcXVlc3Rpb25zIGFyZQ0KcmFpc2VkDQpoZXJlOg0KDQox LiBIb3cgZG9lcyBUVVJOIHNlcnZlciBBIGRlY2lkZSB3aGVuIHRvIHVzZSBVRFAgdG8gc2VuZCBh cHANCmRhdGEsIGFuZCB3aGVuIHRvIHVzZSBUVVJOIHRvIHNlbmQgYXBwIGRhdGE/IFdoaWNoIGNy aXRlcmlhIGNhbg0KYXNzaXN0YW50IHRoZSBUVVJOIHNlcnZlciBBIHRvIG1ha2UgdGhpcyBkZWNp c2lvbj8NCkluDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVy bmJpcy0wMCNzZWN0aW9uLTEwLg0KMiwgaXQgZGVzY3JpYmVzIHRoZSBUVVJOIHNlcnZlciB3aWxs IHNlbmQgVURQIHJhdyBwYWNrZXQgdG8gdGhlDQpwZWVyLCByZWdhcmRsZXNzIHRoZSBwZWVyIGlz IGF3YXJlbmVzcyBvciB1bmF3YXJlbmVzcyB0aGUNCmV4aXN0ZW5jZSBvZiBUVVJOLg0KDQoNClRV Uk4gc2V2ZXIgQSBzZW5kcyDigJxhcHAgZGF0YeKAnSB0byBjbGllbnQgQS4gVGhpcyBpcyB0aGUg 4oCccHJpdmF0ZeKAnQ0Kc2lkZSBvZiB0aGUgVFVSTiBzZXJ2ZXIuIFRVUk4gc2VydmVyIEEgc2Vu ZHMgVFVSTiBlbmNhcHN1bGF0ZWQNCmRhdGEgKGRhdGEgaW5kIG9yDQpjaGFubmVsKSBiYWNrIHRv IGNsaWVudCBBIHVzaW5nIHRoZSBzYW1lIDUgdHVwbGUgY2xpZW50IEEgdXNlZCB0bw0Kc2VuZCBo aXMgYWxsb2NhdGUgcmVxdWVzdC4gVFVSTiBhbGxvd3MgdGhlIGNsaWVudCB0byB1c2UgVURQLCBU Q1ANCm9yIFRMUyB0byBkbyB0aGlzLg0KDQpXaGF0IGhhcHBlbnMgb24gdGhlIOKAnHB1YmxpY+KA nSBzaWRlIG9mIHRoZSBUVVJOIHNlcnZlciBpcyBhbHdheXMgVURQDQooVW5sZXNzIHRoZSBUVVJO IHNlcnZlciBzdXBwb3J0cyBUVVJOLVRDUCBhbmQgdGhlIGNsaWVudCBoYXZlDQphc2tlZCBmb3Ig YSBUQ1AgcG9ydCBhbGxvY2F0aW9uKS4NCg0KVGhlIHJlbW90ZSBzaWRlIGRvIG5vdCBuZWVkIHRv IGtub3cgdGhhdCBpdCBpcyBzZW5kaW5nIHBhY2tldHMgdG8NCmEgVFVSTiBzZXJ2ZXIsIGFuZCB0 aGF0IHRoZSBwYWNrZXRzIHdvdWxkIOKAnG1hZ2ljYWxseeKAnSBiZSBzZW50IHRvDQp0aGUgY2xp ZW50IHRoYXQgYWxsb2NhdGVkIHRoYXQgcG9ydC4gVGhpbmsgb2YgVFVSTiBhcyBhIG1lY2hhbmlz bQ0KdG8gbW92ZSB5b3VyIGJveCBvdXQgb24gdGhlIEludGVybmV0IGFuZCBvYnRhaW5pbmcgcHVi bGljIHJvdXRhYmxlIElQLg0KDQoNCkkgYWdyZWUgd2l0aCB5b3UgYXQgdGhlc2UgcG9pbnRzLiBC dXQgbXkgY29uY2VybiBmb2N1cyBvbiB0aGUNCmNvbW11bmljYXRpb24gY2hhbm5lbCBiZXR3ZWVu IFRVUk4gU2VydmVyIEEvVFVSTiBTZXJ2ZXIgQiBhbmQNClRVUk4NCkIvUGVlciBCLiBJbiBjdXJy ZW50IFRVUk4gZHJhZnQsIHRoZXkgYWxsIHVzZSB0aGUgcHVyZSBVRFAgcGFja2V0Lg0KQnV0IGlu IEJyYW5kb27igJlzIGdyYXBoLCB0aGV5IGFyZSBkaWZmZXJlbnQ6IHRoZSBwcmV2aW91cyBwYWly IHVzZQ0KcHVyZSBVRFAgZGF0YWdyYW0sIGJ1dCB0aGUgbGF0dGVyIHBhaXIgdXNlIERBVEEgaW5k aWNhdGlvbiwgd2hpY2gNCmlzIG5vdCBkZXNjcmliZWQgaW4gY3VycmVudCBUVVJOIGRyYWZ0LA0K DQpVbmxlc3MgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyB0aGlzIGlzIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDEwLjMuDQoNCg0KYW5kIHdpbGwgbGVhZCB0aGUgVFVSTiBzZXJ2ZXIgQSBiZSBjb25mdXNl ZCwgYmVjYXVzZSBpdCBtaWdodCBmYWNlDQp0aGUgVFVSTiBTZXJ2ZXIgQiBhbmQgb3RoZXIgY29t bXVuaWNhdGlvbiBwZWVyLCBzdWNoIGFzIHBlZXIgQyB0aGF0DQpkaXJlY3RseSBjb25uZWN0ZWQg b24gdGhlIFRVUk4gc2VydmVyIEEuICBXaGljaCBlbmNhcHN1bGF0aW9uDQptZXRob2Qgd2lsbCBi ZSB1c2VkIHRoZW4/DQoNCg0KVURQLiBCdXQgdGhhdCByZXF1aXJlcyBjbGllbnQgYSB0byBzZXQg dGhlIGNvcnJlY3QgcGVybWlzc2lvbnMgdG8NCmFsbG93IHRyYWZmaWMgZnJvbSBDIHRvIGJlIHJl bGF5ZWQgdG8gQS4NCg0KV2UgYXJlIGRpc2N1c3Npbmcgbm9ybWFsIFRVUk4gb3BlcmF0aW9uIGhl cmU/IElmIG5vdCBJIGFwb2xvZ2lzZSBpZg0KSSBoYXZlIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhl IGRpc2N1c3Npb24uDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KDQoNCg0KDQoyLiBJbiB5b3VyIGV4 YW1wbGUsIGlmIFRVUk4gQiB1c2UgdGhlIERBVEEgaW5kaWNhdGlvbiB0byBCLCB3aGF0DQp3aWxs IEIgZG8gaWYgaXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgVFVSTiBlbmNhcHN1bGF0aW9uPw0KDQpU aGVyZSBpcyBubyB3YXkgYSBUVVJOIHNlcnZlciB3b3VsZCBzZW5kIGRhdGEgaW5kIHRvIGEgY2xp ZW50DQp3aXRob3V0IHRoZSBjbGllbnQgaGF2aW5nIGFsbG9jYXRlZCBhIHBvcnQuDQpXaXRob3V0 IGNsaWVudCBCIHNlbmRpbmcgdGhlIGFsbG9jYXRlIHJlcXVlc3QgdGhlcmUgd291bGQgbm90IGJl IGENCmJpbmRpbmcgaW4gdGhlIE5BVCBlaXRoZXIuDQoNCg0KQWN0dWFsbHkgdHJ1ZS4gQnV0IG15 IGNvbmNlcm4gaGVyZSBmb2N1cyBzdGlsbCBvbiB0aGUgZGF0YQ0KZm9yd2FyZGluZyBwbGFuZSwg bm90IHRoZSBjb250cm9sIHBsYW5lIG9mIFRVUk4gc29sdXRpb24uDQoNCi4tLg0KUMOlbC1Fcmlr DQoNCg0KQmVzdCBSZWdhcmRzLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBCcmFuZG9uIFdpbGxpYW1zIFttYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0K U2VudDogTW9uZGF5LCBKYW51YXJ5IDEyLCAyMDE1IDExOjQ1IFBNDQpUbzogQWlqdW4gV2FuZzsg dHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4gPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt0cmFtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IN CmRyYWZ0LXdpbGxpYW1zLXBlZXItcmVkaXJlY3QtMDIudHh0DQoNClhPUi1QRUVSLUFERFJFU1Mg Y29udGFpbnMgInRoZSB0cmFuc3BvcnQgYWRkcmVzcyBvZiB0aGUgcGVlciIuDQpJdCBpcyBub3Qg cmVxdWlyZWQgdG8gYmUgYSBzcGVjaWZpYyB0eXBlIG9mIGFkZHJlc3MgKGhvc3QsDQpyZWZsZXhp dmUsIG9yIHJlbGF5KS4NCkl0IHdpbGwgYmUgYW55IGFkZHJlc3MgdGhhdCBjYW4gYmUgdXNlZCB0 byBkZWxpdmVyIGRhdGEgdG8gdGhlDQpyZW1vdGUNCnBlZXIuIElmDQp0d28gVFVSTiByZWxheXMg YXJlIHVzZWQsIHRoZW4gdGhlIFhPUi1QRUVSLUFERFJFU1MgYXR0cmlidXRlIGluDQpTZW5kIGFu ZCBEYXRhIGluZGljYXRpb25zIHdpbGwgY29udGFpbiB0aGUgcmVtb3RlIHBlZXIncw0KYWxsb2Nh dGVkIHJlbGF5IGFkZHJlc3MuDQpUaGVyZQ0KaXMgbm8gbmVlZCB0aGUgZm9yIGVpdGhlciBvZiB0 aGUgcmVsYXlzIHRvIGV2ZW4gYmUgYXdhcmUgdGhhdA0KdGhlDQp0cmFuc3BvcnQNCmFkZHJlc3Mg aXMgYSByZWxheSBhZGRyZXNzLg0KDQpDb25zaWRlciB0aGUgZm9sbG93aW5nOg0KDQpBIDwtPiBY QSA8LT4gVEF8UkEgPC0+IFJCfFRCIDwtPiBYQiA8LT4gQg0KfCAgICAgICAgICAgICAgfCAgICAg ICAgIHwgICAgICAgICAgICAgIHwNCnwtLS0tIFRVUk4gLS0tLXwtLSBVRFAgLS18LS0tLSBUVVJO IC0tLS18DQoNCkEgYW5kIEIgYXJlIHRoZSB0d28gcGVlcnMnIGhvc3QgYWRkcmVzc2VzLg0KWEEg YW5kIFhCIGFyZSB0aGUgdHdvIHBlZXJzJyByZWZsZXhpdmUgYWRkcmVzc2VzLg0KVEEgYW5kIFRC IGFyZSB0aGUgcmVsYXkgc2VydmVycycgYWRkcmVzc2VzIHVzZWQgYXMgdGhlIFRVUk4NCnNlc3Np b24gZW5kcG9pbnRzLg0KUkEgYW5kIFJCIGFyZSB0aGUgdHdvIHBlZXJzJyBhbGxvY2F0ZWQgcmVs YXkgYWRkcmVzc2VzLg0KDQpBIFNlbmQgaW5kaWNhdGlvbiBmcm9tIEEgdG8gVEEgdXNlcyBSQiBh cyB0aGUgWE9SLVBFRVItQUREUkVTUy4NCldoZW4gQSdzIHJlbGF5IHJlY2VpdmVzIHRoZSBTZW5k IGluZGljYXRpb24sIGl0IHNlbmRzIHRoZSBkYXRhDQppbiBhIHBsYWluIFVEUA0KZGF0YWdyYW0N CndpdGggUkEgYXMgdGhlIHNvdXJjZSBhbmQgUkIgYXMgdGhlIGRlc3RpbmF0aW9uLiBXaGVuIEIn cyByZWxheQ0KcmVjZWl2ZXMNCnRoZQ0KVURQIGRhdGFncmFtLCBpdCBzZW5kcyBhIERhdGEgaW5k aWNhdGlvbiBmcm9tIFRCIHRvIEIgd2l0aCBSQSBhcw0KdGhlIFhPUi1QRUVSLUFERFJFU1MuDQoN Ci0tQnJhbmRvbg0KDQpPbiAwMS8xMS8yMDE1IDA3OjQzIFBNLCBBaWp1biBXYW5nIHdyb3RlOg0K SGksIEJyYW5kb246DQoNCkluDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0wMCNzZWN0aW9uLTEwLg0KMSwNCml0IGlzIGRlc2NyaWJlZCBhcyBiZWxv dzoNCg0KV2hlbiBmb3JtaW5nIGEgU2VuZCBpbmRpY2F0aW9uLCB0aGUgY2xpZW50IE1VU1QgaW5j bHVkZSBhbg0KWE9SLVBFRVItICBBRERSRVNTIGF0dHJpYnV0ZSBhbmQgYSBEQVRBIGF0dHJpYnV0 ZS4gIFRoZQ0KWE9SLVBFRVItQUREUkVTUyAgYXR0cmlidXRlIGNvbnRhaW5zIHRoZSB0cmFuc3Bv cnQgYWRkcmVzcyBvZg0KdGhlIHBlZXIgdG8gd2hpY2ggdGhlICBkYXRhIGlzIHRvIGJlIHNlbnQs IGFuZCB0aGUgREFUQQ0KYXR0cmlidXRlIGNvbnRhaW5zIHRoZSBhY3R1YWwgIGFwcGxpY2F0aW9u IGRhdGEgdG8gYmUgc2VudCB0byB0aGUNCnBlZXIuDQoNClNvLCB0aGVyZSBpcyBubyBYT1ItUkVM QVlFRC1BRERSRVNTIGF0dHJpYnV0ZSBpbmNsdWRlZCB0bw0KaWRlbnRpZnkgdGhlIHBlZXIncyBh bGxvY2F0ZWQgcmVsYXkgYWRkcmVzcy4gT24gdGhlIG90aGVyIGhhbmQsDQpYT1ItUkVMQVlFRC1B RERSRVNTIGlzIG1haW5seSByZWZlciB0byB0aGUgcmVxdWVzdGVyJ3MNCmFsbG9jYXRlZCByZWxh eSBhZGRyZXNzLCBub3QgdGhlIGNvcnJlc3BvbmRpbmcgcGVlci4gV2lsbCB3ZQ0KZGVmaW5lIGFn YWluIG9uZSBuZXcgYXR0cmlidXRlLCBzdWNoIGFzDQpYT1ItUEVFUi1SRUxBWUVELUFERFJFU1Mg dG8gdHJhbnNmZXIgdGhlIG5leHQgVFVSTiBzZXJ2ZXIncw0KaW5mb3JtYXRpb24/DQoNCkV2ZW4g aWYgc28sIHdoYXQgd2lsbCBiZSB0aGUgc291cmNlIGFkZHJlc3MgZm9yIHRoZSBwYWNrZXQgZnJv bQ0KdGhlIHNlY29uZCBUVVJOIHNlcnZlciB0byBkZXN0aW5hdGlvbiBwZWVyPyBJZiB3ZSB1c2Ug dGhlDQpYT1ItUkVMQVlFRC1BRERSRVNTLCB0aGVuIHRoZSByZXR1cm4gcGFja2V0IGZyb20gdGhl IHBlZXIgd2lsbA0KYmUgcGFzc2VkIGJhY2sgZGlyZWN0bHkgdG8gdGhlIGZpcnN0IFRVUk4gc2Vy dmVyLCByZXN1bHRzIGluDQpub24tc3ltbWV0cmljIHJvdXRlLiBJZiB3ZSB1c2UgWE9SLVBFRVIt UkVMQVlFRC1BRERSRVNTLCB0aGVuDQp3aGF0IGlzIHRoZSBzb3VyY2UgYWRkcmVzcyBmb3IgdGhl IHBhY2tldCBmcm9tIHRoZSBzZWNvbmQgVFVSTg0Kc2VydmVyIGJhY2sgdG8NCnRoZQ0KZmlyc3Qg VFVSTiBzZXJ2ZXI/DQoNCkJlc3QgUmVnYXJkcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJyYW5kb24gV2lsbGlhbXMgW21haWx0bzpib3dpbGxAYWthbWFpLmNvbV0NClNl bnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEwLCAyMDE1IDE6MDkgQU0NClRvOiBBaWp1biBXYW5nOyB0 cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPiA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW3RyYW1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0K ZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRpcmVjdC0wMi50eHQNCg0KQnkgcmVsYXkgYWRkcmVzcywg SSBtZWFuIHRoZSBYT1ItUkVMQVlFRC1BRERSRVNTIHJldHVybmVkIGluDQp0aGUNCmFsbG9jYXRp b24NCnJlcXVlc3QuIFRoaXMgY2xlYXJseSBpZGVudGlmaWVzIHRoZSB0cnVlIHNvdXJjZSBhbmQN CmRlc3RpbmF0aW9uIGZvciB0aGUNCmRhdGEgaW4NCnRoZSBwYWNrZXQgYXMgd2VsbCBhcyB0aGUg dHdvIHJlbGF5IHNlcnZlcnMgaW52b2x2ZWQuIElmIGJvdGgNCnJlbGF5ZWQNCmFkZHJlc3Nlcw0K YXJlIG9uIHRoZSBzYW1lIHNlcnZlciwgaXQgd2lsbCBvZiBjb3Vyc2Uga25vdyB0aGF0IGFuZCBi ZQ0KYWJsZSB0bw0Kb3B0aW1pemUgYXMNClNpbW9uIGluZGljYXRlZCBpbiBhbiBlYXJsaWVyIGUt bWFpbC4NCg0KLS1CcmFuZG9uDQoNCk9uIDAxLzA4LzIwMTUgMDk6NDAgUE0sIEFpanVuIFdhbmcg d3JvdGU6DQoNCltBaWp1bl06IFRoZXJlIGFyZSB0d28gcmVsYXkgYWRkcmVzcywgb25lIGlzIHRo ZSBUVVJOIHNlcnZlcg0Kd2VsbC1rbm93biBhZGRyZXNzLCBhbm90aGVyIGlzIHRoZSByZWxheSBh ZGRyZXNzIHRoYXQNCmFsbG9jYXRlZCB0byBlYWNoIGNsaWVudC4gV2hpY2ggb25lIHNob3VsZCBi ZSB1c2VkIHRoZW4/IE9uDQp0aGUgb3RoZXIgaGFuZCwgd2hlbiBjbGllbnQgd2FudCB0byBzZW5k IHRyYWZmaWMgdG8gb3RoZXINCnBlZXIsIGl0IGRvZXMgbm90IGtub3cgd2hldGhlciB0aGUgb3Ro ZXIgcGFydCBpcyB1bmRlciB0aGUNCnNhbWUgVFVSTiBzZXJ2ZXIgb3Igbm90LCBob3cgZG8gaXQg c2VsZWN0DQp0aGlzDQppbmZvcm1hdGlvbj8NCg0KDQoNCltBaWp1bl06IGFzIHRoZSBkZWZpbml0 aW9uIGluDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJp cy0wMCNzZWN0aW9uDQotMQ0KNC4zICwgdGhlIFhPUi1QRUVSLUFERFJFU1MgaXMgdGhlIGFkZHJl c3Mgc2VlbiBmcm9tIHRoZSBUVVJODQpzZXJ2ZXIsIHNvIGl0IGNhbid0IGJlIHVzZWQgdG8gZmlu ZCB0aGUgcmVsYXkgYWRkcmVzcyBvZiB0aGUNCnJlbW90ZSBwZWVyLCBhbmQgdGhlbiBjYW4ndCBi ZSB1c2VkIHRvIGRpcmVjdCB0cmFmZmljIHRvDQpkb3duc3RyZWFtIHJlbGF5Lg0KDQoNCg0KDQot LQ0KQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBF bWVyZ2luZw0KUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0K DQoNCg0KDQotLQ0KQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBF bmdpbmVlciBFbWVyZ2luZw0KUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dp ZXMgSW5jLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYu b3JnPiA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGll dGYub3JnPiA8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86 dHJhbUBpZXRmLm9yZz4gPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0KLS0NCkJyYW5kb24gV2lsbGlhbXM7IFNlbmlv ciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNClByb2R1Y3RzIEVuZ2luZWVy aW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRm Lm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1h aWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= --_000_37A39641BA2A439C9602035250015DB5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <98D75652189CEB468E4EB14984ADFA27@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxNCBK YW4gMjAxNSwgYXQgMDk6NTMsIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlq dW5AdHNpbmdodWEub3JnLmNuIiBjbGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SGksDQogUGFs Ojwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNsYXNzPSIiPg0KRnJvbTogdHJhbSBbPGEgaHJl Zj0ibWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBQYWwgTWFydGluc2VuPGJyIGNsYXNzPSIi Pg0KKHBhbG1hcnRpKTxiciBjbGFzcz0iIj4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxNCwg MjAxNSA0OjAxIFBNPGJyIGNsYXNzPSIiPg0KVG86IEFpanVuIFdhbmc8YnIgY2xhc3M9IiI+DQpD Yzo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8L2E+OyBCcmFu ZG9uIFdpbGxpYW1zPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFt0cmFtXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRp cmVjdC0wMi50eHQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAxNCBKYW4gMjAxNSwgYXQgMDI6NTUs IEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNu IiBjbGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9hPiZndDsgd3JvdGU6PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGksIEJyYW5kb24gJmFtcDsgcGFsOjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkxldCdzIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZ3JhcGg6PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSAmbHQ7LSZndDsgWEEgJmx0Oy0mZ3Q7IFRBfFJB ICZsdDstJmd0OyBSQnxUQiAmbHQ7LSZndDsgWEIgJmx0Oy0mZ3Q7IEI8YnIgY2xhc3M9IiI+DQp8 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3wgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PGJy IGNsYXNzPSIiPg0KfCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt8ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3w8YnIgY2xhc3M9IiI+DQp8ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxiciBjbGFzcz0iIj4N CnwgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7JiM0MzstLS0tLS0tLS0tWEMmbHQ7LS0tJmd0O0MgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fDxiciBjbGFzcz0iIj4NCnwgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxiciBjbGFz cz0iIj4NCnwtLS0tIFRVUk4gLS0tLS18LS0tIFVEUCAtLXwtLS0tIFRVUk4gLS0tLS0tLS18PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgdGhlcmUgaXMgYW5vdGhlciBwZWVyKHBlZXIg QykgY29ubmVjdGVkIGRpcmVjdGx5IHRvIFRVUk4gU2VydmVyIEEgYXQgdGhlPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0Kc2FtZSB0aW1lLCB0aGVuIFRVUk4gU2VydmVyIEEgd2lsbCB1c2Ug YWxzbyB0aGUgcHVyZSBVRFAgcGFja2V0IHRvIHJlbGF5IGRhdGE8YnIgY2xhc3M9IiI+DQpmcm9t IEEgdG8gQy48YnIgY2xhc3M9IiI+DQpDbG9zZS4gVGhlIHBhY2tldCB3aWxsIGJlIFRVUk4gZW5j YXBzdWxhdGVkIGZyb20gQSB0byBUQSwgYW5kIHRoZW4gZnJvbSBUQSB0bzxiciBjbGFzcz0iIj4N CkMgcHVyZSBVRFAuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+V2h5DQogVFVSTiBTZXJ2ZXIgQSBzZW5kIHBhY2tldCB0byBDIHZpYSBUQSwgYnV0IHNl bmQgcGFja2V0IHRvIFRVUk4gU2VydmVyIEIgdmlhIFJBPyBUaGlzIHByb2JsZW0gbWF5IGJlIHN1 YnRsZSwgYnV0IGl0IGluZmx1ZW5jZSB0aGUgc29sdXRpb24gb2Ygc2V2ZXJhbCBzY2VuYXJpb3Mu PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+TXkgbWlzdGFrZS4gUGFja2V0cyB0byBDIGdvZXMgZnJvbSBSQS4mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkFzc3VtaW5nIFRBIGlz IHRoZSDigJxwcml2YXRl4oCdIHNpZGUgb2YgdGhlIFRVUk4gc2VydmVyIGFuIFJBIGlzIHRoZSDi gJxwdWJsaWPigJ0uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGUg b25seSBvbmUgdGhhdCBpcyBhYmxlIOKAnHNwZWFr4oCdIHRvIHRoZSA1LXR1cGxlIFRBIGlzIEEg dGhhdCBkaWQgc2VuZCB0aGUgYWxsb2NhdGUgcmVxdWVzdC48L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PlRoZW4sIGhvdyB0aGlzIHBhY2tldCBwYXNzIHRocm91Z2ggdGhlIEVETSBOQVQgZGV2aWNlIHRo YXQgbG9jYXRlczxiciBjbGFzcz0iIj4NCmJlZm9yZSBwZWVyIEM/ICZuYnNwO1BlZXIgQyBvbmx5 IHNlbmQgcmVxdWVzdCBwYWNrZXQgdG8gVFVSTiBTZXJ2ZXIgQeKAmXMgVEE8YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQphZGRyZXNzIHByZXZpb3VzbHkuPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K VGhhdCBpcyBhIHByb2JsZW0gY2xpZW50IEMgbmVlZHMgdG8gaGFuZGxlLiBQcm9iYWJseSBieSB1 c2luZyBpdHMgb3duIFRVUk48YnIgY2xhc3M9IiI+DQpzZXJ2ZXIuIElDRSB3aWxsIGFsc28gaGVs cCBpbiB0aGlzIGNhc2UgYW5kIG1pZ2h0IHJlbmRlciBhbnkgb2YgdGhlIFRVUk4gc2VydmVyczxi ciBjbGFzcz0iIj4NCnJlZHVuZGFudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5BY3R1YWxseSwgSSBjb25zaWRlciBjdXJyZW50 IFRVUk4gZHJhZnQgb25seSBjb25zaWRlciB0aGUgc2NlbmFyaW9zIHRoYXQgdGhlcmU8YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpleGlzdCBvbmx5IG9uZSBUVVJOIFNlcnZlciwgYW5kIHdp bGwgbGVhZCBtb3JlIGNvbXBsZXggZGVzaWduIGlmIGl0IHdhbnQgdG88YnIgY2xhc3M9IiI+DQpz b2x2ZSB0aGUgVFVSTi10by1UVVJOIGF0IHRoZSBzYW1lIHRpbWUuPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KSSBkaXNhZ3JlZS4gVGhlIGN1cnJlbnQgc3VpdGUgb2YgSUNFL1RV Uk4vU1RVTiBSRkNzIGRvIHN1cHBvcnQgdGhpcyBuaWNlbHkuIEk8YnIgY2xhc3M9IiI+DQpkbyBu b3QgdGhpbmsgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGlzIGFwcHJvcHJpYXRlLCBi dXQgd2lsbCBiZSBoYXBweSB0bzxiciBjbGFzcz0iIj4NCmhhdmUgYSBjaGF0IGR1cmluZyB0aGUg bmV4dCBJRVRGIG1lZXRpbmcgZXhwbGFpbmluZyB0aGluZ3MuPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T2ssDQogSWYgcG9zc2libGUsIHdlIGNhbiBk aXNjdXNzIHRoaXMgbW9yZSBkZXRhaWwgZmFjZSB0byBmYWNlLCBidXQgdGhlIG1haWwgZXhjaGFu Z2UgaXMgYWxzbyBvbmUgY2hhbm5lbCB0byB0aGluayBpdCBkZWVwbHkgYW5kIGNhbiBhc3Npc3Qg dXMgZGVzaWduIG9uZSBtb3JlIGxpZ2h0d2VpZ2h0IHNvbHV0aW9uLjwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhlIHByb2JsZW0gaXMgd2UgYXJl IG5vdCBkaXNjdXNzaW5nLiBXZSBhcmUgdHJ5aW5nIHRvIHRlbGwgeW91IHRoYXQgdGhpcyBpcyBh bHJlYWR5IGNvdmVyZWQgaW4gdGhlIGV4aXN0aW5nIHN1aXRlIG9mIFJGQ3MuPC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4uLS48L2Rpdj4NCjxkaXY+UMOlbC1FcmlrPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLi0uPGJyIGNsYXNzPSIiPg0K UMOlbC1FcmlrPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+QmVzdCBSZWdhcmRzLjxiciBjbGFzcz0iIj4N CkFpanVuIFdhbmc8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4N CkZyb206IEJyYW5kb24gV2lsbGlhbXMgWzxhIGhyZWY9Im1haWx0bzpicmFuZG9uLndpbGxpYW1z QGFrYW1haS5jb20iIGNsYXNzPSIiPm1haWx0bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb208 L2E+XTxiciBjbGFzcz0iIj4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxNCwgMjAxNSA3OjA5 IEFNPGJyIGNsYXNzPSIiPg0KVG86IEFpanVuIFdhbmc8YnIgY2xhc3M9IiI+DQpDYzogPGEgaHJl Zj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KU3ViamVjdDogUmU6IFt0cmFtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y PGJyIGNsYXNzPSIiPg0KZHJhZnQtd2lsbGlhbXMtcGVlci1yZWRpcmVjdC0wMi50eHQ8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFncmVlIHdpdGggUMOlbC1FcmlrIHRoYXQgd2UncmUg ZGlzY3Vzc2luZyBleGlzdGluZyBUVVJOIGZ1bmN0aW9uYWxpdHkgaGVyZS48YnIgY2xhc3M9IiI+ DQpUaGVyZSBpcyBubyBvdXRzdGFuZGluZyBwcm9ibGVtIHdpdGggYSB1c2UtY2FzZSBpbnZvbHZp bmcgdHdvIFRVUk48YnIgY2xhc3M9IiI+DQpyZWxheSBzZXJ2ZXJzLCBvbmUgZm9yIGVhY2ggcGVl ci4gVGhlIGV4aXN0aW5nIHByb3RvY29sIHN1cHBvcnRzIHRoaXMganVzdCBmaW5lLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCk1heWJlIHRoZSBsZW5ndGh5IGJhY2stYW5kLWZvcnRoIGRp c2N1c3Npb24gc3VnZ2VzdHMgdGhhdCB0aGVyZSBjb3VsZDxiciBjbGFzcz0iIj4NCmJlIHNvbWUg dmFsdWUgaW4gZG9jdW1lbnRpbmcgdGhpcyBwYXJ0aWN1bGFyIHVzZSBjYXNlIHNvbWV3aGVyZTxi ciBjbGFzcz0iIj4NCih0dXJuYmlzPyBhIHNlcGFyYXRlIGRyYWZ0PykgdG8gaGVscCBjbGFyaWZ5 IGl0IGZvciBmdXR1cmUgaW1wbGVtZW50ZXJzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ci0tQnJhbmRvbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDAxLzEzLzIwMTUgMDE6 NTQgUE0sIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAxMyBKYW4gMjAxNSwgYXQgMTA6MjgsIEFpanVuIFdhbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuIiBjbGFzcz0iIj53 YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9hPjxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJt YWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbiIgY2xhc3M9IiI+bWFpbHRvOndhbmdhaWp1 bkB0c2luZ2h1YS5vcmcuY248L2E+Jmd0OyZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiB0cmFtIFs8YSBocmVmPSJtYWlsdG86dHJh bS1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mIFBhbDxiciBjbGFzcz0iIj4NCk1hcnRpbnNlbjxiciBjbGFzcz0i Ij4NCihwYWxtYXJ0aSk8YnIgY2xhc3M9IiI+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDEzLCAy MDE1IDQ6MzkgUE08YnIgY2xhc3M9IiI+DQpUbzogQWlqdW4gV2FuZzxiciBjbGFzcz0iIj4NCkNj OnRyYW1APGEgaHJlZj0iaHR0cDovL2lldGYub3JnIiBjbGFzcz0iIj5pZXRmLm9yZzwvYT4gJmx0 OzxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJhbUBpZXRm Lm9yZzwvYT4mZ3Q7OyBCcmFuZG9uIFdpbGxpYW1zPGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6 IFt0cmFtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KZHJhZnQt d2lsbGlhbXMtcGVlci1yZWRpcmVjdC0wMi50eHQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAxMyBK YW4gMjAxNSwgYXQgMDE6NTAsIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlq dW5AdHNpbmdodWEub3JnLmNuIiBjbGFzcz0iIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9h PjxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9y Zy5jbiIgY2xhc3M9IiI+bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248L2E+Jmd0OyZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGksIEJyYW5kb248YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgZm9yIHlvdXIgdml2aWQgZ3JhcGggZm9yIG91 ciBkaXNjdXNzaW9uLiBUd28gcXVlc3Rpb25zIGFyZTxiciBjbGFzcz0iIj4NCnJhaXNlZDxiciBj bGFzcz0iIj4NCmhlcmU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KMS4gSG93IGRvZXMg VFVSTiBzZXJ2ZXIgQSBkZWNpZGUgd2hlbiB0byB1c2UgVURQIHRvIHNlbmQgYXBwPGJyIGNsYXNz PSIiPg0KZGF0YSwgYW5kIHdoZW4gdG8gdXNlIFRVUk4gdG8gc2VuZCBhcHAgZGF0YT8gV2hpY2gg Y3JpdGVyaWEgY2FuPGJyIGNsYXNzPSIiPg0KYXNzaXN0YW50IHRoZSBUVVJOIHNlcnZlciBBIHRv IG1ha2UgdGhpcyBkZWNpc2lvbj88YnIgY2xhc3M9IiI+DQpJbjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAw I3NlY3Rpb24tMTAiIGNsYXNzPSIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdHJhbS10dXJuYmlzLTAwI3NlY3Rpb24tMTA8L2E+LjxiciBjbGFzcz0iIj4NCjIsIGl0IGRl c2NyaWJlcyB0aGUgVFVSTiBzZXJ2ZXIgd2lsbCBzZW5kIFVEUCByYXcgcGFja2V0IHRvIHRoZTxi ciBjbGFzcz0iIj4NCnBlZXIsIHJlZ2FyZGxlc3MgdGhlIHBlZXIgaXMgYXdhcmVuZXNzIG9yIHVu YXdhcmVuZXNzIHRoZTxiciBjbGFzcz0iIj4NCmV4aXN0ZW5jZSBvZiBUVVJOLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRVUk4gc2V2 ZXIgQSBzZW5kcyDigJxhcHAgZGF0YeKAnSB0byBjbGllbnQgQS4gVGhpcyBpcyB0aGUg4oCccHJp dmF0ZeKAnTxiciBjbGFzcz0iIj4NCnNpZGUgb2YgdGhlIFRVUk4gc2VydmVyLiBUVVJOIHNlcnZl ciBBIHNlbmRzIFRVUk4gZW5jYXBzdWxhdGVkPGJyIGNsYXNzPSIiPg0KZGF0YSAoZGF0YSBpbmQg b3I8YnIgY2xhc3M9IiI+DQpjaGFubmVsKSBiYWNrIHRvIGNsaWVudCBBIHVzaW5nIHRoZSBzYW1l IDUgdHVwbGUgY2xpZW50IEEgdXNlZCB0bzxiciBjbGFzcz0iIj4NCnNlbmQgaGlzIGFsbG9jYXRl IHJlcXVlc3QuIFRVUk4gYWxsb3dzIHRoZSBjbGllbnQgdG8gdXNlIFVEUCwgVENQPGJyIGNsYXNz PSIiPg0Kb3IgVExTIHRvIGRvIHRoaXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hh dCBoYXBwZW5zIG9uIHRoZSDigJxwdWJsaWPigJ0gc2lkZSBvZiB0aGUgVFVSTiBzZXJ2ZXIgaXMg YWx3YXlzIFVEUDxiciBjbGFzcz0iIj4NCihVbmxlc3MgdGhlIFRVUk4gc2VydmVyIHN1cHBvcnRz IFRVUk4tVENQIGFuZCB0aGUgY2xpZW50IGhhdmU8YnIgY2xhc3M9IiI+DQphc2tlZCBmb3IgYSBU Q1AgcG9ydCBhbGxvY2F0aW9uKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgcmVt b3RlIHNpZGUgZG8gbm90IG5lZWQgdG8ga25vdyB0aGF0IGl0IGlzIHNlbmRpbmcgcGFja2V0cyB0 bzxiciBjbGFzcz0iIj4NCmEgVFVSTiBzZXJ2ZXIsIGFuZCB0aGF0IHRoZSBwYWNrZXRzIHdvdWxk IOKAnG1hZ2ljYWxseeKAnSBiZSBzZW50IHRvPGJyIGNsYXNzPSIiPg0KdGhlIGNsaWVudCB0aGF0 IGFsbG9jYXRlZCB0aGF0IHBvcnQuIFRoaW5rIG9mIFRVUk4gYXMgYSBtZWNoYW5pc208YnIgY2xh c3M9IiI+DQp0byBtb3ZlIHlvdXIgYm94IG91dCBvbiB0aGUgSW50ZXJuZXQgYW5kIG9idGFpbmlu ZyBwdWJsaWMgcm91dGFibGUgSVAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSBhZ3JlZSB3aXRoIHlvdSBhdCB0aGVzZSBwb2ludHMu IEJ1dCBteSBjb25jZXJuIGZvY3VzIG9uIHRoZTxiciBjbGFzcz0iIj4NCmNvbW11bmljYXRpb24g Y2hhbm5lbCBiZXR3ZWVuIFRVUk4gU2VydmVyIEEvVFVSTiBTZXJ2ZXIgQiBhbmQ8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQpUVVJOPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Qi9QZWVy IEIuIEluIGN1cnJlbnQgVFVSTiBkcmFmdCwgdGhleSBhbGwgdXNlIHRoZSBwdXJlIFVEUCBwYWNr ZXQuPGJyIGNsYXNzPSIiPg0KQnV0IGluIEJyYW5kb27igJlzIGdyYXBoLCB0aGV5IGFyZSBkaWZm ZXJlbnQ6IHRoZSBwcmV2aW91cyBwYWlyIHVzZTxiciBjbGFzcz0iIj4NCnB1cmUgVURQIGRhdGFn cmFtLCBidXQgdGhlIGxhdHRlciBwYWlyIHVzZSBEQVRBIGluZGljYXRpb24sIHdoaWNoPGJyIGNs YXNzPSIiPg0KaXMgbm90IGRlc2NyaWJlZCBpbiBjdXJyZW50IFRVUk4gZHJhZnQsPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVW5sZXNzIEkgYW0gbWlzc2luZyBz b21ldGhpbmcgdGhpcyBpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAxMC4zLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPmFuZCB3aWxsIGxlYWQgdGhlIFRVUk4gc2VydmVyIEEgYmUgY29uZnVzZWQsIGJlY2F1 c2UgaXQgbWlnaHQgZmFjZTxiciBjbGFzcz0iIj4NCnRoZSBUVVJOIFNlcnZlciBCIGFuZCBvdGhl ciBjb21tdW5pY2F0aW9uIHBlZXIsIHN1Y2ggYXMgcGVlciBDIHRoYXQ8YnIgY2xhc3M9IiI+DQpk aXJlY3RseSBjb25uZWN0ZWQgb24gdGhlIFRVUk4gc2VydmVyIEEuICZuYnNwO1doaWNoIGVuY2Fw c3VsYXRpb248YnIgY2xhc3M9IiI+DQptZXRob2Qgd2lsbCBiZSB1c2VkIHRoZW4/PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVURQLiBC dXQgdGhhdCByZXF1aXJlcyBjbGllbnQgYSB0byBzZXQgdGhlIGNvcnJlY3QgcGVybWlzc2lvbnMg dG88YnIgY2xhc3M9IiI+DQphbGxvdyB0cmFmZmljIGZyb20gQyB0byBiZSByZWxheWVkIHRvIEEu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2UgYXJlIGRpc2N1c3Npbmcgbm9ybWFsIFRV Uk4gb3BlcmF0aW9uIGhlcmU/IElmIG5vdCBJIGFwb2xvZ2lzZSBpZjxiciBjbGFzcz0iIj4NCkkg aGF2ZSBtaXNzZWQgc29tZXRoaW5nIGluIHRoZSBkaXNjdXNzaW9uLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCi4tLjxiciBjbGFzcz0iIj4NClDDpWwtRXJpazxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4yLiBJbiB5b3VyIGV4YW1wbGUsIGlmIFRVUk4gQiB1c2UgdGhlIERBVEEgaW5k aWNhdGlvbiB0byBCLCB3aGF0PGJyIGNsYXNzPSIiPg0Kd2lsbCBCIGRvIGlmIGl0IGRvZXMgbm90 IHN1cHBvcnQgdGhlIFRVUk4gZW5jYXBzdWxhdGlvbj88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQpUaGVyZSBpcyBubyB3YXkgYSBUVVJOIHNlcnZlciB3b3VsZCBz ZW5kIGRhdGEgaW5kIHRvIGEgY2xpZW50PGJyIGNsYXNzPSIiPg0Kd2l0aG91dCB0aGUgY2xpZW50 IGhhdmluZyBhbGxvY2F0ZWQgYSBwb3J0LjxiciBjbGFzcz0iIj4NCldpdGhvdXQgY2xpZW50IEIg c2VuZGluZyB0aGUgYWxsb2NhdGUgcmVxdWVzdCB0aGVyZSB3b3VsZCBub3QgYmUgYTxiciBjbGFz cz0iIj4NCmJpbmRpbmcgaW4gdGhlIE5BVCBlaXRoZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KQWN0dWFsbHkgdHJ1ZS4gQnV0IG15 IGNvbmNlcm4gaGVyZSBmb2N1cyBzdGlsbCBvbiB0aGUgZGF0YTxiciBjbGFzcz0iIj4NCmZvcndh cmRpbmcgcGxhbmUsIG5vdCB0aGUgY29udHJvbCBwbGFuZSBvZiBUVVJOIHNvbHV0aW9uLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pi4tLjxiciBjbGFzcz0iIj4NClDDpWwtRXJpazxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkJlc3QgUmVn YXJkcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBj bGFzcz0iIj4NCkZyb206IEJyYW5kb24gV2lsbGlhbXMgWzxhIGhyZWY9Im1haWx0bzpicmFuZG9u LndpbGxpYW1zQGFrYW1haS5jb20iIGNsYXNzPSIiPm1haWx0bzpicmFuZG9uLndpbGxpYW1zQGFr YW1haS5jb208L2E+XTxiciBjbGFzcz0iIj4NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMiwgMjAx NSAxMTo0NSBQTTxiciBjbGFzcz0iIj4NClRvOiBBaWp1biBXYW5nOyA8YSBocmVmPSJtYWlsdG86 dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJhbUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFt0cmFtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3I8YnIgY2xhc3M9IiI+DQpkcmFmdC13aWxsaWFtcy1wZWVyLXJlZGlyZWN0LTAy LnR4dDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClhPUi1QRUVSLUFERFJFU1MgY29udGFp bnMgJnF1b3Q7dGhlIHRyYW5zcG9ydCBhZGRyZXNzIG9mIHRoZSBwZWVyJnF1b3Q7LjxiciBjbGFz cz0iIj4NCkl0IGlzIG5vdCByZXF1aXJlZCB0byBiZSBhIHNwZWNpZmljIHR5cGUgb2YgYWRkcmVz cyAoaG9zdCw8YnIgY2xhc3M9IiI+DQpyZWZsZXhpdmUsIG9yIHJlbGF5KS48YnIgY2xhc3M9IiI+ DQpJdCB3aWxsIGJlIGFueSBhZGRyZXNzIHRoYXQgY2FuIGJlIHVzZWQgdG8gZGVsaXZlciBkYXRh IHRvIHRoZTxiciBjbGFzcz0iIj4NCnJlbW90ZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CnBlZXIuIElmPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ dHdvIFRVUk4gcmVsYXlzIGFyZSB1c2VkLCB0aGVuIHRoZSBYT1ItUEVFUi1BRERSRVNTIGF0dHJp YnV0ZSBpbjxiciBjbGFzcz0iIj4NClNlbmQgYW5kIERhdGEgaW5kaWNhdGlvbnMgd2lsbCBjb250 YWluIHRoZSByZW1vdGUgcGVlcidzPGJyIGNsYXNzPSIiPg0KYWxsb2NhdGVkIHJlbGF5IGFkZHJl c3MuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlcmU8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5pcyBubyBuZWVkIHRoZSBmb3IgZWl0aGVyIG9m IHRoZSByZWxheXMgdG8gZXZlbiBiZSBhd2FyZSB0aGF0PGJyIGNsYXNzPSIiPg0KdGhlPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KdHJhbnNwb3J0PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+YWRkcmVzcyBpcyBhIHJlbGF5IGFkZHJlc3MuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ29uc2lkZXIgdGhlIGZvbGxvd2luZzo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpBICZsdDstJmd0OyBYQSAmbHQ7LSZndDsgVEF8UkEgJmx0Oy0m Z3Q7IFJCfFRCICZsdDstJmd0OyBYQiAmbHQ7LSZndDsgQjxiciBjbGFzcz0iIj4NCnwgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8YnIgY2xhc3M9IiI+DQp8LS0tLSBUVVJO IC0tLS18LS0gVURQIC0tfC0tLS0gVFVSTiAtLS0tfDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkEgYW5kIEIgYXJlIHRoZSB0d28gcGVlcnMnIGhvc3QgYWRkcmVzc2VzLjxiciBjbGFzcz0i Ij4NClhBIGFuZCBYQiBhcmUgdGhlIHR3byBwZWVycycgcmVmbGV4aXZlIGFkZHJlc3Nlcy48YnIg Y2xhc3M9IiI+DQpUQSBhbmQgVEIgYXJlIHRoZSByZWxheSBzZXJ2ZXJzJyBhZGRyZXNzZXMgdXNl ZCBhcyB0aGUgVFVSTjxiciBjbGFzcz0iIj4NCnNlc3Npb24gZW5kcG9pbnRzLjxiciBjbGFzcz0i Ij4NClJBIGFuZCBSQiBhcmUgdGhlIHR3byBwZWVycycgYWxsb2NhdGVkIHJlbGF5IGFkZHJlc3Nl cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIFNlbmQgaW5kaWNhdGlvbiBmcm9tIEEg dG8gVEEgdXNlcyBSQiBhcyB0aGUgWE9SLVBFRVItQUREUkVTUy48YnIgY2xhc3M9IiI+DQpXaGVu IEEncyByZWxheSByZWNlaXZlcyB0aGUgU2VuZCBpbmRpY2F0aW9uLCBpdCBzZW5kcyB0aGUgZGF0 YTxiciBjbGFzcz0iIj4NCmluIGEgcGxhaW4gVURQPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KZGF0YWdyYW08YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij53aXRoIFJBIGFzIHRoZSBzb3VyY2UgYW5kIFJCIGFzIHRoZSBkZXN0aW5hdGlvbi4gV2hlbiBC J3MgcmVsYXk8YnIgY2xhc3M9IiI+DQpyZWNlaXZlczxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCnRoZTxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlVE UCBkYXRhZ3JhbSwgaXQgc2VuZHMgYSBEYXRhIGluZGljYXRpb24gZnJvbSBUQiB0byBCIHdpdGgg UkEgYXM8YnIgY2xhc3M9IiI+DQp0aGUgWE9SLVBFRVItQUREUkVTUy48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQotLUJyYW5kb248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAw MS8xMS8yMDE1IDA3OjQzIFBNLCBBaWp1biBXYW5nIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhpLCBCcmFuZG9uOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkluPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbi0xMCIgY2xhc3M9IiI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2Vj dGlvbi0xMDwvYT4uPGJyIGNsYXNzPSIiPg0KMSw8YnIgY2xhc3M9IiI+DQppdCBpcyBkZXNjcmli ZWQgYXMgYmVsb3c6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hlbiBmb3JtaW5nIGEg U2VuZCBpbmRpY2F0aW9uLCB0aGUgY2xpZW50IE1VU1QgaW5jbHVkZSBhbjxiciBjbGFzcz0iIj4N ClhPUi1QRUVSLSAmbmJzcDtBRERSRVNTIGF0dHJpYnV0ZSBhbmQgYSBEQVRBIGF0dHJpYnV0ZS4g Jm5ic3A7VGhlPGJyIGNsYXNzPSIiPg0KWE9SLVBFRVItQUREUkVTUyAmbmJzcDthdHRyaWJ1dGUg Y29udGFpbnMgdGhlIHRyYW5zcG9ydCBhZGRyZXNzIG9mPGJyIGNsYXNzPSIiPg0KdGhlIHBlZXIg dG8gd2hpY2ggdGhlICZuYnNwO2RhdGEgaXMgdG8gYmUgc2VudCwgYW5kIHRoZSBEQVRBPGJyIGNs YXNzPSIiPg0KYXR0cmlidXRlIGNvbnRhaW5zIHRoZSBhY3R1YWwgJm5ic3A7YXBwbGljYXRpb24g ZGF0YSB0byBiZSBzZW50IHRvIHRoZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCnBlZXIuPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQpTbywgdGhlcmUgaXMgbm8gWE9SLVJFTEFZRUQtQUREUkVTUyBhdHRyaWJ1 dGUgaW5jbHVkZWQgdG88YnIgY2xhc3M9IiI+DQppZGVudGlmeSB0aGUgcGVlcidzIGFsbG9jYXRl ZCByZWxheSBhZGRyZXNzLiBPbiB0aGUgb3RoZXIgaGFuZCw8YnIgY2xhc3M9IiI+DQpYT1ItUkVM QVlFRC1BRERSRVNTIGlzIG1haW5seSByZWZlciB0byB0aGUgcmVxdWVzdGVyJ3M8YnIgY2xhc3M9 IiI+DQphbGxvY2F0ZWQgcmVsYXkgYWRkcmVzcywgbm90IHRoZSBjb3JyZXNwb25kaW5nIHBlZXIu IFdpbGwgd2U8YnIgY2xhc3M9IiI+DQpkZWZpbmUgYWdhaW4gb25lIG5ldyBhdHRyaWJ1dGUsIHN1 Y2ggYXM8YnIgY2xhc3M9IiI+DQpYT1ItUEVFUi1SRUxBWUVELUFERFJFU1MgdG8gdHJhbnNmZXIg dGhlIG5leHQgVFVSTiBzZXJ2ZXInczxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmluZm9y bWF0aW9uPzxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCkV2ZW4gaWYgc28sIHdoYXQgd2lsbCBiZSB0aGUgc291cmNlIGFkZHJlc3Mg Zm9yIHRoZSBwYWNrZXQgZnJvbTxiciBjbGFzcz0iIj4NCnRoZSBzZWNvbmQgVFVSTiBzZXJ2ZXIg dG8gZGVzdGluYXRpb24gcGVlcj8gSWYgd2UgdXNlIHRoZTxiciBjbGFzcz0iIj4NClhPUi1SRUxB WUVELUFERFJFU1MsIHRoZW4gdGhlIHJldHVybiBwYWNrZXQgZnJvbSB0aGUgcGVlciB3aWxsPGJy IGNsYXNzPSIiPg0KYmUgcGFzc2VkIGJhY2sgZGlyZWN0bHkgdG8gdGhlIGZpcnN0IFRVUk4gc2Vy dmVyLCByZXN1bHRzIGluPGJyIGNsYXNzPSIiPg0Kbm9uLXN5bW1ldHJpYyByb3V0ZS4gSWYgd2Ug dXNlIFhPUi1QRUVSLVJFTEFZRUQtQUREUkVTUywgdGhlbjxiciBjbGFzcz0iIj4NCndoYXQgaXMg dGhlIHNvdXJjZSBhZGRyZXNzIGZvciB0aGUgcGFja2V0IGZyb20gdGhlIHNlY29uZCBUVVJOPGJy IGNsYXNzPSIiPg0Kc2VydmVyIGJhY2sgdG88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQp0aGU8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj5maXJzdCBUVVJOIHNlcnZlcj88YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpCZXN0IFJlZ2FyZHMuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiBCcmFuZG9uIFdpbGxpYW1z IFs8YSBocmVmPSJtYWlsdG86Ym93aWxsQGFrYW1haS5jb20iIGNsYXNzPSIiPm1haWx0bzpib3dp bGxAYWthbWFpLmNvbTwvYT5dPGJyIGNsYXNzPSIiPg0KU2VudDogU2F0dXJkYXksIEphbnVhcnkg MTAsIDIwMTUgMTowOSBBTTxiciBjbGFzcz0iIj4NClRvOiBBaWp1biBXYW5nOyA8YSBocmVmPSJt YWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwvYT4gJmx0OzxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJhbUBpZXRmLm9yZzwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFt0cmFtXSBGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3I8YnIgY2xhc3M9IiI+DQpkcmFmdC13aWxsaWFtcy1wZWVyLXJlZGly ZWN0LTAyLnR4dDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJ5IHJlbGF5IGFkZHJlc3Ms IEkgbWVhbiB0aGUgWE9SLVJFTEFZRUQtQUREUkVTUyByZXR1cm5lZCBpbjxiciBjbGFzcz0iIj4N CnRoZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmFsbG9jYXRpb248YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5yZXF1ZXN0LiBUaGlzIGNsZWFybHkg aWRlbnRpZmllcyB0aGUgdHJ1ZSBzb3VyY2UgYW5kPGJyIGNsYXNzPSIiPg0KZGVzdGluYXRpb24g Zm9yIHRoZTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmRhdGEgaW48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj50aGUgcGFja2V0IGFzIHdlbGwgYXMg dGhlIHR3byByZWxheSBzZXJ2ZXJzIGludm9sdmVkLiBJZiBib3RoPGJyIGNsYXNzPSIiPg0KcmVs YXllZDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCmFkZHJlc3NlczxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmFyZSBvbiB0aGUgc2FtZSBzZXJ2ZXIs IGl0IHdpbGwgb2YgY291cnNlIGtub3cgdGhhdCBhbmQgYmU8YnIgY2xhc3M9IiI+DQphYmxlIHRv PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0Kb3B0aW1pemUgYXM8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5TaW1vbiBpbmRpY2F0ZWQgaW4gYW4gZWFy bGllciBlLW1haWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS1CcmFuZG9uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMDEvMDgvMjAxNSAwOTo0MCBQTSwgQWlqdW4gV2Fu ZyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQpbQWlqdW5dOiBUaGVyZSBhcmUgdHdvIHJlbGF5IGFkZHJlc3MsIG9uZSBp cyB0aGUgVFVSTiBzZXJ2ZXI8YnIgY2xhc3M9IiI+DQp3ZWxsLWtub3duIGFkZHJlc3MsIGFub3Ro ZXIgaXMgdGhlIHJlbGF5IGFkZHJlc3MgdGhhdDxiciBjbGFzcz0iIj4NCmFsbG9jYXRlZCB0byBl YWNoIGNsaWVudC4gV2hpY2ggb25lIHNob3VsZCBiZSB1c2VkIHRoZW4/IE9uPGJyIGNsYXNzPSIi Pg0KdGhlIG90aGVyIGhhbmQsIHdoZW4gY2xpZW50IHdhbnQgdG8gc2VuZCB0cmFmZmljIHRvIG90 aGVyPGJyIGNsYXNzPSIiPg0KcGVlciwgaXQgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoZSBvdGhl ciBwYXJ0IGlzIHVuZGVyIHRoZTxiciBjbGFzcz0iIj4NCnNhbWUgVFVSTiBzZXJ2ZXIgb3Igbm90 LCBob3cgZG8gaXQgc2VsZWN0PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KdGhpczxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PmluZm9ybWF0aW9uPzxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCltBaWp1bl06IGFzIHRoZSBk ZWZpbml0aW9uIGluPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbiIgY2xhc3M9IiI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDAjc2VjdGlvbjwv YT48YnIgY2xhc3M9IiI+DQotMTxiciBjbGFzcz0iIj4NCjQuMyAsIHRoZSBYT1ItUEVFUi1BRERS RVNTIGlzIHRoZSBhZGRyZXNzIHNlZW4gZnJvbSB0aGUgVFVSTjxiciBjbGFzcz0iIj4NCnNlcnZl ciwgc28gaXQgY2FuJ3QgYmUgdXNlZCB0byBmaW5kIHRoZSByZWxheSBhZGRyZXNzIG9mIHRoZTxi ciBjbGFzcz0iIj4NCnJlbW90ZSBwZWVyLCBhbmQgdGhlbiBjYW4ndCBiZSB1c2VkIHRvIGRpcmVj dCB0cmFmZmljIHRvPGJyIGNsYXNzPSIiPg0KZG93bnN0cmVhbSByZWxheS48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQotLTxiciBjbGFzcz0iIj4NCkJyYW5kb24gV2lsbGlhbXM7IFNl bmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmc8YnIgY2xhc3M9IiI+DQpQ cm9kdWN0cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQpCcmFu ZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5n PGJyIGNsYXNzPSIiPg0KUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMg SW5jLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86dHJh bUBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQp0cmFtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzp0cmFtQGlldGYu b3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW0iIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbTwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnRyYW0gbWFpbGluZyBs aXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIi PnRyYW1AaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xh c3M9IiI+bWFpbHRvOnRyYW1AaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0i Ij4NCi0tPGJyIGNsYXNzPSIiPg0KQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBT b2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZzxiciBjbGFzcz0iIj4NClByb2R1Y3RzIEVuZ2luZWVy aW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnRyYW0g bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmci IGNsYXNzPSIiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQp0cmFtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj50cmFtDQogbWFpbGlu ZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJhbSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_37A39641BA2A439C9602035250015DB5ciscocom_-- From nobody Wed Jan 14 02:50:43 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5D1ACE4C for ; Wed, 14 Jan 2015 02:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tzIS1nz8qS97 for ; Wed, 14 Jan 2015 02:50:32 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596191ACE44 for ; Wed, 14 Jan 2015 02:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33084; q=dns/txt; s=iport; t=1421232632; x=1422442232; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bvqV1LPWk2jHymgRcXshStJFtsfdXIMcWL1EcX1VWwU=; b=Hy/EAYBUBZJydB9K9gXrNNHhQCC15wVeAVjhhB0z6akMvomM6A6cscTx 1whsPvp3pc53T00WfFHe1ENm921Lqs7WfITwrCUOijjMBdCwRBDInCuwm whGEHry9d0mBV3JdywT6tko9U2wd1MLyRFFR1zIpBSC04Lxu6uJuNBeDF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUIAIhItlStJV2P/2dsb2JhbABbgkNDUlgEgwHCdwEJhXECHHhDAQEBAQF9hAwBAQEEAQEBIEsbAgEIEQQBASEHAwICAh8GCxQJCAEBBBOIGAMRDbwHkC4Ng2MBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1PgiYKAQaCYi6BEwWEOwKKBYdJgUSBD4sJgieDPSKDbm+BAyQefgEBAQ X-IronPort-AV: E=Sophos;i="5.07,755,1413244800"; d="scan'208,217";a="113147032" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 14 Jan 2015 10:50:31 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0EAoVLO026491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 Jan 2015 10:50:31 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 04:50:31 -0600 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: [tram] SSODA in TURN-bis Thread-Index: AdAuJda+xEi4Jbc7TpCKn/lLZn1lewB9F2kA Date: Wed, 14 Jan 2015 10:50:30 +0000 Message-ID: <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.219] Content-Type: multipart/alternative; boundary="_000_7F1866120FE74B5EB132903B6B38302Fciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 10:50:39 -0000 --_000_7F1866120FE74B5EB132903B6B38302Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG8gbm90IHNlZSBhIHByb2JsZW0gd2l0aCBhIFRVUk4gc2VydmVyIHJldHVybmlu ZyBhIDQwMCBlcnJvciBjb2RlIGlmIGl0IGdldHMgY29uZnVzZWQgYnkgdHdvIFJBRnMuDQpUaGlz IGlzIGFsbW9zdCBjb3ZlcmVkIGluIHNlY3Rpb24gMi40IG9mIHRoZSBTU09EQSBkcmFmdC4gQ2xp ZW50IGZhbGxiYWNrIHRvIG5vbi1TU09EQSBtb2RlIHdoZW4gZW5jb3VudGVyaW5nIGFuIGVycm9y IHNlZW1zIHRyaXZpYWwuDQooVW5sZXNzIHRoZSBUVVJOIHNlcnZlciBlbmRzIHVwIHVzaW5nIHRv IG11Y2ggQ1BVLCBvdmVyaGVhdHMsIGFuZCBjYXVzZXMgYSBmaXJlIGluIHRoZSBkYXRhY2VudGVy KQ0KDQpCdXQgSSBtaWdodCBsaWtlIGMpIGJldHRlciBhbnl3YXkuIEFkZGluZyBhIG5ldyBhdHRy aWJ1dGUgc2VlbXMgY2xlYW5lciB3aGVuIGFkZGluZyBuZXcgZnVuY3Rpb25hbGl0eS4NCg0KLi0u DQpQw6VsLUVyaWsNCg0KT24gMTIgSmFuIDIwMTUsIGF0IDA2OjA4LCBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+ PiB3cm90ZToNCg0KQUREUkVTUy1FUlJPUi1DT0RFIHNlZW1zIHVzZWZ1bCwgY2xpZW50IGNhbiBk ZXRlcm1pbmUgaWYgaXTigJlzIGEgdGVtcG9yYXJ5IG9yIGxvbmctdGVybSBlcnJvci4NCg0KLVRp cnUNCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NClNl bnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEwLCAyMDE1IDI6MTkgQU0NClRvOiBPbGVnIE1vc2thbGVu a28NCkNjOiBTaW1vbiBQZXJyZWF1bHQ7IEFpanVuIFdhbmc7IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3RyYW1dIFNTT0RBIGluIFRVUk4tYmlzDQoNCk9LLCBzbyB3ZSBoYXZlIGNsZWFyIGV2aWRl bmNlIHRoYXQgc29tZSBkZXBsb3llZCBzZXJ2ZXJzIHdpbGwgZmFpbCAoZGV0ZXJtaW5pc3RpY2Fs bHksIGZvcnR1bmF0ZWx5KSBvbiB0aGUgY3VycmVudCBTU09EQSBwcm9wb3NhbC4NCg0KU28gd2Un cmUgYmFjayB0byB3aGljaCBiYWNrd2FyZHMtY29tcGF0aWJsZSBvcHRpb24gd2Ugd2FudCB0byBw dXJzdWUuIEkgc3VnZ2VzdCBjKSwgd2hpY2ggaXMgdGhlIG9wdGlvbmFsLWNvbXByZWhlbnNpb24g QURESVRJT05BTC1BRERSRVNTLUZBTUlMWS4NCg0KU2VwYXJhdGVseSwgd2UgbmVlZCB0byBkZWNp ZGUgd2hldGhlciB3ZSB3YW50IHRvIHB1cnN1ZSBpc3N1ZSAjMiB0aGF0IEkgaWRlbnRpZmllZCBw cmV2aW91c2x5LCBpLmUuLCBhbGxvd2luZyBzcGVjaWZpYyBlcnJvciBjb2RlcyB0byBiZSByZXR1 cm5lZCBmb3IgZWFjaCBhZGRyZXNzIGZhbWlseS4NCg0KT24gRnJpLCBKYW4gOSwgMjAxNSBhdCAx MDo1MyBBTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20w NDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpJIGRvdWJsZS1jaGVja2VkIHRoYXQgd2l0aCBhIHJl YWwgdGVzdC4gSSByYW4gdGhlIGNvVHVybiB0ZXN0IGNsaWVudCAodGhhdCBpbXBsZW1lbnRzIGV4 cGVyaW1lbnRhbCBTU09EQSBkcmFmdCB3aXRoIHR3byBSQUYgYXR0cmlidXRlcykgYWdhaW5zdCBy ZmM1NzY2LXR1cm4tc2VydmVyIGFuZCB0aGUgc2VydmVyIHlpZWxkZWQgZXJyb3IgNDAwIHdpdGgg dGhlIG1lc3NhZ2UgIk9ubHkgb25lIGFkZHJlc3MgZmFtaWx5IGF0dHJpYnV0ZSBjYW4gYmUgdXNl ZCBpbiBhIHJlcXVlc3QiDQoNCjooDQpBcyBJIHNhaWQsIEkgY2FuIGVsaW1pbmF0ZSB0aGF0IHBy b2JsZW0gaW4gdGhlIHN1YnNlcXVlbnQgcmZjNTc2Ni10dXJuLXNlcnZlciBtYWludGVuYW5jZSBy ZWxlYXNlcywgYnV0IHN0aWxsLi4uDQpJIGFtIHNvcnJ5IHRoYXQgSSBkaWQgbm90IGRpc2NvdmVy IHRoYXQgcHJldmlvdXNseSBhbmQgdGhhdCBJIGFkdm9jYXRlZCBhbiBpbmNvbXBhdGlibGUgaW1w bGVtZW50YXRpb24gb3B0aW9uLg0KU28sIGlmIHRoZSBXRyBpbnNpc3RzIG9uIGEgYmFja3dhcmQt Y29tcGF0aWJsZSBwcm90b2NvbCBpbiBhbGwgc2Vuc2VzLCB0aGVuIHdlIGhhdmUgdG8gY2hvb3Nl IGFub3RoZXIgb3B0aW9uLg0KVGhhbmtzDQpPbGVnDQoNCg0KT24gRnJpLCBKYW4gOSwgMjAxNSBh dCAxMDowMSBBTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzpt b20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpJIGNoZWNrZWQgdGhlIGNvZGUgb2YgcmZjNTc2 Ni10dXJuLXNlcnZlciBhZ2FpbiwgYW5kIEkgZm91bmQgdGhhdCBpdCB3aWxsIE5PVCBoYW5kbGUg dGhlIG11bHRpcGxlLVJBRiBjYXNlLiBJdCB3aWxsIHJldHVybiA0MDAgZXJyb3Igd2l0aCB0aGUg bWVzc2FnZSAiT25seSBvbmUgYWRkcmVzcyBmYW1pbHkgYXR0cmlidXRlIGNhbiBiZSB1c2VkIGlu IGEgcmVxdWVzdCIuIEF0IGxlYXN0LCBpdCdzIGJlZW4gdGhhdCB3YXkgaW4gdGhlIDIwMTQgcmVs ZWFzZXMuIEkgZGlkIG5vdCBjaGVjayB0aGUgb2xkZXIgcmVsZWFzZXMuDQpTb3JyeSB0aGF0IEkg cHJvdmlkZWQgYSB3cm9uZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW1wbGVtZW50YXRpb24sIGJl Zm9yZS4NCkkgY2FuIGZpeCB0aGF0IGNvZGUgYnV0IHN0aWxsIHRoZXJlIGFyZSBwZW9wbGUgb3V0 IHRoZXJlIHdobyB3aWxsIGJlIHVzaW5nIHRoZSAid3JvbmciIHZlcnNpb25zLg0KU28sIGlmIHdl IGRvIGhhdmUgdG8gYmUgYWJzb2x1dGVseSBiYWNrd2FyZCBjb21wYXRpYmxlIHRoZW4gd2UgaGF2 ZSB0byB1c2UgYSBkaWZmZXJlbnQgb3B0aW9uLi4uDQpPbGVnDQoNCg0KT24gRnJpLCBKYW4gOSwg MjAxNSBhdCA5OjM0IEFNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRv Omp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KSSByZXZpZXdlZCB0aGUgY29kZSBmb3IgcmVz dHVuZCwgcmVUdXJuLCBhbmQgcmZjNTc2Ni10dXJuLXNlcnZlciBhbmQgdGhleSBhbGwgYXBwZWFy IHRvIGhhbmRsZSBSQUYgKGFuZCBtdWx0aXBsZSBSQUYpIE9LLg0KDQpUaGUgcHJvYmxlbSwgYXMg SSBzZWUgaXQsIGlzIHRoYXQgdGhlcmUgbWF5IGJlIG90aGVyIFRVUk4gc2VydmVycywgcGVyaGFw cyBub24tb3Blbi1zb3VyY2Ugb25lcywgdGhhdCB3b3JrIGZpbmUgdG9kYXkgd2l0aCBDaHJvbWUs IGJ1dCB3aWxsIHN0YXJ0IHJldHVybmluZyBlcnJvcnMgd2hlbiB3ZSBpbmNsdWRlIFJBRiBvciBt dWx0aXBsZSBSQUYsIGFuZCBzbyBtYWtpbmcgdGhpcyBjaGFuZ2UgbWF5IGJyZWFrIHNvbWUgc21h bGwgbnVtYmVyIG9mIGFwcHMgKHdobyB3aWxsIHRoZW4gYmxhbWUgQ2hyb21lKS4gV2UganVzdCBk b24ndCBrbm93IHdoYXQgaXMgb3V0IHRoZXJlLg0KDQoNCg0KT24gRnJpLCBKYW4gOSwgMjAxNSBh dCA2OjExIEFNLCBTaW1vbiBQZXJyZWF1bHQgPHNwZXJyZWF1bHRAaml2ZS5jb208bWFpbHRvOnNw ZXJyZWF1bHRAaml2ZS5jb20+PiB3cm90ZToNCg0KT24gRnJpLCBKYW4gOSwgMjAxNSBhdCA0OjE3 IEFNLCBBaWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPG1haWx0bzp3YW5nYWlq dW5AdHNpbmdodWEub3JnLmNuPj4gd3JvdGU6DQpBZnRlciB5b3VyIGRldGFpbCBhbmFseXNpcyBh bmQgdGhlIHNlbnRlbmNlIOKAnEZvciBlaXRoZXIgYi9jLCB3ZSB3b3VsZCBuZWVkIHRvIHNheSB0 aGF0IGluY2x1ZGluZyBib3RoIFJBRiBhbmQgT0FGL0FBRiBmb3IgdGhlIHNhbWUgYWRkcmVzcyBm YW1pbHkgaXMgcHJvaGliaXRlZC7igJ0sIEkgdGhpbmsgaXQgbWF5IGJlIGJldHRlciB0byBrZWVw IG9ubHkgb25lIGF0dHJpYnV0ZSB0byBmdWxmaWxsIHRoZSBTU09EQSByZXF1aXJlbWVudD8NCg0K VGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCBTU09EQSBmdW5jdGlvbmFsaXR5IGJlIHJlYWxp emVkIHdpdGggb25seSBvbmUgYXR0cmlidXRlLCBub3IgdGhhdCB0aGUgcHJvdG9jb2wgYmUgZWxl Z2FudCwgbm9yIHRoYXQgaXQgZXhoaWJpdHMgc3ltbWV0cnkgdGhhdCBpcyBwbGVhc2luZyB0byB0 aGUgZXllLg0KDQpUaGVyZSAqaXMqIGEgcmVxdWlyZW1lbnQgdGhhdCBpdCBiZSBiYWNrd2FyZHMt Y29tcGF0aWJsZSB0aG91Z2guIFdoZXRoZXIgdGhhdCBtZWFucyBjb21wYXRpYmxlIHdpdGggdGhl IHNwZWMgb3IgY29tcGF0aWJsZSB3aXRoIGFjdHVhbCBpbXBsZW1lbnRhdGlvbnMgaXMgYSBtYXR0 ZXIgb2YgZGViYXRlLg0KDQpKdXN0aW4sIGlmIHdlIGNhbid0IGZpbmQgYSBzaW5nbGUgaW1wbGVt ZW50YXRpb24gdGhhdCB3b3VsZCBiYXJmLCB3aHkgd291bGQgQ2hyb21lIGhhdmUgdG8gaW1wbGVt ZW50IGEgY29tcGxleCBmYWxsYmFjayBtZWNoYW5pc20/DQoNClNpbW9uDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0 DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8 bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW0NCg0K --_000_7F1866120FE74B5EB132903B6B38302Fciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <14DBC566701DDF479E01218A21D83328@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGRvIG5vdCBzZWUgYSBwcm9ibGVt IHdpdGggYSBUVVJOIHNlcnZlciByZXR1cm5pbmcgYSA0MDAgZXJyb3IgY29kZSBpZiBpdCBnZXRz IGNvbmZ1c2VkIGJ5IHR3byBSQUZzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlzIGFsbW9z dCBjb3ZlcmVkIGluIHNlY3Rpb24gMi40IG9mIHRoZSBTU09EQSBkcmFmdC4gQ2xpZW50IGZhbGxi YWNrIHRvIG5vbi1TU09EQSBtb2RlIHdoZW4gZW5jb3VudGVyaW5nIGFuIGVycm9yIHNlZW1zIHRy aXZpYWwuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPihVbmxlc3MgdGhlIFRVUk4gc2VydmVy IGVuZHMgdXAgdXNpbmcgdG8gbXVjaCBDUFUsIG92ZXJoZWF0cywgYW5kIGNhdXNlcyBhIGZpcmUg aW4gdGhlIGRhdGFjZW50ZXIpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5CdXQgSSBtaWdodCBsaWtlIGMpIGJldHRlciBhbnl3YXkuIEFk ZGluZyBhIG5ldyBhdHRyaWJ1dGUgc2VlbXMgY2xlYW5lciB3aGVuIGFkZGluZyBuZXcgZnVuY3Rp b25hbGl0eS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPi4tLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Qw6VsLUVyaWs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxMiBKYW4gMjAxNSwgYXQgMDY6MDgsIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNv bSIgY2xhc3M9IiI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+QUREUkVT Uy1FUlJPUi1DT0RFIHNlZW1zIHVzZWZ1bCwgY2xpZW50IGNhbiBkZXRlcm1pbmUgaWYgaXTigJlz IGEgdGVtcG9yYXJ5IG9yIGxvbmctdGVybSBlcnJvci48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+LVRpcnU8bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVy LXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5Niwg MjIzKTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5KdXN0aW4g VWJlcnRpIFs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86anVi ZXJ0aUBnb29nbGUuY29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNhdHVyZGF5LCBKYW51YXJ5 IDEwLCAyMDE1IDI6MTkgQU08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk9sZWcgTW9za2FsZW5r bzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U2ltb24gUGVycmVhdWx0OyBBaWp1biBXYW5nOyBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+dHJh bUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFt0cmFtXSBT U09EQSBpbiBUVVJOLWJpczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9LLCBzbyB3ZSBoYXZlIGNsZWFyIGV2aWRlbmNl IHRoYXQgc29tZSBkZXBsb3llZCBzZXJ2ZXJzIHdpbGwgZmFpbCAoZGV0ZXJtaW5pc3RpY2FsbHks IGZvcnR1bmF0ZWx5KSBvbiB0aGUgY3VycmVudCBTU09EQSBwcm9wb3NhbC48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NClNvIHdlJ3JlIGJhY2sgdG8gd2hpY2ggYmFja3dhcmRzLWNvbXBhdGli bGUgb3B0aW9uIHdlIHdhbnQgdG8gcHVyc3VlLiBJIHN1Z2dlc3QgYyksIHdoaWNoIGlzIHRoZSBv cHRpb25hbC1jb21wcmVoZW5zaW9uIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkuPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClNlcGFyYXRlbHksIHdlIG5lZWQgdG8gZGVjaWRl IHdoZXRoZXIgd2Ugd2FudCB0byBwdXJzdWUgaXNzdWUgIzIgdGhhdCBJIGlkZW50aWZpZWQgcHJl dmlvdXNseSwgaS5lLiwgYWxsb3dpbmcgc3BlY2lmaWMgZXJyb3IgY29kZXMgdG8gYmUgcmV0dXJu ZWQgZm9yIGVhY2ggYWRkcmVzcyBmYW1pbHkuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgSmFuIDksIDIw MTUgYXQgMTA6NTMgQU0sIE9sZWcgTW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0 MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tb20wNDAyNjdAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CkkgZG91YmxlLWNoZWNrZWQgdGhhdCB3aXRoIGEgcmVhbCB0ZXN0LiBJIHJhbiB0aGUgY29UdXJu IHRlc3QgY2xpZW50ICh0aGF0IGltcGxlbWVudHMgZXhwZXJpbWVudGFsIFNTT0RBIGRyYWZ0IHdp dGggdHdvIFJBRiBhdHRyaWJ1dGVzKSBhZ2FpbnN0IHJmYzU3NjYtdHVybi1zZXJ2ZXIgYW5kIHRo ZSBzZXJ2ZXIgeWllbGRlZCBlcnJvciA0MDAgd2l0aCB0aGUgbWVzc2FnZSAmcXVvdDtPbmx5IG9u ZSBhZGRyZXNzIGZhbWlseSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQNCiBpbiBhIHJlcXVlc3QmcXVv dDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo6KDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEy cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiPg0KQXMgSSBzYWlkLCBJIGNhbiBlbGltaW5hdGUgdGhhdCBwcm9ibGVtIGluIHRoZSBzdWJz ZXF1ZW50IHJmYzU3NjYtdHVybi1zZXJ2ZXIgbWFpbnRlbmFuY2UgcmVsZWFzZXMsIGJ1dCBzdGls bC4uLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KSSBhbSBzb3JyeSB0aGF0IEkgZGlkIG5v dCBkaXNjb3ZlciB0aGF0IHByZXZpb3VzbHkgYW5kIHRoYXQgSSBhZHZvY2F0ZWQgYW4gaW5jb21w YXRpYmxlIGltcGxlbWVudGF0aW9uIG9wdGlvbi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N ClNvLCBpZiB0aGUgV0cgaW5zaXN0cyBvbiBhIGJhY2t3YXJkLWNvbXBhdGlibGUgcHJvdG9jb2wg aW4gYWxsIHNlbnNlcywgdGhlbiB3ZSBoYXZlIHRvIGNob29zZSBhbm90aGVyIG9wdGlvbi48bzpw IGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NClRoYW5rczxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEz NiwgMTM2LCAxMzYpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KT2xlZzxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IHJnYigxMzYsIDEzNiwgMTM2KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgMTA6 MDEgQU0sIE9sZWcgTW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tb20wNDAyNjdAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CkkgY2hlY2tlZCB0aGUgY29kZSBvZiByZmM1NzY2LXR1cm4tc2VydmVyIGFnYWluLCBhbmQgSSBm b3VuZCB0aGF0IGl0IHdpbGwgTk9UIGhhbmRsZSB0aGUgbXVsdGlwbGUtUkFGIGNhc2UuIEl0IHdp bGwgcmV0dXJuIDQwMCBlcnJvciB3aXRoIHRoZSBtZXNzYWdlICZxdW90O09ubHkgb25lIGFkZHJl c3MgZmFtaWx5IGF0dHJpYnV0ZSBjYW4gYmUgdXNlZCBpbiBhIHJlcXVlc3QmcXVvdDsuIEF0IGxl YXN0LCBpdCdzIGJlZW4gdGhhdCB3YXkgaW4gdGhlIDIwMTQgcmVsZWFzZXMuDQogSSBkaWQgbm90 IGNoZWNrIHRoZSBvbGRlciByZWxlYXNlcy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyI+DQpTb3JyeSB0aGF0IEkgcHJvdmlkZWQgYSB3cm9uZyBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgaW1wbGVtZW50YXRpb24sIGJlZm9yZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyI+DQpJIGNhbiBmaXggdGhhdCBjb2RlIGJ1dCBzdGlsbCB0aGVyZSBh cmUgcGVvcGxlIG91dCB0aGVyZSB3aG8gd2lsbCBiZSB1c2luZyB0aGUgJnF1b3Q7d3JvbmcmcXVv dDsgdmVyc2lvbnMuPG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0K U28sIGlmIHdlIGRvIGhhdmUgdG8gYmUgYWJzb2x1dGVseSBiYWNrd2FyZCBjb21wYXRpYmxlIHRo ZW4gd2UgaGF2ZSB0byB1c2UgYSBkaWZmZXJlbnQgb3B0aW9uLi4uPG86cCBjbGFzcz0iIj48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTM2LCAxMzYs IDEzNik7IiBjbGFzcz0iIj5PbGVnPGJyIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgOTozNCBBTSwgSnVzdGluIFViZXJ0aSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmp1YmVy dGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25l IG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRl ci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDZwdDsgbWFyZ2luOiA1cHQg MGluIDVwdCA0LjhwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCkkgcmV2aWV3ZWQgdGhlIGNvZGUgZm9yIHJlc3R1bmQsIHJlVHVybiwgYW5kIHJm YzU3NjYtdHVybi1zZXJ2ZXIgYW5kIHRoZXkgYWxsIGFwcGVhciB0byBoYW5kbGUgUkFGIChhbmQg bXVsdGlwbGUgUkFGKSBPSy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRoZSBwcm9ibGVt LCBhcyBJIHNlZSBpdCwgaXMgdGhhdCB0aGVyZSBtYXkgYmUgb3RoZXIgVFVSTiBzZXJ2ZXJzLCBw ZXJoYXBzIG5vbi1vcGVuLXNvdXJjZSBvbmVzLCB0aGF0IHdvcmsgZmluZSB0b2RheSB3aXRoIENo cm9tZSwgYnV0IHdpbGwgc3RhcnQgcmV0dXJuaW5nIGVycm9ycyB3aGVuIHdlIGluY2x1ZGUgUkFG IG9yIG11bHRpcGxlIFJBRiwgYW5kIHNvIG1ha2luZyB0aGlzIGNoYW5nZSBtYXkgYnJlYWsgc29t ZSBzbWFsbCBudW1iZXIgb2YNCiBhcHBzICh3aG8gd2lsbCB0aGVuIGJsYW1lIENocm9tZSkuIFdl IGp1c3QgZG9uJ3Qga25vdyB3aGF0IGlzIG91dCB0aGVyZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gRnJpLCBKYW4gOSwgMjAxNSBhdCA2 OjExIEFNLCBTaW1vbiBQZXJyZWF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVycmVhdWx0QGpp dmUuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c3BlcnJlYXVsdEBqaXZlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiBGcmksIEphbiA5LCAy MDE1IGF0IDQ6MTcgQU0sIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlqdW5A dHNpbmdodWEub3JnLmNuIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+d2FuZ2FpanVuQHRzaW5naHVhLm9y Zy5jbjwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQWZ0ZXIgeW91ciBkZXRhaWwg YW5hbHlzaXMgYW5kIHRoZSBzZW50ZW5jZSDigJxGb3IgZWl0aGVyIGIvYywgd2Ugd291bGQgbmVl ZCB0byBzYXkgdGhhdCBpbmNsdWRpbmcgYm90aCBSQUYgYW5kIE9BRi9BQUYgZm9yIHRoZSBzYW1l IGFkZHJlc3MgZmFtaWx5IGlzIHByb2hpYml0ZWQu4oCdLCBJIHRoaW5rIGl0IG1heSBiZSBiZXR0 ZXIgdG8ga2VlcCBvbmx5IG9uZSBhdHRyaWJ1dGUgdG8gZnVsZmlsbCB0aGUgU1NPREEgcmVxdWly ZW1lbnQ/ICZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IFNTT0RBIGZ1bmN0aW9uYWxpdHkgYmUgcmVhbGl6 ZWQgd2l0aCBvbmx5IG9uZSBhdHRyaWJ1dGUsIG5vciB0aGF0IHRoZSBwcm90b2NvbCBiZSBlbGVn YW50LCBub3IgdGhhdCBpdCBleGhpYml0cyBzeW1tZXRyeSB0aGF0IGlzIHBsZWFzaW5nIHRvIHRo ZSBleWUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRoZXJlICppcyogYSBy ZXF1aXJlbWVudCB0aGF0IGl0IGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHRob3VnaC4gV2hldGhl ciB0aGF0IG1lYW5zIGNvbXBhdGlibGUgd2l0aCB0aGUgc3BlYyBvciBjb21wYXRpYmxlIHdpdGgg YWN0dWFsIGltcGxlbWVudGF0aW9ucyBpcyBhIG1hdHRlciBvZiBkZWJhdGUuPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkp1c3RpbiwgaWYgd2UgY2FuJ3QgZmluZCBhIHNpbmds ZSBpbXBsZW1lbnRhdGlvbiB0aGF0IHdvdWxkIGJhcmYsIHdoeSB3b3VsZCBDaHJvbWUgaGF2ZSB0 byBpbXBsZW1lbnQgYSBjb21wbGV4IGZhbGxiYWNrIG1lY2hhbmlzbT88bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEzNiwg MTM2LCAxMzYpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEzNiwgMTM2LCAxMzYpOyIgY2xhc3M9IiI+U2ltb248 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz PSIiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9u ZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVw dDsgcGFkZGluZzogMGluIDBpbiAwaW4gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+dHJhbQ0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7F1866120FE74B5EB132903B6B38302Fciscocom_-- From nobody Wed Jan 14 08:10:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C2F1A8AAE for ; Wed, 14 Jan 2015 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 27SzKhjaM_Rl for ; Wed, 14 Jan 2015 08:10:45 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6301A8AE6 for ; Wed, 14 Jan 2015 08:10:45 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B4A8428518; Wed, 14 Jan 2015 16:10:44 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9F89028517; Wed, 14 Jan 2015 16:10:44 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 98FF880044; Wed, 14 Jan 2015 16:10:44 +0000 (GMT) Message-ID: <54B69504.9030401@akamai.com> Date: Wed, 14 Jan 2015 11:10:44 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aijun Wang References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> <002a01d02f9d$29de2660$7d9a7320$@org.cn> <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> <005501d02fd7$9aead620$d0c08260$@org.cn> In-Reply-To: <005501d02fd7$9aead620$d0c08260$@org.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 16:10:47 -0000 On 01/14/2015 03:53 AM, Aijun Wang wrote: >> I disagree. The current suite of ICE/TURN/STUN RFCs do support this nicely. I >> >do not think further discussion on the list is appropriate, but will be happy to >> >have a chat during the next IETF meeting explaining things. > Ok, If possible, we can discuss this more detail face to face, but the mail exchange is also one channel to think it deeply and can assist us design one more lightweight solution. I also don't see much value in continuing this discussion on the list, because I'm not getting the sense the e-mail exchange is bringing additional clarity. A face-to-face discussion in Dallas will probably resolve this quite quickly. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Jan 14 14:45:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356C21AD082 for ; Wed, 14 Jan 2015 14:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 vU75Mfek7JUn for ; Wed, 14 Jan 2015 14:44:46 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152E61ACEF9 for ; Wed, 14 Jan 2015 14:44:28 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r10so11983871igi.0 for ; Wed, 14 Jan 2015 14:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I8iQdr06U4YozHrD7E4aT0hllSmggMz+XDOmQS21X0I=; b=PMIHHRrmUvfV+5eQ739z4WPbuDoad5xhr2P/rrAJpHz6YvucZEwWYLYVf2i+HmAMm3 u4c49jMTcjUhlFjpaAy0EKKLrpB17NsAJpFHy3ghsFuaNBotqcC67JJLcdwVOPiUJAMZ lNuYKCY6cTjaRhR296jNU36a9aRvIie40zQ1osrwu5bhinq3+ruuBAxRMDkQ95dKksEj mLzHeOdLemthwzbg8qMGHm4twF53vWamrghZiuniqrAF0zHB1FRYP678ki8vA70SEwFa TQkUISiQslsjCkrpn58jJMhj3CDK7jtxo3PbTXJhOjUQkieo+PZMw3JVbH6s+VC4c02k VU8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=I8iQdr06U4YozHrD7E4aT0hllSmggMz+XDOmQS21X0I=; b=ZZU/9QKxiIIBMR2LOhLjF9oPUJ9LsmMNCVvCVSG7C/i2vS9/+T2QxLsV00xEtV15sU mtV3eXXbNgGP12gJ681LzDGk0P/E/7TfmjbZqLEPHnaNoMvea6OOQS8nLZJhgFqoHYbg AfPBCc4zxWXMlK2xJOuBtQ6uNae1sfLJhAm5IGRNErbfKZVV71cD2nRKYZ7qRrVwGSa+ 6Nl5iCOrzytcmGgPc32ShEyuCyuG8IfQPakdNA/5wcyPlqjK0jDMYZdqoOv07OmHEOa8 Do/otaPt3EayHnI3sVwf1gMLJAbC8aeaVIZwOzyT0nZ/REEBGGsSLDA5NQF8s7T9iJLl AfRw== X-Gm-Message-State: ALoCoQne05FX2Ddt20CMgW5kdgt5ddPJdfpkdYDsBQWmXBmdsou/2i2NR5e/+Q6hXbxYLdpvbxtd X-Received: by 10.50.28.8 with SMTP id x8mr7163263igg.19.1421275462272; Wed, 14 Jan 2015 14:44:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Wed, 14 Jan 2015 14:44:02 -0800 (PST) In-Reply-To: <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> From: Justin Uberti Date: Wed, 14 Jan 2015 14:44:02 -0800 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=089e015386d60ead92050ca47ba8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 22:44:50 -0000 --089e015386d60ead92050ca47ba8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi, > > I do not see a problem with a TURN server returning a 400 error code if > it gets confused by two RAFs. > This is almost covered in section 2.4 of the SSODA draft. Client fallback > to non-SSODA mode when encountering an error seems trivial. > (Unless the TURN server ends up using to much CPU, overheats, and causes = a > fire in the datacenter) > > But I might like c) better anyway. Adding a new attribute seems cleaner > when adding new functionality. > Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also a good thing. > > .-. > P=C3=A5l-Erik > > On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) > wrote: > > ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a > temporary or long-term error. > > -Tiru > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Saturday, January 10, 2015 2:19 AM > *To:* Oleg Moskalenko > *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); > tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > OK, so we have clear evidence that some deployed servers will fail > (deterministically, fortunately) on the current SSODA proposal. > > So we're back to which backwards-compatible option we want to pursue. I > suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY= . > > Separately, we need to decide whether we want to pursue issue #2 that I > identified previously, i.e., allowing specific error codes to be returned > for each address family. > > On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko > wrote: > > I double-checked that with a real test. I ran the coTurn test client (tha= t > implements experimental SSODA draft with two RAF attributes) against > rfc5766-turn-server and the server yielded error 400 with the message "On= ly > one address family attribute can be used in a request" > > :( > > As I said, I can eliminate that problem in the subsequent > rfc5766-turn-server maintenance releases, but still... > > I am sorry that I did not discover that previously and that I advocated a= n > incompatible implementation option. > > So, if the WG insists on a backward-compatible protocol in all senses, > then we have to choose another option. > > Thanks > Oleg > > > On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko > wrote: > > I checked the code of rfc5766-turn-server again, and I found that it will > NOT handle the multiple-RAF case. It will return 400 error with the messa= ge > "Only one address family attribute can be used in a request". At least, > it's been that way in the 2014 releases. I did not check the older releas= es. > > Sorry that I provided a wrong information about the implementation, befor= e. > > I can fix that code but still there are people out there who will be usin= g > the "wrong" versions. > > So, if we do have to be absolutely backward compatible then we have to us= e > a different option... > Oleg > > > On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti > wrote: > > I reviewed the code for restund, reTurn, and rfc5766-turn-server and > they all appear to handle RAF (and multiple RAF) OK. > > The problem, as I see it, is that there may be other TURN servers, > perhaps non-open-source ones, that work fine today with Chrome, but will > start returning errors when we include RAF or multiple RAF, and so making > this change may break some small number of apps (who will then blame > Chrome). We just don't know what is out there. > > > > On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault > wrote: > > On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang > wrote: > After your detail analysis and the sentence =E2=80=9CFor either b/c, we = would > need to say that including both RAF and OAF/AAF for the same address fami= ly > is prohibited.=E2=80=9D, I think it may be better to keep only one attrib= ute to > fulfill the SSODA requirement? > > There is no requirement that SSODA functionality be realized with only on= e > attribute, nor that the protocol be elegant, nor that it exhibits symmetr= y > that is pleasing to the eye. > > There *is* a requirement that it be backwards-compatible though. > Whether that means compatible with the spec or compatible with actual > implementations is a matter of debate. > > Justin, if we can't find a single implementation that would barf, why > would Chrome have to implement a complex fallback mechanism? > > Simon > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --089e015386d60ead92050ca47ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <palmarti@c= isco.com> wrote:
Hi,

I do not see a problem with a TURN server returning a 400 error code i= f it gets confused by two RAFs.
This is almost covered in section 2.4 of the SSODA draft. Client fallb= ack to non-SSODA mode when encountering an error seems trivial.=C2=A0
(Unless the TURN server ends up using to much CPU, overheats, and caus= es a fire in the datacenter)

But I might like c) better anyway. Adding a new attribute seems cleane= r when adding new functionality.

Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also= a good thing.

.-.
P=C3=A5l-Erik

On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote= :

ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80= =99s a temporary or long-term error.
=C2=A0
-Tiru
=C2=A0
From:=C2= =A0Justin Uberti [mailto:juberti@googl= e.com]=C2=A0
Sent:=C2=A0Saturday, January 10, 2015 2:19 AM
To:=C2=A0Oleg Moskalenko
Cc:=C2=A0Simon Perreault; Aijun Wang; Tirumaleswar Redd= y (tireddy);=C2=A0tram@ietf.org Subject:=C2=A0Re: [tram] SSODA in TURN-bis
=C2=A0
OK, so we have clear evidence that some deployed servers will fail (determi= nistically, fortunately) on the current SSODA proposal.
=C2=A0
So we're back to which backwards-compatible option we want to pursue. I= suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY.=
=C2=A0
Separately, we need to decide whether we want to pursue issue #2 that I ide= ntified previously, i.e., allowing specific error codes to be returned for = each address family.
=C2=A0
On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I double-checked that with a real test. I ran the coTurn test client (that = implements experimental SSODA draft with two RAF attributes) against rfc576= 6-turn-server and the server yielded error 400 with the message "Only = one address family attribute can be used in a request"

:(

As I said, I can eliminate that problem in the subsequent rfc5766-turn-serv= er maintenance releases, but still...

I am sorry that I did not discover that previously and that I advocated an = incompatible implementation option.

So, if the WG insists on a backward-compatible protocol in all senses, then= we have to choose another option.

Thanks
Oleg

=C2=A0
=C2=A0
On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I checked the code of rfc5766-turn-server again, and I found that it will N= OT handle the multiple-RAF case. It will return 400 error with the message = "Only one address family attribute can be used in a request". At = least, it's been that way in the 2014 releases. I did not check the older releases.

Sorry that I provided a wrong information about the implementation, before.=

I can fix that code but still there are people out there who will be using = the "wrong" versions.

So, if we do have to be absolutely backward compatible then we have to use = a different option...

Oleg
=C2=A0
=C2=A0
On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <juberti@google.com> wrote:
I reviewed the code for restund, reTurn, and rfc5766-turn-server and they a= ll appear to handle RAF (and multiple RAF) OK.
=C2=A0
The problem, as I see it, is that there may be other TURN servers, perhaps = non-open-source ones, that work fine today with Chrome, but will start retu= rning errors when we include RAF or multiple RAF, and so making this change= may break some small number of apps (who will then blame Chrome). We just don't know what is out ther= e.
=C2=A0
=C2=A0
=C2=A0
On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <sperreault@jive.com> wrote:
=C2=A0
On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
After your detail analysis and the sentence =E2=80=9CFor either b/c, we wou= ld need to say that including both RAF and OAF/AAF for the same address fam= ily is prohibited.=E2=80=9D, I think it may be better to keep only one attr= ibute to fulfill the SSODA requirement? =C2=A0

There is no requirement that SSODA functionality be realized with only one = attribute, nor that the protocol be elegant, nor that it exhibits symmetry = that is pleasing to the eye.
=C2=A0
There *is* a requirement that it be backwards-compatible though. Whether th= at means compatible with the spec or compatible with actual implementations= is a matter of debate.
=C2=A0
Justin, if we can't find a single implementation that would barf, why w= ould Chrome have to implement a complex fallback mechanism?
=C2=A0
Simon
=C2=A0
=C2=A0

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman= /listinfo/tram

=C2=A0
=C2=A0
=C2=A0
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/= listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--089e015386d60ead92050ca47ba8-- From nobody Wed Jan 14 16:01:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4EB1B2A6B for ; Wed, 14 Jan 2015 16:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 jswUBN5GK_Wl for ; Wed, 14 Jan 2015 16:01:24 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A742B1AD0AB for ; Wed, 14 Jan 2015 16:01:23 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so12386220iga.5 for ; Wed, 14 Jan 2015 16:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RQIQw2Vhqbe1UU5pEq715bXU7F6Mj5CNW2Ic8AhYf0U=; b=pBMubFG13myoEqXiuKF9oNdWZN6qfgfhUbAKpTDjAweCg8lIeF6LcVDpNNbT59qDBM SPqFqslI63iF+HvHUL7/S522LEUMc2Wf0gyluWfBWTcC43pVjYyIjEvqZ+tsWx6h6Nh2 n1y+BhWYc1bLAh60Q+iEj6jWBBVZEi65MaldokI4S4GLv1T7HJJvFxtssMaPIXpZ/742 /+NLv84SPT2QNLw+pooqmWkHEpcD1c2yTuDgjrxeyVXhBrpHdEDVdnLlOPWPQZTku0hB SVEk9YVDIBnxeCXPmEUroufHryQ3DnMnaU5RqjT0m4NATwTXVpSPV4ppfGWS/RwZqUfm fBjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RQIQw2Vhqbe1UU5pEq715bXU7F6Mj5CNW2Ic8AhYf0U=; b=Ry+fiDw2dMmiSX68lHdDbbefV+dSix4u09JFBjlU17tsZjwaq7hUXirn/myArbcs81 E86Hgt6oZ9tFtdFrkuxYQlMCAlxFcS7w1t1yGHAoV3iTYwH3neK9w/ZFEsCi2PyOUUeq atMLgQP0t2PVpvPfgFA0IKpR79Ut31ZhzLyvCY7uUws7TAe+wfK85GeRFDQ5t4iHLB++ xhcmU3q8MhwGOv1V+v49rxviBmkv++u4tMbi19hYUi3TsKw7bDCPM/h1MMY0lfCjnm6M T+aoHecJ1hVBbQsdH2vX2pSpPBoAq3i+t1kZBWrnpMVyUUkvFQAYiljdkNkbaMHP9bc7 48ow== X-Gm-Message-State: ALoCoQl3hJgAmzb1p2kpHXcmyzW8/dB9FcnrQA7vf8P2ux5347DtJenIy7S3vmmZabB3rriJSGEv X-Received: by 10.42.103.7 with SMTP id k7mr7072346ico.33.1421280082779; Wed, 14 Jan 2015 16:01:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Wed, 14 Jan 2015 16:01:01 -0800 (PST) In-Reply-To: <002e01d02f9e$f0669fa0$d133dee0$@org.cn> References: <913383AAA69FF945B8F946018B75898A3552A606@xmb-rcd-x10.cisco.com> <00d301d02e31$9f79a8d0$de6cfa70$@org.cn> <002a01d02ece$4c063400$e4129c00$@org.cn> <002e01d02f9e$f0669fa0$d133dee0$@org.cn> From: Justin Uberti Date: Wed, 14 Jan 2015 16:01:01 -0800 Message-ID: To: Aijun Wang Content-Type: multipart/alternative; boundary=20cf303ea036760d58050ca58e25 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 00:01:28 -0000 --20cf303ea036760d58050ca58e25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 13, 2015 at 6:08 PM, Aijun Wang wrote: > Hi, Justin: > > > > As you described, the role of enterprise TURN is just let the inner user > to communicate with the outsider remote party when there is firewall at t= he > border of the enterprise network? You have said that when two users are > within the corporate, they will not the use the corporate TURN server. > Correct. > > > It is one common request that the inner user want to communicate with the > outside world, not limited on WebRTC application, so why not use some > tunnel protocol directly, such as L2TP, which rely on UDP datagram and ca= n > eliminate the latency introduced by other tunnel protocol that based on T= CP? > The network admin typically just wants to set up a proxy server (perhaps a combined HTTP/TURN proxy) and be done. L2TP would be a much more complicated design. Also, I don't understand where the TCP would come from. RETURN would use UDP. > > > RETURN maybe one available option, but I think the =E2=80=9CL2TP(or other= tunnel > protocol)+TURN=E2=80=9D is a better solution. On the other hand, RETURN i= s just > another kind UDP tunnel technology? > You can think of RETURN as an application-level UDP tunnel technology, similar to how HTTPS proxying is an application-level TCP tunnel technology; both will be useful in enterprise situations. > > > Best Regards. > > Aijun Wang. > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Wednesday, January 14, 2015 1:38 AM > *To:* Aijun Wang > *Cc:* tram@ietf.org; Tirumaleswar Reddy (tireddy) > > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Mon, Jan 12, 2015 at 5:14 PM, Aijun Wang > wrote: > > Hi, Justin: > > > > Please refer to the reply below. > > > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Tuesday, January 13, 2015 4:23 AM > *To:* Aijun Wang > *Cc:* Tirumaleswar Reddy (tireddy); tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang > wrote: > > Hi, > > > > Do you refer to the draft > http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN > draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does > not describe the situation that the communication peers select the > different public TURN server, and need the TURN server to relay the app > data(TURN to TURN). > > > > That is just normal UDP. > > > > [Aijun]: For TURN to TURN situation, I am discussing it with the Brandon, > please refer to that thread. We should consider carefully for the > transport mechanism between A/TURN Server A; TURN Server A/TURN Server B > and TURN Server B/B when peer A want to talk to B via the two TURN Server > A/B. > > > > In situation that mentioned in RETURN draft, Why not to let ICE or App > Server to select the appropriate TURN server(corporate private TURN serve= r > or public TURN server) based on the information of the two communication > parts? This can even eliminate the solution of RETURN: two peer will us= e > the corporate TURN server when they are both within corporate, and will u= se > the public TURN server when one of them is located outside the corporatio= n? > > > > a) The TURN server isn't needed when both endpoints are within the > enterprise. The TURN server sits on the enterprise border, and is used fo= r > inter-enterprise traffic. > > b) The public TURN server may not be reachable from the enterprise. This > is why the corporate TURN server is needed on the border. > > c) The app may require use of its own TURN server for location privacy > purposes, so both TURN servers may be used in this case. > > > > This is all spelled out in > https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-1. > > > > [Aijun] Would you like to explain more detail about =E2=80=9Cbut using on= ly the enterprise's TURN server reveals information about the user (e.g. or= ganizational affiliation)=E2=80=9D, and how do you achieve this goal via t= he RETURN mechanism? > > > > If only the enterprise TURN server is used, and this server is > on-premises, then the remote party can determine the location of the call= er > via IP geolocation of the relay candidates (as well as organization > affiliation, by seeing who owns that IP). This is similar to the case whe= re > the remote party determines the location of a non-enterprise caller via > their host/srflx candidates, although in this case applications can prote= ct > against this by forcing all traffic through an application-provided relay > server, which provides some amount of location ambiguity. > > > > RETURN attempts to provide this same functionality for the enterprise TUR= N > server case, and to do so it defines how traffic can transit both the > enterprise TURN server as well as the application TURN server. > > > > e.g. > > > > [client] -------- [ETURN] ------------ [ATURN] -------------- [remote > party] > > > > Best Regards. > > > > > > *From:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Monday, January 12, 2015 1:35 PM > *To:* Aijun Wang; 'Justin Uberti' > *Cc:* tram@ietf.org > *Subject:* RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > As Justin has pointed out we will be updating the draft with more details > on the decisions that could be made by ICE and the application to select > the TURN server. TURN-in-TURN communication is already explained in RETUR= N > draft. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Aijun Wang > *Sent:* Monday, January 12, 2015 7:08 AM > *To:* Tirumaleswar Reddy (tireddy); 'Justin Uberti' > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Hi, Reddy and Justin: > > > > I suggest the TURN server selection should be made by ICE, not the client > itself. This can eliminate the needs for the communication between > different TURN server that selected by communication peer. ICE has more > information about the communication situation, and is suitable to make th= is > decision. > > > > There are several issues needed to be solved when the communication peers > select the different TURN server, for example, how to find the second TUR= N > server, what is the communication mechanism between different TURN server= s, > the channel connection among different data segments: client/first TURN > server, first TURN server/second TURN server, and second TURN server/peer > etc. > > > > Best Regards. > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Tirumaleswar Reddy (tireddy) > *Sent:* Sunday, January 11, 2015 1:40 PM > *To:* Justin Uberti > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > Inline [TR] > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Sunday, January 11, 2015 2:17 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > > > > > On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > Enterprise-provided TURN server cannot provide location privacy may not b= e > always true. For example Enterprise network could use TURN server provide= d > by a cloud service and the user needs to know that the Enterprise TURN > server can provide location privacy and not proceed with TURN-in-TURN. > > > > We will have to discuss if TURN server can advertise that it can provide > location privacy in a new attribute or this info can be conveyed > out-of-band (e.g. PAC). > > > > The other problem not discussed in the draft is, what if the user wants > privacy against the calling site and let=E2=80=99s say uses Tor for priva= cy. In > this scenario app TURN server must not be selected. > > > > RETURN handles this situation fine, since the traffic will be routed > through the network-provided TURN server before being routed to the app > TURN server. Of course, if the application does not try to provide locati= on > privacy, only the network-provided TURN server will be used. > > > > [TR] But the problem is how will the endpoint how if network-provided TUR= N > server can provide location privacy or not ? > > TURN server can convey this information in a new STUN attribute > to the client. > > > > However, I think the user is much more likely to trust the application > than its network provider to provide privacy protection. > > > > [TR] User may or may not trust the application server. > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses > users using privacy techniques like Tor so that app server does not learn > the user's IP address. The Poker example given in the above draft explain= s > that the users in the call do not trust the calling service. In this case > IdP ensures that even if malicious calling service replaces the media > addresses with its own addresses and replaces the certificate fingerprin= t > in SDP with its own certificate, IdP assertion would ensure that the Poke= r > site cannot act as man-in-middle device. In this scenario user may not > want to pick app provided TURN server. > > > > -Tiru > > > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Friday, January 09, 2015 4:04 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-patil-tram-turn-serv-selection-00 > > > > At IETF 91, I promised to send feedback on this document, so here goes. > > > > Generally, I think many of the issues mentioned in this document are > important, but the recommendations are confusing and possibly > contradictory; a developer with little knowledge of TURN will have a hard > time figuring out exactly what to do. Furthermore, many of the properties > discussed in this document are dynamic, and should be handled by the ICE > process, rather than in TURN server selection (for example, the notion of > RTT as it relates to user experience). > > > > Therefore, I think this document should take a stronger stance and put > forth explicit best practices for selection (as opposed to "things to > consider"), for non-dynamic properties, and leave the decisions on dynami= c > properties to be resolved by ICE. > > > > For example, I think we should omit the text in Section 3 about what to d= o > with non-working TURN servers, and measuring RTT. Same for Section 3.3, > which also discusses RTT, and Section 3.4, which talks about multiple > interfaces. This can all be handled by ICE. > > > > In addition, the sections on local config and location privacy are > unnecessary when RETURN is used. When RETURN is used, the application can > always use the app TURN server for location privacy, and the relationship > between local TURN server and app TURN server is fully spelled out, so > there is nothing for the application to decide on. > > > > This leaves only the Security, Authentication, and Mobility sections. > > > > For security, I think we can give some clear guidance on what application= s > should do. For security, I think the guidance should be to use only DTLS = + > TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS > aren't available. If privacy is paramount, UDP/TCP fallback may be > contraindicated, but at this point in time, DTLS deployment isn't > widespread enough to truly recommend this. > > > > This relates to the Authentication section - but I think any failures to > authenticate the server cert should cause the TURN allocation to fail. Th= is > is just like any other misconfiguration on the TURN server - there's no > reason we should even allow use of TURN servers whose cert chains don't > validate. So, this section could probably be removed. > > > > Lastly, the Mobility section says that if "all other parameters [are] > equal", a TURN server with mobility should be used. Clearly, all other > parameters will not be equal (e.g. RTT), and even if they were, the clien= t > has no way to know if a server is mobility-capable a priori. So I think > this recommendation ought to be removed, or perhaps turned into some sort > of recommendation for TURN server developers (e.g. TURN servers SHOULD > support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), > probably in a separate doc. > > > > These recommendations should reduce the size of this document and provide > much clearer advice to app developers. > > > > > > > --20cf303ea036760d58050ca58e25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 13, 2015 at 6:08 PM, Aijun Wang <wangaijun@tsinghu= a.org.cn> wrote:

Hi, Justin:

=C2=A0

As you described, the role of enterprise TURN is just l= et the inner user to communicate with the outsider remote party when there = is firewall at the border of the enterprise network? You have said that whe= n two users are within the corporate, they will not the use the corporate T= URN server.


Correct.= =C2=A0

=C2=A0

It is one commo= n request that the inner user want to communicate with the outside world, n= ot limited on WebRTC application, so why not use some tunnel protocol direc= tly, such as L2TP, which rely on UDP datagram and can eliminate the latency= introduced by other tunnel protocol that based on TCP?


The network admin typically just wants = to set up a proxy server (perhaps a combined HTTP/TURN proxy) and be done. = L2TP would be a much more complicated design.

Also= , I don't understand where the TCP would come from. RETURN would use UD= P.=C2=A0

<= /span>

=C2=A0<= /u>

RETURN maybe = one available option, but I think the =E2=80=9CL2TP(or other tunnel protoco= l)+TURN=E2=80=9D is a better solution. On the other hand, RETURN is just an= other kind UDP tunnel technology?

<= br>
You can think of RETURN as an application-level UDP tunnel te= chnology, similar to how HTTPS proxying is an application-level TCP tunnel = technology; both will be useful in enterprise situations.

=C2=A0

Best Regards.

<= p class=3D"MsoNormal">Aijun Wang.

=C2=A0

From:<= span lang=3D"EN-US" style=3D"font-size:10pt;font-family:Tahoma,sans-serif">= tram [mailto:tr= am-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: = Wednesday, January 14, 2015 1:38 AM
To: Aijun Wang
Cc: = tram@ietf.org; Tirum= aleswar Reddy (tireddy)


Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00<= /u>

=C2=A0

=C2=A0

=C2=A0

On Mon, Jan 12, 2015 at 5:14 PM, A= ijun Wang <wangaijun@tsinghua.org.cn> wrote:

Hi, Justin:

=C2=A0

Please refer to the reply below= .

=C2=A0=

=C2=A0

From: Justin Uberti [mailto:juberti@google.com]
Sent:= Tuesday, January 13, 2015 4:23 AM
To: Aijun Wang
Cc: T= irumaleswar Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] Comments on draft-pati= l-tram-turn-serv-selection-00

=C2=A0

=C2=A0<= u>

= =C2=A0

On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang <wangaijun@tsinghua.org.cn>= wrote:

Hi,

=C2=A0

Do you refer to the draft http://www.ietf.org/id/draft-schw= artz-rtcweb-return-04.txt as RETURN draft? This draft describes only TU= RN-in-TURN, not TURN-to-TURN. It does not describe the situation that the c= ommunication peers select the different public TURN server, and need the TU= RN server to relay the app data(TURN to TURN).<= u>

=C2=A0

That is just normal UDP.=C2=A0

=C2=A0

[Aijun]: For TURN to TURN situation, I am discussing it with the B= randon, please refer to that thread.=C2=A0 We should consider carefully for= the transport mechanism between A/TURN Server A; TURN Server A/TURN Server= B and TURN Server B/B when peer A want to talk to B via the two TURN Serve= r A/B.=C2=A0

=C2=A0

In situation that mentioned in RETURN draft, Why not to let ICE or App Se= rver to select the appropriate TURN server(corporate private TURN server or= public TURN server) based on the information of the two communication part= s? This can even eliminate the solution of=C2=A0 RETURN: =C2=A0two peer wil= l use the corporate TURN server when they are both within corporate, and wi= ll use the public TURN server when one of them is located outside the corpo= ration?

=C2=A0=

a) Th= e TURN server isn't needed when both endpoints are within the enterpris= e. The TURN server sits on the enterprise border, and is used for inter-ent= erprise traffic.

= b) The public TURN server may not be reachable from th= e enterprise. This is why the corporate TURN server is needed on the border= .

c) The app may require use of its own TURN server for location privac= y purposes, so both TURN servers may be used in this case.

=C2=A0

T= his is all spelled out in=C2=A0https://tools.ietf.= org/html/draft-schwartz-rtcweb-return-04#section-1.

=C2=A0

[Aijun] =
Would you like to explain more detail about =E2=80=9Cbut using only the enterprise's TURN server=
 reveals information about the user (e.g. organizational affiliation)=E2=80=9D,=C2=A0 and how do you achieve this goal=
 via the RETURN mechanism?=

=C2=A0

If only the enterprise TURN = server is used, and this server is on-premises, then the remote party can d= etermine the location of the caller via IP geolocation of the relay candida= tes (as well as organization affiliation, by seeing who owns that IP). This= is similar to the case where the remote party determines the location of a= non-enterprise caller via their host/srflx candidates, although in this ca= se applications can protect against this by forcing all traffic through an = application-provided relay server, which provides some amount of location a= mbiguity.=C2=A0

<= span lang=3D"EN-US">=C2=A0

RETURN attempts to provide this same functio= nality for the enterprise TURN server case, and to do so it defines how tra= ffic can transit both the enterprise TURN server as well as the application= TURN server.

=C2=A0

e.g.

=C2=A0

=

[client] -------- [ETURN] = ------------ [ATURN] -------------- [remote party]

=

=C2=A0

Best Regards.

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri,sans-seri= f;color:rgb(31,73,125)">=C2=A0

=C2=A0

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
= Sent: Monday, January 12, 2015 1:35 PM
To: Aijun Wang; = 9;Justin Uberti'
Cc: tram@ietf.org
Subject: RE: [tram] Comments on dra= ft-patil-tram-turn-serv-selection-00<= /u>

=C2=A0

As Justin has pointed out we will be updating the draft with more de= tails on the decisions that could be made by ICE and the application to sel= ect the TURN server. TURN-in-TURN communication is already explained in RET= URN draft.

=C2=A0=

-Tiru

=C2=A0

From: tram [<= a href=3D"mailto:tram-bounces@ietf.org" target=3D"_blank">mailto:tram-bounc= es@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, Jan= uary 12, 2015 7:08 AM
To: Tirumaleswar Reddy (tireddy); 'Just= in Uberti'
Cc: tram@ietf.org
Subject: Re: [tram] Comments on draft-pati= l-tram-turn-serv-selection-00

=C2=A0

Hi, Redd= y and Justin:

=C2=A0<= u>

I= suggest the TURN server selection should be made by ICE, not the client it= self.=C2=A0 This can eliminate the needs for the communication between diff= erent TURN server that selected by communication peer. ICE has more informa= tion about the communication situation, and is suitable to make this decisi= on.

=C2=A0

There are seve= ral issues needed to be solved when the communication peers select the diff= erent TURN server, for example, how to find the second TURN server, what is= the communication mechanism between different TURN servers, the channel co= nnection among different data segments: client/first TURN server, first TUR= N server/second TURN server, and second TURN server/peer etc.

=C2=A0

Best Regards.

=C2=A0

From: tram [= mailto:tram-bo= unces@ietf.org] On Behalf Of Tirumaleswar Reddy (= tireddy)
Sent: Sunday, January 11, 2015 1:40 PM
To: Jus= tin Uberti
Cc: tram@ietf.org
Subject: Re: [tra= m] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

Inline [TR]=

=C2=A0

From: Justin Uberti [mailto:juberti@google.com]
Sent: Sunday, January 11, 2015 2:17 AM
To: Tirum= aleswar Reddy (tireddy)
Cc: tram@ietf.org
Subjec= t: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">On Fri, Jan 9, 2015 at 7:38 PM, = Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

=

Hi Justin,

=C2=A0

Enterprise-provided TURN server can= not provide location privacy may not be always true. For example Enterprise= network could use TURN server provided by a cloud service and the user nee= ds to know that the Enterprise TURN server can provide location privacy and= not proceed with TURN-in-TURN. <= /span>

=C2=A0

We will have to discuss if TURN server can advertise that it c= an provide location privacy in a new attribute or this info can be conveyed= out-of-band (e.g. PAC).=C2=A0

=C2=A0

The other problem not discussed = in the draft is, what if the user wants privacy against the calling site an= d let=E2=80=99s say uses Tor for privacy. In this scenario app TURN server = must not be selected.

<= /div>

= =C2=A0

RETURN handles this situation fine, since the traffic will be ro= uted through the network-provided TURN server before being routed to the ap= p TURN server. Of course, if the application does not try to provide locati= on privacy, only the network-provided TURN server will be used.

=C2=A0

[TR] But the problem is how will the endpoint how if network-pr= ovided TURN server can provide location privacy or not ?

=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0TURN server can convey this information in a new ST= UN attribute to the client.

=C2=A0

<= p class=3D"MsoNormal">However, I think the user is muc= h more likely to trust the application than its network provider to provide= privacy protection.

=C2=A0

=

[TR] User may or may not trust = the application server. https://tools.ietf.org/html/draft= -ietf-rtcweb-security-arch-10 discusses users using privacy techniques = like Tor so that app server does not learn the user's IP address. The P= oker example given in the above draft explains that the users in the call d= o not trust the calling service. In this case IdP ensures that even if mali= cious calling service replaces the media addresses with its own addresses= =C2=A0 and replaces the certificate fingerprint in SDP with its own certifi= cate, IdP assertion would ensure that the Poker site cannot act as =C2=A0ma= n-in-middle device. In this scenario user may not want to pick app provided= TURN server.

=C2=A0

-Tiru

=C2=A0

=C2=A0

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Friday, = January 09, 2015 4:04 AM
To: tram@ietf.org
Subjec= t: [tram] Comments on draft-patil-tram-turn-serv-selection-00

=C2=A0

At IETF 91, I promised to send feedback on thi= s document, so here goes.

=C2=A0

Generally, I think many of the issues m= entioned in this document are important, but the recommendations are confus= ing and possibly contradictory; a developer with little knowledge of TURN w= ill have a hard time figuring out exactly what to do. Furthermore, many of = the properties discussed in this document are dynamic, and should be handle= d by the ICE process, rather than in TURN server selection (for example, th= e notion of RTT as it relates to user experience).

=

=C2=A0=

Therefore= , I think this document should take a stronger stance and put forth explici= t best practices for selection (as opposed to "things to consider"= ;), for non-dynamic properties, and leave the decisions on dynamic properti= es to be resolved by ICE.=C2=A0

=C2=A0

For example, I think we shou= ld omit the text in Section 3 about what to do with non-working TURN server= s, and measuring RTT. Same for Section 3.3, which also discusses RTT, and S= ection 3.4, which talks about multiple interfaces. This can all be handled = by ICE.

=C2=A0

In addition, the sections on local config and locati= on privacy are unnecessary when RETURN is used. When RETURN is used, the ap= plication can always use the app TURN server for location privacy, and the = relationship between local TURN server and app TURN server is fully spelled= out, so there is nothing for the application to decide on.

=C2=A0

= This leaves only the Security, Authentication, and Mobility sections.=C2=A0=

=C2=A0

For security, I think we can give some clear guidance on wh= at applications should do. For security, I think the guidance should be to = use only DTLS + TLS, if both are available, with fallback to UDP or TCP if = DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback= may be contraindicated, but at this point in time, DTLS deployment isn'= ;t widespread enough to truly recommend this.

=C2=A0

This relates t= o the Authentication section - but I think any failures to authenticate the= server cert should cause the TURN allocation to fail. This is just like an= y other misconfiguration on the TURN server - there's no reason we shou= ld even allow use of TURN servers whose cert chains don't validate. So,= this section could probably be removed.

=C2=A0

Lastly, the Mobilit= y section says that if "all other parameters [are] equal", a TURN= server with mobility should be used. Clearly, all other parameters will no= t be equal (e.g. RTT), and even if they were, the client has no way to know= if a server is mobility-capable a priori. So I think this recommendation o= ught to be removed, or perhaps turned into some sort of recommendation for = TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD s= upport mobility, SHOULD support redirect), probably in a separate doc.

= =C2=A0

These recommendations should reduce the size of this document an= d provide much clearer advice to app developers.

=C2=A0

=C2=A0

=

=C2=A0


--20cf303ea036760d58050ca58e25-- From nobody Wed Jan 14 23:02:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DED1B2B36 for ; Wed, 14 Jan 2015 23:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZDpiA_HhBGx6 for ; Wed, 14 Jan 2015 23:02:50 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F371B2B1C for ; Wed, 14 Jan 2015 23:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13142; q=dns/txt; s=iport; t=1421305370; x=1422514970; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5PoKhMAtzvL5nELnsa1Z3T/tCuDFq/QjaeIw5uJt+ZU=; b=D2+I+dnh0au5WPsqLO1mj/0eefAzBV62NAkFST99i4ZHACeORmXIDC4s nLCE8s9m8oP/1IONPitz680eXTkZIFgSVQEnCgxq3rGBFP3geTQR6N7Db ilwXm9igcZIg/soNzQMfEu9YCGkmVr+yZJOSVU4pxthkNKrwnZirYdBLt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAMtkt1StJV2P/2dsb2JhbABagkNDgSoEw2yIFgKBGEMBAQEBAX2EDAEBAQRyFwIBCA4DAwECKAcyFAkIAgQBEogs0CsBAQEBBgEBAQEBAQEbjzQ0GIQpBYQ9AogxgVyJD5IKIoNub4EFJBx+AQEB X-IronPort-AV: E=Sophos;i="5.09,402,1418083200"; d="scan'208,217";a="113445491" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 15 Jan 2015 07:02:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0F72mP2019550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Jan 2015 07:02:48 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.100]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 01:02:47 -0600 From: "Prashanth Patil (praspati)" To: Justin Uberti , "tram@ietf.org" Thread-Topic: [tram] Comments on draft-patil-tram-turn-serv-selection-00 Thread-Index: AQHQMJFEhrN2lr3c4U6DjAKzni45UA== Date: Thu, 15 Jan 2015 07:02:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.49.57] Content-Type: multipart/alternative; boundary="_000_D0DD5DEF7042Cpraspaticiscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 07:02:51 -0000 --_000_D0DD5DEF7042Cpraspaticiscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Justin, From: Justin Uberti > Date: Friday, January 9, 2015 4:04 AM To: "tram@ietf.org" > Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00 At IETF 91, I promised to send feedback on this document, so here goes. Generally, I think many of the issues mentioned in this document are import= ant, but the recommendations are confusing and possibly contradictory; a de= veloper with little knowledge of TURN will have a hard time figuring out ex= actly what to do. Furthermore, many of the properties discussed in this doc= ument are dynamic, and should be handled by the ICE process, rather than in= TURN server selection (for example, the notion of RTT as it relates to use= r experience). Therefore, I think this document should take a stronger stance and put fort= h explicit best practices for selection (as opposed to "things to consider"= ), for non-dynamic properties, and leave the decisions on dynamic propertie= s to be resolved by ICE. Yes, we'll clarify this in the next revision. We'll simply advise that dyna= mic properties have to be resolved by ICE. For example, I think we should omit the text in Section 3 about what to do = with non-working TURN servers, and measuring RTT. Same for Section 3.3, whi= ch also discusses RTT, and Section 3.4, which talks about multiple interfac= es. This can all be handled by ICE. In addition, the sections on local config and location privacy are unnecess= ary when RETURN is used. When RETURN is used, the application can always us= e the app TURN server for location privacy, and the relationship between lo= cal TURN server and app TURN server is fully spelled out, so there is nothi= ng for the application to decide on. Sure. We can add a note on RETURN. However, a server selection mechanism sh= ould consider cases in the absence of RETURN, especially for local config. This leaves only the Security, Authentication, and Mobility sections. For security, I think we can give some clear guidance on what applications = should do. For security, I think the guidance should be to use only DTLS + = TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS aren= 't available. Will do. If privacy is paramount, UDP/TCP fallback may be contraindicated, but at th= is point in time, DTLS deployment isn't widespread enough to truly recommen= d this. This relates to the Authentication section - but I think any failures to au= thenticate the server cert should cause the TURN allocation to fail. Yes, we'll make this clear. The documents reads 'prefer a TURN server whose= authenticity can be ascertained', which needs to change. This is just like any other misconfiguration on the TURN server - there's n= o reason we should even allow use of TURN servers whose cert chains don't v= alidate. So, this section could probably be removed. The section offers some guidance on how to validate the certs in case of pr= e-configured list of trusted names etc. We also wanted to add some guidance on how to go about validating certs whe= n the client discovers a TURN server IP address but not necessarily its nam= e, but certificates have a DNS name in the SubjectAltName field. Thoughts? Lastly, the Mobility section says that if "all other parameters [are] equal= ", a TURN server with mobility should be used. Clearly, all other parameter= s will not be equal (e.g. RTT), and even if they were, the client has no wa= y to know if a server is mobility-capable a priori. Right. Given this, we could perhaps recommend that a client that wants mobi= lity sends the STUN MOBILITY-TICKET attribute in the Allocate request and r= ejects a TURN server that doesn=92t include a STUN MOBILITY-TICKET in its r= esponse. If none of the discovered TURN servers support mobility, then the = client just goes back to the first TURN server is attempted to connect. Not= very ideal. We could maybe have a similar mechanism for location privacy? A TURN server= should respond with an attribute indicating that it offers location privac= y. So I think this recommendation ought to be removed, or perhaps turned into = some sort of recommendation for TURN server developers (e.g. TURN servers S= HOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), = probably in a separate doc. These recommendations should reduce the size of this document and provide m= uch clearer advice to app developers. Thanks, Prashanth --_000_D0DD5DEF7042Cpraspaticiscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Justin,

From: Justin Uberti <juberti@google.com>
Date: Friday, January 9, 2015 4:04 = AM
To: "tram@ietf.org" <tram@i= etf.org>
Subject: [tram] Comments on draft-p= atil-tram-turn-serv-selection-00

At IETF = 91, I promised to send feedback on this document, so here goes.

Generally, I think many of the issues mentioned in this document are i= mportant, but the recommendations are confusing and possibly contradictory;= a developer with little knowledge of TURN will have a hard time figuring o= ut exactly what to do. Furthermore, many of the properties discussed in this document are dynamic, and should = be handled by the ICE process, rather than in TURN server selection (for ex= ample, the notion of RTT as it relates to user experience).

Therefore, I think this document should take a stronger stance and put= forth explicit best practices for selection (as opposed to "things to= consider"), for non-dynamic properties, and leave the decisions on dy= namic properties to be resolved by ICE. 

Yes, we'll clarify this in the next revision. We'll simply advise that= dynamic properties have to be resolved by ICE.

For example, I think we should omit the text in Section 3 about what t= o do with non-working TURN servers, and measuring RTT. Same for Section 3.3= , which also discusses RTT, and Section 3.4, which talks about multiple int= erfaces. This can all be handled by ICE.

In addition, the sections on local config and location privacy are unn= ecessary when RETURN is used. When RETURN is used, the application can alwa= ys use the app TURN server for location privacy, and the relationship betwe= en local TURN server and app TURN server is fully spelled out, so there is nothing for the application to de= cide on.

Sure. We can add a note on RETURN. However, a server selection mechani= sm should consider cases in the absence of RETURN, especially for local con= fig.

This leaves only the Security, Authentication, and Mobility sections.&= nbsp;

For security, I think we can give some clear guidance on what applicat= ions should do. For security, I think the guidance should be to use only DT= LS + TLS, if both are available, with fallback to UDP or TCP if DTLS or= TLS aren't available.

Will do.

If privacy is paramount, UDP/TCP fallback may be contraindicated, but = at this point in time, DTLS deployment isn't widespread enough to truly rec= ommend this.

This relates to the Authentication section - but I think any failures = to authenticate the server cert should cause the TURN allocation to fail.

Yes, we'll make this clear. The documents reads 'prefer a TURN server = whose authenticity can be ascertained', which needs to change.

This is just like any other misconfiguration on the TURN server - ther= e's no reason we should even allow use of TURN servers whose cert chains do= n't validate. So, this section could probably be removed.

The section offers some guidance on how to validate the certs in case = of pre-configured list of trusted names etc.
We also wanted to add some guidance on how to go about validating cert= s when the client discovers a TURN server IP address but not necessarily it= s name, but certificates have a DNS name in the SubjectAltName field.<= /div>
Thoughts?

Lastly, the Mobility section says that if "all other parameters [= are] equal", a TURN server with mobility should be used. Clearly, all = other parameters will not be equal (e.g. RTT), and even if they were, the c= lient has no way to know if a server is mobility-capable a priori.

Right. Given this, we could perhaps recommend that a client that wants= mobility sends the STUN MOBILITY-TICKET attribute in the Allocate request = and rejects a TURN server that doesn=92t include a STUN MOBILITY-TICKET in = its response. If none of the discovered TURN servers support mobility, then the client just goes back to the first= TURN server is attempted to connect. Not very ideal.

We could maybe have a similar mechanism for location privacy? A TURN s= erver should respond with an attribute indicating that it offers location p= rivacy.

So I think this recommendation ought to be removed, or perhaps turned = into some sort of recommendation for TURN server developers (e.g. TURN serv= ers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redire= ct), probably in a separate doc.

These recommendations should reduce the size of this document and prov= ide much clearer advice to app developers.

Thanks,
Prashanth
--_000_D0DD5DEF7042Cpraspaticiscocom_-- From nobody Thu Jan 15 03:19:25 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A08E1B2BD4 for ; Thu, 15 Jan 2015 03:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3hWbQbZOuHt4 for ; Thu, 15 Jan 2015 03:19:17 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F68F1B2BC3 for ; Thu, 15 Jan 2015 03:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35970; q=dns/txt; s=iport; t=1421320757; x=1422530357; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WRfM9XGFVmIKwri+52NbVCd1lSoVLNiwfKKHw9Nuz4k=; b=VNjgFDpBkSXtjIbFXKL0bUw2nMI8tKlYcm5SewIkBALqnTK4MtVjoyU5 AFtr4u+L5+NL57ygIamxkVc0cKSwRKl+vKnq+HXyNtohLMQShsu/0uJs+ giudQhQ9QRe1VwsMGHC+U1UpECxfrJfIC8IgGLQdfukaptOtBwqCCQqLt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFALSht1StJV2a/2dsb2JhbABagkNDUlgEgwHDBgEJhXECHHpDAQEBAQF9hAwBAQEEAQEBIEsLEAIBCA4DBAEBIQcDAgICHwYLFAkIAQEEAQ0FiBgDEQ28EI90DYN1AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNT4ImBAYBBoJiLoETBYQ9AooNh0uBRIEPixCCLoM9IoNub4EDJB5+AQEB X-IronPort-AV: E=Sophos;i="5.09,403,1418083200"; d="scan'208,217";a="113499429" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 15 Jan 2015 11:19:16 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0FBJG68018490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Jan 2015 11:19:16 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 05:19:16 -0600 From: "Pal Martinsen (palmarti)" To: Justin Uberti , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] SSODA in TURN-bis Thread-Index: AdAuJda+xEi4Jbc7TpCKn/lLZn1lewB9F2kAABjrfAAAGl/egA== Date: Thu, 15 Jan 2015 11:19:15 +0000 Message-ID: <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.195.5] Content-Type: multipart/alternative; boundary="_000_6A922A2CE6924A36B6AEF8CC2BCF421Fciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 11:19:22 -0000 --_000_6A922A2CE6924A36B6AEF8CC2BCF421Fciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxNCBKYW4gMjAxNSwgYXQgMjM6NDQsIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xl LmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCg0KDQpPbiBXZWQsIEph biAxNCwgMjAxNSBhdCAyOjUwIEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgPHBhbG1hcnRp QGNpc2NvLmNvbTxtYWlsdG86cGFsbWFydGlAY2lzY28uY29tPj4gd3JvdGU6DQpIaSwNCg0KSSBk byBub3Qgc2VlIGEgcHJvYmxlbSB3aXRoIGEgVFVSTiBzZXJ2ZXIgcmV0dXJuaW5nIGEgNDAwIGVy cm9yIGNvZGUgaWYgaXQgZ2V0cyBjb25mdXNlZCBieSB0d28gUkFGcy4NClRoaXMgaXMgYWxtb3N0 IGNvdmVyZWQgaW4gc2VjdGlvbiAyLjQgb2YgdGhlIFNTT0RBIGRyYWZ0LiBDbGllbnQgZmFsbGJh Y2sgdG8gbm9uLVNTT0RBIG1vZGUgd2hlbiBlbmNvdW50ZXJpbmcgYW4gZXJyb3Igc2VlbXMgdHJp dmlhbC4NCihVbmxlc3MgdGhlIFRVUk4gc2VydmVyIGVuZHMgdXAgdXNpbmcgdG8gbXVjaCBDUFUs IG92ZXJoZWF0cywgYW5kIGNhdXNlcyBhIGZpcmUgaW4gdGhlIGRhdGFjZW50ZXIpDQoNCkJ1dCBJ IG1pZ2h0IGxpa2UgYykgYmV0dGVyIGFueXdheS4gQWRkaW5nIGEgbmV3IGF0dHJpYnV0ZSBzZWVt cyBjbGVhbmVyIHdoZW4gYWRkaW5nIG5ldyBmdW5jdGlvbmFsaXR5Lg0KDQpTYXZpbmcgYSByb3Vu ZHRyaXAgKGkuZS4gYnkgbm90IGhhdmluZyB0byByZXRyeSkgd2hlbiBkb2luZyBTU09EQSBpcyBh bHNvIGEgZ29vZCB0aGluZy4NCg0KR29vZCBwb2ludC4gU2luY2UgdGhpcyBwcm9iYWJseSB3b3Vs ZCB0YWtlIHNvbWUgdGltZSB0byBkZXBsb3kgb24gdGhlIHNlcnZlciBzaWRlIHRoZSBleHRyYSBj aGF0dGVyIGNvdWxkIGJlY29tZSBhIGJpdCBhbm5veWluZy4NCg0KVGlydSwgZG8geW91IGhhdmUg ZW5vdWdoIGluZm9ybWF0aW9uIHRvIGFkZCB0aGlzIHRvIHRoZSBUVVJOYmlzIGRyYWZ0PyBPciBk byB5b3UgdGhpbmsgbW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZD8NCg0KLi0uDQpQw6VsLUVyaWsN Cg0KDQouLS4NClDDpWwtRXJpaw0KDQpPbiAxMiBKYW4gMjAxNSwgYXQgMDY6MDgsIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNp c2NvLmNvbT4+IHdyb3RlOg0KDQpBRERSRVNTLUVSUk9SLUNPREUgc2VlbXMgdXNlZnVsLCBjbGll bnQgY2FuIGRldGVybWluZSBpZiBpdOKAmXMgYSB0ZW1wb3Jhcnkgb3IgbG9uZy10ZXJtIGVycm9y Lg0KDQotVGlydQ0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUu Y29tXQ0KU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTAsIDIwMTUgMjoxOSBBTQ0KVG86IE9sZWcg TW9za2FsZW5rbw0KQ2M6IFNpbW9uIFBlcnJlYXVsdDsgQWlqdW4gV2FuZzsgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXMNCg0KT0ssIHNvIHdlIGhhdmUgY2xl YXIgZXZpZGVuY2UgdGhhdCBzb21lIGRlcGxveWVkIHNlcnZlcnMgd2lsbCBmYWlsIChkZXRlcm1p bmlzdGljYWxseSwgZm9ydHVuYXRlbHkpIG9uIHRoZSBjdXJyZW50IFNTT0RBIHByb3Bvc2FsLg0K DQpTbyB3ZSdyZSBiYWNrIHRvIHdoaWNoIGJhY2t3YXJkcy1jb21wYXRpYmxlIG9wdGlvbiB3ZSB3 YW50IHRvIHB1cnN1ZS4gSSBzdWdnZXN0IGMpLCB3aGljaCBpcyB0aGUgb3B0aW9uYWwtY29tcHJl aGVuc2lvbiBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZLg0KDQpTZXBhcmF0ZWx5LCB3ZSBuZWVk IHRvIGRlY2lkZSB3aGV0aGVyIHdlIHdhbnQgdG8gcHVyc3VlIGlzc3VlICMyIHRoYXQgSSBpZGVu dGlmaWVkIHByZXZpb3VzbHksIGkuZS4sIGFsbG93aW5nIHNwZWNpZmljIGVycm9yIGNvZGVzIHRv IGJlIHJldHVybmVkIGZvciBlYWNoIGFkZHJlc3MgZmFtaWx5Lg0KDQpPbiBGcmksIEphbiA5LCAy MDE1IGF0IDEwOjUzIEFNLCBPbGVnIE1vc2thbGVua28gPG1vbTA0MDI2N0BnbWFpbC5jb208bWFp bHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+PiB3cm90ZToNCkkgZG91YmxlLWNoZWNrZWQgdGhhdCB3 aXRoIGEgcmVhbCB0ZXN0LiBJIHJhbiB0aGUgY29UdXJuIHRlc3QgY2xpZW50ICh0aGF0IGltcGxl bWVudHMgZXhwZXJpbWVudGFsIFNTT0RBIGRyYWZ0IHdpdGggdHdvIFJBRiBhdHRyaWJ1dGVzKSBh Z2FpbnN0IHJmYzU3NjYtdHVybi1zZXJ2ZXIgYW5kIHRoZSBzZXJ2ZXIgeWllbGRlZCBlcnJvciA0 MDAgd2l0aCB0aGUgbWVzc2FnZSAiT25seSBvbmUgYWRkcmVzcyBmYW1pbHkgYXR0cmlidXRlIGNh biBiZSB1c2VkIGluIGEgcmVxdWVzdCINCg0KOigNCkFzIEkgc2FpZCwgSSBjYW4gZWxpbWluYXRl IHRoYXQgcHJvYmxlbSBpbiB0aGUgc3Vic2VxdWVudCByZmM1NzY2LXR1cm4tc2VydmVyIG1haW50 ZW5hbmNlIHJlbGVhc2VzLCBidXQgc3RpbGwuLi4NCkkgYW0gc29ycnkgdGhhdCBJIGRpZCBub3Qg ZGlzY292ZXIgdGhhdCBwcmV2aW91c2x5IGFuZCB0aGF0IEkgYWR2b2NhdGVkIGFuIGluY29tcGF0 aWJsZSBpbXBsZW1lbnRhdGlvbiBvcHRpb24uDQpTbywgaWYgdGhlIFdHIGluc2lzdHMgb24gYSBi YWNrd2FyZC1jb21wYXRpYmxlIHByb3RvY29sIGluIGFsbCBzZW5zZXMsIHRoZW4gd2UgaGF2ZSB0 byBjaG9vc2UgYW5vdGhlciBvcHRpb24uDQpUaGFua3MNCk9sZWcNCg0KDQpPbiBGcmksIEphbiA5 LCAyMDE1IGF0IDEwOjAxIEFNLCBPbGVnIE1vc2thbGVua28gPG1vbTA0MDI2N0BnbWFpbC5jb208 bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+PiB3cm90ZToNCkkgY2hlY2tlZCB0aGUgY29kZSBv ZiByZmM1NzY2LXR1cm4tc2VydmVyIGFnYWluLCBhbmQgSSBmb3VuZCB0aGF0IGl0IHdpbGwgTk9U IGhhbmRsZSB0aGUgbXVsdGlwbGUtUkFGIGNhc2UuIEl0IHdpbGwgcmV0dXJuIDQwMCBlcnJvciB3 aXRoIHRoZSBtZXNzYWdlICJPbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBhdHRyaWJ1dGUgY2FuIGJl IHVzZWQgaW4gYSByZXF1ZXN0Ii4gQXQgbGVhc3QsIGl0J3MgYmVlbiB0aGF0IHdheSBpbiB0aGUg MjAxNCByZWxlYXNlcy4gSSBkaWQgbm90IGNoZWNrIHRoZSBvbGRlciByZWxlYXNlcy4NClNvcnJ5 IHRoYXQgSSBwcm92aWRlZCBhIHdyb25nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBpbXBsZW1lbnRh dGlvbiwgYmVmb3JlLg0KSSBjYW4gZml4IHRoYXQgY29kZSBidXQgc3RpbGwgdGhlcmUgYXJlIHBl b3BsZSBvdXQgdGhlcmUgd2hvIHdpbGwgYmUgdXNpbmcgdGhlICJ3cm9uZyIgdmVyc2lvbnMuDQpT bywgaWYgd2UgZG8gaGF2ZSB0byBiZSBhYnNvbHV0ZWx5IGJhY2t3YXJkIGNvbXBhdGlibGUgdGhl biB3ZSBoYXZlIHRvIHVzZSBhIGRpZmZlcmVudCBvcHRpb24uLi4NCk9sZWcNCg0KDQpPbiBGcmks IEphbiA5LCAyMDE1IGF0IDk6MzQgQU0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNv bTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQpJIHJldmlld2VkIHRoZSBjb2Rl IGZvciByZXN0dW5kLCByZVR1cm4sIGFuZCByZmM1NzY2LXR1cm4tc2VydmVyIGFuZCB0aGV5IGFs bCBhcHBlYXIgdG8gaGFuZGxlIFJBRiAoYW5kIG11bHRpcGxlIFJBRikgT0suDQoNClRoZSBwcm9i bGVtLCBhcyBJIHNlZSBpdCwgaXMgdGhhdCB0aGVyZSBtYXkgYmUgb3RoZXIgVFVSTiBzZXJ2ZXJz LCBwZXJoYXBzIG5vbi1vcGVuLXNvdXJjZSBvbmVzLCB0aGF0IHdvcmsgZmluZSB0b2RheSB3aXRo IENocm9tZSwgYnV0IHdpbGwgc3RhcnQgcmV0dXJuaW5nIGVycm9ycyB3aGVuIHdlIGluY2x1ZGUg UkFGIG9yIG11bHRpcGxlIFJBRiwgYW5kIHNvIG1ha2luZyB0aGlzIGNoYW5nZSBtYXkgYnJlYWsg c29tZSBzbWFsbCBudW1iZXIgb2YgYXBwcyAod2hvIHdpbGwgdGhlbiBibGFtZSBDaHJvbWUpLiBX ZSBqdXN0IGRvbid0IGtub3cgd2hhdCBpcyBvdXQgdGhlcmUuDQoNCg0KDQpPbiBGcmksIEphbiA5 LCAyMDE1IGF0IDY6MTEgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3BlcnJlYXVsdEBqaXZlLmNvbTxt YWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT4+IHdyb3RlOg0KDQpPbiBGcmksIEphbiA5LCAyMDE1 IGF0IDQ6MTcgQU0sIEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248bWFpbHRv OndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCkFmdGVyIHlvdXIgZGV0YWlsIGFu YWx5c2lzIGFuZCB0aGUgc2VudGVuY2Ug4oCcRm9yIGVpdGhlciBiL2MsIHdlIHdvdWxkIG5lZWQg dG8gc2F5IHRoYXQgaW5jbHVkaW5nIGJvdGggUkFGIGFuZCBPQUYvQUFGIGZvciB0aGUgc2FtZSBh ZGRyZXNzIGZhbWlseSBpcyBwcm9oaWJpdGVkLuKAnSwgSSB0aGluayBpdCBtYXkgYmUgYmV0dGVy IHRvIGtlZXAgb25seSBvbmUgYXR0cmlidXRlIHRvIGZ1bGZpbGwgdGhlIFNTT0RBIHJlcXVpcmVt ZW50Pw0KDQpUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IFNTT0RBIGZ1bmN0aW9uYWxpdHkg YmUgcmVhbGl6ZWQgd2l0aCBvbmx5IG9uZSBhdHRyaWJ1dGUsIG5vciB0aGF0IHRoZSBwcm90b2Nv bCBiZSBlbGVnYW50LCBub3IgdGhhdCBpdCBleGhpYml0cyBzeW1tZXRyeSB0aGF0IGlzIHBsZWFz aW5nIHRvIHRoZSBleWUuDQoNClRoZXJlICppcyogYSByZXF1aXJlbWVudCB0aGF0IGl0IGJlIGJh Y2t3YXJkcy1jb21wYXRpYmxlIHRob3VnaC4gV2hldGhlciB0aGF0IG1lYW5zIGNvbXBhdGlibGUg d2l0aCB0aGUgc3BlYyBvciBjb21wYXRpYmxlIHdpdGggYWN0dWFsIGltcGxlbWVudGF0aW9ucyBp cyBhIG1hdHRlciBvZiBkZWJhdGUuDQoNCkp1c3RpbiwgaWYgd2UgY2FuJ3QgZmluZCBhIHNpbmds ZSBpbXBsZW1lbnRhdGlvbiB0aGF0IHdvdWxkIGJhcmYsIHdoeSB3b3VsZCBDaHJvbWUgaGF2ZSB0 byBpbXBsZW1lbnQgYSBjb21wbGV4IGZhbGxiYWNrIG1lY2hhbmlzbT8NCg0KU2ltb24NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWls aW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBp ZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJh bUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0K DQoNCg0K --_000_6A922A2CE6924A36B6AEF8CC2BCF421Fciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <02758CC9A981D545BCB736C78814FE0E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxNCBK YW4gMjAxNSwgYXQgMjM6NDQsIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJl cnRpQGdvb2dsZS5jb20iIGNsYXNzPSIiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IFdlZCwgSmFuIDE0LCAyMDE1IGF0IDI6NTAgQU0sIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKQ0K PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86cGFsbWFydGlAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+cGFsbWFydGlAY2lzY28uY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiIGNs YXNzPSIiPkhpLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SSBkbyBub3Qgc2VlIGEgcHJvYmxlbSB3aXRoIGEgVFVSTiBzZXJ2ZXIgcmV0dXJuaW5n IGEgNDAwIGVycm9yIGNvZGUgaWYgaXQgZ2V0cyBjb25mdXNlZCBieSB0d28gUkFGcy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhpcyBpcyBhbG1vc3QgY292ZXJlZCBpbiBzZWN0aW9uIDIuNCBvZiB0 aGUgU1NPREEgZHJhZnQuIENsaWVudCBmYWxsYmFjayB0byBub24tU1NPREEgbW9kZSB3aGVuIGVu Y291bnRlcmluZyBhbiBlcnJvciBzZWVtcyB0cml2aWFsLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4oVW5sZXNzIHRoZSBUVVJOIHNlcnZlciBlbmRzIHVwIHVzaW5nIHRvIG11Y2ggQ1BVLCBv dmVyaGVhdHMsIGFuZCBjYXVzZXMgYSBmaXJlIGluIHRoZSBkYXRhY2VudGVyKTwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnV0IEkgbWln aHQgbGlrZSBjKSBiZXR0ZXIgYW55d2F5LiBBZGRpbmcgYSBuZXcgYXR0cmlidXRlIHNlZW1zIGNs ZWFuZXIgd2hlbiBhZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHkuPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlNhdmluZyBhIHJvdW5kdHJpcCAoaS5lLiBieSBub3QgaGF2aW5nIHRvIHJldHJ5KSB3aGVu IGRvaW5nIFNTT0RBIGlzIGFsc28gYSBnb29kIHRoaW5nLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KR29vZCBwb2ludC4gU2luY2UgdGhpcyBwcm9iYWJseSB3b3VsZCB0YWtlIHNvbWUgdGltZSB0 byBkZXBsb3kgb24gdGhlIHNlcnZlciBzaWRlIHRoZSBleHRyYSBjaGF0dGVyIGNvdWxkIGJlY29t ZSBhIGJpdCBhbm5veWluZy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PlRpcnUsIGRvIHlvdSBoYXZlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBhZGQgdGhpcyB0 byB0aGUgVFVSTmJpcyBkcmFmdD8gT3IgZG8geW91IHRoaW5rIG1vcmUgZGlzY3Vzc2lvbiBpcyBu ZWVkZWQ/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4uLS48L2Rpdj4N CjxkaXY+UMOlbC1FcmlrPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4uLS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ UMOlbC1FcmlrPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEyIEphbiAyMDE1LCBhdCAwNjowOCwg VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlA Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dGlyZWRkeUBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6 bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4 IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6 ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 Y29sb3I6cmdiKDMxLDczLDEyNSkiIGNsYXNzPSIiPkFERFJFU1MtRVJST1ItQ09ERSBzZWVtcyB1 c2VmdWwsIGNsaWVudCBjYW4gZGV0ZXJtaW5lIGlmIGl04oCZcyBhIHRlbXBvcmFyeSBvciBsb25n LXRlcm0gZXJyb3IuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250 LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOnJnYigz MSw3MywxMjUpIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3 IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOnJnYigzMSw3MywxMjUpIiBjbGFzcz0i Ij4tVGlydTx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1p bHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMXB0O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpyZ2IoMzEsNzMs MTI1KSIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImJvcmRlci1zdHlsZTpzb2xpZCBub25lIG5vbmU7Ym9yZGVyLXRvcC1jb2xvcjpyZ2Io MTgxLDE5NiwyMjMpO2JvcmRlci10b3Atd2lkdGg6MXB0O3BhZGRpbmc6M3B0IDBpbiAwaW4iIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEy cHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSxzYW5z LXNlcmlmIiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSxzYW5zLXNlcmlmIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+SnVzdGluIFViZXJ0aSBbPGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbSIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbTwvYT5dPHNw YW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6 PC9iPjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwgSmFudWFyeSAxMCwgMjAx NSAyOjE5IEFNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSIi PiZuYnNwOzwvc3Bhbj5PbGVnIE1vc2thbGVua288YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5D Yzo8L2I+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPlNpbW9uIFBlcnJlYXVsdDsgQWlqdW4g V2FuZzsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTs8c3BhbiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjpwdXJwbGU7 dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRyYW1A aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4g Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPlJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXM8dSBjbGFz cz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZh bWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+ Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4g MC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2Vy aWYiIGNsYXNzPSIiPg0KT0ssIHNvIHdlIGhhdmUgY2xlYXIgZXZpZGVuY2UgdGhhdCBzb21lIGRl cGxveWVkIHNlcnZlcnMgd2lsbCBmYWlsIChkZXRlcm1pbmlzdGljYWxseSwgZm9ydHVuYXRlbHkp IG9uIHRoZSBjdXJyZW50IFNTT0RBIHByb3Bvc2FsLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4g MC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2Vy aWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAu MDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlm IiBjbGFzcz0iIj4NClNvIHdlJ3JlIGJhY2sgdG8gd2hpY2ggYmFja3dhcmRzLWNvbXBhdGlibGUg b3B0aW9uIHdlIHdhbnQgdG8gcHVyc3VlLiBJIHN1Z2dlc3QgYyksIHdoaWNoIGlzIHRoZSBvcHRp b25hbC1jb21wcmVoZW5zaW9uIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkuPHUgY2xhc3M9IiI+ PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5 OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4mbmJz cDs8dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTon VGltZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQpTZXBhcmF0ZWx5LCB3ZSBuZWVkIHRv IGRlY2lkZSB3aGV0aGVyIHdlIHdhbnQgdG8gcHVyc3VlIGlzc3VlICMyIHRoYXQgSSBpZGVudGlm aWVkIHByZXZpb3VzbHksIGkuZS4sIGFsbG93aW5nIHNwZWNpZmljIGVycm9yIGNvZGVzIHRvIGJl IHJldHVybmVkIGZvciBlYWNoIGFkZHJlc3MgZmFtaWx5Ljx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAw MXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBj bGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1z aXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0K T24gRnJpLCBKYW4gOSwgMjAxNSBhdCAxMDo1MyBBTSwgT2xlZyBNb3NrYWxlbmtvICZsdDs8YSBo cmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bW9tMDQwMjY3 QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46MGluIDBpbiAxMnB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBO ZXcgUm9tYW4nLHNlcmlmIj4NCkkgZG91YmxlLWNoZWNrZWQgdGhhdCB3aXRoIGEgcmVhbCB0ZXN0 LiBJIHJhbiB0aGUgY29UdXJuIHRlc3QgY2xpZW50ICh0aGF0IGltcGxlbWVudHMgZXhwZXJpbWVu dGFsIFNTT0RBIGRyYWZ0IHdpdGggdHdvIFJBRiBhdHRyaWJ1dGVzKSBhZ2FpbnN0IHJmYzU3NjYt dHVybi1zZXJ2ZXIgYW5kIHRoZSBzZXJ2ZXIgeWllbGRlZCBlcnJvciA0MDAgd2l0aCB0aGUgbWVz c2FnZSAmcXVvdDtPbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQN CiBpbiBhIHJlcXVlc3QmcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo6KDx1IGNs YXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMTJwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWls eTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+DQpBcyBJIHNhaWQsIEkgY2FuIGVsaW1pbmF0ZSB0 aGF0IHByb2JsZW0gaW4gdGhlIHN1YnNlcXVlbnQgcmZjNTc2Ni10dXJuLXNlcnZlciBtYWludGVu YW5jZSByZWxlYXNlcywgYnV0IHN0aWxsLi4uPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGluIDBp biAxMnB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlm Ij4NCkkgYW0gc29ycnkgdGhhdCBJIGRpZCBub3QgZGlzY292ZXIgdGhhdCBwcmV2aW91c2x5IGFu ZCB0aGF0IEkgYWR2b2NhdGVkIGFuIGluY29tcGF0aWJsZSBpbXBsZW1lbnRhdGlvbiBvcHRpb24u PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAxMnB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQt ZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj4NClNvLCBpZiB0aGUgV0cgaW5zaXN0cyBv biBhIGJhY2t3YXJkLWNvbXBhdGlibGUgcHJvdG9jb2wgaW4gYWxsIHNlbnNlcywgdGhlbiB3ZSBo YXZlIHRvIGNob29zZSBhbm90aGVyIG9wdGlvbi48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjowaW4g MGluIDEycHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2Vy aWYiPg0KVGhhbmtzPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMzYsMTM2LDEzNikiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCk9sZWc8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bh bj48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGlt ZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEz NiwxMzYsMTM2KSIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBp biAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxz ZXJpZiIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0 O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFz cz0iIj4NCk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgMTA6MDEgQU0sIE9sZWcgTW9za2FsZW5rbyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHN0eWxlPSJjb2xvcjpwdXJw bGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm1v bTA0MDI2N0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMTJwdDtmb250LXNpemU6MTJwdDtmb250 LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+DQpJIGNoZWNrZWQgdGhlIGNvZGUgb2Yg cmZjNTc2Ni10dXJuLXNlcnZlciBhZ2FpbiwgYW5kIEkgZm91bmQgdGhhdCBpdCB3aWxsIE5PVCBo YW5kbGUgdGhlIG11bHRpcGxlLVJBRiBjYXNlLiBJdCB3aWxsIHJldHVybiA0MDAgZXJyb3Igd2l0 aCB0aGUgbWVzc2FnZSAmcXVvdDtPbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBhdHRyaWJ1dGUgY2Fu IGJlIHVzZWQgaW4gYSByZXF1ZXN0JnF1b3Q7LiBBdCBsZWFzdCwgaXQncyBiZWVuIHRoYXQgd2F5 IGluIHRoZSAyMDE0IHJlbGVhc2VzLg0KIEkgZGlkIG5vdCBjaGVjayB0aGUgb2xkZXIgcmVsZWFz ZXMuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMTJwdDtm b250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiI+DQpTb3Jy eSB0aGF0IEkgcHJvdmlkZWQgYSB3cm9uZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW1wbGVtZW50 YXRpb24sIGJlZm9yZS48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGlu IDBpbiAxMnB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNl cmlmIj4NCkkgY2FuIGZpeCB0aGF0IGNvZGUgYnV0IHN0aWxsIHRoZXJlIGFyZSBwZW9wbGUgb3V0 IHRoZXJlIHdobyB3aWxsIGJlIHVzaW5nIHRoZSAmcXVvdDt3cm9uZyZxdW90OyB2ZXJzaW9ucy48 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46MGluIDBpbiAxMnB0O2ZvbnQt c2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIj4NClNvLCBpZiB3 ZSBkbyBoYXZlIHRvIGJlIGFic29sdXRlbHkgYmFja3dhcmQgY29tcGF0aWJsZSB0aGVuIHdlIGhh dmUgdG8gdXNlIGEgZGlmZmVyZW50IG9wdGlvbi4uLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBp biAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21h bicsc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMzYsMTM2LDEzNiki IGNsYXNzPSIiPk9sZWc8YnIgY2xhc3M9IiI+DQombmJzcDs8dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1m YW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91 PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0 O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFz cz0iIj4NCk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgOTozNCBBTSwgSnVzdGluIFViZXJ0aSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+anViZXJ0 aUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxl Om5vbmUgbm9uZSBub25lIHNvbGlkO2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7 Ym9yZGVyLWxlZnQtd2lkdGg6MXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNnB0O21hcmdpbjo1cHQg MGluIDVwdCA0LjhwdCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250 LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+ DQpJIHJldmlld2VkIHRoZSBjb2RlIGZvciByZXN0dW5kLCByZVR1cm4sIGFuZCByZmM1NzY2LXR1 cm4tc2VydmVyIGFuZCB0aGV5IGFsbCBhcHBlYXIgdG8gaGFuZGxlIFJBRiAoYW5kIG11bHRpcGxl IFJBRikgT0suPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJw dDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8dSBjbGFz cz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7 Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KVGhlIHByb2Js ZW0sIGFzIEkgc2VlIGl0LCBpcyB0aGF0IHRoZXJlIG1heSBiZSBvdGhlciBUVVJOIHNlcnZlcnMs IHBlcmhhcHMgbm9uLW9wZW4tc291cmNlIG9uZXMsIHRoYXQgd29yayBmaW5lIHRvZGF5IHdpdGgg Q2hyb21lLCBidXQgd2lsbCBzdGFydCByZXR1cm5pbmcgZXJyb3JzIHdoZW4gd2UgaW5jbHVkZSBS QUYgb3IgbXVsdGlwbGUgUkFGLCBhbmQgc28gbWFraW5nIHRoaXMgY2hhbmdlIG1heSBicmVhayBz b21lIHNtYWxsIG51bWJlciBvZg0KIGFwcHMgKHdobyB3aWxsIHRoZW4gYmxhbWUgQ2hyb21lKS4g V2UganVzdCBkb24ndCBrbm93IHdoYXQgaXMgb3V0IHRoZXJlLjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMg TmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xh c3M9IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5l dyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNz PSIiPjwvdT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAwMDFw dDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xh c3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6 ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFzcz0iIj4NCk9u IEZyaSwgSmFuIDksIDIwMTUgYXQgNjoxMSBBTSwgU2ltb24gUGVycmVhdWx0ICZsdDs8YSBocmVm PSJtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbSIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+c3BlcnJlYXVsdEBq aXZlLmNvbTwvYT4mZ3Q7IHdyb3RlOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow aW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9t YW4nLHNlcmlmIiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48 L3U+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4w MDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYi IGNsYXNzPSIiPg0KT24gRnJpLCBKYW4gOSwgMjAxNSBhdCA0OjE3IEFNLCBBaWp1biBXYW5nICZs dDs8YSBocmVmPSJtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbiIgc3R5bGU9ImNvbG9y OnB1cnBsZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9 IiI+d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjwvYT4mZ3Q7IHdyb3RlOjx1IGNsYXNzPSIiPjwv dT48dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46MGluIDBpbiAwLjAw MDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJyxzZXJpZiIg Y2xhc3M9IiI+DQpBZnRlciB5b3VyIGRldGFpbCBhbmFseXNpcyBhbmQgdGhlIHNlbnRlbmNlIOKA nEZvciBlaXRoZXIgYi9jLCB3ZSB3b3VsZCBuZWVkIHRvIHNheSB0aGF0IGluY2x1ZGluZyBib3Ro IFJBRiBhbmQgT0FGL0FBRiBmb3IgdGhlIHNhbWUgYWRkcmVzcyBmYW1pbHkgaXMgcHJvaGliaXRl ZC7igJ0sIEkgdGhpbmsgaXQgbWF5IGJlIGJldHRlciB0byBrZWVwIG9ubHkgb25lIGF0dHJpYnV0 ZSB0byBmdWxmaWxsIHRoZSBTU09EQSByZXF1aXJlbWVudD8gJm5ic3A7PHUgY2xhc3M9IiI+PC91 Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAw aW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbics c2VyaWYiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQg dGhhdCBTU09EQSBmdW5jdGlvbmFsaXR5IGJlIHJlYWxpemVkIHdpdGggb25seSBvbmUgYXR0cmli dXRlLCBub3IgdGhhdCB0aGUgcHJvdG9jb2wgYmUgZWxlZ2FudCwgbm9yIHRoYXQgaXQgZXhoaWJp dHMgc3ltbWV0cnkgdGhhdCBpcyBwbGVhc2luZyB0byB0aGUgZXllLjx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGlt ZXMgTmV3IFJvbWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUg Y2xhc3M9IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVz IE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KVGhlcmUgKmlzKiBhIHJlcXVpcmVtZW50IHRo YXQgaXQgYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgdGhvdWdoLiBXaGV0aGVyIHRoYXQgbWVhbnMg Y29tcGF0aWJsZSB3aXRoIHRoZSBzcGVjIG9yIGNvbXBhdGlibGUgd2l0aCBhY3R1YWwgaW1wbGVt ZW50YXRpb25zIGlzIGEgbWF0dGVyIG9mIGRlYmF0ZS48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBS b21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIi PjwvdT48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjow aW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9t YW4nLHNlcmlmIiBjbGFzcz0iIj4NCkp1c3RpbiwgaWYgd2UgY2FuJ3QgZmluZCBhIHNpbmdsZSBp bXBsZW1lbnRhdGlvbiB0aGF0IHdvdWxkIGJhcmYsIHdoeSB3b3VsZCBDaHJvbWUgaGF2ZSB0byBp bXBsZW1lbnQgYSBjb21wbGV4IGZhbGxiYWNrIG1lY2hhbmlzbT88dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVz IE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMzYs MTM2LDEzNikiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0 O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpyZ2IoMTM2LDEzNiwxMzYpIiBjbGFzcz0iIj5TaW1vbjx1IGNsYXNzPSIiPjwv dT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAxcHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1m YW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91 PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAuMDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFt aWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlmIiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4m bmJzcDs8dSBjbGFzcz0iIj48L3U+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjowaW4gMGluIDEycHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1m YW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQp0cmFtIG1haWxpbmcgbGlzdDxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiBzdHlsZT0iY29sb3I6 cHVycGxlO3RleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij50cmFtQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgc3R5bGU9ImNvbG9yOnB1cnBsZTt0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 MGluIDBpbiAwLjAwMDFwdDtmb250LXNpemU6MTJwdDtmb250LWZhbWlseTonVGltZXMgTmV3IFJv bWFuJyxzZXJpZiIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+ PC91PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjowaW4gMGluIDAu MDAwMXB0O2ZvbnQtc2l6ZToxMnB0O2ZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nLHNlcmlm IiBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHls ZTpub25lIG5vbmUgbm9uZSBzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpibHVlO2JvcmRlci1sZWZ0 LXdpZHRoOjEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNHB0IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOjBpbiAwaW4gMC4wMDAx cHQ7Zm9udC1zaXplOjEycHQ7Zm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbicsc2VyaWYiIGNs YXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9y bWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5v bmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7ZmxvYXQ6bm9uZTtkaXNwbGF5 OmlubGluZSFpbXBvcnRhbnQiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh O2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9u dC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdodDpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv bnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1h bDtsaW5lLWhlaWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtmbG9h dDpub25lO2Rpc3BsYXk6aW5saW5lIWltcG9ydGFudCIgY2xhc3M9IiI+dHJhbQ0KIG1haWxpbmcg bGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJw eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1h bDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFs O3dvcmQtc3BhY2luZzowcHgiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5v cmciIHN0eWxlPSJjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTtmb250LWZh bWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUt aGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5z Zm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4IiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9y bWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5v bmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiIGNsYXNzPSIiPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiBzdHlsZT0iY29s b3I6cHVycGxlO3RleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7Zm9udC1mYW1pbHk6SGVsdmV0aWNh O2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9u dC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdodDpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIGNsYXNzPSIiPnRyYW1AaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6A922A2CE6924A36B6AEF8CC2BCF421Fciscocom_-- From nobody Thu Jan 15 06:24:11 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9711B2BFF for ; Thu, 15 Jan 2015 06:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 uNs2IPII2-rP for ; Thu, 15 Jan 2015 06:24:07 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A471B2BFE for ; Thu, 15 Jan 2015 06:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32306; q=dns/txt; s=iport; t=1421331847; x=1422541447; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Iy2wA2tOGFLtQI8T4/cm9SILFv9tosYMhzlScfssYrQ=; b=gsMns25klXxMUUt1aVBIu8R73ZhmspJq7sDzez2W86YFQaqCFujcJBbo afSHeYukKOkQIuJ2q921gvNKm1fzRmm8PFD24ArJE7ZzAf8zQRLp+0GX9 OHBj37gT1JHeQFrJj/3dC9A84BzYk3ml76daDLqhtZ6vWRGyjjnBy/9qx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFACDMt1StJV2Z/2dsb2JhbABagkNDUlgEgwHAbIIbAQmFcQIcdEMBAQEBAX2EDAEBAQQBAQEgCkELEAIBCBEEAQELFgcDAgICHwYLFAkIAQEEAQ0FCIgQAxENvR+PcA2DdQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjU+BeS0EBgEGgmIugRMFhD0Cig2HS4JTilU7gi6DPSKDbm+BAyQefgEBAQ X-IronPort-AV: E=Sophos;i="5.09,403,1418083200"; d="scan'208,217";a="387308127" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jan 2015 14:24:06 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0FEO5Gm016745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Jan 2015 14:24:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 08:24:05 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Pal Martinsen (palmarti)" , Justin Uberti Thread-Topic: [tram] SSODA in TURN-bis Thread-Index: AdAuJda+25AKc4h/S+aWW1oBlMrfVwB9F2kAABjrfAAAGmAqgAAGNleg Date: Thu, 15 Jan 2015 14:24:04 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> In-Reply-To: <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.69.107] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552BF10xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:24:10 -0000 --_000_913383AAA69FF945B8F946018B75898A3552BF10xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAx NSwgMjAxNSA0OjQ5IFBNDQpUbzogSnVzdGluIFViZXJ0aTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gU1NPREEgaW4g VFVSTi1iaXMNCg0KDQpPbiAxNCBKYW4gMjAxNSwgYXQgMjM6NDQsIEp1c3RpbiBVYmVydGkgPGp1 YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCg0K DQpPbiBXZWQsIEphbiAxNCwgMjAxNSBhdCAyOjUwIEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0 aSkgPHBhbG1hcnRpQGNpc2NvLmNvbTxtYWlsdG86cGFsbWFydGlAY2lzY28uY29tPj4gd3JvdGU6 DQpIaSwNCg0KSSBkbyBub3Qgc2VlIGEgcHJvYmxlbSB3aXRoIGEgVFVSTiBzZXJ2ZXIgcmV0dXJu aW5nIGEgNDAwIGVycm9yIGNvZGUgaWYgaXQgZ2V0cyBjb25mdXNlZCBieSB0d28gUkFGcy4NClRo aXMgaXMgYWxtb3N0IGNvdmVyZWQgaW4gc2VjdGlvbiAyLjQgb2YgdGhlIFNTT0RBIGRyYWZ0LiBD bGllbnQgZmFsbGJhY2sgdG8gbm9uLVNTT0RBIG1vZGUgd2hlbiBlbmNvdW50ZXJpbmcgYW4gZXJy b3Igc2VlbXMgdHJpdmlhbC4NCihVbmxlc3MgdGhlIFRVUk4gc2VydmVyIGVuZHMgdXAgdXNpbmcg dG8gbXVjaCBDUFUsIG92ZXJoZWF0cywgYW5kIGNhdXNlcyBhIGZpcmUgaW4gdGhlIGRhdGFjZW50 ZXIpDQoNCkJ1dCBJIG1pZ2h0IGxpa2UgYykgYmV0dGVyIGFueXdheS4gQWRkaW5nIGEgbmV3IGF0 dHJpYnV0ZSBzZWVtcyBjbGVhbmVyIHdoZW4gYWRkaW5nIG5ldyBmdW5jdGlvbmFsaXR5Lg0KDQpT YXZpbmcgYSByb3VuZHRyaXAgKGkuZS4gYnkgbm90IGhhdmluZyB0byByZXRyeSkgd2hlbiBkb2lu ZyBTU09EQSBpcyBhbHNvIGEgZ29vZCB0aGluZy4NCg0KR29vZCBwb2ludC4gU2luY2UgdGhpcyBw cm9iYWJseSB3b3VsZCB0YWtlIHNvbWUgdGltZSB0byBkZXBsb3kgb24gdGhlIHNlcnZlciBzaWRl IHRoZSBleHRyYSBjaGF0dGVyIGNvdWxkIGJlY29tZSBhIGJpdCBhbm5veWluZy4NCg0KVGlydSwg ZG8geW91IGhhdmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGFkZCB0aGlzIHRvIHRoZSBUVVJOYmlz IGRyYWZ0Pw0KDQpbVFJdIFllcywgSWYgdGhlcmUgYXJlIG5vIGZ1cnRoZXIgb2JqZWN0aW9ucyB3 aWxsIHVwZGF0ZSB0aGUgZHJhZnQgbmV4dCB3ZWVrLg0KDQpDaGVlcnMsDQotVGlydQ0KDQpPciBk byB5b3UgdGhpbmsgbW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZD8NCg0KLi0uDQpQw6VsLUVyaWsN Cg0KDQoNCi4tLg0KUMOlbC1FcmlrDQoNCk9uIDEyIEphbiAyMDE1LCBhdCAwNjowOCwgVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlA Y2lzY28uY29tPj4gd3JvdGU6DQoNCkFERFJFU1MtRVJST1ItQ09ERSBzZWVtcyB1c2VmdWwsIGNs aWVudCBjYW4gZGV0ZXJtaW5lIGlmIGl04oCZcyBhIHRlbXBvcmFyeSBvciBsb25nLXRlcm0gZXJy b3IuDQoNCi1UaXJ1DQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb21dDQpTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxMCwgMjAxNSAyOjE5IEFNDQpUbzogT2xl ZyBNb3NrYWxlbmtvDQpDYzogU2ltb24gUGVycmVhdWx0OyBBaWp1biBXYW5nOyBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFt0cmFtXSBTU09EQSBpbiBUVVJOLWJpcw0KDQpPSywgc28gd2UgaGF2ZSBj bGVhciBldmlkZW5jZSB0aGF0IHNvbWUgZGVwbG95ZWQgc2VydmVycyB3aWxsIGZhaWwgKGRldGVy bWluaXN0aWNhbGx5LCBmb3J0dW5hdGVseSkgb24gdGhlIGN1cnJlbnQgU1NPREEgcHJvcG9zYWwu DQoNClNvIHdlJ3JlIGJhY2sgdG8gd2hpY2ggYmFja3dhcmRzLWNvbXBhdGlibGUgb3B0aW9uIHdl IHdhbnQgdG8gcHVyc3VlLiBJIHN1Z2dlc3QgYyksIHdoaWNoIGlzIHRoZSBvcHRpb25hbC1jb21w cmVoZW5zaW9uIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkuDQoNClNlcGFyYXRlbHksIHdlIG5l ZWQgdG8gZGVjaWRlIHdoZXRoZXIgd2Ugd2FudCB0byBwdXJzdWUgaXNzdWUgIzIgdGhhdCBJIGlk ZW50aWZpZWQgcHJldmlvdXNseSwgaS5lLiwgYWxsb3dpbmcgc3BlY2lmaWMgZXJyb3IgY29kZXMg dG8gYmUgcmV0dXJuZWQgZm9yIGVhY2ggYWRkcmVzcyBmYW1pbHkuDQoNCk9uIEZyaSwgSmFuIDks IDIwMTUgYXQgMTA6NTMgQU0sIE9sZWcgTW9za2FsZW5rbyA8bW9tMDQwMjY3QGdtYWlsLmNvbTxt YWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbT4+IHdyb3RlOg0KSSBkb3VibGUtY2hlY2tlZCB0aGF0 IHdpdGggYSByZWFsIHRlc3QuIEkgcmFuIHRoZSBjb1R1cm4gdGVzdCBjbGllbnQgKHRoYXQgaW1w bGVtZW50cyBleHBlcmltZW50YWwgU1NPREEgZHJhZnQgd2l0aCB0d28gUkFGIGF0dHJpYnV0ZXMp IGFnYWluc3QgcmZjNTc2Ni10dXJuLXNlcnZlciBhbmQgdGhlIHNlcnZlciB5aWVsZGVkIGVycm9y IDQwMCB3aXRoIHRoZSBtZXNzYWdlICJPbmx5IG9uZSBhZGRyZXNzIGZhbWlseSBhdHRyaWJ1dGUg Y2FuIGJlIHVzZWQgaW4gYSByZXF1ZXN0Ig0KDQo6KA0KQXMgSSBzYWlkLCBJIGNhbiBlbGltaW5h dGUgdGhhdCBwcm9ibGVtIGluIHRoZSBzdWJzZXF1ZW50IHJmYzU3NjYtdHVybi1zZXJ2ZXIgbWFp bnRlbmFuY2UgcmVsZWFzZXMsIGJ1dCBzdGlsbC4uLg0KSSBhbSBzb3JyeSB0aGF0IEkgZGlkIG5v dCBkaXNjb3ZlciB0aGF0IHByZXZpb3VzbHkgYW5kIHRoYXQgSSBhZHZvY2F0ZWQgYW4gaW5jb21w YXRpYmxlIGltcGxlbWVudGF0aW9uIG9wdGlvbi4NClNvLCBpZiB0aGUgV0cgaW5zaXN0cyBvbiBh IGJhY2t3YXJkLWNvbXBhdGlibGUgcHJvdG9jb2wgaW4gYWxsIHNlbnNlcywgdGhlbiB3ZSBoYXZl IHRvIGNob29zZSBhbm90aGVyIG9wdGlvbi4NClRoYW5rcw0KT2xlZw0KDQoNCk9uIEZyaSwgSmFu IDksIDIwMTUgYXQgMTA6MDEgQU0sIE9sZWcgTW9za2FsZW5rbyA8bW9tMDQwMjY3QGdtYWlsLmNv bTxtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbT4+IHdyb3RlOg0KSSBjaGVja2VkIHRoZSBjb2Rl IG9mIHJmYzU3NjYtdHVybi1zZXJ2ZXIgYWdhaW4sIGFuZCBJIGZvdW5kIHRoYXQgaXQgd2lsbCBO T1QgaGFuZGxlIHRoZSBtdWx0aXBsZS1SQUYgY2FzZS4gSXQgd2lsbCByZXR1cm4gNDAwIGVycm9y IHdpdGggdGhlIG1lc3NhZ2UgIk9ubHkgb25lIGFkZHJlc3MgZmFtaWx5IGF0dHJpYnV0ZSBjYW4g YmUgdXNlZCBpbiBhIHJlcXVlc3QiLiBBdCBsZWFzdCwgaXQncyBiZWVuIHRoYXQgd2F5IGluIHRo ZSAyMDE0IHJlbGVhc2VzLiBJIGRpZCBub3QgY2hlY2sgdGhlIG9sZGVyIHJlbGVhc2VzLg0KU29y cnkgdGhhdCBJIHByb3ZpZGVkIGEgd3JvbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGltcGxlbWVu dGF0aW9uLCBiZWZvcmUuDQpJIGNhbiBmaXggdGhhdCBjb2RlIGJ1dCBzdGlsbCB0aGVyZSBhcmUg cGVvcGxlIG91dCB0aGVyZSB3aG8gd2lsbCBiZSB1c2luZyB0aGUgIndyb25nIiB2ZXJzaW9ucy4N ClNvLCBpZiB3ZSBkbyBoYXZlIHRvIGJlIGFic29sdXRlbHkgYmFja3dhcmQgY29tcGF0aWJsZSB0 aGVuIHdlIGhhdmUgdG8gdXNlIGEgZGlmZmVyZW50IG9wdGlvbi4uLg0KT2xlZw0KDQoNCk9uIEZy aSwgSmFuIDksIDIwMTUgYXQgOTozNCBBTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUu Y29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCkkgcmV2aWV3ZWQgdGhlIGNv ZGUgZm9yIHJlc3R1bmQsIHJlVHVybiwgYW5kIHJmYzU3NjYtdHVybi1zZXJ2ZXIgYW5kIHRoZXkg YWxsIGFwcGVhciB0byBoYW5kbGUgUkFGIChhbmQgbXVsdGlwbGUgUkFGKSBPSy4NCg0KVGhlIHBy b2JsZW0sIGFzIEkgc2VlIGl0LCBpcyB0aGF0IHRoZXJlIG1heSBiZSBvdGhlciBUVVJOIHNlcnZl cnMsIHBlcmhhcHMgbm9uLW9wZW4tc291cmNlIG9uZXMsIHRoYXQgd29yayBmaW5lIHRvZGF5IHdp dGggQ2hyb21lLCBidXQgd2lsbCBzdGFydCByZXR1cm5pbmcgZXJyb3JzIHdoZW4gd2UgaW5jbHVk ZSBSQUYgb3IgbXVsdGlwbGUgUkFGLCBhbmQgc28gbWFraW5nIHRoaXMgY2hhbmdlIG1heSBicmVh ayBzb21lIHNtYWxsIG51bWJlciBvZiBhcHBzICh3aG8gd2lsbCB0aGVuIGJsYW1lIENocm9tZSku IFdlIGp1c3QgZG9uJ3Qga25vdyB3aGF0IGlzIG91dCB0aGVyZS4NCg0KDQoNCk9uIEZyaSwgSmFu IDksIDIwMTUgYXQgNjoxMSBBTSwgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0QGppdmUuY29t PG1haWx0bzpzcGVycmVhdWx0QGppdmUuY29tPj4gd3JvdGU6DQoNCk9uIEZyaSwgSmFuIDksIDIw MTUgYXQgNDoxNyBBTSwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWls dG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+IHdyb3RlOg0KQWZ0ZXIgeW91ciBkZXRhaWwg YW5hbHlzaXMgYW5kIHRoZSBzZW50ZW5jZSDigJxGb3IgZWl0aGVyIGIvYywgd2Ugd291bGQgbmVl ZCB0byBzYXkgdGhhdCBpbmNsdWRpbmcgYm90aCBSQUYgYW5kIE9BRi9BQUYgZm9yIHRoZSBzYW1l IGFkZHJlc3MgZmFtaWx5IGlzIHByb2hpYml0ZWQu4oCdLCBJIHRoaW5rIGl0IG1heSBiZSBiZXR0 ZXIgdG8ga2VlcCBvbmx5IG9uZSBhdHRyaWJ1dGUgdG8gZnVsZmlsbCB0aGUgU1NPREEgcmVxdWly ZW1lbnQ/DQoNClRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgU1NPREEgZnVuY3Rpb25hbGl0 eSBiZSByZWFsaXplZCB3aXRoIG9ubHkgb25lIGF0dHJpYnV0ZSwgbm9yIHRoYXQgdGhlIHByb3Rv Y29sIGJlIGVsZWdhbnQsIG5vciB0aGF0IGl0IGV4aGliaXRzIHN5bW1ldHJ5IHRoYXQgaXMgcGxl YXNpbmcgdG8gdGhlIGV5ZS4NCg0KVGhlcmUgKmlzKiBhIHJlcXVpcmVtZW50IHRoYXQgaXQgYmUg YmFja3dhcmRzLWNvbXBhdGlibGUgdGhvdWdoLiBXaGV0aGVyIHRoYXQgbWVhbnMgY29tcGF0aWJs ZSB3aXRoIHRoZSBzcGVjIG9yIGNvbXBhdGlibGUgd2l0aCBhY3R1YWwgaW1wbGVtZW50YXRpb25z IGlzIGEgbWF0dGVyIG9mIGRlYmF0ZS4NCg0KSnVzdGluLCBpZiB3ZSBjYW4ndCBmaW5kIGEgc2lu Z2xlIGltcGxlbWVudGF0aW9uIHRoYXQgd291bGQgYmFyZiwgd2h5IHdvdWxkIENocm9tZSBoYXZl IHRvIGltcGxlbWVudCBhIGNvbXBsZXggZmFsbGJhY2sgbWVjaGFuaXNtPw0KDQpTaW1vbg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1h aWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFt QGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt DQoNCg0K --_000_913383AAA69FF945B8F946018B75898A3552BF10xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQYWwgTWFy dGluc2VuIChwYWxtYXJ0aSkNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAx NSwgMjAxNSA0OjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gVWJlcnRpOyBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gU1NPREEgaW4gVFVSTi1iaXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE0IEphbiAyMDE1LCBhdCAyMzo0NCwgSnVzdGluIFViZXJ0 aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSI+anViZXJ0aUBnb29nbGUu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIEphbiAxNCwgMjAxNSBhdCAyOjUwIEFNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5wYWxt YXJ0aUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvIG5vdCBzZWUgYSBwcm9ibGVtIHdpdGggYSBUVVJOIHNlcnZlciByZXR1 cm5pbmcgYSA0MDAgZXJyb3IgY29kZSBpZiBpdCBnZXRzIGNvbmZ1c2VkIGJ5IHR3byBSQUZzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBp cyBhbG1vc3QgY292ZXJlZCBpbiBzZWN0aW9uIDIuNCBvZiB0aGUgU1NPREEgZHJhZnQuIENsaWVu dCBmYWxsYmFjayB0byBub24tU1NPREEgbW9kZSB3aGVuIGVuY291bnRlcmluZyBhbiBlcnJvciBz ZWVtcyB0cml2aWFsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+KFVubGVzcyB0aGUgVFVSTiBzZXJ2ZXIgZW5kcyB1cCB1c2luZyB0byBt dWNoIENQVSwgb3ZlcmhlYXRzLCBhbmQgY2F1c2VzIGEgZmlyZSBpbiB0aGUgZGF0YWNlbnRlcik8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0 IEkgbWlnaHQgbGlrZSBjKSBiZXR0ZXIgYW55d2F5LiBBZGRpbmcgYSBuZXcgYXR0cmlidXRlIHNl ZW1zIGNsZWFuZXIgd2hlbiBhZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2F2aW5nIGEg cm91bmR0cmlwIChpLmUuIGJ5IG5vdCBoYXZpbmcgdG8gcmV0cnkpIHdoZW4gZG9pbmcgU1NPREEg aXMgYWxzbyBhIGdvb2QgdGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Hb29kIHBvaW50LiBTaW5jZSB0aGlzIHByb2JhYmx5IHdvdWxkIHRha2Ugc29tZSB0aW1lIHRv IGRlcGxveSBvbiB0aGUgc2VydmVyIHNpZGUgdGhlIGV4dHJhIGNoYXR0ZXIgY291bGQgYmVjb21l IGEgYml0IGFubm95aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaXJ1LCBkbyB5b3UgaGF2ZSBlbm91Z2ggaW5mb3JtYXRpb24g dG8gYWRkIHRoaXMgdG8gdGhlIFRVUk5iaXMgZHJhZnQ/DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bVFJdIFllcywgSWYgdGhlcmUgYXJlIG5vIGZ1cnRoZXIgb2JqZWN0 aW9ucyB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgbmV4dCB3ZWVrLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PciBkbyB5b3UgdGhpbmsgbW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li0uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qw6VsLUVyaWs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li0uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qw6VsLUVyaWs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gMTIgSmFuIDIwMTUsIGF0IDA2OjA4LCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp ICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50 aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5BRERSRVNTLUVSUk9SLUNPREUgc2VlbXMgdXNlZnVsLCBjbGllbnQgY2Fu IGRldGVybWluZSBpZiBpdOKAmXMgYSB0ZW1wb3Jhcnkgb3IgbG9uZy10ZXJtIGVycm9yLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0p1c3RpbiBVYmVydGkgWzxh IGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86anViZXJ0aUBnb29nbGUuY29tPC9zcGFuPjwvYT5d Jm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7U2F0dXJkYXksIEphbnVhcnkgMTAsIDIwMTUg MjoxOSBBTTxicj4NCjxiPlRvOjwvYj4mbmJzcDtPbGVnIE1vc2thbGVua288YnI+DQo8Yj5DYzo8 L2I+Jm5ic3A7U2ltb24gUGVycmVhdWx0OyBBaWp1biBXYW5nOyBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpOyZuYnNwOzxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFt0cmFtXSBTU09EQSBpbiBUVVJOLWJpczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBzbyB3ZSBoYXZlIGNsZWFyIGV2aWRlbmNlIHRoYXQgc29t ZSBkZXBsb3llZCBzZXJ2ZXJzIHdpbGwgZmFpbCAoZGV0ZXJtaW5pc3RpY2FsbHksIGZvcnR1bmF0 ZWx5KSBvbiB0aGUgY3VycmVudCBTU09EQSBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNv IHdlJ3JlIGJhY2sgdG8gd2hpY2ggYmFja3dhcmRzLWNvbXBhdGlibGUgb3B0aW9uIHdlIHdhbnQg dG8gcHVyc3VlLiBJIHN1Z2dlc3QgYyksIHdoaWNoIGlzIHRoZSBvcHRpb25hbC1jb21wcmVoZW5z aW9uIEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNlcGFyYXRlbHksIHdlIG5lZWQgdG8gZGVjaWRlIHdoZXRoZXIgd2Ugd2FudCB0byBwdXJzdWUg aXNzdWUgIzIgdGhhdCBJIGlkZW50aWZpZWQgcHJldmlvdXNseSwgaS5lLiwgYWxsb3dpbmcgc3Bl Y2lmaWMgZXJyb3IgY29kZXMgdG8gYmUgcmV0dXJuZWQgZm9yIGVhY2ggYWRkcmVzcyBmYW1pbHku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgMTA6NTMgQU0sIE9sZWcgTW9za2Fs ZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tb20wNDAyNjdAZ21haWwuY29tPC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SSBkb3VibGUtY2hlY2tlZCB0aGF0IHdpdGggYSByZWFsIHRlc3QuIEkgcmFu IHRoZSBjb1R1cm4gdGVzdCBjbGllbnQgKHRoYXQgaW1wbGVtZW50cyBleHBlcmltZW50YWwgU1NP REEgZHJhZnQgd2l0aCB0d28gUkFGIGF0dHJpYnV0ZXMpIGFnYWluc3QgcmZjNTc2Ni10dXJuLXNl cnZlciBhbmQgdGhlIHNlcnZlciB5aWVsZGVkIGVycm9yIDQwMCB3aXRoIHRoZSBtZXNzYWdlDQog JnF1b3Q7T25seSBvbmUgYWRkcmVzcyBmYW1pbHkgYXR0cmlidXRlIGNhbiBiZSB1c2VkIGluIGEg cmVxdWVzdCZxdW90Ozxicj4NCjxicj4NCjooPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QXMgSSBzYWlkLCBJ IGNhbiBlbGltaW5hdGUgdGhhdCBwcm9ibGVtIGluIHRoZSBzdWJzZXF1ZW50IHJmYzU3NjYtdHVy bi1zZXJ2ZXIgbWFpbnRlbmFuY2UgcmVsZWFzZXMsIGJ1dCBzdGlsbC4uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkkgYW0gc29ycnkgdGhhdCBJIGRpZCBub3QgZGlzY292ZXIgdGhhdCBwcmV2aW91c2x5IGFu ZCB0aGF0IEkgYWR2b2NhdGVkIGFuIGluY29tcGF0aWJsZSBpbXBsZW1lbnRhdGlvbiBvcHRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+U28sIGlmIHRoZSBXRyBpbnNpc3RzIG9uIGEgYmFja3dhcmQtY29t cGF0aWJsZSBwcm90b2NvbCBpbiBhbGwgc2Vuc2VzLCB0aGVuIHdlIGhhdmUgdG8gY2hvb3NlIGFu b3RoZXIgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5rczxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48YnI+DQpPbGVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgMTA6MDEgQU0sIE9sZWcgTW9za2FsZW5rbyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tb20wNDAyNjdAZ21haWwuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBjaGVja2VkIHRoZSBj b2RlIG9mIHJmYzU3NjYtdHVybi1zZXJ2ZXIgYWdhaW4sIGFuZCBJIGZvdW5kIHRoYXQgaXQgd2ls bCBOT1QgaGFuZGxlIHRoZSBtdWx0aXBsZS1SQUYgY2FzZS4gSXQgd2lsbCByZXR1cm4gNDAwIGVy cm9yIHdpdGggdGhlIG1lc3NhZ2UgJnF1b3Q7T25seSBvbmUgYWRkcmVzcyBmYW1pbHkgYXR0cmli dXRlIGNhbiBiZSB1c2VkIGluIGEgcmVxdWVzdCZxdW90Oy4NCiBBdCBsZWFzdCwgaXQncyBiZWVu IHRoYXQgd2F5IGluIHRoZSAyMDE0IHJlbGVhc2VzLiBJIGRpZCBub3QgY2hlY2sgdGhlIG9sZGVy IHJlbGVhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Tb3JyeSB0aGF0IEkgcHJvdmlkZWQg YSB3cm9uZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW1wbGVtZW50YXRpb24sIGJlZm9yZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SSBjYW4gZml4IHRoYXQgY29kZSBidXQgc3RpbGwgdGhlcmUg YXJlIHBlb3BsZSBvdXQgdGhlcmUgd2hvIHdpbGwgYmUgdXNpbmcgdGhlICZxdW90O3dyb25nJnF1 b3Q7IHZlcnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TbywgaWYgd2UgZG8gaGF2ZSB0 byBiZSBhYnNvbHV0ZWx5IGJhY2t3YXJkIGNvbXBhdGlibGUgdGhlbiB3ZSBoYXZlIHRvIHVzZSBh IGRpZmZlcmVudCBvcHRpb24uLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+T2xlZzxi cj4NCiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGcmksIEphbiA5LCAyMDE1IGF0IDk6MzQgQU0sIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhy ZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5qdWJlcnRpQGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJldmlld2VkIHRoZSBjb2RlIGZvciByZXN0dW5k LCByZVR1cm4sIGFuZCByZmM1NzY2LXR1cm4tc2VydmVyIGFuZCB0aGV5IGFsbCBhcHBlYXIgdG8g aGFuZGxlIFJBRiAoYW5kIG11bHRpcGxlIFJBRikgT0suPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg cHJvYmxlbSwgYXMgSSBzZWUgaXQsIGlzIHRoYXQgdGhlcmUgbWF5IGJlIG90aGVyIFRVUk4gc2Vy dmVycywgcGVyaGFwcyBub24tb3Blbi1zb3VyY2Ugb25lcywgdGhhdCB3b3JrIGZpbmUgdG9kYXkg d2l0aCBDaHJvbWUsIGJ1dCB3aWxsIHN0YXJ0IHJldHVybmluZyBlcnJvcnMgd2hlbiB3ZSBpbmNs dWRlIFJBRiBvciBtdWx0aXBsZSBSQUYsIGFuZCBzbyBtYWtpbmcgdGhpcyBjaGFuZ2UgbWF5IGJy ZWFrDQogc29tZSBzbWFsbCBudW1iZXIgb2YgYXBwcyAod2hvIHdpbGwgdGhlbiBibGFtZSBDaHJv bWUpLiBXZSBqdXN0IGRvbid0IGtub3cgd2hhdCBpcyBvdXQgdGhlcmUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgNjoxMSBBTSwgU2ltb24gUGVycmVhdWx0ICZsdDs8 YSBocmVmPSJtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNwZXJyZWF1bHRAaml2ZS5jb208L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDksIDIwMTUgYXQgNDoxNyBBTSwg QWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53YW5nYWlqdW5AdHNp bmdodWEub3JnLmNuPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXIgeW91ciBkZXRhaWwgYW5hbHlzaXMg YW5kIHRoZSBzZW50ZW5jZSDigJxGb3IgZWl0aGVyIGIvYywgd2Ugd291bGQgbmVlZCB0byBzYXkg dGhhdCBpbmNsdWRpbmcgYm90aCBSQUYgYW5kIE9BRi9BQUYgZm9yIHRoZSBzYW1lIGFkZHJlc3Mg ZmFtaWx5IGlzIHByb2hpYml0ZWQu4oCdLCBJIHRoaW5rIGl0IG1heSBiZSBiZXR0ZXIgdG8ga2Vl cCBvbmx5IG9uZSBhdHRyaWJ1dGUgdG8gZnVsZmlsbCB0aGUgU1NPREENCiByZXF1aXJlbWVudD8g Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NClRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgU1NPREEgZnVuY3Rp b25hbGl0eSBiZSByZWFsaXplZCB3aXRoIG9ubHkgb25lIGF0dHJpYnV0ZSwgbm9yIHRoYXQgdGhl IHByb3RvY29sIGJlIGVsZWdhbnQsIG5vciB0aGF0IGl0IGV4aGliaXRzIHN5bW1ldHJ5IHRoYXQg aXMgcGxlYXNpbmcgdG8gdGhlIGV5ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUg KmlzKiBhIHJlcXVpcmVtZW50IHRoYXQgaXQgYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgdGhvdWdo LiBXaGV0aGVyIHRoYXQgbWVhbnMgY29tcGF0aWJsZSB3aXRoIHRoZSBzcGVjIG9yIGNvbXBhdGli bGUgd2l0aCBhY3R1YWwgaW1wbGVtZW50YXRpb25zIGlzIGEgbWF0dGVyIG9mIGRlYmF0ZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdGluLCBpZiB3ZSBjYW4ndCBmaW5kIGEgc2luZ2xl IGltcGxlbWVudGF0aW9uIHRoYXQgd291bGQgYmFyZiwgd2h5IHdvdWxkIENocm9tZSBoYXZlIHRv IGltcGxlbWVudCBhIGNvbXBsZXggZmFsbGJhY2sgbWVjaGFuaXNtPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij5TaW1vbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJh bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+ PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxlIj50cmFtQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A3552BF10xmbrcdx10ciscoc_-- From nobody Thu Jan 15 22:02:19 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027181ABD8F for ; Thu, 15 Jan 2015 22:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.69 X-Spam-Level: ** X-Spam-Status: No, score=2.69 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 snInNXbPijXh for ; Thu, 15 Jan 2015 22:02:13 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2841A9138 for ; Thu, 15 Jan 2015 22:02:09 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06Cb4Am9k7hUEB_rAA==.59718S4; Fri, 16 Jan 2015 12:29:55 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Pal Martinsen \(palmarti\)'" , "'Justin Uberti'" References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> Date: Fri, 16 Jan 2015 14:01:51 +0800 Message-ID: <006101d03151$edf85010$c9e8f030$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01D03194.FC1B9010" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAuJda+25AKc4h/S+aWW1oBlMrfVwB9F2kAABjrfAAAGmAqgAAGNlegABNo+1A= Content-Language: zh-cn X-CM-TRANSID: Z0GX06Cb4Am9k7hUEB_rAA==.59718S4 X-Coremail-Antispam: 1U3129KBjvJXoWxtrW7KFWxJF4rXr48uF1xXwb_yoW3Ww18pF W3Gry5Gr4kJF1xC3ykZr4xWryFvrZ5GFyDGrn5Kr12y398WasFqry8tw4Y9Fy7Grs5ua1j vr4j9r47ZryfZ3DanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r126r1D0xZFpf9x0JUZVyxUUUUU= Archived-At: Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 06:02:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0062_01D03194.FC1B9010 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi,Tiru,Pal and Justin: =20 I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D = attribute to fulfill the function of SSODA by clarifying the behavior of = TURN server based on whether this attribute is present or not: =20 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the = allocated relay address family will be same as the source = address=E2=80=99s family of Allocate Request message. = https://tools.ietf.org/html/rfc6156#section-4.2 has the following = description: =20 =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST allocate an IPv4-relayed transport address for the TURN client. If allocation of IPv4 addresses is disabled by local policy, the server returns a 440 (Address Family not Supported) Allocate error = response.=E2=80=9D =20 This paragraph should be modified as below: =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST allocate an relayed transport address from the same family as the = source address of Allocate Request message for the TURN client. If this allocation is disabled by local policy, the server returns a 440 (Address Family not Supported) Allocate error = response.=E2=80=9D =20 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the following = procedure of the client and server should only need to conform to = https://tools.ietf.org/html/rfc6156, no new attribute and procedure need = be introduced.=20 =20 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribute = Family=E2=80=9D attribute that I proposed previously. Will such = solution be less confusable and be less prone to problem to the TURN = developer? RFC6156 also describes the following sentence: =E2=80=9CThe REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address).=E2=80=9D If we can change the name of the attribute, then change the attribute = name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional = Attribute Family=E2=80=9D may be more better. If this is impossible, we = just need only update the behavior of TURN server that described in = RFC6156, as I suggested above. =20 Best Regards. Aijun Wang =20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) Sent: Thursday, January 15, 2015 10:24 PM To: Pal Martinsen (palmarti); Justin Uberti Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 From: Pal Martinsen (palmarti)=20 Sent: Thursday, January 15, 2015 4:49 PM To: Justin Uberti; Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 =20 On 14 Jan 2015, at 23:44, Justin Uberti wrote: =20 =20 =20 On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) = wrote: Hi,=20 =20 I do not see a problem with a TURN server returning a 400 error code if = it gets confused by two RAFs. This is almost covered in section 2.4 of the SSODA draft. Client = fallback to non-SSODA mode when encountering an error seems trivial.=20 (Unless the TURN server ends up using to much CPU, overheats, and causes = a fire in the datacenter) =20 But I might like c) better anyway. Adding a new attribute seems cleaner = when adding new functionality. =20 Saving a roundtrip (i.e. by not having to retry) when doing SSODA is = also a good thing. =20 Good point. Since this probably would take some time to deploy on the = server side the extra chatter could become a bit annoying.=20 =20 Tiru, do you have enough information to add this to the TURNbis draft?=20 =20 [TR] Yes, If there are no further objections will update the draft next = week. =20 Cheers, -Tiru =20 Or do you think more discussion is needed? =20 .-. P=C3=A5l-Erik =20 =20 .-. P=C3=A5l-Erik =20 On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) = wrote: =20 ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a = temporary or long-term error. =20 -Tiru =20 From: Justin Uberti [ = mailto:juberti@google.com]=20 Sent: Saturday, January 10, 2015 2:19 AM To: Oleg Moskalenko Cc: Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); = tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 OK, so we have clear evidence that some deployed servers will fail = (deterministically, fortunately) on the current SSODA proposal. =20 So we're back to which backwards-compatible option we want to pursue. I = suggest c), which is the optional-comprehension = ADDITIONAL-ADDRESS-FAMILY. =20 Separately, we need to decide whether we want to pursue issue #2 that I = identified previously, i.e., allowing specific error codes to be = returned for each address family. =20 On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko < = mom040267@gmail.com> wrote: I double-checked that with a real test. I ran the coTurn test client = (that implements experimental SSODA draft with two RAF attributes) = against rfc5766-turn-server and the server yielded error 400 with the = message "Only one address family attribute can be used in a request" :( As I said, I can eliminate that problem in the subsequent = rfc5766-turn-server maintenance releases, but still... I am sorry that I did not discover that previously and that I advocated = an incompatible implementation option. So, if the WG insists on a backward-compatible protocol in all senses, = then we have to choose another option. Thanks Oleg =20 =20 On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko < = mom040267@gmail.com> wrote: I checked the code of rfc5766-turn-server again, and I found that it = will NOT handle the multiple-RAF case. It will return 400 error with the = message "Only one address family attribute can be used in a request". At = least, it's been that way in the 2014 releases. I did not check the = older releases. Sorry that I provided a wrong information about the implementation, = before. I can fix that code but still there are people out there who will be = using the "wrong" versions. So, if we do have to be absolutely backward compatible then we have to = use a different option... Oleg =20 =20 On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti < = juberti@google.com> wrote: I reviewed the code for restund, reTurn, and rfc5766-turn-server and = they all appear to handle RAF (and multiple RAF) OK. =20 The problem, as I see it, is that there may be other TURN servers, = perhaps non-open-source ones, that work fine today with Chrome, but will = start returning errors when we include RAF or multiple RAF, and so = making this change may break some small number of apps (who will then = blame Chrome). We just don't know what is out there. =20 =20 =20 On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault < = sperreault@jive.com> wrote: =20 On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang < = wangaijun@tsinghua.org.cn> wrote: After your detail analysis and the sentence =E2=80=9CFor either b/c, we = would need to say that including both RAF and OAF/AAF for the same = address family is prohibited.=E2=80=9D, I think it may be better to keep = only one attribute to fulfill the SSODA requirement? =20 There is no requirement that SSODA functionality be realized with only = one attribute, nor that the protocol be elegant, nor that it exhibits = symmetry that is pleasing to the eye. =20 There *is* a requirement that it be backwards-compatible though. Whether = that means compatible with the spec or compatible with actual = implementations is a matter of debate. =20 Justin, if we can't find a single implementation that would barf, why = would Chrome have to implement a complex fallback mechanism? =20 Simon =20 =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_0062_01D03194.FC1B9010 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,Tiru,Pal and Justin:

 

I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D = attribute to fulfill the function of SSODA by clarifying the behavior of = TURN server based on whether this attribute is present or = not:

 

1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the = allocated relay address family will be same as the source = address=E2=80=99s family =C2=A0of Allocate Request message. =C2=A0https://tools.ie= tf.org/html/rfc6156#section-4.2 has the following = description:

 

=E2=80=9CIf the =
REQUESTED-ADDRESS-FAMILY attribute is absent, the server =
MUST

=C2=A0=C2=A0 = allocate an IPv4-relayed transport address for the TURN client.=C2=A0 = If

=C2=A0=C2=A0 = allocation of IPv4 addresses is disabled by local policy, the = server

=C2=A0=C2=A0 = returns a 440 (Address Family not Supported) Allocate error = response.=E2=80=9D

 

This paragraph should be modified as below:

=E2=80=9CIf the =
REQUESTED-ADDRESS-FAMILY attribute is absent, the server =
MUST

=C2=A0=C2=A0 = allocate an relayed transport address from the same family as the = source address of Allocate Request message for the TURN = client.=C2=A0 If this

=C2=A0=C2=A0 = allocation is disabled = by local policy, the server

=C2=A0=C2=A0 = returns a 440 (Address Family not Supported) Allocate error = response.=E2=80=9D

 

2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the = following procedure of the client and server should only need to conform = to https://tools.ietf.org/html/= rfc6156, no new attribute and procedure need be introduced. =

 

3. Here, the RAF attribute act just as the =E2=80=9CAdditional = Attribute Family=E2=80=9D attribute that I proposed previously. = =C2=A0Will such solution be less confusable and be less prone to problem = to the TURN developer?

RFC6156 also describes the following =
sentence:
=E2=80=9CThe =
REQUESTED-ADDRESS-FAMILY
=C2=A0=C2=A0 attribute allows a client to =
explicitly request the address type =
the
=C2=A0=C2=A0 TURN server will allocate (e.g., =
an IPv4-only node may request the
=C2=A0=C2=A0 TURN server to =
allocate an IPv6 address).=E2=80=9D

If we can change the name of the attribute, then change the attribute = name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional Attribute Family=E2=80=9D may be more better. If this is impossible, we just need = only update the behavior of TURN server that described in RFC6156, = =C2=A0as I suggested above.

 

Best Regards.

Aijun Wang

 

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Thursday, January 15, 2015 10:24 = PM
To: Pal Martinsen (palmarti); Justin Uberti
Cc: = tram@ietf.org
Subject: Re: [tram] SSODA in = TURN-bis

 

From:= Pal = Martinsen (palmarti)
Sent: Thursday, January 15, 2015 4:49 = PM
To: Justin Uberti; Tirumaleswar Reddy = (tireddy)
Cc: tram@ietf.org
Subject: Re: = [tram] SSODA in TURN-bis

 

 

On 14 Jan 2015, at 23:44, Justin = Uberti <juberti@google.com> = wrote:

 

 

 

On Wed, Jan 14, 2015 at 2:50 AM, = Pal Martinsen (palmarti) <palmarti@cisco.com> = wrote:

Hi,

 

I do not see a problem with a TURN = server returning a 400 error code if it gets confused by two = RAFs.

This is almost covered in section 2.4 of the SSODA draft. = Client fallback to non-SSODA mode when encountering an error seems = trivial. 

(Unless the TURN server ends up = using to much CPU, overheats, and causes a fire in the = datacenter)

 

But I might like c) better anyway. = Adding a new attribute seems cleaner when adding new = functionality.

 

Saving a roundtrip (i.e. by not = having to retry) when doing SSODA is also a good = thing.

 

Good point. Since this probably = would take some time to deploy on the server side the extra chatter = could become a bit annoying. 

 

Tiru, do you have enough = information to add this to the TURNbis draft?

 

[TR] Yes, If there are no further objections will update the draft = next week.

 

Cheers,

-Tiru

 

Or do you think more discussion is = needed?

 

.-.

P=C3=A5l-Erik

 

 

.-.

P=C3=A5l-Erik

 

On 12 Jan 2015, at 06:08, = Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> = wrote:

 

ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s = a temporary or long-term error.

 

-Tiru

 

From:=  Justin= Uberti [mailto:juberti@google.com] 
= Sent: Saturday, January 10, 2015 2:19 = AM
To: Oleg Moskalenko
Cc: Simon = Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: R= e: [tram] SSODA in TURN-bis

 

OK, so we have clear evidence that = some deployed servers will fail (deterministically, fortunately) on the = current SSODA proposal.

 

So we're back to which = backwards-compatible option we want to pursue. I suggest c), which is = the optional-comprehension = ADDITIONAL-ADDRESS-FAMILY.

 

Separately, we need to decide = whether we want to pursue issue #2 that I identified previously, i.e., = allowing specific error codes to be returned for each address = family.

 

On Fri, Jan 9, 2015 at 10:53 AM, = Oleg Moskalenko <mom040267@gmail.com> = wrote:

I = double-checked that with a real test. I ran the coTurn test client (that = implements experimental SSODA draft with two RAF attributes) against = rfc5766-turn-server and the server yielded error 400 with the message = "Only one address family attribute can be used in a = request"

:(

As I said, I can = eliminate that problem in the subsequent rfc5766-turn-server maintenance = releases, but still...

I am sorry that I did = not discover that previously and that I advocated an incompatible = implementation option.

So, if the WG insists = on a backward-compatible protocol in all senses, then we have to choose = another option.

Thanks
Oleg

 

 

On Fri, Jan 9, 2015 at 10:01 AM, = Oleg Moskalenko <mom040267@gmail.com> = wrote:

I checked the code of = rfc5766-turn-server again, and I found that it will NOT handle the = multiple-RAF case. It will return 400 error with the message "Only = one address family attribute can be used in a request". At least, = it's been that way in the 2014 releases. I did not check the older = releases.

Sorry that I provided = a wrong information about the implementation, = before.

I can fix that code = but still there are people out there who will be using the = "wrong" versions.

So, = if we do have to be absolutely backward compatible then we have to use a = different option...

Oleg
 

 

On Fri, Jan 9, 2015 at 9:34 AM, = Justin Uberti <juberti@google.com> = wrote:

I = reviewed the code for restund, reTurn, and rfc5766-turn-server and they = all appear to handle RAF (and multiple RAF) = OK.

 

The problem, as I see it, is that = there may be other TURN servers, perhaps non-open-source ones, that work = fine today with Chrome, but will start returning errors when we include = RAF or multiple RAF, and so making this change may break some small = number of apps (who will then blame Chrome). We just don't know what is = out there.

 

 

 

On Fri, Jan 9, 2015 at 6:11 AM, = Simon Perreault <sperreault@jive.com> = wrote:

 

On Fri, Jan 9, 2015 at 4:17 AM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

After your detail analysis and the sentence =E2=80=9CFor = either b/c, we would need to say that including both RAF and OAF/AAF for = the same address family is prohibited.=E2=80=9D, I think it may be = better to keep only one attribute to fulfill the SSODA requirement? =  


There is no requirement that SSODA functionality be = realized with only one attribute, nor that the protocol be elegant, nor = that it exhibits symmetry that is pleasing to the = eye.

 

There *is* a requirement that it be = backwards-compatible though. Whether that means compatible with the spec = or compatible with actual implementations is a matter of = debate.

 

Justin, if we can't find a single = implementation that would barf, why would Chrome have to implement a = complex fallback = mechanism?

 

Simon

 

 

_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram<= /a>

 

__________= _____________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 


_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

------=_NextPart_000_0062_01D03194.FC1B9010-- From nobody Thu Jan 15 22:23:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A348A1AC399 for ; Thu, 15 Jan 2015 22:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no 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 ohPwI_VKsEZq for ; Thu, 15 Jan 2015 22:23:48 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63581AC398 for ; Thu, 15 Jan 2015 22:23:47 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id bs8so2400986wib.0 for ; Thu, 15 Jan 2015 22:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zRyyTEyYDFOy7Jnd5OStslI61wM71vS4dy+Q2562ZaM=; b=TtfiDNnSi2rVuSJqi/9plc40AAE/dAyIQtKZMuxtzHfvYXCtcUNuuPoC2KLoIjrGLk 91S9jn/OlpUeDBUHd4rmw5CK9mynS7aqInFrO6hQ/Ai1lkx7Gf1x7KqMWXwiOWlye7K3 YECTzs+ww/eDvH5sSYEv+PUOoyBlaf/3JiyjwaB304y7UxiDToD04rhS+5fZSVXeW+r4 d9QJV+Ve+lCop/aRU3Rf+2xyI6gJSUbPOjnB9q2US6OFYb7z4i8x6oFPPrGZV1CnYSmg uYgOIVNqrXajCIbUAo/kxLTPqK1Hf/RPnx8R8E/nC22Bu44wDq7DQA5WGyh+4rguT+Z0 8dgA== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr2903551wiw.21.1421389426395; Thu, 15 Jan 2015 22:23:46 -0800 (PST) Received: by 10.194.87.98 with HTTP; Thu, 15 Jan 2015 22:23:46 -0800 (PST) In-Reply-To: <006101d03151$edf85010$c9e8f030$@org.cn> References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> Date: Thu, 15 Jan 2015 22:23:46 -0800 Message-ID: From: Oleg Moskalenko To: Aijun Wang Content-Type: multipart/alternative; boundary=f46d04389577d91187050cbf03b9 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 06:23:51 -0000 --f46d04389577d91187050cbf03b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that that proposal makes sense. But I am not sure that it is backward-compatible enough. We have to go through all cases of SSODA/non-SSODA entities communicating, for different protocol request options. Aijun, would you like to go through all those cases to double-check that it works as supposed ? Thanks Oleg On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang wrote: > Hi,Tiru,Pal and Justin: > > > > I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attribute= to fulfill the > function of SSODA by clarifying the behavior of TURN server based on > whether this attribute is present or not: > > > > 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the alloca= ted relay address > family will be same as the source address=E2=80=99s family of Allocate R= equest > message. https://tools.ietf.org/html/rfc6156#section-4.2 has the > following description: > > > > =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST > > allocate an IPv4-relayed transport address for the TURN client. If > > allocation of IPv4 addresses is disabled by local policy, the server > > returns a 440 (Address Family not Supported) Allocate error response.= =E2=80=9D > > > > This paragraph should be modified as below: > > =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST > > allocate an relayed transport address *from the same family as the > source address of Allocate Request message* for the TURN client. If > *this* > > * allocation* is disabled by local policy, the server > > returns a 440 (Address Family not Supported) Allocate error response.= =E2=80=9D > > > > 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the following = procedure of the > client and server should only need to conform to > https://tools.ietf.org/html/rfc6156, no new attribute and procedure need > be introduced. > > > > 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribute = Family=E2=80=9D > attribute that I proposed previously. Will such solution be less > confusable and be less prone to problem to the TURN developer? > > RFC6156 also describes the following sentence: > > =E2=80=9CThe REQUESTED-ADDRESS-FAMILY > > attribute allows a client to *explicitly* request the address type the > > TURN server will allocate (e.g., an IPv4-only node may request the > > TURN server to allocate an IPv6 address).=E2=80=9D > > If we can change the name of the attribute, then change the attribute nam= e > =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional Attribu= te Family=E2=80=9D may be more > better. If this is impossible, we just need only update the behavior of > TURN server that described in RFC6156, as I suggested above. > > > > Best Regards. > > Aijun Wang > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Tirumaleswar > Reddy (tireddy) > *Sent:* Thursday, January 15, 2015 10:24 PM > *To:* Pal Martinsen (palmarti); Justin Uberti > > *Cc:* tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > *From:* Pal Martinsen (palmarti) > *Sent:* Thursday, January 15, 2015 4:49 PM > *To:* Justin Uberti; Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > > > On 14 Jan 2015, at 23:44, Justin Uberti wrote: > > > > > > > > On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com> wrote: > > Hi, > > > > I do not see a problem with a TURN server returning a 400 error code if i= t > gets confused by two RAFs. > > This is almost covered in section 2.4 of the SSODA draft. Client fallback > to non-SSODA mode when encountering an error seems trivial. > > (Unless the TURN server ends up using to much CPU, overheats, and causes = a > fire in the datacenter) > > > > But I might like c) better anyway. Adding a new attribute seems cleaner > when adding new functionality. > > > > Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also > a good thing. > > > > Good point. Since this probably would take some time to deploy on the > server side the extra chatter could become a bit annoying. > > > > Tiru, do you have enough information to add this to the TURNbis draft? > > > > [TR] Yes, If there are no further objections will update the draft next > week. > > > > Cheers, > > -Tiru > > > > Or do you think more discussion is needed? > > > > .-. > > P=C3=A5l-Erik > > > > > > .-. > > P=C3=A5l-Erik > > > > On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) > wrote: > > > > ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a t= emporary > or long-term error. > > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Saturday, January 10, 2015 2:19 AM > *To:* Oleg Moskalenko > *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); > tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > OK, so we have clear evidence that some deployed servers will fail > (deterministically, fortunately) on the current SSODA proposal. > > > > So we're back to which backwards-compatible option we want to pursue. I > suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY= . > > > > Separately, we need to decide whether we want to pursue issue #2 that I > identified previously, i.e., allowing specific error codes to be returned > for each address family. > > > > On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko > wrote: > > I double-checked that with a real test. I ran the coTurn test client (tha= t > implements experimental SSODA draft with two RAF attributes) against > rfc5766-turn-server and the server yielded error 400 with the message "On= ly > one address family attribute can be used in a request" > > :( > > As I said, I can eliminate that problem in the subsequent > rfc5766-turn-server maintenance releases, but still... > > I am sorry that I did not discover that previously and that I advocated a= n > incompatible implementation option. > > So, if the WG insists on a backward-compatible protocol in all senses, > then we have to choose another option. > > Thanks > Oleg > > > > > > On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko > wrote: > > I checked the code of rfc5766-turn-server again, and I found that it will > NOT handle the multiple-RAF case. It will return 400 error with the messa= ge > "Only one address family attribute can be used in a request". At least, > it's been that way in the 2014 releases. I did not check the older releas= es. > > Sorry that I provided a wrong information about the implementation, befor= e. > > I can fix that code but still there are people out there who will be usin= g > the "wrong" versions. > > So, if we do have to be absolutely backward compatible then we have to us= e > a different option... > > Oleg > > > > > On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti wrote: > > I reviewed the code for restund, reTurn, and rfc5766-turn-server and they > all appear to handle RAF (and multiple RAF) OK. > > > > The problem, as I see it, is that there may be other TURN servers, perhap= s > non-open-source ones, that work fine today with Chrome, but will start > returning errors when we include RAF or multiple RAF, and so making this > change may break some small number of apps (who will then blame Chrome). = We > just don't know what is out there. > > > > > > > > On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault > wrote: > > > > On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang > wrote: > > After your detail analysis and the sentence =E2=80=9CFor either b/c, we w= ould need > to say that including both RAF and OAF/AAF for the same address family is > prohibited.=E2=80=9D, I think it may be better to keep only one attribute= to > fulfill the SSODA requirement? > > > There is no requirement that SSODA functionality be realized with only on= e > attribute, nor that the protocol be elegant, nor that it exhibits symmetr= y > that is pleasing to the eye. > > > > There *is* a requirement that it be backwards-compatible though. Whether > that means compatible with the spec or compatible with actual > implementations is a matter of debate. > > > > Justin, if we can't find a single implementation that would barf, why > would Chrome have to implement a complex fallback mechanism? > > > > Simon > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --f46d04389577d91187050cbf03b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that that proposal makes sense. But I am not = sure that it is backward-compatible enough. We have to go through all cases= of SSODA/non-SSODA entities communicating, for different protocol request = options.

Aijun, would you like to go through all those cases t= o double-check that it works as supposed ?

Thanks
Oleg


On Thu, Jan 15= , 2015 at 10:01 PM, Aijun Wang <wangaijun@tsinghua.org.cn><= /span> wrote:

Hi,Tiru,Pal and Justin:

=C2=A0

I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attribut= e to fulfill the function of SSODA by clarifying the behavior of TURN serve= r based on whether this attribute is present or not:

= =C2=A0

1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, the= n the allocated relay address family will be same as the source address=E2= =80=99s family =C2=A0of Allocate Request message. =C2=A0https://tools.ie= tf.org/html/rfc6156#section-4.2 has the following description:

=C2=A0

=E2=80=9CIf =
the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST=

=C2=A0=C2=A0 allocate an IPv4-rela= yed transport address for the TURN client.=C2=A0 If

=C2=A0=C2=A0 allocation of IPv4 addresses is disa= bled by local policy, the server

=C2=A0=C2=A0 returns a 440 (Address Family not Supported) Allocate = error response.=E2=80=9D

=C2=A0

This paragraph should be modified as belo= w:

=
=E2=80=9CIf the REQUEST=
ED-ADDRESS-FAMILY attribute is absent, the server MUST=

=C2=A0=C2=A0 allocate an relayed transport = address from the same family as the source address of Allocate Request m= essage for the TURN client.=C2=A0 If this

=C2=A0=C2=A0 allocation is disabl= ed by local policy, the server

=C2=A0=C2=A0 returns a 440 (Address Family not Supported) Allocate erro= r response.=E2=80=9D

=C2=A0

2. If the =E2=80=9CRAF=E2=80=9D attribute i= s present, then the following procedure of the client and server should onl= y need to conform to https://tools.ietf.org/html/rfc6156, no new attribute and p= rocedure need be introduced.

=C2=A0

=

3. Here, t= he RAF attribute act just as the =E2=80=9CAdditional Attribute Family=E2=80= =9D attribute that I proposed previously.=C2=A0 Will such solution be less = confusable and be less prone to problem to the TURN developer?

RFC6156 also des=
cribes the following sentence:
=E2=80=9CThe REQUESTED-ADDRESS-FAMILY
=C2=A0=C2=A0 attribute allow= s a client to explicitly request the address type the<= /span>
=C2=A0=C2=A0 =
TURN server will allocate (e.g., an IPv4-only node may request the
=C2=A0=
=C2=A0 TURN server to allocate an IPv6 address).=E2=80=9D

If w= e can change the name of the attribute, then change the attribute name =E2= =80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional Attribute Family=E2=80=9D may be more better. If this is impossible= , we just need only update the behavior of TURN server that described in RF= C6156, =C2=A0as I suggested above.

=C2=A0

Best Regard= s.

Aijun Wang

=C2=A0

=C2=A0

<= div class=3D"h5">

=C2=A0<= u>

From:= Pal Martinsen (palmarti)
Sent= : Thursday, January 15, 2015 4:49 PM
To: Justin Uberti; Tirum= aleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] SSODA in TURN= -bis

=C2=A0

=C2=A0

On 14 Ja= n 2015, at 23:44, Justin Uberti <juberti@google.com> wrote:

=

=C2=A0

=C2=A0

=C2= =A0

On We= d, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:<= /u>

Hi, <= u>

=C2=A0

I do not see a problem with a TURN server returning a 400 error = code if it gets confused by two RAFs.

This is almost covered in section= 2.4 of the SSODA draft. Client fallback to non-SSODA mode when encounterin= g an error seems trivial.=C2=A0

(Unless the TURN server ends up using t= o much CPU, overheats, and causes a fire in the datacenter)

=C2= =A0

But I might like c) better anyway. Adding a new attribute seems cleaner wh= en adding new functionality.

=C2=A0

Saving a roundtrip (i.e. = by not having to retry) when doing SSODA is also a good thing.

=C2=A0

Good point. Since this probably would t= ake some time to deploy on the server side the extra chatter could become a= bit annoying.=C2=A0

=C2=A0

Tiru, do you have enough information to= add this to the TURNbis draft?

=C2=A0

[TR] Yes, If there are no further objection= s will update the draft next week.

=C2=A0

Cheer= s,

-Tiru

=C2=A0

Or do you think more discussion is nee= ded?

=C2=A0

.-.

P=C3=A5l-Erik

<= div>

=C2=A0

<= div>

=C2=A0=

.-.

P=C3=A5l= -Erik

<= span lang=3D"EN-US">=C2=A0

On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <= tireddy@cisco.com> wrote:

=C2=A0

From:=C2=A0Justin Uberti [= mailto:juberti@google.com]=C2=A0
Sent:=C2=A0= Saturday, January 10, 2015 2:19 AM
To:=C2=A0Oleg Moskalenko
Cc:=C2=A0Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy);=C2= =A0tram@ietf.org
Subject:=C2=A0Re: [tram] SSODA i= n TURN-bis

=

=C2=A0=

OK, so we= have clear evidence that some deployed servers will fail (deterministicall= y, fortunately) on the current SSODA proposal.

=C2=A0

So we're back to which backwards-compatible option we want to pursue= . I suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMI= LY.

=C2=A0

Separately, we need to decide whet= her we want to pursue issue #2 that I identified previously, i.e., allowing= specific error codes to be returned for each address family.=

=C2= =A0

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I double-checked that with a real test. I ran the= coTurn test client (that implements experimental SSODA draft with two RAF = attributes) against rfc5766-turn-server and the server yielded error 400 wi= th the message "Only one address family attribute can be used in a req= uest"

:(

As I said, I can elimina= te that problem in the subsequent rfc5766-turn-server maintenance releases,= but still...

I am sorry that I did not disco= ver that previously and that I advocated an incompatible implementation opt= ion.

So, if the WG insists on a backward-comp= atible protocol in all senses, then we have to choose another option.

Thanks
Oleg

=C2=A0

<= /div>

= =C2=A0

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I checked the code of rfc5766-turn-server again, and I found th= at it will NOT handle the multiple-RAF case. It will return 400 error with = the message "Only one address family attribute can be used in a reques= t". At least, it's been that way in the 2014 releases. I did not c= heck the older releases.

Sorry that I pr= ovided a wrong information about the implementation, before.<= /span>

= I can fix that code but still there are people out the= re who will be using the "wrong" versions.

So, if we do have to be absolutely backward compatible then we= have to use a different option...

=

Oleg=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <juberti= @google.com> wrote:

I reviewed the code for restund, reTurn, and rfc5766-turn-server and th= ey all appear to handle RAF (and multiple RAF) OK.

=

=C2=A0

The problem, as I see it, is that there may be other TURN servers, p= erhaps non-open-source ones, that work fine today with Chrome, but will sta= rt returning errors when we include RAF or multiple RAF, and so making this= change may break some small number of apps (who will then blame Chrome). W= e just don't know what is out there.

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 9, 201= 5 at 6:11 AM, Simon Perreault <sperreault@jive.com= > wrote:

=C2=A0

On Fri, Jan 9, 2015 at 4:17 AM, A= ijun Wang <wangaijun@tsinghua.org.cn> wro= te:

After your detail analysis and the sentence =E2=80=9CFor either b/c= , we would need to say that including both RAF and OAF/AAF for the same add= ress family is prohibited.=E2=80=9D, I think it may be better to keep only = one attribute to fulfill the SSODA requirement? =C2=A0=


There = is no requirement that SSODA functionality be realized with only one attrib= ute, nor that the protocol be elegant, nor that it exhibits symmetry that i= s pleasing to the eye.

=C2=A0

=

There *is* a re= quirement that it be backwards-compatible though. Whether that means compat= ible with the spec or compatible with actual implementations is a matter of= debate.

=C2=A0

Justin, if we can't find = a single implementation that would barf, why would Chrome have to implement= a complex fallback mechanism?

=C2= =A0

Simo= n

=C2=A0

=C2=A0

____________________= ___________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/= tram

=C2=A0

=C2=A0

=C2=A0

____= ___________________________________________
tram mailing list
= tram@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tram

=C2= =A0


________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tram

=C2=A0

=C2=A0


__________________________________= _____________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--f46d04389577d91187050cbf03b9-- From nobody Fri Jan 16 06:36:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77B01ACD7E for ; Fri, 16 Jan 2015 06:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 5ZNFUC71U7Ha for ; Fri, 16 Jan 2015 06:36:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 160AD1ACD78 for ; Fri, 16 Jan 2015 06:36:08 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A0C82476F0; Fri, 16 Jan 2015 14:36:07 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4E302476E6; Fri, 16 Jan 2015 14:36:07 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 49B7C202A; Fri, 16 Jan 2015 14:36:07 +0000 (GMT) Message-ID: <54B921D7.5050009@akamai.com> Date: Fri, 16 Jan 2015 09:36:07 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aijun Wang References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> <002a01d02f9d$29de2660$7d9a7320$@org.cn> <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> <005501d02fd7$9aead620$d0c08260$@org.cn> <37A39641-BA2A-439C-9602-035250015DB5@cisco.com> <008101d03172$4a6cee30$df46ca90$@org.cn> In-Reply-To: <008101d03172$4a6cee30$df46ca90$@org.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 14:36:12 -0000 Hi Aijun, If both A and C are using TA as their TURN relay address, they will still each get a different allocated relay address (call them RA and RC). Traffic from B or C to A will use RA as the XOR-PEER-ADDRESS value and traffic from A or B to C will use RC as the XOR-PEER-ADDRESS value. In this way, TA can clearly identify the intended recipient of any pure UDP packet arriving on a relay address. Neither of the TURN relays is required to "know" that the remote peer is using a relay, although relay TA could optimize communication between A and C if it recognizes that both peers' relay addresses are local. No changes are required to the existing RFCs in order to facilitate this communication. All that is required is for each of the peers to specify the correct XOR-PEER-ADDRESS. The client may know the nature of the specified address, but the relay server does not need to know. --Brandon PS: As I suggested in an earlier e-mail, I'm not getting the sense that e-mail communication is proving to be effective at resolving this issue. I think this same question has been answered multiple times in different ways, and further related questions on the list will be counterproductive. I don't want to discourage you or anyone from asking questions on the list about how this stuff works, but I think this particular issue will be resolved more easily face-to-face in Dallas. On 01/16/2015 04:53 AM, Aijun Wang wrote: > Hi, Pal: > > http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/?include_text=1 > has the following describes: > > “…The TURN protocol was designed to be used as part of the ICE > > (Interactive Connectivity Establishment) approach to NAT traversal, > > though it also can be used without ICE.” > > From our discussion or your teaching in previous mail, It is obviously > that TURN can’t worked alone itself. It need additional process for UDP > packet to pass through NAT before C----as you said, “…That is a problem > client C needs to handle. Probably by using its own TURN server. ICE > will also help in this case and might render any of the TURN servers > redundant…) > > For TCP transport, this will be even worse, because TCP requires first > the channel being built before peer can exchange STUN/TURN packet. But > the TCP channel will not be built successfully due to TURN server > allocates specific relay address for every client, which is also > different from the TURN server’s well-known address that is used to > receive the Send Indication. > > Even for UDP transport as that described in current TURN/ICE, Let’s > suppose C can receive the UDP packet( NAT device has been punched via > other means), and C will send back the return packet via also UDP > packet, which destination will be RA. Then the TURN Server will see a > XOR-PEER-ADDRESS(XC’) of client C that is different from the value XC, > this will then influence the procedure of permission control on TURN > Server established before. > > Have you ever consider these situations? If possible, I can explain the > detail process later when we meet the upcoming IETF conference. > > Best Regards. > > Aijun Wang. > > *From:*Pal Martinsen (palmarti) [mailto:palmarti@cisco.com] > *Sent:* Wednesday, January 14, 2015 6:37 PM > *To:* Aijun Wang > *Cc:* tram@ietf.org ; Brandon Williams > *Subject:* Re: [tram] New Version Notification for > draft-williams-peer-redirect-02.txt > > On 14 Jan 2015, at 09:53, Aijun Wang > wrote: > > Hi, Pal: > > > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen > (palmarti) > Sent: Wednesday, January 14, 2015 4:01 PM > To: Aijun Wang > Cc:tram@ietf.org ; Brandon Williams > Subject: Re: [tram] New Version Notification for > draft-williams-peer-redirect-02.txt > > > > On 14 Jan 2015, at 02:55, Aijun Wang > wrote: > > Hi, Brandon & pal: > > Let's consider the following graph: > > A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B > | | | | > | | | > | | | > | +----------XC<--->C | > | | > |---- TURN -----|--- UDP --|---- TURN --------| > > If there is another peer(peer C) connected directly to TURN Server A > at the > > same time, then TURN Server A will use also the pure UDP packet to > relay data > from A to C. > Close. The packet will be TURN encapsulated from A to TA, and then > from TA to > C pure UDP. > > > Why TURN Server A send packet to C via TA, but send packet to TURN > Server B via RA? This problem may be subtle, but it influence the > solution of several scenarios. > > My mistake. Packets to C goes from RA. > > Assuming TA is the “private”side of the TURN server an RA is the “public”. > > The only one that is able “speak”to the 5-tuple TA is A that did send > the allocate request. > > > Then, how this packet pass through the EDM NAT device that locates > before peer C? Peer C only send request packet to TURN Server A’s TA > > address previously. > > That is a problem client C needs to handle. Probably by using its own TURN > server. ICE will also help in this case and might render any of the TURN > servers > redundant. > > > Actually, I consider current TURN draft only consider the scenarios that > there > > exist only one TURN Server, and will lead more complex design if it want to > solve the TURN-to-TURN at the same time. > > > I disagree. The current suite of ICE/TURN/STUN RFCs do support this > nicely. I > do not think further discussion on the list is appropriate, but will be > happy to > have a chat during the next IETF meeting explaining things. > > > Ok, If possible, we can discuss this more detail face to face, but the > mail exchange is also one channel to think it deeply and can assist us > design one more lightweight solution. > > The problem is we are not discussing. We are trying to tell you that > this is already covered in the existing suite of RFCs. > > .-. > > Pål-Erik > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Jan 16 08:35:23 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C561ACDCE for ; Fri, 16 Jan 2015 08:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 qEQXjDVbbpfJ for ; Fri, 16 Jan 2015 08:35:19 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5525F1ACEB9 for ; Fri, 16 Jan 2015 08:35:19 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5A75047643 for ; Fri, 16 Jan 2015 16:35:18 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4E48B47642 for ; Fri, 16 Jan 2015 16:35:18 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 461108007C for ; Fri, 16 Jan 2015 16:35:18 +0000 (GMT) Message-ID: <54B93DC6.2020101@akamai.com> Date: Fri, 16 Jan 2015 11:35:18 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> <003401d02978$21689220$6439b660$@org.cn> <54ADA694.9010300@akamai.com> <005b01d02ae3$17832d80$46898880$@org.cn> <54AECBD9.5010903@akamai.com> <008e01d02bb5$9f058b40$dd10a1c0$@org.cn> <54B00B30.20508@akamai.com> <008b01d02e00$c1be3450$453a9cf0$@org.cn> <54B3EBF5.9090103@akamai.com> <002901d02eca$f8d75f00$ea861d00$@org.cn> <90F966ED-363B-4392-8EB2-48AC2DD3848F@cisco.com> <00a101d02f13$575f1e80$061d5b80$@org.cn> <5A8F6D13-C1C7-47F1-AE5B-7BFBE25DC052@cisco.com> <54B5A597.8030801@akamai.com> <002a01d02f9d$29de2660$7d9a7320$@org.cn> <1D7191B9-9195-4A7A-B9BA-BA3E54F2E077@cisco.com> <005501d02fd7$9aead620$d0c08260$@org.cn> <37A39641-BA2A-439C-9602-035250015DB5@cisco.com> <008101d03172$4a6cee30$df46ca90$@org.cn> <54B921D7.5050009@akamai.com> In-Reply-To: <54B921D7.5050009@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:35:21 -0000 Oops ... just to be clear ... I meant "If both A and C are using TA as their TURN server address", meaning that's the other side of the TURN 5-tuple. On 01/16/2015 09:36 AM, Brandon Williams wrote: > Hi Aijun, > > If both A and C are using TA as their TURN relay address, they will > still each get a different allocated relay address (call them RA and > RC). Traffic from B or C to A will use RA as the XOR-PEER-ADDRESS value > and traffic from A or B to C will use RC as the XOR-PEER-ADDRESS value. > In this way, TA can clearly identify the intended recipient of any pure > UDP packet arriving on a relay address. Neither of the TURN relays is > required to "know" that the remote peer is using a relay, although relay > TA could optimize communication between A and C if it recognizes that > both peers' relay addresses are local. > > No changes are required to the existing RFCs in order to facilitate this > communication. All that is required is for each of the peers to specify > the correct XOR-PEER-ADDRESS. The client may know the nature of the > specified address, but the relay server does not need to know. > > --Brandon > > PS: As I suggested in an earlier e-mail, I'm not getting the sense that > e-mail communication is proving to be effective at resolving this issue. > I think this same question has been answered multiple times in different > ways, and further related questions on the list will be > counterproductive. I don't want to discourage you or anyone from asking > questions on the list about how this stuff works, but I think this > particular issue will be resolved more easily face-to-face in Dallas. > > On 01/16/2015 04:53 AM, Aijun Wang wrote: >> Hi, Pal: >> >> http://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/?include_text=1 >> has the following describes: >> >> “…The TURN protocol was designed to be used as part of the ICE >> >> (Interactive Connectivity Establishment) approach to NAT traversal, >> >> though it also can be used without ICE.” >> >> From our discussion or your teaching in previous mail, It is obviously >> that TURN can’t worked alone itself. It need additional process for UDP >> packet to pass through NAT before C----as you said, “…That is a problem >> client C needs to handle. Probably by using its own TURN server. ICE >> will also help in this case and might render any of the TURN servers >> redundant…) >> >> For TCP transport, this will be even worse, because TCP requires first >> the channel being built before peer can exchange STUN/TURN packet. But >> the TCP channel will not be built successfully due to TURN server >> allocates specific relay address for every client, which is also >> different from the TURN server’s well-known address that is used to >> receive the Send Indication. >> >> Even for UDP transport as that described in current TURN/ICE, Let’s >> suppose C can receive the UDP packet( NAT device has been punched via >> other means), and C will send back the return packet via also UDP >> packet, which destination will be RA. Then the TURN Server will see a >> XOR-PEER-ADDRESS(XC’) of client C that is different from the value XC, >> this will then influence the procedure of permission control on TURN >> Server established before. >> >> Have you ever consider these situations? If possible, I can explain the >> detail process later when we meet the upcoming IETF conference. >> >> Best Regards. >> >> Aijun Wang. >> >> *From:*Pal Martinsen (palmarti) [mailto:palmarti@cisco.com] >> *Sent:* Wednesday, January 14, 2015 6:37 PM >> *To:* Aijun Wang >> *Cc:* tram@ietf.org ; Brandon Williams >> *Subject:* Re: [tram] New Version Notification for >> draft-williams-peer-redirect-02.txt >> >> On 14 Jan 2015, at 09:53, Aijun Wang > > wrote: >> >> Hi, Pal: >> >> >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen >> (palmarti) >> Sent: Wednesday, January 14, 2015 4:01 PM >> To: Aijun Wang >> Cc:tram@ietf.org ; Brandon Williams >> Subject: Re: [tram] New Version Notification for >> draft-williams-peer-redirect-02.txt >> >> >> >> On 14 Jan 2015, at 02:55, Aijun Wang > > wrote: >> >> Hi, Brandon & pal: >> >> Let's consider the following graph: >> >> A <-> XA <-> TA|RA <-> RB|TB <-> XB <-> B >> | | | | >> | | | >> | | | >> | +----------XC<--->C | >> | | >> |---- TURN -----|--- UDP --|---- TURN --------| >> >> If there is another peer(peer C) connected directly to TURN Server A >> at the >> >> same time, then TURN Server A will use also the pure UDP packet to >> relay data >> from A to C. >> Close. The packet will be TURN encapsulated from A to TA, and then >> from TA to >> C pure UDP. >> >> >> Why TURN Server A send packet to C via TA, but send packet to TURN >> Server B via RA? This problem may be subtle, but it influence the >> solution of several scenarios. >> >> My mistake. Packets to C goes from RA. >> >> Assuming TA is the “private”side of the TURN server an RA is the “public”. >> >> The only one that is able “speak”to the 5-tuple TA is A that did send >> the allocate request. >> >> >> Then, how this packet pass through the EDM NAT device that locates >> before peer C? Peer C only send request packet to TURN Server A’s TA >> >> address previously. >> >> That is a problem client C needs to handle. Probably by using its own TURN >> server. ICE will also help in this case and might render any of the TURN >> servers >> redundant. >> >> >> Actually, I consider current TURN draft only consider the scenarios that >> there >> >> exist only one TURN Server, and will lead more complex design if it want to >> solve the TURN-to-TURN at the same time. >> >> >> I disagree. The current suite of ICE/TURN/STUN RFCs do support this >> nicely. I >> do not think further discussion on the list is appropriate, but will be >> happy to >> have a chat during the next IETF meeting explaining things. >> >> >> Ok, If possible, we can discuss this more detail face to face, but the >> mail exchange is also one channel to think it deeply and can assist us >> design one more lightweight solution. >> >> The problem is we are not discussing. We are trying to tell you that >> this is already covered in the existing suite of RFCs. >> >> .-. >> >> Pål-Erik >> >> >> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Jan 16 08:54:53 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC51A3BA0 for ; Mon, 5 Jan 2015 03:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zWR5WTrPa7iR for ; Mon, 5 Jan 2015 03:23:42 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863391A1AD2 for ; Mon, 5 Jan 2015 03:23:42 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so17055149lbj.22 for ; Mon, 05 Jan 2015 03:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OwX7mSyCnZuPaYYqffq2SoZ66XqrAvf6zPORGRzEBQo=; b=rY8arE7Z2Z+2bihdZqT44V9/1eYarS9uwrEM3KKkWMi8H86KHECbXQy4Jcis4xZadf 8f3koTd7mhwlTbfQ7TO5YviTUJ85dE1kEOUIDbnJrsgemHUHaorvcrtLw43R8Qf5vLeW 93Ai9QjF93XP9jWnpeYQM9klTuvTUHQUVI7LAIyDz9M+xg2IbZknBLyh7ClIIcDd3+mK gqE2y7F4urYF/m3zP3ZA6msxm0RNzAKgI0PLHWpEZ85dWZspwGcwU6QesEtwsdKC6hrx Hb2rXvlezpagJAplUQnyQwIuvxJEDjMwDrYAmfJ3chMkgF7AP2sC4961ypKcJwml9tnV Laag== X-Received: by 10.153.5.1 with SMTP id ci1mr84487358lad.67.1420457020869; Mon, 05 Jan 2015 03:23:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.135.7 with HTTP; Mon, 5 Jan 2015 03:23:20 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A355263AC@xmb-rcd-x10.cisco.com> From: Varun Singh Date: Mon, 5 Jan 2015 13:23:20 +0200 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FkRLy2ce29SzJzERIOAHSL3dZeQ X-Mailman-Approved-At: Fri, 16 Jan 2015 08:54:49 -0800 Cc: Simon Perreault , Aijun Wang , Brandon Williams , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:23:50 -0000 Hi Aijun, Snipped most of the previous message, just responding to the RTCP/STUN messages. On Mon, Jan 5, 2015 at 9:27 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang [snip!] >> I think the dynamic path selection should be left to and be considered by the >> application layer itself, such as RTCP protocol etc. > > In case of MPRTP, Path characteristics discovered using ICE will be used for picking the interface for the primary sub-flow and interfaces for subsequent sub-flows and MPRTP RTCP report can be used later for load balancing. IMO the RTCP or application layer will finally pick the paths, the STUN packets expose preliminary metrics (RTT and loss) to the RTP layer. This helps the RTP layer determine if the path is (or which paths are) capable of meeting the delay requirements of the multimedia application (different for conversational, live, VoD, etc.) without sending any media packets. Then it is up to the congestion control algorithm (at the RTP layer) to schedule media packets on those paths, observe if they have sufficient capacity. If not the RTP layer can add more paths, or vary the encoding rate, or switch between existing rates. Cheers, Varun -- http://www.netlab.tkk.fi/~varun/ From nobody Fri Jan 16 09:11:00 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFA61ACE8A for ; Fri, 16 Jan 2015 09:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 3pS1yGZ2SUth for ; Fri, 16 Jan 2015 09:10:54 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899721ACE01 for ; Fri, 16 Jan 2015 09:10:54 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rp18so21721010iec.10 for ; Fri, 16 Jan 2015 09:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=isF5fpLGLXHpkt/0SFvrD11y0sBoEPJUu0w53DSSkV4=; b=cTnFPbABpFW8QWl8q1Ewnbqdkt/Ja11ADmyVK4SAJzoA+zw2TrWgqmWNGwehj1EKfD 67IJ5kwY75Fi3RtKaX33Zcu5DgQZX0tgNhAyJDShjP+0PxOQgcts/33D86wDP473ydFt KnCgEV7TCUJXbrdQUh3YlygLW1pckHdvZQbk9Ulk9b7yTH/s/9VEhJLygWzJ5rG9446s iOldxRYCbW7jxCaryfqXxlSlsJ9EIcMkgrRZwk+4Xw7Yz07jCho71ARKGVShJCp8+E1h LT26JPKRpPNKxao5zjQO/XVpXLmR78lY1Qe4F7OMO+7Ef/mmcGe7zM7S1X4dmsNc0+2f zMtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=isF5fpLGLXHpkt/0SFvrD11y0sBoEPJUu0w53DSSkV4=; b=Fo2v+ima32dWqcFbvDyQYNNHLNKbfDNlMDvJfr8zIc8hHUJvkRP692arshScQryIJz g/fOAXOTFyM234TmX0mv1DsAwcNKWdHKgfhMmS3XUwwpTFPgyrcFeTdMVSpQk1DWIaHB oh33/jpFIjfmOKGnWKP/+SoB5Mz3zXUXnhNXkaKTcCYkfabloNSUr3lO3G8ztlOipoeg TrgbbauBzQHH7cHhHnrAOwI3aTyvl8IE0oOPGfkYa1vGyvgnzqsA8NksiMq9s8oL4WJf SDb4K2vhJso04+CVzJ6r2mB5XTo4qEP9jLE3lmXusvBmaG9eeRtYrYcFrwZr7pKa/+Et K9+A== X-Gm-Message-State: ALoCoQnT+qTjb4GqSOtGdKVRhCNjgoiu4fRU7dJyk8vViPach9fBRrpulKtKH0vddG3Qwwzq0BWN X-Received: by 10.43.61.7 with SMTP id wu7mr15785648icb.24.1421428253624; Fri, 16 Jan 2015 09:10:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Fri, 16 Jan 2015 09:10:33 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> From: Justin Uberti Date: Fri, 16 Jan 2015 09:10:33 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=bcaec51d20f421d8b6050cc80e28 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 17:10:58 -0000 --bcaec51d20f421d8b6050cc80e28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's too late to take this approach. Every existing TURN server out there assumes that no RAF =3D IPv4. We can't change the past. It's also not clear how you expect this to provide SSODA functionality, e.g. how do you distinguish between an IPv4 client asking for v6 only vs v4+v6. On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko wrote: > I think that that proposal makes sense. But I am not sure that it is > backward-compatible enough. We have to go through all cases of > SSODA/non-SSODA entities communicating, for different protocol request > options. > > Aijun, would you like to go through all those cases to double-check that > it works as supposed ? > > Thanks > Oleg > > > On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang > wrote: > >> Hi,Tiru,Pal and Justin: >> >> >> >> I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attribut= e to fulfill the >> function of SSODA by clarifying the behavior of TURN server based on >> whether this attribute is present or not: >> >> >> >> 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the alloc= ated relay >> address family will be same as the source address=E2=80=99s family of A= llocate >> Request message. https://tools.ietf.org/html/rfc6156#section-4.2 has >> the following description: >> >> >> >> =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server= MUST >> >> allocate an IPv4-relayed transport address for the TURN client. If >> >> allocation of IPv4 addresses is disabled by local policy, the server >> >> returns a 440 (Address Family not Supported) Allocate error response.= =E2=80=9D >> >> >> >> This paragraph should be modified as below: >> >> =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server= MUST >> >> allocate an relayed transport address *from the same family as the >> source address of Allocate Request message* for the TURN client. If >> *this* >> >> * allocation* is disabled by local policy, the server >> >> returns a 440 (Address Family not Supported) Allocate error response.= =E2=80=9D >> >> >> >> 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the following= procedure of the >> client and server should only need to conform to >> https://tools.ietf.org/html/rfc6156, no new attribute and procedure need >> be introduced. >> >> >> >> 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribute= Family=E2=80=9D >> attribute that I proposed previously. Will such solution be less >> confusable and be less prone to problem to the TURN developer? >> >> RFC6156 also describes the following sentence: >> >> =E2=80=9CThe REQUESTED-ADDRESS-FAMILY >> >> attribute allows a client to *explicitly* request the address type th= e >> >> TURN server will allocate (e.g., an IPv4-only node may request the >> >> TURN server to allocate an IPv6 address).=E2=80=9D >> >> If we can change the name of the attribute, then change the attribute >> name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional A= ttribute Family=E2=80=9D may be >> more better. If this is impossible, we just need only update the behavio= r >> of TURN server that described in RFC6156, as I suggested above. >> >> >> >> Best Regards. >> >> Aijun Wang >> >> >> >> >> >> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Tirumaleswar >> Reddy (tireddy) >> *Sent:* Thursday, January 15, 2015 10:24 PM >> *To:* Pal Martinsen (palmarti); Justin Uberti >> >> *Cc:* tram@ietf.org >> *Subject:* Re: [tram] SSODA in TURN-bis >> >> >> >> *From:* Pal Martinsen (palmarti) >> *Sent:* Thursday, January 15, 2015 4:49 PM >> *To:* Justin Uberti; Tirumaleswar Reddy (tireddy) >> *Cc:* tram@ietf.org >> *Subject:* Re: [tram] SSODA in TURN-bis >> >> >> >> >> >> On 14 Jan 2015, at 23:44, Justin Uberti wrote: >> >> >> >> >> >> >> >> On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) < >> palmarti@cisco.com> wrote: >> >> Hi, >> >> >> >> I do not see a problem with a TURN server returning a 400 error code if >> it gets confused by two RAFs. >> >> This is almost covered in section 2.4 of the SSODA draft. Client fallbac= k >> to non-SSODA mode when encountering an error seems trivial. >> >> (Unless the TURN server ends up using to much CPU, overheats, and causes >> a fire in the datacenter) >> >> >> >> But I might like c) better anyway. Adding a new attribute seems cleaner >> when adding new functionality. >> >> >> >> Saving a roundtrip (i.e. by not having to retry) when doing SSODA is als= o >> a good thing. >> >> >> >> Good point. Since this probably would take some time to deploy on the >> server side the extra chatter could become a bit annoying. >> >> >> >> Tiru, do you have enough information to add this to the TURNbis draft? >> >> >> >> [TR] Yes, If there are no further objections will update the draft next >> week. >> >> >> >> Cheers, >> >> -Tiru >> >> >> >> Or do you think more discussion is needed? >> >> >> >> .-. >> >> P=C3=A5l-Erik >> >> >> >> >> >> .-. >> >> P=C3=A5l-Erik >> >> >> >> On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) >> wrote: >> >> >> >> ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a = temporary >> or long-term error. >> >> >> >> -Tiru >> >> >> >> *From:* Justin Uberti [mailto:juberti@google.com ] >> *Sent:* Saturday, January 10, 2015 2:19 AM >> *To:* Oleg Moskalenko >> *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); >> tram@ietf.org >> *Subject:* Re: [tram] SSODA in TURN-bis >> >> >> >> OK, so we have clear evidence that some deployed servers will fail >> (deterministically, fortunately) on the current SSODA proposal. >> >> >> >> So we're back to which backwards-compatible option we want to pursue. I >> suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMIL= Y. >> >> >> >> Separately, we need to decide whether we want to pursue issue #2 that I >> identified previously, i.e., allowing specific error codes to be returne= d >> for each address family. >> >> >> >> On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko >> wrote: >> >> I double-checked that with a real test. I ran the coTurn test client >> (that implements experimental SSODA draft with two RAF attributes) again= st >> rfc5766-turn-server and the server yielded error 400 with the message "O= nly >> one address family attribute can be used in a request" >> >> :( >> >> As I said, I can eliminate that problem in the subsequent >> rfc5766-turn-server maintenance releases, but still... >> >> I am sorry that I did not discover that previously and that I advocated >> an incompatible implementation option. >> >> So, if the WG insists on a backward-compatible protocol in all senses, >> then we have to choose another option. >> >> Thanks >> Oleg >> >> >> >> >> >> On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko >> wrote: >> >> I checked the code of rfc5766-turn-server again, and I found that it wil= l >> NOT handle the multiple-RAF case. It will return 400 error with the mess= age >> "Only one address family attribute can be used in a request". At least, >> it's been that way in the 2014 releases. I did not check the older relea= ses. >> >> Sorry that I provided a wrong information about the implementation, >> before. >> >> I can fix that code but still there are people out there who will be >> using the "wrong" versions. >> >> So, if we do have to be absolutely backward compatible then we have to >> use a different option... >> >> Oleg >> >> >> >> >> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti wrote= : >> >> I reviewed the code for restund, reTurn, and rfc5766-turn-server and the= y >> all appear to handle RAF (and multiple RAF) OK. >> >> >> >> The problem, as I see it, is that there may be other TURN servers, >> perhaps non-open-source ones, that work fine today with Chrome, but will >> start returning errors when we include RAF or multiple RAF, and so makin= g >> this change may break some small number of apps (who will then blame >> Chrome). We just don't know what is out there. >> >> >> >> >> >> >> >> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >> wrote: >> >> >> >> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >> wrote: >> >> After your detail analysis and the sentence =E2=80=9CFor either b/c, we = would >> need to say that including both RAF and OAF/AAF for the same address fam= ily >> is prohibited.=E2=80=9D, I think it may be better to keep only one attri= bute to >> fulfill the SSODA requirement? >> >> >> There is no requirement that SSODA functionality be realized with only >> one attribute, nor that the protocol be elegant, nor that it exhibits >> symmetry that is pleasing to the eye. >> >> >> >> There *is* a requirement that it be backwards-compatible though. Whether >> that means compatible with the spec or compatible with actual >> implementations is a matter of debate. >> >> >> >> Justin, if we can't find a single implementation that would barf, why >> would Chrome have to implement a complex fallback mechanism? >> >> >> >> Simon >> >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --bcaec51d20f421d8b6050cc80e28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's too late to take this approach. Every existing TU= RN server out there assumes that no RAF =3D IPv4. We can't change the p= ast.

It's also not clear how you expect this to prov= ide SSODA functionality, e.g. how do you distinguish between an IPv4 client= asking for v6 only vs v4+v6.

On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko <mom= 040267@gmail.com> wrote:
I think that that proposal makes sense. But I am not su= re that it is backward-compatible enough. We have to go through all cases o= f SSODA/non-SSODA entities communicating, for different protocol request op= tions.

Aijun, would you like to go through all those cases to = double-check that it works as supposed ?

Thanks
Oleg


On Thu, Jan 15, 2015 at 10:01 PM, Aij= un Wang <wangaijun@tsinghua.org.cn> wrote:

Hi,T= iru,Pal and Justin:

=C2=A0

I suggest we use t= he =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attribute to fulfill the func= tion of SSODA by clarifying the behavior of TURN server based on whether th= is attribute is present or not:

=C2=A0

1. If th= e =E2=80=9CRAF=E2=80=9D attribute is not present, then the allocated relay = address family will be same as the source address=E2=80=99s family =C2=A0of= Allocate Request message. =C2=A0https://tools.ietf.org/html/rfc6156#sec= tion-4.2 has the following description:

=C2=A0<= /u>

=E2=80=9CIf the REQUESTED-ADDRESS-FAM=
ILY attribute is absent, the server MUST

=C2=A0=C2=A0 allocate an IPv4-relayed transport address fo= r the TURN client.=C2=A0 If

= =C2=A0=C2=A0 allocation of IPv4 addresses is disabled by local policy, the= server

=C2=A0=C2=A0 return= s a 440 (Address Family not Supported) Allocate error response.=E2=80=9D

=C2=A0<= u>

This paragraph should be modified as below:

= 
=E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute=
 is absent, the server MUST

=C2=A0=C2=A0 allocate an relayed transport address from the same fami= ly as the source address of Allocate Request message for the TURN clien= t.=C2=A0 If this

<= span style=3D"font-size:10.0pt;font-family:=E5=AE=8B=E4=BD=93" lang=3D"EN">= =C2=A0=C2=A0 allocation is disabled by local policy, the server=

=C2=A0=C2=A0 returns a 440= (Address Family not Supported) Allocate error response.=E2=80=9D

=C2=A0

2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the following= procedure of the client and server should only need to conform to https://tools.ie= tf.org/html/rfc6156, no new attribute and procedure need be introduced.=

=C2=A0

3. Here, the RAF attribute act just as= the =E2=80=9CAdditional Attribute Family=E2=80=9D attribute that I propose= d previously.=C2=A0 Will such solution be less confusable and be less prone= to problem to the TURN developer?

RFC6156 also describes the following sentenc=
e:
=E2=80=9CThe REQUESTED=
-ADDRESS-FAMILY
=C2=A0=C2=A0 attribute allows a client to explicitly request the address type the
=C2=A0=C2=A0 TURN server will allocate (e=
.g., an IPv4-only node may request the
=C2=A0=C2=A0 TURN server to allocat=
e an IPv6 address).=E2=80=9D

If we can change the name of the = attribute, then change the attribute name =E2=80=9CREQUESTED-ADDRESS-FAMILY= =E2=80=9D to =E2=80=9CAddi= tional Attribute Family=E2=80= =9D may be more better. If this is impossible, we just need only update the= behavior of TURN server that described in RFC6156, =C2=A0as I suggested ab= ove.

=C2=A0

Best Regards.

Aijun Wang

=C2=A0

=C2=A0

<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0= cm 0cm">

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of T= irumaleswar Reddy (tireddy)
Sent: Thursday, January 15, 2015 10:2= 4 PM
To: Pal Martinsen (palmarti); Justin Uberti

<= div>
Cc: tram@= ietf.org
Subject: Re: [tram] SSODA in TURN-bis<= /div>

=C2=A0

From: Pal Martins= en (palmarti)
Sent: Thursday, January 15, 2015 4:49 PM
To:= Justin Uberti; Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject:= Re: [tram] SSODA in TURN-bis

=C2=A0

=C2=A0

On 14 Jan 2015, at 23:44, Justin Uberti <juberti@google.com> wrote:=

= =C2=A0

=C2=A0

=C2=A0

= On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmar= ti) <palmarti@ci= sco.com> wrote:

= Hi,

=C2=A0

I do not see a problem with a TURN serv= er returning a 400 error code if it gets confused by two RAFs.

This is = almost covered in section 2.4 of the SSODA draft. Client fallback to non-SS= ODA mode when encountering an error seems trivial.=C2=A0

(Unless the TU= RN server ends up using to much CPU, overheats, and causes a fire in the da= tacenter)

=C2=A0

But I might like c) better anyway. Adding a new at= tribute seems cleaner when adding new functionality.

=C2= =A0

Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also = a good thing.

=C2=A0=

Good point. Si= nce this probably would take some time to deploy on the server side the ext= ra chatter could become a bit annoying.=C2=A0

=C2=A0

Tiru, do you h= ave enough information to add this to the TURNbis draft?

=C2=A0

[TR] Yes, If there= are no further objections will update the draft next week.

<= u>=C2=A0

Cheers,

= -Tiru

=C2=A0=

Or do you thi= nk more discussion is needed?

=C2=A0

.-.

=

P=C3=A5l-Erik=

=C2=A0

=

=C2=A0

.-.

P=C3=A5l-Erik

=C2=A0<= /p>

On 12 Jan 2015, at 06:08, Tirumale= swar Reddy (tireddy) <tireddy@cisco.com> wrote:

=C2=A0

AD= DRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a tempo= rary or long-term error.

=C2=A0

-Tiru=

=C2=A0

From:=C2=A0Justin Uberti [mailto:juberti@google.com]=C2= =A0
Sent:=C2=A0Saturday, January 10, 2015 2:19 AM
To:= =C2=A0Oleg Moskalenko
Cc:=C2=A0Simon Perreault; Aijun Wang; Tirum= aleswar Reddy (tireddy);=C2=A0tram@ietf.org
Subject:<= /b>=C2=A0Re: [tram] SSODA in TURN-bis=

=C2=A0

OK, so we have clear evidence that some deployed servers = will fail (deterministically, fortunately) on the current SSODA proposal.

=C2=A0

So we're back to which backwards-compatib= le option we want to pursue. I suggest c), which is the optional-comprehens= ion ADDITIONAL-ADDRESS-FAMILY.

=C2=A0

Separat= ely, we need to decide whether we want to pursue issue #2 that I identified= previously, i.e., allowing specific error codes to be returned for each ad= dress family.

=C2=A0

On Fri, Jan 9, 2015 at 10:53 AM, Ol= eg Moskalenko <= mom040267@gmail.com> wrote:

I double-checked that wi= th a real test. I ran the coTurn test client (that implements experimental = SSODA draft with two RAF attributes) against rfc5766-turn-server and the se= rver yielded error 400 with the message "Only one address family attri= bute can be used in a request"

:(

As I said, I can eliminate that problem in the subsequent rfc5766-turn-ser= ver maintenance releases, but still...

I am s= orry that I did not discover that previously and that I advocated an incomp= atible implementation option.

So, if the WG i= nsists on a backward-compatible protocol in all senses, then we have to cho= ose another option.

Thanks
Oleg

=C2=A0

=

=C2=A0

On Fri, Jan 9, 2015 at 10:01 AM, O= leg Moskalenko <mom040267@gmail.com> wrote:<= /u>

I checked the code of rfc5766-turn-ser= ver again, and I found that it will NOT handle the multiple-RAF case. It wi= ll return 400 error with the message "Only one address family attribut= e can be used in a request". At least, it's been that way in the 2= 014 releases. I did not check the older releases.

<= /div>

Sorry that I provided a wrong information about the implementati= on, before.

I can fix that code but stil= l there are people out there who will be using the "wrong" versio= ns.

So, if we do have to be absolutely b= ackward compatible then we have to use a different option...<= /span>

Oleg
=C2=A0=

=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin = Uberti <juberti@google.com> wrote:=

I reviewed the code for restund, reTurn, an= d rfc5766-turn-server and they all appear to handle RAF (and multiple RAF) = OK.

=C2=A0

The problem, as I see it, is that there= may be other TURN servers, perhaps non-open-source ones, that work fine to= day with Chrome, but will start returning errors when we include RAF or mul= tiple RAF, and so making this change may break some small number of apps (w= ho will then blame Chrome). We just don't know what is out there.

=C2=A0

=C2=A0

=C2= =A0

On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <sperreault@jive.com> wrote:

=C2=A0

On= Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <wangaijun@tsi= nghua.org.cn> wrote:

After your detail analysis and the s= entence =E2=80=9CFor either b/c, we would need to say that including both R= AF and OAF/AAF for the same address family is prohibited.=E2=80=9D, I think= it may be better to keep only one attribute to fulfill the SSODA requireme= nt? =C2=A0

=
There is no requirement that SSODA functionality b= e realized with only one attribute, nor that the protocol be elegant, nor t= hat it exhibits symmetry that is pleasing to the eye.<= /p>

=C2=A0=

There *is* a requirement that it be backwards-compatible th= ough. Whether that means compatible with the spec or compatible with actual= implementations is a matter of debate.

=C2=A0=

Justin, if we can't find a single implementation that would barf, why= would Chrome have to implement a complex fallback mechanism?=

=C2=A0<= /span>

Simon

=C2=A0

=C2=A0

_______________________________________________
tram mailing = list
tram@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tram

=C2=A0

=C2=A0

=C2=A0

_______________________________________________<= br>tram mailing list
tram@ietf.org=
https://www.ietf.org/mailman/listinfo/tram=

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><= br>_______________________________________________
tram mailing list
= tram@ietf.org
https= ://www.ietf.org/mailman/listinfo/tram

=C2=A0<= /span>

=C2=A0


_______= ________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



--bcaec51d20f421d8b6050cc80e28-- From nobody Fri Jan 16 10:35:31 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B311AD0D1 for ; Fri, 16 Jan 2015 10:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no 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 SMKPWmvVvka9 for ; Fri, 16 Jan 2015 10:35:24 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A331ACE72 for ; Fri, 16 Jan 2015 10:35:24 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id x13so21999228wgg.12 for ; Fri, 16 Jan 2015 10:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CL4/qd0TQF+KbCB8ia90CbIgxjMCfSt72mRTOlTukNc=; b=eJdfiTyq1CHmTY104l1+AuIy3mOkV/5JJtt9iCDQl2mCEFiv+sa9TaPwh5ZEXsS4ie /xi4Jo6SyN2zyIyK27WZ6Ylom34h78aYoO9qinp3NlZfVsJgx3SXl0JQt6WcjE9De1Pa /+mA/mYLBcDvZNpJCpw01ezJNZtuZJx1+1HmMp2s1z3EMZ9WnPazT+0RB/NqTyx94ZXL 7WF1xeNEbJW6eihVdPgZayggkf/m8WERSSB2IOjZ2Hb8t1vG1hzQnp0XOBBsF8zcNplt ertR1eVMMCLZm3UJRwBS2FGQByGIb00prhcwff0nZLOufm54XSCzR8QKjbIVfYOODKrx IVpQ== MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr30908293wjr.48.1421433322876; Fri, 16 Jan 2015 10:35:22 -0800 (PST) Received: by 10.194.87.98 with HTTP; Fri, 16 Jan 2015 10:35:22 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> Date: Fri, 16 Jan 2015 10:35:22 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b86c898483935050cc93cef Archived-At: Cc: "Pal Martinsen \(palmarti\)" , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:35:28 -0000 --047d7b86c898483935050cc93cef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then we are back to, I guess, the option c). On Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti wrote: > It's too late to take this approach. Every existing TURN server out there > assumes that no RAF =3D IPv4. We can't change the past. > > It's also not clear how you expect this to provide SSODA functionality, > e.g. how do you distinguish between an IPv4 client asking for v6 only vs > v4+v6. > > On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko > wrote: > >> I think that that proposal makes sense. But I am not sure that it is >> backward-compatible enough. We have to go through all cases of >> SSODA/non-SSODA entities communicating, for different protocol request >> options. >> >> Aijun, would you like to go through all those cases to double-check that >> it works as supposed ? >> >> Thanks >> Oleg >> >> >> On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang >> wrote: >> >>> Hi,Tiru,Pal and Justin: >>> >>> >>> >>> I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attribu= te to fulfill the >>> function of SSODA by clarifying the behavior of TURN server based on >>> whether this attribute is present or not: >>> >>> >>> >>> 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the allo= cated relay >>> address family will be same as the source address=E2=80=99s family of = Allocate >>> Request message. https://tools.ietf.org/html/rfc6156#section-4.2 has >>> the following description: >>> >>> >>> >>> =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the serve= r MUST >>> >>> allocate an IPv4-relayed transport address for the TURN client. If >>> >>> allocation of IPv4 addresses is disabled by local policy, the server >>> >>> returns a 440 (Address Family not Supported) Allocate error response= . >>> =E2=80=9D >>> >>> >>> >>> This paragraph should be modified as below: >>> >>> =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the serve= r MUST >>> >>> allocate an relayed transport address *from the same family as the >>> source address of Allocate Request message* for the TURN client. If >>> *this* >>> >>> * allocation* is disabled by local policy, the server >>> >>> returns a 440 (Address Family not Supported) Allocate error response= . >>> =E2=80=9D >>> >>> >>> >>> 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the followin= g procedure of >>> the client and server should only need to conform to >>> https://tools.ietf.org/html/rfc6156, no new attribute and procedure >>> need be introduced. >>> >>> >>> >>> 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribut= e Family=E2=80=9D >>> attribute that I proposed previously. Will such solution be less >>> confusable and be less prone to problem to the TURN developer? >>> >>> RFC6156 also describes the following sentence: >>> >>> =E2=80=9CThe REQUESTED-ADDRESS-FAMILY >>> >>> attribute allows a client to *explicitly* request the address type t= he >>> >>> TURN server will allocate (e.g., an IPv4-only node may request the >>> >>> TURN server to allocate an IPv6 address).=E2=80=9D >>> >>> If we can change the name of the attribute, then change the attribute >>> name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional = Attribute Family=E2=80=9D may be >>> more better. If this is impossible, we just need only update the behavi= or >>> of TURN server that described in RFC6156, as I suggested above. >>> >>> >>> >>> Best Regards. >>> >>> Aijun Wang >>> >>> >>> >>> >>> >>> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Tirumaleswar >>> Reddy (tireddy) >>> *Sent:* Thursday, January 15, 2015 10:24 PM >>> *To:* Pal Martinsen (palmarti); Justin Uberti >>> >>> *Cc:* tram@ietf.org >>> *Subject:* Re: [tram] SSODA in TURN-bis >>> >>> >>> >>> *From:* Pal Martinsen (palmarti) >>> *Sent:* Thursday, January 15, 2015 4:49 PM >>> *To:* Justin Uberti; Tirumaleswar Reddy (tireddy) >>> *Cc:* tram@ietf.org >>> *Subject:* Re: [tram] SSODA in TURN-bis >>> >>> >>> >>> >>> >>> On 14 Jan 2015, at 23:44, Justin Uberti wrote: >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) < >>> palmarti@cisco.com> wrote: >>> >>> Hi, >>> >>> >>> >>> I do not see a problem with a TURN server returning a 400 error code if >>> it gets confused by two RAFs. >>> >>> This is almost covered in section 2.4 of the SSODA draft. Client >>> fallback to non-SSODA mode when encountering an error seems trivial. >>> >>> (Unless the TURN server ends up using to much CPU, overheats, and cause= s >>> a fire in the datacenter) >>> >>> >>> >>> But I might like c) better anyway. Adding a new attribute seems cleaner >>> when adding new functionality. >>> >>> >>> >>> Saving a roundtrip (i.e. by not having to retry) when doing SSODA is >>> also a good thing. >>> >>> >>> >>> Good point. Since this probably would take some time to deploy on the >>> server side the extra chatter could become a bit annoying. >>> >>> >>> >>> Tiru, do you have enough information to add this to the TURNbis draft? >>> >>> >>> >>> [TR] Yes, If there are no further objections will update the draft next >>> week. >>> >>> >>> >>> Cheers, >>> >>> -Tiru >>> >>> >>> >>> Or do you think more discussion is needed? >>> >>> >>> >>> .-. >>> >>> P=C3=A5l-Erik >>> >>> >>> >>> >>> >>> .-. >>> >>> P=C3=A5l-Erik >>> >>> >>> >>> On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) < >>> tireddy@cisco.com> wrote: >>> >>> >>> >>> ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a >>> temporary or long-term error. >>> >>> >>> >>> -Tiru >>> >>> >>> >>> *From:* Justin Uberti [mailto:juberti@google.com ] >>> *Sent:* Saturday, January 10, 2015 2:19 AM >>> *To:* Oleg Moskalenko >>> *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); >>> tram@ietf.org >>> *Subject:* Re: [tram] SSODA in TURN-bis >>> >>> >>> >>> OK, so we have clear evidence that some deployed servers will fail >>> (deterministically, fortunately) on the current SSODA proposal. >>> >>> >>> >>> So we're back to which backwards-compatible option we want to pursue. I >>> suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMI= LY. >>> >>> >>> >>> Separately, we need to decide whether we want to pursue issue #2 that I >>> identified previously, i.e., allowing specific error codes to be return= ed >>> for each address family. >>> >>> >>> >>> On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko >>> wrote: >>> >>> I double-checked that with a real test. I ran the coTurn test client >>> (that implements experimental SSODA draft with two RAF attributes) agai= nst >>> rfc5766-turn-server and the server yielded error 400 with the message "= Only >>> one address family attribute can be used in a request" >>> >>> :( >>> >>> As I said, I can eliminate that problem in the subsequent >>> rfc5766-turn-server maintenance releases, but still... >>> >>> I am sorry that I did not discover that previously and that I advocated >>> an incompatible implementation option. >>> >>> So, if the WG insists on a backward-compatible protocol in all senses, >>> then we have to choose another option. >>> >>> Thanks >>> Oleg >>> >>> >>> >>> >>> >>> On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko >>> wrote: >>> >>> I checked the code of rfc5766-turn-server again, and I found that it >>> will NOT handle the multiple-RAF case. It will return 400 error with th= e >>> message "Only one address family attribute can be used in a request". A= t >>> least, it's been that way in the 2014 releases. I did not check the old= er >>> releases. >>> >>> Sorry that I provided a wrong information about the implementation, >>> before. >>> >>> I can fix that code but still there are people out there who will be >>> using the "wrong" versions. >>> >>> So, if we do have to be absolutely backward compatible then we have to >>> use a different option... >>> >>> Oleg >>> >>> >>> >>> >>> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti >>> wrote: >>> >>> I reviewed the code for restund, reTurn, and rfc5766-turn-server and >>> they all appear to handle RAF (and multiple RAF) OK. >>> >>> >>> >>> The problem, as I see it, is that there may be other TURN servers, >>> perhaps non-open-source ones, that work fine today with Chrome, but wil= l >>> start returning errors when we include RAF or multiple RAF, and so maki= ng >>> this change may break some small number of apps (who will then blame >>> Chrome). We just don't know what is out there. >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >>> wrote: >>> >>> >>> >>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >>> wrote: >>> >>> After your detail analysis and the sentence =E2=80=9CFor either b/c, we= would >>> need to say that including both RAF and OAF/AAF for the same address fa= mily >>> is prohibited.=E2=80=9D, I think it may be better to keep only one attr= ibute to >>> fulfill the SSODA requirement? >>> >>> >>> There is no requirement that SSODA functionality be realized with only >>> one attribute, nor that the protocol be elegant, nor that it exhibits >>> symmetry that is pleasing to the eye. >>> >>> >>> >>> There *is* a requirement that it be backwards-compatible though. Whethe= r >>> that means compatible with the spec or compatible with actual >>> implementations is a matter of debate. >>> >>> >>> >>> Justin, if we can't find a single implementation that would barf, why >>> would Chrome have to implement a complex fallback mechanism? >>> >>> >>> >>> Simon >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >> > --047d7b86c898483935050cc93cef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Then we are back to, I guess, the option c).

On Fri, Jan 16, 2015 = at 9:10 AM, Justin Uberti <juberti@google.com> wrote:
It's too late to take thi= s approach. Every existing TURN server out there assumes that no RAF =3D IP= v4. We can't change the past.

It's also not clea= r how you expect this to provide SSODA functionality, e.g. how do you disti= nguish between an IPv4 client asking for v6 only vs v4+v6.

On Th= u, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko <mom040267@gmail.com&g= t; wrote:
I = think that that proposal makes sense. But I am not sure that it is backward= -compatible enough. We have to go through all cases of SSODA/non-SSODA enti= ties communicating, for different protocol request options.

Ai= jun, would you like to go through all those cases to double-check that it w= orks as supposed ?

Thanks
Oleg
<= br>

On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang <wan= gaijun@tsinghua.org.cn> wrote:

Hi,Tiru,Pal and Justin:

=C2=A0

I suggest we use the =E2=80=9CREQUESTED-A= DDRESS-FAMILY=E2=80=9D attribute to fulfill the function of SSODA by clarif= ying the behavior of TURN server based on whether this attribute is present= or not:

=C2=A0

1. If the =E2=80=9CRAF=E2=80=9D= attribute is not present, then the allocated relay address family will be = same as the source address=E2=80=99s family =C2=A0of Allocate Request messa= ge. =C2=A0https://tools.ietf.org/html/rfc6156#section-4.2 has the fo= llowing description:

=C2=A0

=E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent=
, the server MUST

=C2=A0= =C2=A0 allocate an IPv4-relayed transport address for the TURN client.=C2= =A0 If

=C2=A0=C2=A0 allocat= ion of IPv4 addresses is disabled by local policy, the server=

=C2=A0=C2=A0 returns a 440 (Address Fami= ly not Supported) Allocate error response.=E2=80=9D

=C2=A0

This paragraph= should be modified as below:

=E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server=
 MUST

=C2=A0=C2=A0 alloca= te an relayed transport address from the same family as the source addre= ss of Allocate Request message for the TURN client.=C2=A0 If this=

=C2=A0=C2=A0 allocatio= n is disabled by local policy, the server<= /p>

=C2=A0=C2=A0 returns a 440 (Address Family not= Supported) Allocate error response.=E2=80=9D

=C2=A0

2. If the =E2=80= =9CRAF=E2=80=9D attribute is present, then the following procedure of the c= lient and server should only need to conform to https://tools.ietf.org/html/rfc6156<= /a>, no new attribute and procedure need be introduced.

<= /u>=C2=A0

3. Here, the RAF attribute act just as the =E2=80=9CAdditi= onal Attribute Family=E2=80=9D attribute that I proposed previously.=C2=A0 = Will such solution be less confusable and be less prone to problem to the T= URN developer?

RFC6156 also describes the following sentence:
=E2=80=9CThe REQUESTED-ADDRESS-FAMILY
=C2=
=A0=C2=A0 attribute allows a client to explicitly request the addres=
s type the
=C2=A0=C2=A0 TURN server will allocate (e.g., an IPv4-only node=
 may request the
=C2=A0=C2=A0 TURN server to allocate an IPv6 address).=E2=
=80=9D

If we can change the name of the attribute, then change= the attribute name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9C= Additional Attribute Famil= y=E2=80=9D may be more better= . If this is impossible, we just need only update the behavior of TURN serv= er that described in RFC6156, =C2=A0as I suggested above.

=C2=A0

Best Regards.

Aijun Wang

=C2=A0=

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy= )
Sent: Thursday, January 15, 2015 10:24 PM
To: Pal Mar= tinsen (palmarti); Justin Uberti


Cc: tram@ietf.org
Subject= : Re: [tram] SSODA in TURN-bis

=C2=A0<= /u>

From: Pal Martinsen (palmarti)
Sent: Thursday, January 15, 2015 4:49 PM
To: Justin Uberti; Tirumale= swar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] SSODA in TURN-b= is

<= /u>=C2=A0

<= /u>=C2=A0

On 14 Jan = 2015, at 23:44, Justin Uberti <juberti@google.com> wrote:

=C2=A0=

=C2=A0<= /u>

=C2= =A0

On We= d, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:<= /u>

Hi, <= u>

=C2=A0

I do not see a problem with a TURN server returning a 400 error = code if it gets confused by two RAFs.

This is almost covered in section= 2.4 of the SSODA draft. Client fallback to non-SSODA mode when encounterin= g an error seems trivial.=C2=A0

(Unless the TURN server ends up using t= o much CPU, overheats, and causes a fire in the datacenter)

=C2= =A0

But I might like c) better anyway. Adding a new attribute seems cleaner wh= en adding new functionality.

=C2=A0

Saving a roundtrip (i.e. = by not having to retry) when doing SSODA is also a good thing.

=C2=A0

Good point. Since this probably would t= ake some time to deploy on the server side the extra chatter could become a= bit annoying.=C2=A0

=C2=A0

Tiru, do you have enough information to= add this to the TURNbis draft?

=C2=A0

[TR] Yes, If there are no further objection= s will update the draft next week.

=C2=A0

Cheer= s,

-Tiru

=C2=A0

Or do you think more discussion is nee= ded?

=C2=A0

.-.

P=C3=A5l-Erik

<= div>

=C2=A0

<= div>

=C2=A0=

.-.

P=C3=A5l= -Erik

<= span lang=3D"EN-US">=C2=A0

On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <= tireddy@cisco.com> wrote:

=C2=A0

From:=C2=A0Justin Uberti [= mailto:juberti@google.com]=C2=A0
Sent:=C2=A0= Saturday, January 10, 2015 2:19 AM
To:=C2=A0Oleg Moskalenko
Cc:=C2=A0Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy);=C2= =A0tram@ietf.org
Subject:=C2=A0Re: [tram] SSODA i= n TURN-bis

=

=C2=A0=

OK, so we= have clear evidence that some deployed servers will fail (deterministicall= y, fortunately) on the current SSODA proposal.

=C2=A0

So we're back to which backwards-compatible option we want to pursue= . I suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMI= LY.

=C2=A0

Separately, we need to decide whet= her we want to pursue issue #2 that I identified previously, i.e., allowing= specific error codes to be returned for each address family.=

=C2= =A0

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I double-checked that with a real test. I ran the= coTurn test client (that implements experimental SSODA draft with two RAF = attributes) against rfc5766-turn-server and the server yielded error 400 wi= th the message "Only one address family attribute can be used in a req= uest"

:(

As I said, I can elimina= te that problem in the subsequent rfc5766-turn-server maintenance releases,= but still...

I am sorry that I did not disco= ver that previously and that I advocated an incompatible implementation opt= ion.

So, if the WG insists on a backward-comp= atible protocol in all senses, then we have to choose another option.

Thanks
Oleg

=C2=A0

<= /div>

= =C2=A0

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I checked the code of rfc5766-turn-server again, and I found th= at it will NOT handle the multiple-RAF case. It will return 400 error with = the message "Only one address family attribute can be used in a reques= t". At least, it's been that way in the 2014 releases. I did not c= heck the older releases.

Sorry that I pr= ovided a wrong information about the implementation, before.<= /span>

= I can fix that code but still there are people out the= re who will be using the "wrong" versions.

So, if we do have to be absolutely backward compatible then we= have to use a different option...

=

Oleg=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <juberti= @google.com> wrote:

I reviewed the code for restund, reTurn, and rfc5766-turn-server and th= ey all appear to handle RAF (and multiple RAF) OK.

=

=C2=A0

The problem, as I see it, is that there may be other TURN servers, p= erhaps non-open-source ones, that work fine today with Chrome, but will sta= rt returning errors when we include RAF or multiple RAF, and so making this= change may break some small number of apps (who will then blame Chrome). W= e just don't know what is out there.

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 9, 201= 5 at 6:11 AM, Simon Perreault <sperreault@jive.com= > wrote:

=C2=A0

On Fri, Jan 9, 2015 at 4:17 AM, A= ijun Wang <wangaijun@tsinghua.org.cn> wro= te:

After your detail analysis and the sentence =E2=80=9CFor either b/c= , we would need to say that including both RAF and OAF/AAF for the same add= ress family is prohibited.=E2=80=9D, I think it may be better to keep only = one attribute to fulfill the SSODA requirement? =C2=A0=


There = is no requirement that SSODA functionality be realized with only one attrib= ute, nor that the protocol be elegant, nor that it exhibits symmetry that i= s pleasing to the eye.

=C2=A0

=

There *is* a re= quirement that it be backwards-compatible though. Whether that means compat= ible with the spec or compatible with actual implementations is a matter of= debate.

=C2=A0

Justin, if we can't find = a single implementation that would barf, why would Chrome have to implement= a complex fallback mechanism?

=C2= =A0

Simo= n

=C2=A0

=C2=A0

____________________= ___________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/= tram

=C2=A0

=C2=A0

=C2=A0

____= ___________________________________________
tram mailing list
= tram@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tram

=C2= =A0


________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tram

=C2=A0

=C2=A0


__________________________________= _____________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram




--047d7b86c898483935050cc93cef-- From nobody Fri Jan 16 11:37:22 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A501B2AD3 for ; Fri, 16 Jan 2015 11:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 heT66e7hczIl for ; Fri, 16 Jan 2015 11:37:15 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8581B2AD2 for ; Fri, 16 Jan 2015 11:37:14 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so5184825igq.0 for ; Fri, 16 Jan 2015 11:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2TZ/6gvVrAhzrl1B+IM/DqQkbR2/1RoHydn1UYnURt0=; b=mjY5ajvlh9vgr0B5dAF7MrZ20NgGC6ghMeMBt5Pm8vYsh+K6dFj0z1n4G+VVwH/P8X dYnoXKGkoufGGFE07hpz4AdQXMbxyijpyoGcbq8HARuhVPnSLCD6I8oyfl+a6ZhbzEXG +ictGkA797Z1Rjpddj2qV04GYAa8Cjm2eQkEL3FKeKoQmGO+AWeGs7Lm1M/HoZ1UEmQJ 3ctwcWLyZ7VlBWYqIWJca4mBEphiBqj4ThgJm/oItDgcZRuO+tarRqL8fO08hefaHyTQ 1ZqX0rchg4dXxrab6hkr4ruv6eCzaQ5M023XIXcsKSlA5RQVlAlfUnZbZ4Z5FOKVivhx Ki/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2TZ/6gvVrAhzrl1B+IM/DqQkbR2/1RoHydn1UYnURt0=; b=dqhznFOhiXd5TQJ0edVicU11uvgprl94QsAS86OUvNBQhMJRB447uzNUcJKFRmRArs MIJbdumadeQugpTDzcjsRrdRGWXUQQ3dzfLmBOcdIUZEG4VEfbb4EcHzUY73SPtzCmgj B5EoOQ0IwAtQ3yGNN52zIClwciR7ecpnJnErMqkn3nxgysi+fejgLQGxTmLMbXcVKj7T 77D7f2kIcM/CdKZ2ceWKjUDFskBy7Q3q7Zub6k403nquw8MUl6WdBKZlzq9NzDzbGaNd jJVdodW5piET4iIHUvnlbtxXF978TRMvLS2FMoDggsDW/qubnllMUvQycWnY15kWHQLn Te1w== X-Gm-Message-State: ALoCoQmrgUo5pO5eJrYgJv+YM3rMlwQJbvDbEeu1sNbhx3Pc+XogGDA2CY0eP0FVJcNYf7MlnOwc X-Received: by 10.42.62.145 with SMTP id y17mr16797188ich.21.1421437029323; Fri, 16 Jan 2015 11:37:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.59.40 with HTTP; Fri, 16 Jan 2015 11:36:49 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> From: Justin Uberti Date: Fri, 16 Jan 2015 11:36:49 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=90e6ba6149a03434ef050cca19b6 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 19:37:19 -0000 --90e6ba6149a03434ef050cca19b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yeah. I think we should just get this into turn-bis and be done with it. Nobody seemed to have much of an opinion on ADDRESS-ERROR-CODE, so I suggest we write it up and see if we still like it. On Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko wrote: > Then we are back to, I guess, the option c). > > On Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti wrote= : > >> It's too late to take this approach. Every existing TURN server out ther= e >> assumes that no RAF =3D IPv4. We can't change the past. >> >> It's also not clear how you expect this to provide SSODA functionality, >> e.g. how do you distinguish between an IPv4 client asking for v6 only vs >> v4+v6. >> >> On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko >> wrote: >> >>> I think that that proposal makes sense. But I am not sure that it is >>> backward-compatible enough. We have to go through all cases of >>> SSODA/non-SSODA entities communicating, for different protocol request >>> options. >>> >>> Aijun, would you like to go through all those cases to double-check tha= t >>> it works as supposed ? >>> >>> Thanks >>> Oleg >>> >>> >>> On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang >>> wrote: >>> >>>> Hi,Tiru,Pal and Justin: >>>> >>>> >>>> >>>> I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attrib= ute to fulfill >>>> the function of SSODA by clarifying the behavior of TURN server based = on >>>> whether this attribute is present or not: >>>> >>>> >>>> >>>> 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the all= ocated relay >>>> address family will be same as the source address=E2=80=99s family of= Allocate >>>> Request message. https://tools.ietf.org/html/rfc6156#section-4.2 has >>>> the following description: >>>> >>>> >>>> >>>> =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the serv= er MUST >>>> >>>> allocate an IPv4-relayed transport address for the TURN client. If >>>> >>>> allocation of IPv4 addresses is disabled by local policy, the serve= r >>>> >>>> returns a 440 (Address Family not Supported) Allocate error respons= e. >>>> =E2=80=9D >>>> >>>> >>>> >>>> This paragraph should be modified as below: >>>> >>>> =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the serv= er MUST >>>> >>>> allocate an relayed transport address *from the same family as the >>>> source address of Allocate Request message* for the TURN client. If >>>> *this* >>>> >>>> * allocation* is disabled by local policy, the server >>>> >>>> returns a 440 (Address Family not Supported) Allocate error respons= e. >>>> =E2=80=9D >>>> >>>> >>>> >>>> 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the followi= ng procedure of >>>> the client and server should only need to conform to >>>> https://tools.ietf.org/html/rfc6156, no new attribute and procedure >>>> need be introduced. >>>> >>>> >>>> >>>> 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribu= te >>>> Family=E2=80=9D attribute that I proposed previously. Will such solut= ion be less >>>> confusable and be less prone to problem to the TURN developer? >>>> >>>> RFC6156 also describes the following sentence: >>>> >>>> =E2=80=9CThe REQUESTED-ADDRESS-FAMILY >>>> >>>> attribute allows a client to *explicitly* request the address type = the >>>> >>>> TURN server will allocate (e.g., an IPv4-only node may request the >>>> >>>> TURN server to allocate an IPv6 address).=E2=80=9D >>>> >>>> If we can change the name of the attribute, then change the attribute >>>> name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional= Attribute Family=E2=80=9D may >>>> be more better. If this is impossible, we just need only update the >>>> behavior of TURN server that described in RFC6156, as I suggested abo= ve. >>>> >>>> >>>> >>>> Best Regards. >>>> >>>> Aijun Wang >>>> >>>> >>>> >>>> >>>> >>>> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Tirumaleswa= r >>>> Reddy (tireddy) >>>> *Sent:* Thursday, January 15, 2015 10:24 PM >>>> *To:* Pal Martinsen (palmarti); Justin Uberti >>>> >>>> *Cc:* tram@ietf.org >>>> *Subject:* Re: [tram] SSODA in TURN-bis >>>> >>>> >>>> >>>> *From:* Pal Martinsen (palmarti) >>>> *Sent:* Thursday, January 15, 2015 4:49 PM >>>> *To:* Justin Uberti; Tirumaleswar Reddy (tireddy) >>>> *Cc:* tram@ietf.org >>>> *Subject:* Re: [tram] SSODA in TURN-bis >>>> >>>> >>>> >>>> >>>> >>>> On 14 Jan 2015, at 23:44, Justin Uberti wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) < >>>> palmarti@cisco.com> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> I do not see a problem with a TURN server returning a 400 error code i= f >>>> it gets confused by two RAFs. >>>> >>>> This is almost covered in section 2.4 of the SSODA draft. Client >>>> fallback to non-SSODA mode when encountering an error seems trivial. >>>> >>>> (Unless the TURN server ends up using to much CPU, overheats, and >>>> causes a fire in the datacenter) >>>> >>>> >>>> >>>> But I might like c) better anyway. Adding a new attribute seems cleane= r >>>> when adding new functionality. >>>> >>>> >>>> >>>> Saving a roundtrip (i.e. by not having to retry) when doing SSODA is >>>> also a good thing. >>>> >>>> >>>> >>>> Good point. Since this probably would take some time to deploy on the >>>> server side the extra chatter could become a bit annoying. >>>> >>>> >>>> >>>> Tiru, do you have enough information to add this to the TURNbis draft? >>>> >>>> >>>> >>>> [TR] Yes, If there are no further objections will update the draft nex= t >>>> week. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> -Tiru >>>> >>>> >>>> >>>> Or do you think more discussion is needed? >>>> >>>> >>>> >>>> .-. >>>> >>>> P=C3=A5l-Erik >>>> >>>> >>>> >>>> >>>> >>>> .-. >>>> >>>> P=C3=A5l-Erik >>>> >>>> >>>> >>>> On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) < >>>> tireddy@cisco.com> wrote: >>>> >>>> >>>> >>>> ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s = a >>>> temporary or long-term error. >>>> >>>> >>>> >>>> -Tiru >>>> >>>> >>>> >>>> *From:* Justin Uberti [mailto:juberti@google.com ] >>>> *Sent:* Saturday, January 10, 2015 2:19 AM >>>> *To:* Oleg Moskalenko >>>> *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); >>>> tram@ietf.org >>>> *Subject:* Re: [tram] SSODA in TURN-bis >>>> >>>> >>>> >>>> OK, so we have clear evidence that some deployed servers will fail >>>> (deterministically, fortunately) on the current SSODA proposal. >>>> >>>> >>>> >>>> So we're back to which backwards-compatible option we want to pursue. = I >>>> suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAM= ILY. >>>> >>>> >>>> >>>> Separately, we need to decide whether we want to pursue issue #2 that = I >>>> identified previously, i.e., allowing specific error codes to be retur= ned >>>> for each address family. >>>> >>>> >>>> >>>> On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko >>>> wrote: >>>> >>>> I double-checked that with a real test. I ran the coTurn test client >>>> (that implements experimental SSODA draft with two RAF attributes) aga= inst >>>> rfc5766-turn-server and the server yielded error 400 with the message = "Only >>>> one address family attribute can be used in a request" >>>> >>>> :( >>>> >>>> As I said, I can eliminate that problem in the subsequent >>>> rfc5766-turn-server maintenance releases, but still... >>>> >>>> I am sorry that I did not discover that previously and that I advocate= d >>>> an incompatible implementation option. >>>> >>>> So, if the WG insists on a backward-compatible protocol in all senses, >>>> then we have to choose another option. >>>> >>>> Thanks >>>> Oleg >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko >>>> wrote: >>>> >>>> I checked the code of rfc5766-turn-server again, and I found that it >>>> will NOT handle the multiple-RAF case. It will return 400 error with t= he >>>> message "Only one address family attribute can be used in a request". = At >>>> least, it's been that way in the 2014 releases. I did not check the ol= der >>>> releases. >>>> >>>> Sorry that I provided a wrong information about the implementation, >>>> before. >>>> >>>> I can fix that code but still there are people out there who will be >>>> using the "wrong" versions. >>>> >>>> So, if we do have to be absolutely backward compatible then we have to >>>> use a different option... >>>> >>>> Oleg >>>> >>>> >>>> >>>> >>>> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti >>>> wrote: >>>> >>>> I reviewed the code for restund, reTurn, and rfc5766-turn-server and >>>> they all appear to handle RAF (and multiple RAF) OK. >>>> >>>> >>>> >>>> The problem, as I see it, is that there may be other TURN servers, >>>> perhaps non-open-source ones, that work fine today with Chrome, but wi= ll >>>> start returning errors when we include RAF or multiple RAF, and so mak= ing >>>> this change may break some small number of apps (who will then blame >>>> Chrome). We just don't know what is out there. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault >>>> wrote: >>>> >>>> >>>> >>>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang >>>> wrote: >>>> >>>> After your detail analysis and the sentence =E2=80=9CFor either b/c, w= e would >>>> need to say that including both RAF and OAF/AAF for the same address f= amily >>>> is prohibited.=E2=80=9D, I think it may be better to keep only one att= ribute to >>>> fulfill the SSODA requirement? >>>> >>>> >>>> There is no requirement that SSODA functionality be realized with only >>>> one attribute, nor that the protocol be elegant, nor that it exhibits >>>> symmetry that is pleasing to the eye. >>>> >>>> >>>> >>>> There *is* a requirement that it be backwards-compatible though. >>>> Whether that means compatible with the spec or compatible with actual >>>> implementations is a matter of debate. >>>> >>>> >>>> >>>> Justin, if we can't find a single implementation that would barf, why >>>> would Chrome have to implement a complex fallback mechanism? >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>> >> > --90e6ba6149a03434ef050cca19b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yeah. I think we should just get this into turn-bis and be= done with it.

Nobody seemed to have much of an opinion = on ADDRESS-ERROR-CODE, so I suggest we write it up and see if we still like= it.

O= n Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
Then= we are back to, I guess, the option c).

On= Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti <juberti@google.com>= wrote:
It's = too late to take this approach. Every existing TURN server out there assume= s that no RAF =3D IPv4. We can't change the past.

It= 's also not clear how you expect this to provide SSODA functionality, e= .g. how do you distinguish between an IPv4 client asking for v6 only vs v4+= v6.

On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko <<= a href=3D"mailto:mom040267@gmail.com" target=3D"_blank">mom040267@gmail.com= > wrote:
<= div>I think that that proposal makes sense. But I am not sure that it is ba= ckward-compatible enough. We have to go through all cases of SSODA/non-SSOD= A entities communicating, for different protocol request options.

Aijun, would you like to go through all those cases to double-check tha= t it works as supposed ?

Thanks
Ole= g


On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:

Hi,Tiru,Pal and Ju= stin:

=C2=A0

<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-s= erif";color:#1f497d" lang=3D"EN-US">I suggest we use the =E2=80=9CREQU= ESTED-ADDRESS-FAMILY=E2=80=9D attribute to fulfill the function of SSODA by= clarifying the behavior of TURN server based on whether this attribute is = present or not:

=C2=A0

1. If the =E2=80=9CRAF= =E2=80=9D attribute is not present, then the allocated relay address family= will be same as the source address=E2=80=99s family =C2=A0of Allocate Requ= est message. =C2=A0https://tools.ietf.org/html/rfc6156#section-4.2 h= as the following description:

=C2=A0

= 
=E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute=
 is absent, the server MUST

=C2=A0=C2=A0 allocate an IPv4-relayed transport address for the TURN cli= ent.=C2=A0 If

=C2=A0=C2=A0 = allocation of IPv4 addresses is disabled by local policy, the server=

=C2=A0=C2=A0 returns a 440 (Addre= ss Family not Supported) Allocate error response.=E2=80=9D

=C2=A0<= /p>

This pa= ragraph should be modified as below:

=E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the=
 server MUST

=C2=A0=C2= =A0 allocate an relayed transport address from the same family as the so= urce address of Allocate Request message for the TURN client.=C2=A0 If = this

=C2=A0=C2= =A0 allocation is disabled by local policy, the server

=C2=A0=C2=A0 returns a 440 (Address= Family not Supported) Allocate error response.=E2=80=9D

=C2=A0

2. If the= =E2=80=9CRAF=E2=80=9D attribute is present, then the following procedure o= f the client and server should only need to conform to https://tools.ietf.org/html/r= fc6156, no new attribute and procedure need be introduced.

=C2=A0

3. Here, the RAF attribute act just as the =E2=80= =9CAdditional Attribute Family=E2=80=9D attribute that I proposed previousl= y.=C2=A0 Will such solution be less confusable and be less prone to problem= to the TURN developer?

RFC6156 also describes the following sentence:
=E2=80=9C<=
/span>The REQUESTED-ADDRESS-FA=
MILY
=C2=A0=C2=A0 attribute allows a client to explicitly request=
 the address type the
=C2=A0=C2=A0 TURN server will allocate (e.g., an IPv=
4-only node may request the
=C2=A0=C2=A0 TURN server to allocate an IPv6 a=
ddress).=E2=80=9D

If we can change the name of the attribute, = then change the attribute name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D t= o =E2=80=9CAdditional Attr= ibute Family=E2=80=9D may be = more better. If this is impossible, we just need only update the behavior o= f TURN server that described in RFC6156, =C2=A0as I suggested above.=

=C2=A0

Best Regards.

Aijun Wang

=C2=A0

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar R= eddy (tireddy)
Sent: Thursday, January 15, 2015 10:24 PM
To= : Pal Martinsen (palmarti); Justin Uberti


Cc= : tram@ietf.org<= br>Subject: Re: [tram] SSODA in TURN-bis

<= /u>=C2=A0

From: Pal Martinsen (palmarti) <= br>Sent: Thursday, January 15, 2015 4:49 PM
To: Justin Ube= rti; Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] SSO= DA in TURN-bis

=C2=A0

=C2=A0

On 14 Jan 2015, at 23:44, Justin Uberti <juberti@google.com> wrote:<= /span>

=C2=A0

=C2=A0

= =C2=A0

On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) <palmarti@cisco.com>= wrote:

Hi,

=C2=A0

I do not see a problem with a TURN server returning a= 400 error code if it gets confused by two RAFs.

This is almost covered= in section 2.4 of the SSODA draft. Client fallback to non-SSODA mode when = encountering an error seems trivial.=C2=A0

(Unless the TURN server ends= up using to much CPU, overheats, and causes a fire in the datacenter)

= =C2=A0

But I might like c) better anyway. Adding a new attribute seems = cleaner when adding new functionality.

=

=C2=A0

Saving a roundt= rip (i.e. by not having to retry) when doing SSODA is also a good thing.=

=C2=A0

Good point. Since this probabl= y would take some time to deploy on the server side the extra chatter could= become a bit annoying.=C2=A0

=C2=A0

Tiru, do you have enough inf= ormation to add this to the TURNbis draft?

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d" lang=3D"EN-US">[TR] Yes, If there are no further = objections will update the draft next week.

=C2=A0<= /u>

Cheers,

-Tiru

=C2=A0

Or do you think more discussi= on is needed?

=C2=A0

.-.

P=C3=A5l-Erik

=

=C2=A0

=C2=A0=

.-.

P= =C3=A5l-Erik

=C2=A0

= On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy)= <tireddy@cisco.c= om> wrote:

=C2=A0

ADDRESS-ERROR-CODE see= ms useful, client can determine if it=E2=80=99s a temporary or long-term er= ror.

=C2=A0

-Tiru

=C2=A0=

From:=C2=A0Justin Ube= rti [mailto:juberti@google.com]=C2=A0
Sent:= =C2=A0Saturday, January 10, 2015 2:19 AM
To:=C2=A0Oleg Moskalenko=
Cc:=C2=A0Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tiredd= y);=C2=A0tram@ietf.org
Subject:=C2=A0Re: [tram] S= SODA in TURN-bis

=

=C2=A0<= u>

OK,= so we have clear evidence that some deployed servers will fail (determinis= tically, fortunately) on the current SSODA proposal.

=C2=A0=

So we're back to which backwards-compatible option we want t= o pursue. I suggest c), which is the optional-comprehension ADDITIONAL-ADDR= ESS-FAMILY.

=C2=A0

=

Separately, we need to dec= ide whether we want to pursue issue #2 that I identified previously, i.e., = allowing specific error codes to be returned for each address family.

=C2=A0

= On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <<= a href=3D"mailto:mom040267@gmail.com" target=3D"_blank">mom040267@gmail.com> wrote:

I double-checked that with a real test. I r= an the coTurn test client (that implements experimental SSODA draft with tw= o RAF attributes) against rfc5766-turn-server and the server yielded error = 400 with the message "Only one address family attribute can be used in= a request"

:(

As I said, I can e= liminate that problem in the subsequent rfc5766-turn-server maintenance rel= eases, but still...

I am sorry that I did not= discover that previously and that I advocated an incompatible implementati= on option.

So, if the WG insists on a backwar= d-compatible protocol in all senses, then we have to choose another option.=

Thanks
Oleg=

=C2=A0

<= /div>

=C2=A0

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <= mom040267@gmail.com> wrote:

I checked the code of rfc5766-turn-server again, and I fo= und that it will NOT handle the multiple-RAF case. It will return 400 error= with the message "Only one address family attribute can be used in a = request". At least, it's been that way in the 2014 releases. I did= not check the older releases.

Sorry th= at I provided a wrong information about the implementation, before.<= u>

I can fix that code but still there are people = out there who will be using the "wrong" versions.

<= span lang=3D"EN-US">So, if we do have to be absolutely backward compatible = then we have to use a different option...

= Oleg
=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <= juberti@google.com> wrote:

I reviewed the code for restund, reTurn, and rfc5766-turn-server= and they all appear to handle RAF (and multiple RAF) OK.

=C2=A0

The problem, as I see it, is that there may be other TURN ser= vers, perhaps non-open-source ones, that work fine today with Chrome, but w= ill start returning errors when we include RAF or multiple RAF, and so maki= ng this change may break some small number of apps (who will then blame Chr= ome). We just don't know what is out there.

=C2=A0

=C2=A0

=

=C2=A0

________= _______________________________________
tram mailing list
tram@i= etf.org
https://www.ietf.org/mailm= an/listinfo/tram

=C2=A0

=C2=A0<= u>

=C2=A0

_______________________________________________
tram mailing lis= t
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

= =C2=A0


________________= _______________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mai= lman/listinfo/tram

=C2=A0

=C2=A0


_________________________= ______________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram





--90e6ba6149a03434ef050cca19b6-- From nobody Mon Jan 19 01:11:50 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6F1AD355 for ; Mon, 19 Jan 2015 01:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.491 X-Spam-Level: *** X-Spam-Status: No, score=3.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_PSBL=2.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Yi7BqJskV6cW for ; Mon, 19 Jan 2015 01:11:38 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBBC1A8A4A for ; Mon, 19 Jan 2015 01:11:33 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06BbAwBrtLxUvsQVAQ==.40600S4; Mon, 19 Jan 2015 15:38:23 +0800 (CST) From: "Aijun Wang" To: "'Justin Uberti'" , "'Oleg Moskalenko'" References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> In-Reply-To: Date: Mon, 19 Jan 2015 17:11:05 +0800 Message-ID: <00c901d033c7$db226fc0$91674f40$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01D0340A.E945AFC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAxt/3DT7R3K5/2Q6itgQg9vgtaPQCDTTgg Content-Language: zh-cn X-CM-TRANSID: Z0GX06BbAwBrtLxUvsQVAQ==.40600S4 X-Coremail-Antispam: 1U3129KBjvJXoW3ZrW8XF4fGw1kArW5Ww17Jrb_yoWDZry3pF W5Gry5Gr4kXF1xuw4kZr4IgryF9rZ5GFy7Grn5Kr12y3s8WasFvFy8Kw4Y9r9rGrs5Ca1Y vrWj9r47u345Z3DanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r126r1D0xZFpf9x0JUZVyxUUUUU= Archived-At: Cc: "'Pal Martinsen \(palmarti\)'" , tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 09:11:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01D0340A.E945AFC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Justin: =20 According to the guideline defined in = https://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with = the situation that one IPv6-only client send the Allocation Request, but = does not include RAF attribute? Will you still allocate it one IPv4 = Relay Address in default? =20 I think IPv4-only client will always need one IPv4 relay address and = IPv6-only client will always need one IPv6 relay address. If they need = additional relay address that in belong to other address family, they = just need include one RAF or AAF attribute in the Allocate Request, this = can accomplish the SSODA requirement that you mentioned. =20 TURN server that receives the Allocation Request which includes one RAF = or AAF attribute should do the following task: 1. Check the validity of the message. The required RAF or AAF attribute = should be different from the address family of source address of the = Allocate Request message. 2. If valid, Allocate two relay address for this client simultaneously. = One for default address type, and the other is the required address = type. 3. All other guidelines of RFC6156 keeps unchanged. =20 Is this more simple? =20 Best Regards. Aijun Wang. =20 From: Justin Uberti [mailto:juberti@google.com]=20 Sent: Saturday, January 17, 2015 3:37 AM To: Oleg Moskalenko Cc: Aijun Wang; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); = tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 yeah. I think we should just get this into turn-bis and be done with it. =20 Nobody seemed to have much of an opinion on ADDRESS-ERROR-CODE, so I = suggest we write it up and see if we still like it. =20 On Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko = wrote: Then we are back to, I guess, the option c). =20 On Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti = wrote: It's too late to take this approach. Every existing TURN server out = there assumes that no RAF =3D IPv4. We can't change the past. =20 It's also not clear how you expect this to provide SSODA functionality, = e.g. how do you distinguish between an IPv4 client asking for v6 only vs = v4+v6. =20 On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko = wrote: I think that that proposal makes sense. But I am not sure that it is = backward-compatible enough. We have to go through all cases of = SSODA/non-SSODA entities communicating, for different protocol request = options. Aijun, would you like to go through all those cases to double-check that = it works as supposed ? Thanks Oleg =20 On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang = wrote: Hi,Tiru,Pal and Justin: =20 I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D = attribute to fulfill the function of SSODA by clarifying the behavior of = TURN server based on whether this attribute is present or not: =20 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the = allocated relay address family will be same as the source = address=E2=80=99s family of Allocate Request message. = https://tools.ietf.org/html/rfc6156#section-4.2 has the following = description: =20 =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST allocate an IPv4-relayed transport address for the TURN client. If allocation of IPv4 addresses is disabled by local policy, the server returns a 440 (Address Family not Supported) Allocate error = response.=E2=80=9D =20 This paragraph should be modified as below: =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST allocate an relayed transport address from the same family as the = source address of Allocate Request message for the TURN client. If this allocation is disabled by local policy, the server returns a 440 (Address Family not Supported) Allocate error = response.=E2=80=9D =20 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the following = procedure of the client and server should only need to conform to = https://tools.ietf.org/html/rfc6156, no new attribute and procedure need = be introduced.=20 =20 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribute = Family=E2=80=9D attribute that I proposed previously. Will such = solution be less confusable and be less prone to problem to the TURN = developer? RFC6156 also describes the following sentence: =E2=80=9CThe REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address).=E2=80=9D If we can change the name of the attribute, then change the attribute = name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional = Attribute Family=E2=80=9D may be more better. If this is impossible, we = just need only update the behavior of TURN server that described in = RFC6156, as I suggested above. =20 Best Regards. Aijun Wang =20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy (tireddy) Sent: Thursday, January 15, 2015 10:24 PM To: Pal Martinsen (palmarti); Justin Uberti Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 From: Pal Martinsen (palmarti)=20 Sent: Thursday, January 15, 2015 4:49 PM To: Justin Uberti; Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 =20 On 14 Jan 2015, at 23:44, Justin Uberti wrote: =20 =20 =20 On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) = wrote: Hi,=20 =20 I do not see a problem with a TURN server returning a 400 error code if = it gets confused by two RAFs. This is almost covered in section 2.4 of the SSODA draft. Client = fallback to non-SSODA mode when encountering an error seems trivial.=20 (Unless the TURN server ends up using to much CPU, overheats, and causes = a fire in the datacenter) =20 But I might like c) better anyway. Adding a new attribute seems cleaner = when adding new functionality. =20 Saving a roundtrip (i.e. by not having to retry) when doing SSODA is = also a good thing. =20 Good point. Since this probably would take some time to deploy on the = server side the extra chatter could become a bit annoying.=20 =20 Tiru, do you have enough information to add this to the TURNbis draft?=20 =20 [TR] Yes, If there are no further objections will update the draft next = week. =20 Cheers, -Tiru =20 Or do you think more discussion is needed? =20 .-. P=C3=A5l-Erik =20 =20 .-. P=C3=A5l-Erik =20 On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) = wrote: =20 ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a = temporary or long-term error. =20 -Tiru =20 From: Justin Uberti [ = mailto:juberti@google.com]=20 Sent: Saturday, January 10, 2015 2:19 AM To: Oleg Moskalenko Cc: Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); = tram@ietf.org Subject: Re: [tram] SSODA in TURN-bis =20 OK, so we have clear evidence that some deployed servers will fail = (deterministically, fortunately) on the current SSODA proposal. =20 So we're back to which backwards-compatible option we want to pursue. I = suggest c), which is the optional-comprehension = ADDITIONAL-ADDRESS-FAMILY. =20 Separately, we need to decide whether we want to pursue issue #2 that I = identified previously, i.e., allowing specific error codes to be = returned for each address family. =20 On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko < = mom040267@gmail.com> wrote: I double-checked that with a real test. I ran the coTurn test client = (that implements experimental SSODA draft with two RAF attributes) = against rfc5766-turn-server and the server yielded error 400 with the = message "Only one address family attribute can be used in a request" :( As I said, I can eliminate that problem in the subsequent = rfc5766-turn-server maintenance releases, but still... I am sorry that I did not discover that previously and that I advocated = an incompatible implementation option. So, if the WG insists on a backward-compatible protocol in all senses, = then we have to choose another option. Thanks Oleg =20 =20 On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko < = mom040267@gmail.com> wrote: I checked the code of rfc5766-turn-server again, and I found that it = will NOT handle the multiple-RAF case. It will return 400 error with the = message "Only one address family attribute can be used in a request". At = least, it's been that way in the 2014 releases. I did not check the = older releases. Sorry that I provided a wrong information about the implementation, = before. I can fix that code but still there are people out there who will be = using the "wrong" versions. So, if we do have to be absolutely backward compatible then we have to = use a different option... Oleg =20 =20 On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti < = juberti@google.com> wrote: I reviewed the code for restund, reTurn, and rfc5766-turn-server and = they all appear to handle RAF (and multiple RAF) OK. =20 The problem, as I see it, is that there may be other TURN servers, = perhaps non-open-source ones, that work fine today with Chrome, but will = start returning errors when we include RAF or multiple RAF, and so = making this change may break some small number of apps (who will then = blame Chrome). We just don't know what is out there. =20 =20 =20 On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault < = sperreault@jive.com> wrote: =20 On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang < = wangaijun@tsinghua.org.cn> wrote: After your detail analysis and the sentence =E2=80=9CFor either b/c, we = would need to say that including both RAF and OAF/AAF for the same = address family is prohibited.=E2=80=9D, I think it may be better to keep = only one attribute to fulfill the SSODA requirement? =20 There is no requirement that SSODA functionality be realized with only = one attribute, nor that the protocol be elegant, nor that it exhibits = symmetry that is pleasing to the eye. =20 There *is* a requirement that it be backwards-compatible though. Whether = that means compatible with the spec or compatible with actual = implementations is a matter of debate. =20 Justin, if we can't find a single implementation that would barf, why = would Chrome have to implement a complex fallback mechanism? =20 Simon =20 =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 =20 ------=_NextPart_000_00CA_01D0340A.E945AFC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Justin:

 

According to the guideline defined in https://tools.ietf.org/html/rfc6156#section-4.2, = how do you deal with the situation that one IPv6-only client send the = Allocation Request, but does not include RAF attribute? Will you still = allocate it one IPv4 Relay Address in default?

 

I think IPv4-only client will always need one IPv4 relay address and = IPv6-only client will always need one IPv6 relay address. If they need = additional relay address that in belong to other address family, they = just need include one RAF or AAF attribute in the Allocate Request, this = can accomplish the SSODA requirement that you = mentioned.

 

TURN server that receives the Allocation Request which includes one = RAF or AAF attribute should do the following = task:

1. Check the validity of the message.=C2=A0 The required RAF or AAF = attribute should be different from the address family of source address = of the Allocate Request message.

2. If valid, Allocate two relay address for this client = simultaneously. One for default address type, and the other is the = required address type.

3. All other guidelines of RFC6156 keeps = unchanged.

 

Is this more simple?

 

Best Regards.

Aijun Wang.

 

From:= Justin = Uberti [mailto:juberti@google.com]
Sent: Saturday, January = 17, 2015 3:37 AM
To: Oleg Moskalenko
Cc: Aijun Wang; = Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); = tram@ietf.org
Subject: Re: [tram] SSODA in = TURN-bis

 

yeah. I think we should just get this into turn-bis and be = done with it.

 

Nobody seemed to have much of an = opinion on ADDRESS-ERROR-CODE, so I suggest we write it up and see if we = still like it.

 

On Fri, Jan 16, 2015 at 10:35 AM, = Oleg Moskalenko <mom040267@gmail.com> = wrote:

Then we are back to, I guess, the option = c).

 

On Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti <juberti@google.com> = wrote:

It's too late to take this approach. Every existing TURN = server out there assumes that no RAF =3D IPv4. We can't change the = past.

 

It's also not clear how you expect = this to provide SSODA functionality, e.g. how do you distinguish between = an IPv4 client asking for v6 only vs = v4+v6.

 

On Thu, Jan 15, 2015 at 10:23 PM, = Oleg Moskalenko <mom040267@gmail.com> = wrote:

I think that that = proposal makes sense. But I am not sure that it is backward-compatible = enough. We have to go through all cases of SSODA/non-SSODA entities = communicating, for different protocol request = options.

Aijun, would you like = to go through all those cases to double-check that it works as supposed = ?

Thanks
Oleg

<= div>

 

On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi,Tiru,Pal and Justin:

 

I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D = attribute to fulfill the function of SSODA by clarifying the behavior of = TURN server based on whether this attribute is present or = not:

 

1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the = allocated relay address family will be same as the source = address=E2=80=99s family  of Allocate Request message.  https://tools.ietf.org/html/rfc6156#section-4.2 = has the following description:

 

=E2=80=9CIf the =
REQUESTED-ADDRESS-FAMILY attribute is absent, the server =
MUST

   allocate an = IPv4-relayed transport address for the TURN client.  If

   allocation of IPv4 = addresses is disabled by local policy, the server

   returns a 440 (Address = Family not Supported) Allocate error response.=E2=80=9D

 

This paragraph should be modified as below:

=E2=80=9CIf the =
REQUESTED-ADDRESS-FAMILY attribute is absent, the server =
MUST

   allocate an relayed = transport address from the same family as the source address of = Allocate Request message for the TURN client.  If = this

   = allocation is = disabled by local policy, the server

   returns a 440 (Address = Family not Supported) Allocate error response.=E2=80=9D

 

2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the = following procedure of the client and server should only need to conform = to https://tools.ietf.org/html/rfc6156, no new = attribute and procedure need be introduced.

 

3. Here, the RAF attribute act just as the =E2=80=9CAdditional = Attribute Family=E2=80=9D attribute that I proposed previously.  = Will such solution be less confusable and be less prone to problem to = the TURN developer?

RFC6156 also describes the following sentence:
=E2=80=9CThe =
REQUESTED-ADDRESS-FAMILY
   attribute allows a client to =
explicitly request the address type the
   TURN server will allocate (e.g., =
an IPv4-only node may request the
   TURN server to allocate an IPv6 =
address).=E2=80=9D

If we can change the name of the attribute, then change the attribute = name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional Attribute Family=E2=80=9D may be more better. If this is impossible, we just need = only update the behavior of TURN server that described in RFC6156, =  as I suggested above.

 

Best Regards.

Aijun Wang

 

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy)
Sent: Thursday, January 15, = 2015 10:24 PM
To: Pal Martinsen (palmarti); Justin = Uberti


Cc: tram@ietf.org
Subject: Re: [tram] SSODA = in TURN-bis

 

From:= Pal = Martinsen (palmarti)
Sent: Thursday, January 15, 2015 4:49 = PM
To: Justin Uberti; Tirumaleswar Reddy = (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] SSODA = in TURN-bis

 

 

On 14 Jan 2015, at 23:44, Justin Uberti <juberti@google.com> = wrote:

 

 

 

On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) = <palmarti@cisco.com> = wrote:

Hi,

 

I do not see a problem with a TURN server returning a 400 = error code if it gets confused by two = RAFs.

This is almost covered in section 2.4 of the SSODA draft. = Client fallback to non-SSODA mode when encountering an error seems = trivial. 

(Unless the TURN server ends up using to much CPU, = overheats, and causes a fire in the = datacenter)

 

But I might like c) better anyway. Adding a new attribute = seems cleaner when adding new = functionality.

 

Saving a roundtrip (i.e. by not having to retry) when doing = SSODA is also a good = thing.

 

Good point. Since this probably would take some time to = deploy on the server side the extra chatter could become a bit = annoying. 

 

Tiru, do you have enough information to add this to the = TURNbis draft?

 

[TR] Yes, If there are no further objections will update the draft = next week.

 

Cheers,

-Tiru

 

Or do you think more discussion is = needed?

 

.-.

P=C3=A5l-Erik

 

 

.-.

P=C3=A5l-Erik

 

On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) = <tireddy@cisco.com> = wrote:

 

ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s = a temporary or long-term error.

 

-Tiru

 

From:=  Justin= Uberti [mailto:juberti@google.com] 
= Sent: Saturday, January 10, 2015 2:19 = AM
To: Oleg Moskalenko
Cc: Simon = Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); tram@ietf.org
Subject: R= e: [tram] SSODA in TURN-bis

 

OK, so we have clear evidence that some deployed servers = will fail (deterministically, fortunately) on the current SSODA = proposal.

 

So we're back to which backwards-compatible option we want = to pursue. I suggest c), which is the optional-comprehension = ADDITIONAL-ADDRESS-FAMILY.

 

Separately, we need to decide whether we want to pursue = issue #2 that I identified previously, i.e., allowing specific error = codes to be returned for each address = family.

 

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <mom040267@gmail.com> = wrote:

I double-checked that with a real test. I ran the coTurn = test client (that implements experimental SSODA draft with two RAF = attributes) against rfc5766-turn-server and the server yielded error 400 = with the message "Only one address family attribute can be used in = a request"

:(

As I said, I can eliminate that problem in the subsequent = rfc5766-turn-server maintenance releases, but = still...

I am sorry that I did not discover that previously and that = I advocated an incompatible implementation = option.

So, if the WG insists on a backward-compatible protocol in = all senses, then we have to choose another = option.

Thanks
Oleg

 

 

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <mom040267@gmail.com> = wrote:

I checked the code of rfc5766-turn-server again, and I = found that it will NOT handle the multiple-RAF case. It will return 400 = error with the message "Only one address family attribute can be = used in a request". At least, it's been that way in the 2014 = releases. I did not check the older = releases.

Sorry that I provided a wrong information about the = implementation, before.

I can fix that code but still there are people out there = who will be using the "wrong" = versions.

So, if we do have to be absolutely backward compatible then = we have to use a different = option...

Oleg
 

 

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <juberti@google.com> = wrote:

I reviewed the code for restund, reTurn, and = rfc5766-turn-server and they all appear to handle RAF (and multiple RAF) = OK.

 

The problem, as I see it, is that there may be other TURN = servers, perhaps non-open-source ones, that work fine today with Chrome, = but will start returning errors when we include RAF or multiple RAF, and = so making this change may break some small number of apps (who will then = blame Chrome). We just don't know what is out = there.

 

 

 

On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <sperreault@jive.com> = wrote:

 

On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

After your detail analysis and the sentence =E2=80=9CFor = either b/c, we would need to say that including both RAF and OAF/AAF for = the same address family is prohibited.=E2=80=9D, I think it may be = better to keep only one attribute to fulfill the SSODA requirement? =  


There is no requirement that SSODA functionality be = realized with only one attribute, nor that the protocol be elegant, nor = that it exhibits symmetry that is pleasing to the = eye.

 

There *is* a requirement that it be backwards-compatible = though. Whether that means compatible with the spec or compatible with = actual implementations is a matter of = debate.

 

Justin, if we can't find a single implementation that would = barf, why would Chrome have to implement a complex fallback = mechanism?

 

Simon

 

 

_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram<= /a>

 

__________= _____________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 


_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 


_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

 

 

------=_NextPart_000_00CA_01D0340A.E945AFC0-- From nobody Mon Jan 19 01:23:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41C1AD218 for ; Mon, 19 Jan 2015 01:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no 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 yQ2wFodmGTDs for ; Mon, 19 Jan 2015 01:23:08 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09651AD36F for ; Mon, 19 Jan 2015 01:23:00 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so481030wgh.6 for ; Mon, 19 Jan 2015 01:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GA7szExk9RP6WECZ5HW+T4luDFI1WSH5xKMzXsTG+q4=; b=iyqEjyw7OxSn4xi6OkTANd0YKAcOQt4rWnKlIns0roW1QK0yLSq2RfXLp1/RPxIyeg wN80GYuZUOXwOEVQ0ZAIe6YASg8UOR7I7lPoqpk/ytYYcPFLUR2PhQPciKRmAOXEr/Ga 8kOjzacV7aQH/Rpk3cIYutDVFQIUUyebL9WxqbJPFEAXLx9NuPuKlaAV7nGTRZMukuk/ 8AvpWt4T7Coj8o6nfKHs3kf/FVmxuyWe15mTXibiq4d5gnGpRu4iD3QU1ueQHo9i2rxJ hU9kgf7Pocu46Jonk4likdNpRS8GG2JEKOFpuZ9GFeXUYlc/hxXZzq7i1EUKV4zfDIWM ayoQ== MIME-Version: 1.0 X-Received: by 10.194.2.240 with SMTP id 16mr3747539wjx.108.1421659379628; Mon, 19 Jan 2015 01:22:59 -0800 (PST) Received: by 10.194.87.98 with HTTP; Mon, 19 Jan 2015 01:22:59 -0800 (PST) In-Reply-To: <00c901d033c7$db226fc0$91674f40$@org.cn> References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> <00c901d033c7$db226fc0$91674f40$@org.cn> Date: Mon, 19 Jan 2015 01:22:59 -0800 Message-ID: From: Oleg Moskalenko To: Aijun Wang Content-Type: multipart/alternative; boundary=047d7b343d845081aa050cfdde86 Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 09:23:12 -0000 --047d7b343d845081aa050cfdde86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 19, 2015 at 1:11 AM, Aijun Wang wrote: > Hi, Justin: > > > > According to the guideline defined in > https://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with the > situation that one IPv6-only client send the Allocation Request, but does > not include RAF attribute? Will you still allocate it one IPv4 Relay > Address in default? > The section text is saying: If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST allocate an IPv4-relayed transport address for the TURN client. The existing RFC6156-compliant servers behave that way. > > I think IPv4-only client will always need one IPv4 relay address and > IPv6-only client will always need one IPv6 relay address. If they need > additional relay address that in belong to other address family, they jus= t > need include one RAF or AAF attribute in the Allocate Request, this can > accomplish the SSODA requirement that you mentioned. > > > > TURN server that receives the Allocation Request which includes one RAF o= r > AAF attribute should do the following task: > > 1. Check the validity of the message. The required RAF or AAF attribute > should be different from the address family of source address of the > Allocate Request message. > According to RFC 6156, if an IPv6 client needs an IPv6 relay, then it includes IPv6 RAF in the request. Some clients will continue behaving that way. > 2. If valid, Allocate two relay address for this client simultaneously. > One for default address type, and the other is the required address type. > > 3. All other guidelines of RFC6156 keeps unchanged. > > > > Is this more simple? > As I said before, I like your proposal, but it is incompatible with the old clients and with the old servers, as far as I can see. We have a legacy of RFC 6156 that makes SSODA rather complicated. Oleg > > > Best Regards. > > Aijun Wang. > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Saturday, January 17, 2015 3:37 AM > *To:* Oleg Moskalenko > *Cc:* Aijun Wang; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); > tram@ietf.org > > *Subject:* Re: [tram] SSODA in TURN-bis > > > > yeah. I think we should just get this into turn-bis and be done with it. > > > > Nobody seemed to have much of an opinion on ADDRESS-ERROR-CODE, so I > suggest we write it up and see if we still like it. > > > > On Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko > wrote: > > Then we are back to, I guess, the option c). > > > > On Fri, Jan 16, 2015 at 9:10 AM, Justin Uberti wrote= : > > It's too late to take this approach. Every existing TURN server out there > assumes that no RAF =3D IPv4. We can't change the past. > > > > It's also not clear how you expect this to provide SSODA functionality, > e.g. how do you distinguish between an IPv4 client asking for v6 only vs > v4+v6. > > > > On Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko > wrote: > > I think that that proposal makes sense. But I am not sure that it is > backward-compatible enough. We have to go through all cases of > SSODA/non-SSODA entities communicating, for different protocol request > options. > > Aijun, would you like to go through all those cases to double-check that > it works as supposed ? > > Thanks > Oleg > > > > On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang > wrote: > > Hi,Tiru,Pal and Justin: > > > > I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D attribute= to fulfill the > function of SSODA by clarifying the behavior of TURN server based on > whether this attribute is present or not: > > > > 1. If the =E2=80=9CRAF=E2=80=9D attribute is not present, then the alloca= ted relay address > family will be same as the source address=E2=80=99s family of Allocate R= equest > message. https://tools.ietf.org/html/rfc6156#section-4.2 has the > following description: > > > > =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST > > allocate an IPv4-relayed transport address for the TURN client. If > > allocation of IPv4 addresses is disabled by local policy, the server > > returns a 440 (Address Family not Supported) Allocate error response.= =E2=80=9D > > > > This paragraph should be modified as below: > > =E2=80=9CIf the REQUESTED-ADDRESS-FAMILY attribute is absent, the server = MUST > > allocate an relayed transport address *from the same family as the > source address of Allocate Request message* for the TURN client. If > *this* > > * allocation* is disabled by local policy, the server > > returns a 440 (Address Family not Supported) Allocate error response.= =E2=80=9D > > > > 2. If the =E2=80=9CRAF=E2=80=9D attribute is present, then the following = procedure of the > client and server should only need to conform to > https://tools.ietf.org/html/rfc6156, no new attribute and procedure need > be introduced. > > > > 3. Here, the RAF attribute act just as the =E2=80=9CAdditional Attribute = Family=E2=80=9D > attribute that I proposed previously. Will such solution be less > confusable and be less prone to problem to the TURN developer? > > RFC6156 also describes the following sentence: > > =E2=80=9CThe REQUESTED-ADDRESS-FAMILY > > attribute allows a client to *explicitly* request the address type the > > TURN server will allocate (e.g., an IPv4-only node may request the > > TURN server to allocate an IPv6 address).=E2=80=9D > > If we can change the name of the attribute, then change the attribute nam= e > =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80=9CAdditional Attribu= te Family=E2=80=9D may be more > better. If this is impossible, we just need only update the behavior of > TURN server that described in RFC6156, as I suggested above. > > > > Best Regards. > > Aijun Wang > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Tirumaleswar > Reddy (tireddy) > *Sent:* Thursday, January 15, 2015 10:24 PM > *To:* Pal Martinsen (palmarti); Justin Uberti > > > *Cc:* tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > *From:* Pal Martinsen (palmarti) > *Sent:* Thursday, January 15, 2015 4:49 PM > *To:* Justin Uberti; Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > > > On 14 Jan 2015, at 23:44, Justin Uberti wrote: > > > > > > > > On Wed, Jan 14, 2015 at 2:50 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com> wrote: > > Hi, > > > > I do not see a problem with a TURN server returning a 400 error code if i= t > gets confused by two RAFs. > > This is almost covered in section 2.4 of the SSODA draft. Client fallback > to non-SSODA mode when encountering an error seems trivial. > > (Unless the TURN server ends up using to much CPU, overheats, and causes = a > fire in the datacenter) > > > > But I might like c) better anyway. Adding a new attribute seems cleaner > when adding new functionality. > > > > Saving a roundtrip (i.e. by not having to retry) when doing SSODA is also > a good thing. > > > > Good point. Since this probably would take some time to deploy on the > server side the extra chatter could become a bit annoying. > > > > Tiru, do you have enough information to add this to the TURNbis draft? > > > > [TR] Yes, If there are no further objections will update the draft next > week. > > > > Cheers, > > -Tiru > > > > Or do you think more discussion is needed? > > > > .-. > > P=C3=A5l-Erik > > > > > > .-. > > P=C3=A5l-Erik > > > > On 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) > wrote: > > > > ADDRESS-ERROR-CODE seems useful, client can determine if it=E2=80=99s a t= emporary > or long-term error. > > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* Saturday, January 10, 2015 2:19 AM > *To:* Oleg Moskalenko > *Cc:* Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy); > tram@ietf.org > *Subject:* Re: [tram] SSODA in TURN-bis > > > > OK, so we have clear evidence that some deployed servers will fail > (deterministically, fortunately) on the current SSODA proposal. > > > > So we're back to which backwards-compatible option we want to pursue. I > suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY= . > > > > Separately, we need to decide whether we want to pursue issue #2 that I > identified previously, i.e., allowing specific error codes to be returned > for each address family. > > > > On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko > wrote: > > I double-checked that with a real test. I ran the coTurn test client (tha= t > implements experimental SSODA draft with two RAF attributes) against > rfc5766-turn-server and the server yielded error 400 with the message "On= ly > one address family attribute can be used in a request" > > :( > > As I said, I can eliminate that problem in the subsequent > rfc5766-turn-server maintenance releases, but still... > > I am sorry that I did not discover that previously and that I advocated a= n > incompatible implementation option. > > So, if the WG insists on a backward-compatible protocol in all senses, > then we have to choose another option. > > Thanks > Oleg > > > > > > On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko > wrote: > > I checked the code of rfc5766-turn-server again, and I found that it will > NOT handle the multiple-RAF case. It will return 400 error with the messa= ge > "Only one address family attribute can be used in a request". At least, > it's been that way in the 2014 releases. I did not check the older releas= es. > > Sorry that I provided a wrong information about the implementation, befor= e. > > I can fix that code but still there are people out there who will be usin= g > the "wrong" versions. > > So, if we do have to be absolutely backward compatible then we have to us= e > a different option... > > Oleg > > > > > On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti wrote: > > I reviewed the code for restund, reTurn, and rfc5766-turn-server and they > all appear to handle RAF (and multiple RAF) OK. > > > > The problem, as I see it, is that there may be other TURN servers, perhap= s > non-open-source ones, that work fine today with Chrome, but will start > returning errors when we include RAF or multiple RAF, and so making this > change may break some small number of apps (who will then blame Chrome). = We > just don't know what is out there. > > > > > > > > On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault > wrote: > > > > On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang > wrote: > > After your detail analysis and the sentence =E2=80=9CFor either b/c, we w= ould need > to say that including both RAF and OAF/AAF for the same address family is > prohibited.=E2=80=9D, I think it may be better to keep only one attribute= to > fulfill the SSODA requirement? > > > There is no requirement that SSODA functionality be realized with only on= e > attribute, nor that the protocol be elegant, nor that it exhibits symmetr= y > that is pleasing to the eye. > > > > There *is* a requirement that it be backwards-compatible though. Whether > that means compatible with the spec or compatible with actual > implementations is a matter of debate. > > > > Justin, if we can't find a single implementation that would barf, why > would Chrome have to implement a complex fallback mechanism? > > > > Simon > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > --047d7b343d845081aa050cfdde86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 19, 2015 at 1:11 AM, Aijun Wang <wangaijun@tsinghu= a.org.cn> wrote:

Hi, Justin:=

=C2=A0

According to the guidelin= e defined in htt= ps://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with the = situation that one IPv6-only client send the Allocation Request, but does n= ot include RAF attribute? Will you still allocate it one IPv4 Relay Address= in default?


The sec= tion text is saying:
If the REQUESTED-ADDRESS-FAMILY att=
ribute is absent, the server MUST
allocate an IPv4-relayed transport add=
ress for the TURN client.
=C2=A0The existing RFC6156-compli= ant servers behave that way.

=C2=A0

I think IPv4-only client will = always need one IPv4 relay address and IPv6-only client will always need on= e IPv6 relay address. If they need additional relay address that in belong = to other address family, they just need include one RAF or AAF attribute in= the Allocate Request, this can accomplish the SSODA requirement that you m= entioned.

=C2=A0

TURN server that= receives the Allocation Request which includes one RAF or AAF attribute sh= ould do the following task:

= 1. Check the validity of t= he message.=C2=A0 The required RAF or AAF attribute should be different fro= m the address family of source address of the Allocate Request message.


According to RFC 6156, = if an IPv6 client needs an IPv6 relay, then it includes IPv6 RAF in the req= uest. Some clients will continue behaving that way.
=C2=A0

2. If valid, Allocate = two relay address for this client simultaneously. One for default address t= ype, and the other is the required address type.

3. Al= l other guidelines of RFC6156 keeps unchanged.

= =C2=A0

Is this more simple?


As I said before, I like your proposal, but it is inc= ompatible with the old clients and with the old servers, as far as I can se= e. We have a legacy of RFC 6156 that makes SSODA rather complicated.
Oleg

=C2=A0

=

=C2=A0

Best Regards.

Aijun Wang.

=C2=A0

=

From: Justin Uberti [mailto:juberti@google.com]
Sent: Saturday, January 17, 2015 = 3:37 AM
To: Oleg Moskalenko
Cc: Aijun Wang; Tirumaleswa= r Reddy (tireddy); Pal Martinsen (palmarti); tram@ietf.org

Subject: Re: [tram] SSODA in TURN-bis

<= /p>

=C2=A0

yeah. I think we should just get this into turn-bis and be done= with it.

=C2=A0

Nobody seemed to have much of an opinion on ADDRESS-ERRO= R-CODE, so I suggest we write it up and see if we still like it.<= /u>

= =C2=A0

On Fri, Jan 16, 2015 at 10:35 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:=

T= hen we are back to, I guess, the option c).

<= div>

=C2=A0<= /u>

On Fri, Jan = 16, 2015 at 9:10 AM, Justin Uberti <juberti@google.com> wrote:<= /p>

It's too late to ta= ke this approach. Every existing TURN server out there assumes that no RAF = =3D IPv4. We can't change the past.

=C2=A0

=

It's also not clear ho= w you expect this to provide SSODA functionality, e.g. how do you distingui= sh between an IPv4 client asking for v6 only vs v4+v6.=

=C2=A0

O= n Thu, Jan 15, 2015 at 10:23 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I think that that proposal makes sense. But I am= not sure that it is backward-compatible enough. We have to go through all = cases of SSODA/non-SSODA entities communicating, for different protocol req= uest options.

Aijun, would you like to go throu= gh all those cases to double-check that it works as supposed ?

Thank= s
Oleg

=C2=A0

= On Thu, Jan 15, 2015 at 10:01 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrot= e:

Hi,Tiru,Pal and Justin:

=C2=A0<= u>

I suggest we use the =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80= =9D attribute to fulfill the function of SSODA by clarifying the behavior o= f TURN server based on whether this attribute is present or not:

=C2=A0

1. If the =E2=80=9CRAF=E2=80=9D attribute is not presen= t, then the allocated relay address family will be same as the source addre= ss=E2=80=99s family =C2=A0of Allocate Request message. =C2=A0https://too= ls.ietf.org/html/rfc6156#section-4.2 has the following description:

=C2=A0

=E2=80=9CIf th=
e REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST

=C2=A0=C2=A0 allocate an IPv4-relayed tra= nsport address for the TURN client.=C2=A0 If=

=C2=A0=C2=A0 allocation of IPv4 addresses is disabled by local= policy, the server

=C2=A0=C2=A0= returns a 440 (Address Family not Supported) Allocate error response.=E2=80=9D

=C2=A0

This paragraph should be modified as below:

=E2=80=9C=
If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST=

=C2=A0=C2=A0 allocate an relayed tra= nsport address from the same family as the source address of Allocate Re= quest message for the TURN client.=C2=A0 If this

=C2=A0=C2=A0 allocation is disabled by local policy, the server<= /span>

= =C2=A0=C2=A0 returns a 440 (Addr= ess Family not Supported) Allocate error response.=E2=80=9D=

=C2=A0

<= p class=3D"MsoNormal">2. I= f the =E2=80=9CRAF=E2=80=9D attribute is present, then the following proced= ure of the client and server should only need to conform to https://tools.ietf.org/h= tml/rfc6156, no new attribute and procedure need be introduced. =

=C2=A0

3. Here, the RAF attribute act just as the =E2=80= =9CAdditional Attribute Family=E2=80=9D attribute that I proposed previousl= y.=C2=A0 Will such solution be less confusable and be less prone to problem= to the TURN developer?

RFC6156 also describ=
es the following sentence:=

=E2=80=9CThe REQUESTED-ADDRESS-FAMILY
=C2=A0=C2=A0 attribute allows a client to expli=
citly request the address type the
=C2=A0=C2=
=A0 TURN server will allocate (e.g., an IPv4-only node may request the
=C2=A0=C2=A0 TURN server to allocate an IPv6 address=
).=E2=80=9D

If we can change the name of the attribute, then cha= nge the attribute name =E2=80=9CREQUESTED-ADDRESS-FAMILY=E2=80=9D to =E2=80= =9CAdditional Attri= bute Family=E2=80=9D m= ay be more better. If this is impossible, we just need only update the beha= vior of TURN server that described in RFC6156, =C2=A0as I suggested above.<= /span>

= =C2=A0

Best Regards.=

Aijun Wang

=C2=A0

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy)
Sent: Thursday, January 15, 2015= 10:24 PM
To: Pal Martinsen (palmarti); Justin Uberti

<= span lang=3D"EN-US">
Cc: tram@ietf.org
Subject: Re: [tram] SSODA in TURN-b= is

=C2=A0

From: Pal Martinsen (palmarti)
Sent: Thursday, January 15, 2015 4:= 49 PM
To: Justin Uberti; Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
= Subject: Re: [tram] SSODA in TURN-bis=

=C2=A0=

=C2=A0=

On 14 Jan 2015, at = 23:44, Justin Uberti <juberti@google.com> wrote:

=C2=A0

=

=C2=A0

=C2=A0<= /span>

On Wed, Jan 14, = 2015 at 2:50 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:<= /span>

Hi,

=C2=A0=

I = do not see a problem with a TURN server returning a 400 error code if it ge= ts confused by two RAFs.

This is almost covered in section 2.4 of the S= SODA draft. Client fallback to non-SSODA mode when encountering an error se= ems trivial.=C2=A0

(Unless the TURN server ends up using to much CPU, o= verheats, and causes a fire in the datacenter)

=C2=A0

But I might l= ike c) better anyway. Adding a new attribute seems cleaner when adding new = functionality.

=C2=A0

Saving a roundtrip (i.e. by not having = to retry) when doing SSODA is also a good thing.

=C2=A0

= Good point. Since this probably would take some time t= o deploy on the server side the extra chatter could become a bit annoying.= =C2=A0

=C2=A0

Tiru, do you have enough information to add this to t= he TURNbis draft?

=C2=A0=

[TR] Yes, If there are no further objections will update t= he draft next week.

=C2=A0

<= span style=3D"font-size:11pt;font-family:"Calibri","sans-ser= if";color:rgb(31,73,125)" lang=3D"EN-US">Cheers,

-Tiru

=C2=A0

Or do you think more discussion is needed?<= u>

=C2=A0

.-.

P=C3=A5l-Erik

=C2= =A0

=C2=A0

.-.

=

P=C3=A5l-Erik=

=C2=A0

On= 12 Jan 2015, at 06:08, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

=C2=A0=

ADDRESS-ERROR-CODE seems useful, client= can determine if it=E2=80=99s a temporary or long-term error.

<= span style=3D"font-size:11pt;font-family:"Calibri","sans-ser= if";color:rgb(31,73,125)" lang=3D"EN-US">=C2=A0

-Tiru

=C2=A0

From:=C2=A0Justin Ubert= i [mailto:juberti@google.com]=C2=A0
Sent:=C2= =A0Saturday, January 10, 2015 2:19 AM
To:=C2=A0Oleg MoskalenkoCc:=C2=A0Simon Perreault; Aijun Wang; Tirumaleswar Reddy (tireddy);= =C2=A0tram@ietf.org
Subject:=C2=A0Re: [tram] SSOD= A in TURN-bis

=C2=A0<= /u>

OK, so= we have clear evidence that some deployed servers will fail (deterministic= ally, fortunately) on the current SSODA proposal.

<= /div>

=C2=A0=

So we're back to which backwards-compatible option we want to pur= sue. I suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-F= AMILY.

=C2=A0

=

Separately, we need to decide w= hether we want to pursue issue #2 that I identified previously, i.e., allow= ing specific error codes to be returned for each address family.<= /u>

= =C2=A0

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I double-checked that with a real test. I ran the = coTurn test client (that implements experimental SSODA draft with two RAF a= ttributes) against rfc5766-turn-server and the server yielded error 400 wit= h the message "Only one address family attribute can be used in a requ= est"

:(

As I said, I can eliminate = that problem in the subsequent rfc5766-turn-server maintenance releases, bu= t still...

I am sorry that I did not discover t= hat previously and that I advocated an incompatible implementation option.<= u>

So, if the WG insists on a backward-compatible = protocol in all senses, then we have to choose another option.

Thanks
Oleg

=C2=A0

=C2=A0

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko= <mom040267@gmail.com> wrote:

I checked the code of rfc5766-turn-server again, and= I found that it will NOT handle the multiple-RAF case. It will return 400 = error with the message "Only one address family attribute can be used = in a request". At least, it's been that way in the 2014 releases. = I did not check the older releases.

Sorry = that I provided a wrong information about the implementation, before.

I can fix that code but still there are people = out there who will be using the "wrong" versions.

So, if we do have to be absolutely backward compatible th= en we have to use a different option...

=

Oleg
=C2=A0

<= /div>

=C2= =A0

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <juberti@google.com> wrote:

I reviewed the code for restund, reTurn, and rfc5766-turn-serv= er and they all appear to handle RAF (and multiple RAF) OK.

=C2=A0=

The problem, as I see it, is that there may be other TURN s= ervers, perhaps non-open-source ones, that work fine today with Chrome, but= will start returning errors when we include RAF or multiple RAF, and so ma= king this change may break some small number of apps (who will then blame C= hrome). We just don't know what is out there.

<= /div>

=C2=A0<= /u>

=C2=A0

=C2=A0

_______________________________________________
tram mailing lis= t
tram@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tram

=C2=A0<= u>

=C2=A0

=C2=A0

_________________= ______________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman= /listinfo/tram

=

=C2=A0

=


_______________________________________________tram mailing list
t= ram@ietf.org
https://www.ietf.org/mailman/listinfo/tram<= /u>

=C2=A0

=C2=A0

=


_______________________________________________
tram mail= ing list
tram@ietf.or= g
https://www.ietf.org/mailman/listinfo/tram<= /p>

=C2=A0

=C2=A0

=C2=A0

=

=C2=A0


--047d7b343d845081aa050cfdde86-- From nobody Mon Jan 19 17:33:58 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D481A8F4B for ; Mon, 19 Jan 2015 17:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 4J_AaYNubks1 for ; Mon, 19 Jan 2015 17:33:54 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B581A87D5 for ; Mon, 19 Jan 2015 17:33:53 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so15289754igq.0 for ; Mon, 19 Jan 2015 17:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p6KE6iSTWg0pYnEDZ+sklLc7fBSEqKqBxTUGkhnrN24=; b=Ym9fFBkl5SaGNJPNMzSgEs4cj3f2ZNFBp4D1tzqIv/UVaocGdFtBPyzVbzYI9I8fBy /KZwLwGDb63usbAs8pA7mZic+pCoRjkrzxjH98Ahwvw9g8/0xCi+MMx3SRuBZ9SzgYfc cVzlh/RWUiogpkksDhpJBHS6KRRfe0CkmSk+kLNm9HuXbeNXOaP6VdPh8j9rmB07aFAx SZRxPP9BDDw2KwiU6jsewfOGJS3mgN4hWxXgblcHK7qFo4TVtXR411W1pO/zharpNP8g dgKYQvdFsWGXE2XEkICW1AEBAkQ76lLr3acnFghfVSPKl+k3uanMMgrxDosrIPNz3Dww qZBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p6KE6iSTWg0pYnEDZ+sklLc7fBSEqKqBxTUGkhnrN24=; b=PKPsz4vqMoggEIZFcaaxpkOXab8l/ETbtN+OyRQ+ySx8cpdQtr18UibML5h7orugA+ 5e2wI5/cg57MjfRGBdTJj+G2Y+FrGKcB+JN00W1v0GFKIpp0xz1nca92cElx8h/xQXuo 1a38WNYypr/rDPC3wY1hjGVTML/4l9gn5c1VNmCdWgqfHoUlJli2aDpS9AgfaEJ4FxHr 7mifVqgRSyIi+KXRGCpfL6eLb2yWRogX9MytbMK9kaxKfxrtRbsGha7q1lSTCNgBkDxL o73vGkzjRYQ3p8qEEKXF9Bup95H5zecOS2Mo7vqg+hsCEyG+up+0xYWH/S2wRq5oQXPS Dqfw== X-Gm-Message-State: ALoCoQnI2EbswMAoJIs4MkC2/Zu5NQWfYOpPvVouc7OLkyAsD/MomYE74Ajvl6WbpLUkmai3eVg1 X-Received: by 10.50.83.10 with SMTP id m10mr23016405igy.23.1421717633030; Mon, 19 Jan 2015 17:33:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.235.228 with HTTP; Mon, 19 Jan 2015 17:33:32 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A3552A58B@xmb-rcd-x10.cisco.com> <7F186612-0FE7-4B5E-B132-903B6B38302F@cisco.com> <6A922A2C-E692-4A36-B6AE-F8CC2BCF421F@cisco.com> <913383AAA69FF945B8F946018B75898A3552BF10@xmb-rcd-x10.cisco.com> <006101d03151$edf85010$c9e8f030$@org.cn> <00c901d033c7$db226fc0$91674f40$@org.cn> From: Justin Uberti Date: Mon, 19 Jan 2015 17:33:32 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e0122acca7cfc9d050d0b6e6c Archived-At: Cc: "Pal Martinsen \(palmarti\)" , Aijun Wang , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] SSODA in TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:33:55 -0000 --089e0122acca7cfc9d050d0b6e6c Content-Type: text/plain; charset=UTF-8 On Mon, Jan 19, 2015 at 1:22 AM, Oleg Moskalenko wrote: > > > On Mon, Jan 19, 2015 at 1:11 AM, Aijun Wang > wrote: > >> Hi, Justin: >> >> >> >> According to the guideline defined in >> https://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with >> the situation that one IPv6-only client send the Allocation Request, but >> does not include RAF attribute? Will you still allocate it one IPv4 Relay >> Address in default? >> > > The section text is saying: > > If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST > allocate an IPv4-relayed transport address for the TURN client. > > The existing RFC6156-compliant servers behave that way. > > >> >> I think IPv4-only client will always need one IPv4 relay address and >> IPv6-only client will always need one IPv6 relay address. If they need >> additional relay address that in belong to other address family, they just >> need include one RAF or AAF attribute in the Allocate Request, this can >> accomplish the SSODA requirement that you mentioned. >> >> >> >> TURN server that receives the Allocation Request which includes one RAF >> or AAF attribute should do the following task: >> >> 1. Check the validity of the message. The required RAF or AAF attribute >> should be different from the address family of source address of the >> Allocate Request message. >> > > According to RFC 6156, if an IPv6 client needs an IPv6 relay, then it > includes IPv6 RAF in the request. Some clients will continue behaving that > way. > > >> 2. If valid, Allocate two relay address for this client simultaneously. >> One for default address type, and the other is the required address type. >> >> 3. All other guidelines of RFC6156 keeps unchanged. >> >> >> >> Is this more simple? >> > > As I said before, I like your proposal, but it is incompatible with the > old clients and with the old servers, as far as I can see. We have a legacy > of RFC 6156 that makes SSODA rather complicated. > We can't change the past, we can only work around it. --089e0122acca7cfc9d050d0b6e6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 19, 2015 at 1:22 AM, Oleg Moskalenko <= mom040267@gmail.co= m> wrote:
=

On Mon, Jan 19, 2015 at 1:11 AM, Aijun Wang <wangaijun@tsing= hua.org.cn> wrote:

Hi, Justin:=

=C2=A0

According to the guidelin= e defined in htt= ps://tools.ietf.org/html/rfc6156#section-4.2, how do you deal with the = situation that one IPv6-only client send the Allocation Request, but does n= ot include RAF attribute? Will you still allocate it one IPv4 Relay Address= in default?


= The section text is saying:
If the REQUESTED-ADDRE=
SS-FAMILY attribute is absent, the server MUST
allocate an IPv4-relayed =
transport address for the TURN client.
=C2=A0The exi= sting RFC6156-compliant servers behave that way.

=C2=A0

I think IPv4-only client will always need one IPv4 relay address= and IPv6-only client will always need one IPv6 relay address. If they need= additional relay address that in belong to other address family, they just= need include one RAF or AAF attribute in the Allocate Request, this can ac= complish the SSODA requirement that you mentioned.

=

= =C2=A0

TURN server that receives the Allocation Request w= hich includes one RAF or AAF attribute should do the following task:=

1. Check the validity of the message.=C2=A0 The required RAF= or AAF attribute should be different from the address family of source add= ress of the Allocate Request message.


According to RFC 6156, if an IPv6 client needs an = IPv6 relay, then it includes IPv6 RAF in the request. Some clients will con= tinue behaving that way.
=C2=A0

2. If valid, Allocate two relay = address for this client simultaneously. One for default address type, and t= he other is the required address type.

3. All other gu= idelines of RFC6156 keeps unchanged.

=C2=A0<= /u>

Is this more simple?

As I said before, I like your proposal, but it is incomp= atible with the old clients and with the old servers, as far as I can see. = We have a legacy of RFC 6156 that makes SSODA rather complicated.

We can't change the past= , we can only work around it.=C2=A0
--089e0122acca7cfc9d050d0b6e6c-- From nobody Tue Jan 20 07:44:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983E81B2DE5 for ; Tue, 20 Jan 2015 07:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 iuM8dpG_GjDW for ; Tue, 20 Jan 2015 07:44:32 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0EDC1B2DDF for ; Tue, 20 Jan 2015 07:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1421768672; x=1422978272; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GETm7P6XyX5eHt7Un9OzL1ba40yFX0NNER1ZMmBNYUc=; b=B8dXCVxxxJIxpwoYJzXPk6b7GY9RtH3GtYnXz63TeCR7PcZ36XuDCH9D K7fQ+R03bQPWNCfrIhJ3me96bOn4fZ6dqsMaXHTPNoDbkUFaJTR8rBNto EJPgmNFT14lRZy3hmH3BY8kEbYF6miHDD/Rf9ymR58WMTPZOKKwtM2e3N s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFABV3vlStJV2Q/2dsb2JhbABbgwZSUwUEgwPBCoInhW8CHIEIQwEBAQEBfYQMAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYgjCAW8RZNcAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Ehjic4BoJiLoETBY5Zg0eGZDaCRo4aIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,434,1418083200"; d="scan'208";a="388673766" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jan 2015 15:44:31 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0KFiVNn021148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Jan 2015 15:44:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 09:44:31 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-stun-path-data-01.txt Thread-Index: AQHQNMckPFN375Z+bEqkeaCrMF5GHpzJJNNA Date: Tue, 20 Jan 2015 15:44:31 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552E199@xmb-rcd-x10.cisco.com> References: <20150120153822.2851.30079.idtracker@ietfa.amsl.com> In-Reply-To: <20150120153822.2851.30079.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.64.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:44:34 -0000 VXBkYXRlZCBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFt LXN0dW4tcGF0aC1kYXRhLTAxIHRvIGFkZHJlc3MgY29tbWVudHMgZnJvbSB0aGUgV0cuIEZ1cnRo ZXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkg MjAsIDIwMTUgOTowOCBQTQ0KVG86IFZhcnVuIFNpbmdoOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpOyBEYW4gV2luZyAoZHdpbmcpOyBWYXJ1biBTaW5naDsgVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBEYW4gV2luZyAoZHdpbmcpOyBQ YWwgTWFydGluc2VuIChwYWxtYXJ0aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMS50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMS50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXJlZGR5LXRyYW0t c3R1bi1wYXRoLWRhdGENClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlEaXNjb3Zlcnkgb2YgcGF0aCBj aGFyYWN0ZXJpc3RpY3MgdXNpbmcgU1RVTg0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMS0yMA0KR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOQ0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LXRyYW0tc3R1bi1w YXRoLWRhdGEtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1k YXRhLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMQ0KDQpBYnN0cmFjdDoNCiAgIEEgaG9z dCB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMgbmVlZHMgdG8gY2hvb3NlIHRoZSBiZXN0IGludGVy ZmFjZQ0KICAgZm9yIGNvbW11bmljYXRpb24uICBPZnRlbnRpbWVzLCB0aGlzIGRlY2lzaW9uIGlz IGJhc2VkIG9uIGEgc3RhdGljDQogICBjb25maWd1cmF0aW9uIGFuZCBkb2VzIG5vdCBjb25zaWRl ciB0aGUgcGF0aCBjaGFyYWN0ZXJpc3RpY3MsIHdoaWNoDQogICBtYXkgYWZmZWN0IHRoZSB1c2Vy IGV4cGVyaWVuY2UuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGZv ciBhbiBlbmRwb2ludCB0byBkaXNjb3ZlciB0aGUNCiAgIHBhdGggY2hhcmFjdGVyaXN0aWNzIHVz aW5nIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KICAgbWVzc2Fn ZXMuICBUaGUgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gY2FuIHRoZW4gYmUgdXNlZCB0byBpbmZs dWVuY2UNCiAgIHRoZSBlbmRwb2ludCdzIEludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxp c2htZW50IChJQ0UpIGNhbmRpZGF0ZQ0KICAgcGFpciBzZWxlY3Rpb24gYWxnb3JpdGhtLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Jan 20 07:51:54 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7141B2E0E; Tue, 20 Jan 2015 07:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 x5crJZLvI6ZO; Tue, 20 Jan 2015 07:51:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA491B2E14; Tue, 20 Jan 2015 07:51:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120155150.8454.14590.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 07:51:50 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:51:52 -0000 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 Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-06.txt Pages : 20 Date : 2015-01-20 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensure that access to a STUN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-06 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/ From nobody Tue Jan 20 07:55:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCBC1B2E08 for ; Tue, 20 Jan 2015 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PO9XoZJ4e0Id for ; Tue, 20 Jan 2015 07:55:33 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DC11B2A9A for ; Tue, 20 Jan 2015 07:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2198; q=dns/txt; s=iport; t=1421769333; x=1422978933; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m6EgOogaa0WPp/s0axbwbsud9ea6oRFb/g1g5Dfh6mk=; b=Ppw+d4Kig4qyV+V2vJ3jG0MWsY7+PAgg+KeOCP983Aug2GLTTPbKQG1i KT1cqvmJiS3TxgUZwk/ih+/mGfpnnk/RXTv4L8QfaG6H9CrjcABD8JFmq /r9CETRE00LECVfXpRxiMmhuYwbfYosDT5liRwu9NtwB3/MXaEsiQwLBv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAEt6vlStJA2B/2dsb2JhbABbgwZSUwUExA2CGwyFbwKBJEMBAQEBAX2EDAEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEEwgBiCMIBdAtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49IOAaDEIETBY5Zg0eGZDaCRo4aIoNub4EFJBx+AQEB X-IronPort-AV: E=Sophos;i="5.09,434,1418083200"; d="scan'208";a="115165898" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP; 20 Jan 2015 15:55:19 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0KFtIBQ028868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Jan 2015 15:55:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 09:55:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt Thread-Index: AQHQNMkGKM6QPfWZLUOifqaG9+zJ35zJKOjw Date: Tue, 20 Jan 2015 15:55:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552E1DB@xmb-rcd-x10.cisco.com> References: <20150120155150.8454.14590.idtracker@ietfa.amsl.com> In-Reply-To: <20150120155150.8454.14590.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.64.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:55:35 -0000 Revision http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-= 06 addresses comments from Spencer. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, January 20, 2015 9:22 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : Session Traversal Utilities for NAT (STUN) Exte= nsion for Third > Party Authorization > Authors : Tirumaleswar Reddy > Prashanth Patil > Ram Mohan Ravindranath > Justin Uberti > Filename : draft-ietf-tram-turn-third-party-authz-06.txt > Pages : 20 > Date : 2015-01-20 >=20 > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for Session Traversal Utilities for > NAT (STUN) authentication. The usage of ephemeral tokens ensure that > access to a STUN server can be controlled even if the tokens are > compromised. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jan 20 11:33:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064E31B2B1A for ; Tue, 20 Jan 2015 11:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 RAV_jCSMaJEd for ; Tue, 20 Jan 2015 11:33:39 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B519F1ACDB2 for ; Tue, 20 Jan 2015 11:33:38 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so16460404wid.5 for ; Tue, 20 Jan 2015 11:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DspRIznbYo9reTKqnU4XB04V4ZCB3nAb1GPsC7xMKHs=; b=dndKJdLhKPAgiNO5fweuSUu9Hxo6FaW8drzRb8Y2vAPvgDACF/KpAZTFanGz/u6iXP ucNTURXWqfeYvJsostc35wXlK2MZUj+h83gv2nH+btnBk/hJvNWTmMDk3iP2qZH/Y/lm a/K7EhO14H2/fv4RfsygkTYiu2joeVctXk8ysYkY8vCiiup/TdqvzdnJUy2xwrNWP6Dp OcMA4c2XVgcuNwQrXRUFbkGAu4TogI7dR3e+lgx8L4gc/7sseoBL+gIPQ85ZpIXIdF2Z yHe1pxOYDMoE0fHCnF6DE9txjB0QLqGzk8RkeXoSpv0mj00q+dmKPNkGZYHJtIeXuG6Y 1C1w== MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr20755679wjr.48.1421782405520; Tue, 20 Jan 2015 11:33:25 -0800 (PST) Received: by 10.194.87.98 with HTTP; Tue, 20 Jan 2015 11:33:25 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3552E1DB@xmb-rcd-x10.cisco.com> References: <20150120155150.8454.14590.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3552E1DB@xmb-rcd-x10.cisco.com> Date: Tue, 20 Jan 2015 11:33:25 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b86c8983aa18e050d1a8331 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 19:33:41 -0000 --047d7b86c8983aa18e050d1a8331 Content-Type: text/plain; charset=UTF-8 A new change that I noticed in this draft is that it is making impossible simultaneous support of the original 'legacy' long-term credentials and the new third party credentials in the same server. If the server includes the THIRD-PARTY-AUTHORIZATION attribute in the 401 response, then the client is REQUIRED to provide the new authorization scheme. So, we have a few problems here: 1) This is incompatible with the old clients. 2) If we really do want that change, then we have to make the THIRD-PARTY-AUTHORIZATION attribute comprehension-required. Currently, it is comprehension-optional. With the current scheme, there is a logical mistake: you are allowing the client to ignore the TPA attribute (by making it comprehension-optional) but in the same time you are NOT allowing the client to ignore it (because you are requiring that the third-party authorization to be used). It has to be resolved one way or another. I'd recommend to rollback to the previous draft because the older draft did not have contradictions and the old draft allowed the server administrators to decide which combination of the authorization schemes they want to deploy. On Tue, Jan 20, 2015 at 7:55 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Revision > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 > addresses comments from Spencer. > > -Tiru > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Tuesday, January 20, 2015 9:22 PM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.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 Working > > Group of the IETF. > > > > Title : Session Traversal Utilities for NAT (STUN) > Extension for Third > > Party Authorization > > Authors : Tirumaleswar Reddy > > Prashanth Patil > > Ram Mohan Ravindranath > > Justin Uberti > > Filename : draft-ietf-tram-turn-third-party-authz-06.txt > > Pages : 20 > > Date : 2015-01-20 > > > > Abstract: > > This document proposes the use of OAuth to obtain and validate > > ephemeral tokens that can be used for Session Traversal Utilities for > > NAT (STUN) authentication. The usage of ephemeral tokens ensure that > > access to a STUN server can be controlled even if the tokens are > > compromised. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-06 > > > > > > 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 > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b86c8983aa18e050d1a8331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A new change that I noticed in this draft i= s that it is making impossible simultaneous support of the original 'le= gacy' long-term credentials and the new third party credentials in the = same server. If the server includes the THIRD-PARTY-AUTHORIZATION attribute= in the 401 response, then the client is REQUIRED to provide the new author= ization scheme. So, we have a few problems here:

1) This is in= compatible with the old clients.
2) If we really do want that chan= ge, then we have to make the THIRD-PARTY-AUTHORIZATION attribute comprehens= ion-required. Currently, it is comprehension-optional. With the current sch= eme, there is a logical mistake: you are allowing the client to ignore the = TPA attribute (by making it comprehension-optional) but in the same time yo= u are NOT allowing the client to ignore it (because you are requiring that = the third-party authorization to be used). It has to be resolved one way or= another.

I'd recommend to rollback to the previous draft = because the older draft did not have contradictions and the old draft allow= ed the server administrators to decide which combination of the authorizati= on schemes they want to deploy.



On Tue, Jan 20, 2015 at 7:55 AM,= Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
=
Revision http://tool= s.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 addresses com= ments from Spencer.

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Tuesday, January 20, 2015 9:22 PM
> To: i-d-announce@ietf.org=
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.= txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the TURN Revised and Modernized Wor= king
> Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Session Traversal Utilities for NAT (STUN) Extension for Third<= br> > Party Authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Tirumaleswar Reddy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Prashanth Patil
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ram Mohan Ravindranath
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Justin Uberti
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turn-third-party-authz-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 20
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-20
>
> Abstract:
>=C2=A0 =C2=A0 This document proposes the use of OAuth to obtain and val= idate
>=C2=A0 =C2=A0 ephemeral tokens that can be used for Session Traversal U= tilities for
>=C2=A0 =C2=A0 NAT (STUN) authentication.=C2=A0 The usage of ephemeral t= okens ensure that
>=C2=A0 =C2=A0 access to a STUN server can be controlled even if the tok= ens are
>=C2=A0 =C2=A0 compromised.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iet= f-tram-turn-third-party-authz/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-tur= n-third-party-authz-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-tram-turn-third-party-authz-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b86c8983aa18e050d1a8331-- From nobody Tue Jan 20 21:21:03 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA151A0362 for ; Tue, 20 Jan 2015 21:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mjbitkgf88bh for ; Tue, 20 Jan 2015 21:20:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846791A0367 for ; Tue, 20 Jan 2015 21:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23384; q=dns/txt; s=iport; t=1421817656; x=1423027256; h=from:to:cc:subject:date:message-id:mime-version; bh=35Y0jH4OnfY4g4m19n+FAu9tFz2QiqdfjuiSi5FKsOE=; b=KA4OQVhxr2PetR3Wttj6dN8wNlC8VEofYecuWQUC+Cb//u3lyxxzpWKA kN2ELNqQ8FfPPp3kp+1BJtT3qHeVQccpM9i8DVad/wNe1RCIaAspoVAe3 4XAYvBPBVJvmmZ2+Vj5i5InXIl+NffxMMtU+Fa9sMH4J+n4XYA1FrGGjz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoIACE2v1StJV2d/2dsb2JhbABbgkNDUlMFBIMDwQk8gV8BC4VvAhyBBEMBAQEBAX2EDAEBAQQBAQEgCkELDAYBCA4DBAEBCx0DAgQfBgsUCQkBBA4FCAGIDwMRCAW7W49tDYRQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF41PgXkPHgQGBwOCXy6BEwWOWYNHhAyCWDaCRogphXEigX2BcW+BBSQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,439,1418083200"; d="scan'208,217";a="389220393" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 21 Jan 2015 05:20:55 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t0L5Ktmm001359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 05:20:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 23:20:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt Thread-Index: AdA1OgKgzPdSkSbsTxmAyJ5jLuPAXA== Date: Wed, 21 Jan 2015 05:20:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552E6F7@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.37.195] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552E6F7xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 05:21:00 -0000 --_000_913383AAA69FF945B8F946018B75898A3552E6F7xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xlZywNCg0KR29vZCBwb2ludCwgTW9kaWZpZWQgdGV4dCBpbiBzZWN0aW9ucyA0LCA2LjEg dG8gYmUgbW9yZSBjbGVhciB3aGVuIHRoZSBjbGllbnQgc3VwcG9ydHMgYm90aCBtZXRob2RzDQoN Ck5FVyAoU2VjdGlvbiA0KToNCkEgU1RVTiBjbGllbnQgc2hvdWxkIGtub3cgdGhlIGF1dGhlbnRp Y2F0aW9uIGNhcGFiaWxpdHkgb2YgdGhlIFNUVU4gc2VydmVyIGJlZm9yZSBkZWNpZGluZyB0byB1 c2UgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbi4gQSBTVFVOIGNsaWVudCBpbml0aWFsbHkgbWFr ZXMgYSByZXF1ZXN0IHdpdGhvdXQgYW55IGF1dGhvcml6YXRpb24uIElmIHRoZSBTVFVOIHNlcnZl ciBzdXBwb3J0cyB0aGlyZCBwYXJ0eSBhdXRob3JpemF0aW9uLCBpdCB3aWxsIHJldHVybiBhbiBl cnJvciBtZXNzYWdlIGluZGljYXRpbmcgdGhhdCB0aGUgY2xpZW50IGNhbiBhdXRob3JpemUgdG8g dGhlIFNUVU4gc2VydmVyIHVzaW5nIE9BdXRoIGFjY2VzcyB0b2tlbi4gVGhlIFNUVU4gc2VydmVy IGluY2x1ZGVzIGFuIEVSUk9SLUNPREUgYXR0cmlidXRlIHdpdGggYSB2YWx1ZSBvZiA0MDEgKFVu YXV0aG9yaXplZCksIGEgbm9uY2UgdmFsdWUgaW4gYSBOT05DRSBhdHRyaWJ1dGUgYW5kIGEgU09G VFdBUkUgYXR0cmlidXRlIHRoYXQgZ2l2ZXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFNUVU4gc2Vy dmVyJ3Mgc29mdHdhcmUuIFRoZSBTVFVOIHNlcnZlcnMgYWxzbyBpbmNsdWRlcyBhZGRpdGlvbmFs IFNUVU4gYXR0cmlidXRlIFRISVJELVBBUlRZLUFVVEhPUklaQVRJT04gc2lnbmFsaW5nIHRoZSBT VFVOIGNsaWVudCB0aGF0IHRoZSBTVFVOIHNlcnZlciBzdXBwb3J0cyB0aGlyZCBwYXJ0eSBhdXRo b3JpemF0aW9uLg0KDQooU2VjdGlvbiA2LjEpDQpJZiB0aGUgY2xpZW50IGlzIGFibGUgdG8gY29t cHJlaGVuZCBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIGl0IE1VU1QgZW5zdXJlIHRoYXQgdGhp cmQgcGFydHkgYXV0aG9yaXphdGlvbiB0YWtlcyBwcmVjZWRlbmNlIG92ZXIgZmlyc3QgcGFydHkg YXV0aGVudGljYXRpb24gKGV4cGxhaW5lZCBpbiBzZWN0aW9uIDEwIG9mIFJGQyA1Mzg5KS4gSWYg dGhlIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0IG9yIGlzIG5vdCBjYXBhYmxlIG9mIGRvaW5nIHRo aXJkIHBhcnR5IGF1dGhvcml6YXRpb24gdGhlbiBpdCBkZWZhdWx0cyB0byBmaXJzdCBwYXJ0eSBh dXRoZW50aWNhdGlvbi4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KRnJvbTogT2xlZyBNb3NrYWxlbmtv IFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAy MSwgMjAxNSAxOjAzIEFNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IHRy YW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10 cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDYudHh0DQoNCkEgbmV3IGNoYW5nZSB0aGF0IEkg bm90aWNlZCBpbiB0aGlzIGRyYWZ0IGlzIHRoYXQgaXQgaXMgbWFraW5nIGltcG9zc2libGUgc2lt dWx0YW5lb3VzIHN1cHBvcnQgb2YgdGhlIG9yaWdpbmFsICdsZWdhY3knIGxvbmctdGVybSBjcmVk ZW50aWFscyBhbmQgdGhlIG5ldyB0aGlyZCBwYXJ0eSBjcmVkZW50aWFscyBpbiB0aGUgc2FtZSBz ZXJ2ZXIuIElmIHRoZSBzZXJ2ZXIgaW5jbHVkZXMgdGhlIFRISVJELVBBUlRZLUFVVEhPUklaQVRJ T04gYXR0cmlidXRlIGluIHRoZSA0MDEgcmVzcG9uc2UsIHRoZW4gdGhlIGNsaWVudCBpcyBSRVFV SVJFRCB0byBwcm92aWRlIHRoZSBuZXcgYXV0aG9yaXphdGlvbiBzY2hlbWUuIFNvLCB3ZSBoYXZl IGEgZmV3IHByb2JsZW1zIGhlcmU6DQoxKSBUaGlzIGlzIGluY29tcGF0aWJsZSB3aXRoIHRoZSBv bGQgY2xpZW50cy4NCjIpIElmIHdlIHJlYWxseSBkbyB3YW50IHRoYXQgY2hhbmdlLCB0aGVuIHdl IGhhdmUgdG8gbWFrZSB0aGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiBhdHRyaWJ1dGUgY29t cHJlaGVuc2lvbi1yZXF1aXJlZC4gQ3VycmVudGx5LCBpdCBpcyBjb21wcmVoZW5zaW9uLW9wdGlv bmFsLiBXaXRoIHRoZSBjdXJyZW50IHNjaGVtZSwgdGhlcmUgaXMgYSBsb2dpY2FsIG1pc3Rha2U6 IHlvdSBhcmUgYWxsb3dpbmcgdGhlIGNsaWVudCB0byBpZ25vcmUgdGhlIFRQQSBhdHRyaWJ1dGUg KGJ5IG1ha2luZyBpdCBjb21wcmVoZW5zaW9uLW9wdGlvbmFsKSBidXQgaW4gdGhlIHNhbWUgdGlt ZSB5b3UgYXJlIE5PVCBhbGxvd2luZyB0aGUgY2xpZW50IHRvIGlnbm9yZSBpdCAoYmVjYXVzZSB5 b3UgYXJlIHJlcXVpcmluZyB0aGF0IHRoZSB0aGlyZC1wYXJ0eSBhdXRob3JpemF0aW9uIHRvIGJl IHVzZWQpLiBJdCBoYXMgdG8gYmUgcmVzb2x2ZWQgb25lIHdheSBvciBhbm90aGVyLg0KSSdkIHJl Y29tbWVuZCB0byByb2xsYmFjayB0byB0aGUgcHJldmlvdXMgZHJhZnQgYmVjYXVzZSB0aGUgb2xk ZXIgZHJhZnQgZGlkIG5vdCBoYXZlIGNvbnRyYWRpY3Rpb25zIGFuZCB0aGUgb2xkIGRyYWZ0IGFs bG93ZWQgdGhlIHNlcnZlciBhZG1pbmlzdHJhdG9ycyB0byBkZWNpZGUgd2hpY2ggY29tYmluYXRp b24gb2YgdGhlIGF1dGhvcml6YXRpb24gc2NoZW1lcyB0aGV5IHdhbnQgdG8gZGVwbG95Lg0KDQoN Ck9uIFR1ZSwgSmFuIDIwLCAyMDE1IGF0IDc6NTUgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3Rl Og0KUmV2aXNpb24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1 cm4tdGhpcmQtcGFydHktYXV0aHotMDYgYWRkcmVzc2VzIGNvbW1lbnRzIGZyb20gU3BlbmNlci4N Cg0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFtIFtt YWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtDQo+IGRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnRz QGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDIwLCAyMDE1IDk6MjIgUE0NCj4g VG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0K PiBDYzogdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4gU3ViamVjdDogW3Ry YW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTA2 LnR4dA0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBUVVJOIFJldmlzZWQgYW5kIE1vZGVybml6ZWQgV29ya2luZw0KPiBH cm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZXNzaW9u IFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgRXh0ZW5zaW9uIGZvciBUaGlyZA0K PiBQYXJ0eSBBdXRob3JpemF0aW9uDQo+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogVGlydW1h bGVzd2FyIFJlZGR5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUHJhc2hhbnRoIFBhdGls DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUmFtIE1vaGFuIFJhdmluZHJhbmF0aA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIEp1c3RpbiBVYmVydGkNCj4gICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDYudHh0DQo+ ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDIwDQo+ICAgICAgIERhdGUgICAgICAgICAgICA6IDIw MTUtMDEtMjANCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhl IHVzZSBvZiBPQXV0aCB0byBvYnRhaW4gYW5kIHZhbGlkYXRlDQo+ICAgIGVwaGVtZXJhbCB0b2tl bnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvcg0K PiAgICBOQVQgKFNUVU4pIGF1dGhlbnRpY2F0aW9uLiAgVGhlIHVzYWdlIG9mIGVwaGVtZXJhbCB0 b2tlbnMgZW5zdXJlIHRoYXQNCj4gICAgYWNjZXNzIHRvIGEgU1RVTiBzZXJ2ZXIgY2FuIGJlIGNv bnRyb2xsZWQgZXZlbiBpZiB0aGUgdG9rZW5zIGFyZQ0KPiAgICBjb21wcm9taXNlZC4NCj4NCj4N Cj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRo aXJkLXBhcnR5LWF1dGh6Lw0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFt LXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDYNCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wNg0KPg0KPg0KPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4N Cj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0cmFtIG1haWxpbmcg bGlzdA0KPiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYu b3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFtDQoNCg== --_000_913383AAA69FF945B8F946018B75898A3552E6F7xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg T2xlZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkdvb2QgcG9pbnQsIE1vZGlmaWVkIHRleHQgaW4gc2VjdGlvbnMgNCwg Ni4xIHRvIGJlIG1vcmUgY2xlYXIgd2hlbiB0aGUgY2xpZW50IHN1cHBvcnRzIGJvdGggbWV0aG9k cw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5ORVcgKFNlY3Rpb24gNCk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkEgU1RVTiBjbGllbnQgc2hvdWxkIGtub3cgdGhlIGF1dGhlbnRpY2F0aW9uIGNhcGFiaWxp dHkgb2YgdGhlIFNUVU4gc2VydmVyIGJlZm9yZSBkZWNpZGluZyB0byB1c2UgdGhpcmQgcGFydHkg YXV0aG9yaXphdGlvbi4gQSBTVFVOIGNsaWVudCBpbml0aWFsbHkgbWFrZXMgYQ0KIHJlcXVlc3Qg d2l0aG91dCBhbnkgYXV0aG9yaXphdGlvbi4gSWYgdGhlIFNUVU4gc2VydmVyIHN1cHBvcnRzIHRo aXJkIHBhcnR5IGF1dGhvcml6YXRpb24sIGl0IHdpbGwgcmV0dXJuIGFuIGVycm9yIG1lc3NhZ2Ug aW5kaWNhdGluZyB0aGF0IHRoZSBjbGllbnQgY2FuIGF1dGhvcml6ZSB0byB0aGUgU1RVTiBzZXJ2 ZXIgdXNpbmcgT0F1dGggYWNjZXNzIHRva2VuLiBUaGUgU1RVTiBzZXJ2ZXIgaW5jbHVkZXMgYW4g RVJST1ItQ09ERSBhdHRyaWJ1dGUNCiB3aXRoIGEgdmFsdWUgb2YgNDAxIChVbmF1dGhvcml6ZWQp LCBhIG5vbmNlIHZhbHVlIGluIGEgTk9OQ0UgYXR0cmlidXRlIGFuZCBhIFNPRlRXQVJFIGF0dHJp YnV0ZSB0aGF0IGdpdmVzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBTVFVOIHNlcnZlcidzIHNvZnR3 YXJlLiBUaGUgU1RVTiBzZXJ2ZXJzIGFsc28gaW5jbHVkZXMgYWRkaXRpb25hbCBTVFVOIGF0dHJp YnV0ZSBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIHNpZ25hbGluZyB0aGUgU1RVTiBjbGllbnQN CiB0aGF0IHRoZSBTVFVOIHNlcnZlciBzdXBwb3J0cyB0aGlyZCBwYXJ0eSBhdXRob3JpemF0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+KFNlY3Rpb24gNi4xKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J ZiB0aGUgY2xpZW50IGlzIGFibGUgdG8gY29tcHJlaGVuZCBUSElSRC1QQVJUWS1BVVRIT1JJWkFU SU9OIGl0IE1VU1QgZW5zdXJlIHRoYXQgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiB0YWtlcyBw cmVjZWRlbmNlIG92ZXIgZmlyc3QgcGFydHkgYXV0aGVudGljYXRpb24NCiAoZXhwbGFpbmVkIGlu IHNlY3Rpb24gMTAgb2YgUkZDIDUzODkpLiBJZiB0aGUgY2xpZW50IGRvZXMgbm90IHN1cHBvcnQg b3IgaXMgbm90IGNhcGFibGUgb2YgZG9pbmcgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiB0aGVu IGl0IGRlZmF1bHRzIHRvIGZpcnN0IHBhcnR5IGF1dGhlbnRpY2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hl ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20w NDAyNjdAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAy MSwgMjAxNSAxOjAzIEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpPGJyPg0KPGI+Q2M6PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdHJhbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0 aHotMDYudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ QSBuZXcgY2hhbmdlIHRoYXQgSSBub3RpY2VkIGluIHRoaXMgZHJhZnQgaXMgdGhhdCBpdCBpcyBt YWtpbmcgaW1wb3NzaWJsZSBzaW11bHRhbmVvdXMgc3VwcG9ydCBvZiB0aGUgb3JpZ2luYWwgJ2xl Z2FjeScgbG9uZy10ZXJtIGNyZWRlbnRpYWxzIGFuZCB0aGUgbmV3IHRoaXJkIHBhcnR5IGNyZWRl bnRpYWxzIGluIHRoZSBzYW1lIHNlcnZlci4gSWYgdGhlIHNlcnZlcg0KIGluY2x1ZGVzIHRoZSBU SElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJpYnV0ZSBpbiB0aGUgNDAxIHJlc3BvbnNlLCB0 aGVuIHRoZSBjbGllbnQgaXMgUkVRVUlSRUQgdG8gcHJvdmlkZSB0aGUgbmV3IGF1dGhvcml6YXRp b24gc2NoZW1lLiBTbywgd2UgaGF2ZSBhIGZldyBwcm9ibGVtcyBoZXJlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBUaGlzIGlzIGluY29tcGF0aWJsZSB3 aXRoIHRoZSBvbGQgY2xpZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4yKSBJZiB3ZSByZWFsbHkgZG8g d2FudCB0aGF0IGNoYW5nZSwgdGhlbiB3ZSBoYXZlIHRvIG1ha2UgdGhlIFRISVJELVBBUlRZLUFV VEhPUklaQVRJT04gYXR0cmlidXRlIGNvbXByZWhlbnNpb24tcmVxdWlyZWQuIEN1cnJlbnRseSwg aXQgaXMgY29tcHJlaGVuc2lvbi1vcHRpb25hbC4gV2l0aCB0aGUgY3VycmVudCBzY2hlbWUsIHRo ZXJlIGlzIGEgbG9naWNhbA0KIG1pc3Rha2U6IHlvdSBhcmUgYWxsb3dpbmcgdGhlIGNsaWVudCB0 byBpZ25vcmUgdGhlIFRQQSBhdHRyaWJ1dGUgKGJ5IG1ha2luZyBpdCBjb21wcmVoZW5zaW9uLW9w dGlvbmFsKSBidXQgaW4gdGhlIHNhbWUgdGltZSB5b3UgYXJlIE5PVCBhbGxvd2luZyB0aGUgY2xp ZW50IHRvIGlnbm9yZSBpdCAoYmVjYXVzZSB5b3UgYXJlIHJlcXVpcmluZyB0aGF0IHRoZSB0aGly ZC1wYXJ0eSBhdXRob3JpemF0aW9uIHRvIGJlIHVzZWQpLiBJdCBoYXMgdG8gYmUNCiByZXNvbHZl ZCBvbmUgd2F5IG9yIGFub3RoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSdkIHJlY29tbWVuZCB0byBy b2xsYmFjayB0byB0aGUgcHJldmlvdXMgZHJhZnQgYmVjYXVzZSB0aGUgb2xkZXIgZHJhZnQgZGlk IG5vdCBoYXZlIGNvbnRyYWRpY3Rpb25zIGFuZCB0aGUgb2xkIGRyYWZ0IGFsbG93ZWQgdGhlIHNl cnZlciBhZG1pbmlzdHJhdG9ycyB0byBkZWNpZGUgd2hpY2ggY29tYmluYXRpb24gb2YgdGhlIGF1 dGhvcml6YXRpb24gc2NoZW1lcw0KIHRoZXkgd2FudCB0byBkZXBsb3kuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFuIDIwLCAyMDE1IGF0 IDc6NTUgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0 bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpc2lv biA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVy bi10aGlyZC1wYXJ0eS1hdXRoei0wNiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDY8L2E+ IGFkZHJlc3NlcyBjb21tZW50cyBmcm9tIFNwZW5jZXIuPGJyPg0KPGJyPg0KLVRpcnU8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogdHJhbSBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciPnRyYW0tYm91bmNlc0BpZXRmLm9y ZzwvYT5dIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC08YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpk cmFmdHNAaWV0Zi5vcmciPmRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNk YXksIEphbnVhcnkgMjAsIDIwMTUgOToyMiBQTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0 bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IENjOiA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IFN1YmplY3Q6IFt0cmFtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVy bi10aGlyZC1wYXJ0eS1hdXRoei0wNi50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZndDsmbmJzcDsgVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgVFVSTiBSZXZpc2VkIGFuZCBNb2Rlcm5pemVkIFdvcmtpbmc8YnI+DQom Z3Q7IEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1RpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKSBFeHRl bnNpb24gZm9yIFRoaXJkPGJyPg0KJmd0OyBQYXJ0eSBBdXRob3JpemF0aW9uPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQcmFzaGFudGggUGF0aWw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JhbSBNb2hhbiBSYXZpbmRyYW5h dGg8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0p1c3Rp biBVYmVydGk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlsZW5hbWUmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0 eS1hdXRoei0wNi50eHQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFnZXMm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjA8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDogMjAxNS0wMS0yMDxicj4NCiZndDs8YnI+DQomZ3Q7IEFic3RyYWN0Ojxi cj4NCiZndDsmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiBP QXV0aCB0byBvYnRhaW4gYW5kIHZhbGlkYXRlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgZXBoZW1l cmFsIHRva2VucyB0aGF0IGNhbiBiZSB1c2VkIGZvciBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRp ZXMgZm9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgTkFUIChTVFVOKSBhdXRoZW50aWNhdGlvbi4m bmJzcDsgVGhlIHVzYWdlIG9mIGVwaGVtZXJhbCB0b2tlbnMgZW5zdXJlIHRoYXQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyBhY2Nlc3MgdG8gYSBTVFVOIHNlcnZlciBjYW4gYmUgY29udHJvbGxlZCBl dmVuIGlmIHRoZSB0b2tlbnMgYXJlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY29tcHJvbWlzZWQu PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0 aHovIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei88L2E+PGJyPg0KJmd0Ozxicj4N CiZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t dHVybi10aGlyZC1wYXJ0eS1hdXRoei0wNiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDY8 L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDYiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTA2PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZn dDs8YnI+DQomZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHRyYW0gbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1A aWV0Zi5vcmciPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A3552E6F7xmbrcdx10ciscoc_-- From nobody Tue Jan 20 22:15:47 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514131A036E for ; Tue, 20 Jan 2015 22:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 BpltgvGBGJMq for ; Tue, 20 Jan 2015 22:15:43 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C5A1A0354 for ; Tue, 20 Jan 2015 22:15:42 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id fb4so23628976wid.2 for ; Tue, 20 Jan 2015 22:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FJ1XDrEqKKiu8m/TTSaPZXEmzmWTppL9cLvYdetPwm8=; b=lMlMZukGiBIoqVxt97HSPGgI7qKfsYoXOfRk32PNhSJBOPsiswHIaqhPhA22AtriJk annBZPSuwUn7sNAntr5gsSn8NOX/24kJrRJah6laOILtj+AexW9j2vXuYNgeCflPVvZO 3/HErcqXo/WYdZgx3/nJxMXod1RYaHqN6fiPt04JuBodNiVOCPatXYUZSTROkbHFHn5F nY9VuhzesfM665yLO0Cc9yqAjJ+DzsbQc44eGrdfnkANfBX0QLhcQq25cLG5aSQQ5Q8o DTA2F9ro4nHWhVtrgSawAPosyNBK872rh2Z3aU8hjTztM1LEfGUXJ9T+kF9SLPOLJc1Y J1Rg== MIME-Version: 1.0 X-Received: by 10.194.2.240 with SMTP id 16mr25456545wjx.108.1421820941372; Tue, 20 Jan 2015 22:15:41 -0800 (PST) Received: by 10.194.87.98 with HTTP; Tue, 20 Jan 2015 22:15:41 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3552E6F7@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A3552E6F7@xmb-rcd-x10.cisco.com> Date: Tue, 20 Jan 2015 22:15:41 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b343d842512e7050d237cbe Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 06:15:45 -0000 --047d7b343d842512e7050d237cbe Content-Type: text/plain; charset=UTF-8 That's great. I agree with the text. Thanks ! Oleg On Tue, Jan 20, 2015 at 9:20 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Oleg, > > > > Good point, Modified text in sections 4, 6.1 to be more clear when the > client supports both methods > > > > NEW (Section 4): > > A STUN client should know the authentication capability of the STUN server > before deciding to use third party authorization. A STUN client initially > makes a request without any authorization. If the STUN server supports > third party authorization, it will return an error message indicating that > the client can authorize to the STUN server using OAuth access token. The > STUN server includes an ERROR-CODE attribute with a value of 401 > (Unauthorized), a nonce value in a NONCE attribute and a SOFTWARE attribute > that gives information about the STUN server's software. The STUN servers > also includes additional STUN attribute THIRD-PARTY-AUTHORIZATION signaling > the STUN client that the STUN server supports third party authorization. > > > > (Section 6.1) > > If the client is able to comprehend THIRD-PARTY-AUTHORIZATION it MUST > ensure that third party authorization takes precedence over first party > authentication (explained in section 10 of RFC 5389). If the client does > not support or is not capable of doing third party authorization then it > defaults to first party authentication. > > > > Cheers, > > -Tiru > > > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Wednesday, January 21, 2015 1:03 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: > draft-ietf-tram-turn-third-party-authz-06.txt > > > > A new change that I noticed in this draft is that it is making impossible > simultaneous support of the original 'legacy' long-term credentials and the > new third party credentials in the same server. If the server includes the > THIRD-PARTY-AUTHORIZATION attribute in the 401 response, then the client is > REQUIRED to provide the new authorization scheme. So, we have a few > problems here: > > 1) This is incompatible with the old clients. > > 2) If we really do want that change, then we have to make the > THIRD-PARTY-AUTHORIZATION attribute comprehension-required. Currently, it > is comprehension-optional. With the current scheme, there is a logical > mistake: you are allowing the client to ignore the TPA attribute (by making > it comprehension-optional) but in the same time you are NOT allowing the > client to ignore it (because you are requiring that the third-party > authorization to be used). It has to be resolved one way or another. > > I'd recommend to rollback to the previous draft because the older draft > did not have contradictions and the old draft allowed the server > administrators to decide which combination of the authorization schemes > they want to deploy. > > > > > > On Tue, Jan 20, 2015 at 7:55 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Revision > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 > addresses comments from Spencer. > > -Tiru > > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Tuesday, January 20, 2015 9:22 PM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.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 Working > > Group of the IETF. > > > > Title : Session Traversal Utilities for NAT (STUN) > Extension for Third > > Party Authorization > > Authors : Tirumaleswar Reddy > > Prashanth Patil > > Ram Mohan Ravindranath > > Justin Uberti > > Filename : draft-ietf-tram-turn-third-party-authz-06.txt > > Pages : 20 > > Date : 2015-01-20 > > > > Abstract: > > This document proposes the use of OAuth to obtain and validate > > ephemeral tokens that can be used for Session Traversal Utilities for > > NAT (STUN) authentication. The usage of ephemeral tokens ensure that > > access to a STUN server can be controlled even if the tokens are > > compromised. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-06 > > > > > > 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 > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --047d7b343d842512e7050d237cbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's great. I agree with the text.

=
Thanks !
Oleg


On Tue, Jan 20, 2015 at 9:20 PM, Tirumaleswar Redd= y (tireddy) <tireddy@cisco.com> wrote:

Hi Oleg,

=C2=A0

Good point, Modified text= in sections 4, 6.1 to be more clear when the client supports both methods

=C2=A0

NEW (Section 4):

A STUN client should know= the authentication capability of the STUN server before deciding to use th= ird party authorization. A STUN client initially makes a request without any authorization. If the STUN server supports third party= authorization, it will return an error message indicating that the client = can authorize to the STUN server using OAuth access token. The STUN server = includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a nonce value in a NONCE attribute and= a SOFTWARE attribute that gives information about the STUN server's so= ftware. The STUN servers also includes additional STUN attribute THIRD-PART= Y-AUTHORIZATION signaling the STUN client that the STUN server supports third party authorization.

=C2=A0

(Section 6.1)

If the client is able to = comprehend THIRD-PARTY-AUTHORIZATION it MUST ensure that third party author= ization takes precedence over first party authentication (explained in section 10 of RFC 5389). If the client does not support or i= s not capable of doing third party authorization then it defaults to first = party authentication.

=C2=A0

Cheers,

-Tiru

=C2=A0

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Wednesday, January 21, 2015 1:03 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-aut= hz-06.txt

=C2=A0

A new change that I n= oticed in this draft is that it is making impossible simultaneous support o= f the original 'legacy' long-term credentials and the new third par= ty credentials in the same server. If the server includes the THIRD-PARTY-AUTHORIZATION attribute in the 401 response, then= the client is REQUIRED to provide the new authorization scheme. So, we hav= e a few problems here:

1) This is incompatible with the old clients.=

2) If we really do wa= nt that change, then we have to make the THIRD-PARTY-AUTHORIZATION attribut= e comprehension-required. Currently, it is comprehension-optional. With the= current scheme, there is a logical mistake: you are allowing the client to ignore the TPA attribute (by makin= g it comprehension-optional) but in the same time you are NOT allowing the = client to ignore it (because you are requiring that the third-party authori= zation to be used). It has to be resolved one way or another.

I'd recommend to = rollback to the previous draft because the older draft did not have contrad= ictions and the old draft allowed the server administrators to decide which= combination of the authorization schemes they want to deploy.

=C2=A0

=C2=A0

On Tue, Jan 20, 2015 at 7:55 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Revision http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 ad= dresses comments from Spencer.

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Tuesday, January 20, 2015 9:22 PM
> To: i-d-ann= ounce@ietf.org
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-06.= txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the TURN Revised and Modernized Wor= king
> Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Session Traversal Utilities for NAT (STUN) Extension for Third<= br> > Party Authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Tirumaleswar Reddy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Prashanth Patil
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ram Mohan Ravindranath
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Justin Uberti
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turn-third-party-authz-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 20
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-20
>
> Abstract:
>=C2=A0 =C2=A0 This document proposes the use of OAuth to obtain and val= idate
>=C2=A0 =C2=A0 ephemeral tokens that can be used for Session Traversal U= tilities for
>=C2=A0 =C2=A0 NAT (STUN) authentication.=C2=A0 The usage of ephemeral t= okens ensure that
>=C2=A0 =C2=A0 access to a STUN server can be controlled even if the tok= ens are
>=C2=A0 =C2=A0 compromised.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-06 >
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz-0= 6
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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
> tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0


--047d7b343d842512e7050d237cbe-- From nobody Wed Jan 21 07:46:30 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127721A1AEB; Wed, 21 Jan 2015 07:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 gBzzSVp3ql_l; Wed, 21 Jan 2015 07:46:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B37BC1A1AE0; Wed, 21 Jan 2015 07:46:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121154626.11146.70452.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 07:46:26 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-07.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:46:28 -0000 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 Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-07.txt Pages : 20 Date : 2015-01-21 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensure that access to a STUN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-07 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/ From nobody Wed Jan 21 12:03:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683161A87AB; Wed, 21 Jan 2015 12:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 mmA6nszEOToV; Wed, 21 Jan 2015 12:03:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9F1A8763; Wed, 21 Jan 2015 12:03:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150121200308.32037.53813.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 12:03:08 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 20:03:11 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensure that access to a STUN server can be controlled even if the tokens are compromised. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 22 20:29:08 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E066A1A8F4C; Thu, 22 Jan 2015 20:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 yl9C47bPSp_s; Thu, 22 Jan 2015 20:28:53 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5471E1A1A6C; Thu, 22 Jan 2015 20:28:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AA17C187E27; Thu, 22 Jan 2015 20:28:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150123042825.AA17C187E27@rfc-editor.org> Date: Thu, 22 Jan 2015 20:28:25 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, tram@ietf.org, rfc-editor@rfc-editor.org Subject: [tram] RFC 7443 on Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 04:28:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7443 Title: Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages Author: P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin Status: Informational Stream: IETF Date: January 2015 Mailbox: praspati@cisco.com, tireddy@cisco.com, gsalguei@cisco.com, marc@petit-huguenin.org Pages: 5 Characters: 9145 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tram-alpn-08.txt URL: https://www.rfc-editor.org/info/rfc7443 Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS). This document is a product of the TURN Revised and Modernized Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jan 22 23:25:13 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EB11A0377; Thu, 22 Jan 2015 23:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 LQFkbn_j6U7F; Thu, 22 Jan 2015 23:25:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E31D1A8F4C; Thu, 22 Jan 2015 23:25:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123072509.4573.9953.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 23:25:09 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 07:25:11 -0000 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 Working Group of the IETF. Title : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-01.txt Pages : 11 Date : 2015-01-22 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 or the ISP, 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 two such mechanisms for TURN server discovery. 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: http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-01 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/ From nobody Tue Jan 27 20:50:48 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43E01A90F2; Tue, 27 Jan 2015 20:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5kEALv1lvwQa; Tue, 27 Jan 2015 20:50:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B3D1ACD26; Tue, 27 Jan 2015 20:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7280; q=dns/txt; s=iport; t=1422420643; x=1423630243; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dJ5C8Dn6CXI7z7c5wRG8Sh4x3q6PzOwOxAnQioynJ8I=; b=PZdCwNWMXbvtxPZYn6PT7F5thN1ENPc9MvNh71745wwN9Gvj6QDAa2VU FdvNBgGOYAjE+PY2LFypSKPKYex0QdSU1lMxkZhQjhS/t0S9MVpK9gLjp 9B/ebHKczAnylQXbCAvu1jQAeTXmrHeCX+m4RoSMo/jOs44wW8pUZ0/Rt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoGAERqyFStJV2S/2dsb2JhbABagwZSWQSCfME9giWFcQIcgQBDAQEBAQF9hAwBAQEDASMRNwMLBQcEAgEIEQQBAQECAgYZBAMCAgIwFAEICAIEDgUIAYgbCA2/ZJUaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiyeCfxYbBwaCYi6BEwWOboNLhms2gkmOKCKCMoE8b4EEJBx+AQEB X-IronPort-AV: E=Sophos;i="5.09,479,1418083200"; d="scan'208";a="391290182" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jan 2015 04:50:42 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0S4ofsa018038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jan 2015 04:50:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 22:50:40 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "drafts-lastcall@iana.org" Thread-Topic: [IANA #804968] Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard Thread-Index: AQHQOoogbHtr2zrsPUyjbEKBA22M65zU4bUw Date: Wed, 28 Jan 2015 04:50:39 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35532FF8@xmb-rcd-x10.cisco.com> References: <20150121200309.32037.30290.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "iesg@ietf.org" , "tram-chairs@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] [IANA #804968] Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 04:50:44 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZWFybCBMaWFuZyB2aWEgUlQg W21haWx0bzpkcmFmdHMtbGFzdGNhbGxAaWFuYS5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSmFu dWFyeSAyOCwgMjAxNSA1OjA3IEFNDQo+IENjOiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1w YXJ0eS1hdXRoekB0b29scy5pZXRmLm9yZzsgdHJhbS0NCj4gY2hhaXJzQHRvb2xzLmlldGYub3Jn OyBpZXNnQGlldGYub3JnDQo+IFN1YmplY3Q6IFtJQU5BICM4MDQ5NjhdIExhc3QgQ2FsbDogPGRy YWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LQ0KPiAwNy50eHQ+IChTZXNzaW9u IFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgRXh0ZW5zaW9uIGZvciBUaGlyZCBQ YXJ0eQ0KPiBBdXRob3JpemF0aW9uKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gKEJFR0lO IElBTkEgTEFTVCBDQUxMIENPTU1FTlRTKQ0KPiANCj4gSUVTRy9BdXRob3JzL1dHIENoYWlyczoN Cj4gDQo+IElBTkEgaGFzIHJldmlld2VkIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5 LWF1dGh6LTA3ICBBdXRob3JzIHNob3VsZA0KPiByZXZpZXcgdGhlIGNvbW1lbnRzIGFuZC9vciBx dWVzdGlvbnMgYmVsb3cuICBQbGVhc2UgcmVwb3J0IGFueQ0KPiBpbmFjY3VyYWNpZXMgYW5kIHJl c3BvbmQgdG8gYW55IHF1ZXN0aW9ucyBhcyBzb29uIGFzIHBvc3NpYmxlLg0KPiANCj4gSUFOQSBo YXMgcXVlc3Rpb25zIGFib3V0IHNvbWUgb2YgdGhlIElBTkEgYWN0aW9ucyByZXF1ZXN0ZWQgaW4g dGhlIElBTkENCj4gQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KPiAN Cj4gV2UgcmVjZWl2ZWQgdGhlIGZvbGxvd2luZyBjb21tZW50cy9xdWVzdGlvbnMgZnJvbSB0aGUg SUFOQSdzIHJldmlld2VyOg0KPiANCj4gSUFOQSB1bmRlcnN0YW5kcyB0aGF0LCB1cG9uIGFwcHJv dmFsIG9mIHRoaXMgZG9jdW1lbnQsIHRoZXJlIGlzIGEgc2luZ2xlDQo+IGFjdGlvbiB3aGljaCBJ QU5BIG11c3QgY29tcGxldGUuDQo+IA0KPiBJbiB0aGUgU1RVTiBBdHRyaWJ1dGVzIHN1YnJlZ2lz dHJ5IG9mIHRoZSBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVA0KPiAoU1RVTikg UGFyYW1ldGVycyByZWdpc3RyeSBsb2NhdGVkIGF0Og0KPiANCj4gaHR0cDovL3d3dy5pYW5hLm9y Zy9hc3NpZ25tZW50cy9zdHVuLXBhcmFtZXRlcnMvDQo+IA0KPiB0d28gbmV3IFNUVU4gYXR0cmli dXRlcyBhcmUgdG8gYmUgcmVnaXN0ZXJlZCBhcyBmb2xsb3dzOg0KPiANCj4gVmFsdWU6IFsgVEJE LWF0LXJlZ2lzdHJhdGlvbiBdDQo+IE5hbWU6IFRISVJELVBBUlRZLUFVVEhPUklaQVRJT04NCj4g UmVmZXJlbmNlOiBbIFJGQy10by1iZSBdDQo+IA0KPiBWYWx1ZTogWyBUQkQtYXQtcmVnaXN0cmF0 aW9uIF0NCj4gTmFtZTogQUNDRVNTLVRPS0VODQo+IFJlZmVyZW5jZTogWyBSRkMtdG8tYmUgXQ0K PiANCj4gUXVlc3Rpb246IHdoaWNoIHJhbmdlIG9yIHJhbmdlcyBpbiB0aGUgU1RVTiBBdHRyaWJ1 dGVzIHJlZ2lzdHJ5IHRoZSBhYm92ZQ0KPiB0d28gbmV3DQo+IGF0dHJpYnV0ZXMgc2hvdWxkIGJl IHJlZ2lzdGVyZWQ/ICAgVGhlIHJlZ2lzdHJ5IGRlZmluZXMgdGhlIGZvbGxvd2luZyByYW5nZXM6 DQo+IA0KPiBSYW5nZSAJUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMgCU5vdGUNCj4gMHgwMDAwLTB4 M0ZGRglJRVRGIFJldmlldwljb21wcmVoZW5zaW9uLXJlcXVpcmVkIHJhbmdlDQo+IDB4NDAwMC0w eDdGRkYJRGVzaWduYXRlZCBFeHBlcnQJY29tcHJlaGVuc2lvbi1yZXF1aXJlZCByYW5nZQ0KPiAw eDgwMDAtMHhCRkZGCUlFVEYgUmV2aWV3CWNvbXByZWhlbnNpb24tb3B0aW9uYWwgcmFuZ2UNCj4g MHhDMDAwLTB4RkZGRglEZXNpZ25hdGVkIEV4cGVydAljb21wcmVoZW5zaW9uLW9wdGlvbmFsIHJh bmdlDQo+IA0KPiBJdCBhcHBlYXJzIHRoYXQgc2VjdGlvbiA2IGRlZmluZXMgdGhlIG5ldyBhdHRy aWJ1dGVzIHRvIGJlIGluIHR3byBkaWZmZXJlbnQNCj4gcmFuZ2VzLCBjb21wcmVoZW5zaW9uLW9w dGlvbmFsIGFuZCBjb21wcmVoZW5zaW9uLXJlcXVpcmVkLiAgSXMgdGhhdA0KPiBjb3JyZWN0PyAg DQoNClllcy4NCg0KPiBJZiBzbywgcGxlYXNlIGVpdGhlciBhZGQgdGhlIHJhbmdlcyBpbiB0aGUg SUMgc2VjdGlvbiBvciBhZGQgYSBwb2ludGVyDQo+IHRvIHNlY3Rpb24gNiBpbiB0aGUgSUMgc2Vj dGlvbi4NCg0KTkVXIChJQyBzZWN0aW9uKToNCg0KICAgW1BhcmFncmFwaHMgYmVsb3cgaW4gYnJh Y2VzIHNob3VsZCBiZSByZW1vdmVkIGJ5IHRoZSBSRkMgRWRpdG9yIHVwb24NCiAgIHB1YmxpY2F0 aW9uXQ0KDQogICBbVGhlIFRISVJELVBBUlRZLUFVVEhPUklaQVRJT04gYXR0cmlidXRlIHJlcXVp cmVzIHRoYXQgSUFOQSBhbGxvY2F0ZSBhIHZhbHVlIGluDQogICB0aGUgIlNUVU4gYXR0cmlidXRl cyBSZWdpc3RyeSIgZnJvbSB0aGUgY29tcHJlaGVuc2lvbi1vcHRpb25hbCByYW5nZQ0KICAgKDB4 ODAwMC0weEZGRkYpXQ0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIFRISVJELVBBUlRZ LUFVVEhPUklaQVRJT04gU1RVTiBhdHRyaWJ1dGUsIGRlc2NyaWJlZA0KICAgaW4gU2VjdGlvbiA2 LiAgSUFOQSBoYXMgYWxsb2NhdGVkIHRoZSBjb21wcmVoZW5zaW9uLW9wdGlvbmFsDQogICBjb2Rl cG9pbnQgVEJEIGZvciB0aGlzIGF0dHJpYnV0ZS4NCg0KICAgW1RoZSBBQ0NFU1MtVE9LRU4gYXR0 cmlidXRlIHJlcXVpcmVzIHRoYXQgSUFOQSBhbGxvY2F0ZSBhIHZhbHVlDQogICBpbiB0aGUgIlNU VU4gYXR0cmlidXRlcyBSZWdpc3RyeSIgZnJvbSB0aGUgY29tcHJlaGVuc2lvbi1yZXF1aXJlZA0K ICAgcmFuZ2UgKDB4MDAwMC0weDNGRkYpXQ0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhl IEFDQ0VTUy1UT0tFTiBTVFVOIGF0dHJpYnV0ZSwgZGVzY3JpYmVkDQogICBpbiBTZWN0aW9uIDYu ICBJQU5BIGhhcyBhbGxvY2F0ZWQgdGhlIGNvbXByZWhlbnNpb24tcmVxdWlyZWQNCiAgIGNvZGVw b2ludCBUQkQgZm9yIHRoaXMgYXR0cmlidXRlLg0KDQotVGlydQ0KDQo+IA0KPiBGdXJ0aGVyLCBp ZiBhIG5ldyBhdHRyaWJ1dGUgaXMgaW4gdGhlIGNvbXByZWhlbnNpb24tb3B0aW9uYWwgcmFuZ2Us IHRoZQ0KPiBhdXRob3JzIG5lZWQgdG8gZGVmaW5lIHdoaWNoIG9mIHRoZSBjb21wcmVoZW5zaW9u LW9wdGlvbmFsIHJhbmdlcywNCj4gMHg4MDAwLTB4QkZGRiBvciAweEMwMDAtMHhGRkZGLCB0aGUg bmV3IGF0dHJpYnV0ZSBzaG91bGQgYmUgcmVnaXN0ZXJlZC4NCj4gU28sIGlmIHRoZSBhdXRob3Jz IHBpY2sgIjB4ODAwMC0weEJGRkYiIG9mIHRoZSBjb21wcmVoZW5zaW9uLW9wdGlvbmFsDQo+IHJh bmdlLCBJRVRGIFJldmlldyByZWdpc3RyYXRpb24gcnVsZSB3aWxsIGJlIHVzZWQuICBUaGUgSUMg c2VjdGlvbiBoYXMgbm8gY2xlYXINCj4gdGV4dHMgYWJvdXQgdGhlc2UuDQo+IA0KPiANCj4gSUFO QSB1bmRlcnN0YW5kcyB0aGF0IHRoaXMgaXMgdGhlIG9ubHkgYWN0aW9uIHRoYXQgbmVlZHMgdG8g YmUgY29tcGxldGVkDQo+IHVwb24gYXBwcm92YWwgb2YgdGhpcyBkb2N1bWVudC4NCj4gDQo+IE5v dGU6ICBUaGUgYWN0aW9ucyByZXF1ZXN0ZWQgaW4gdGhpcyBkb2N1bWVudCB3aWxsIG5vdCBiZSBj b21wbGV0ZWQgdW50aWwgdGhlDQo+IGRvY3VtZW50IGhhcyBiZWVuIGFwcHJvdmVkIGZvciBwdWJs aWNhdGlvbiBhcyBhbiBSRkMuIFRoaXMgbWVzc2FnZSBpcyBvbmx5DQo+IHRvIGNvbmZpcm0gd2hh dCBhY3Rpb25zIHdpbGwgYmUgcGVyZm9ybWVkLg0KPiANCj4gDQo+IFRoYW5rcywNCj4gDQo+IFBl YXJsIExpYW5nDQo+IElDQU5ODQo+IA0KPiAoRU5EIElBTkEgTEFTVCBDQUxMIENPTU1FTlRTKQ0K PiANCj4gT24gV2VkIEphbiAyMSAyMDowMzozMyAyMDE1LCBpZXNnLXNlY3JldGFyeUBpZXRmLm9y ZyB3cm90ZToNCj4gPg0KPiA+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0 aGUgVFVSTiBSZXZpc2VkIGFuZCBNb2Rlcm5pemVkDQo+ID4gV0cNCj4gPiAodHJhbSkgdG8gY29u c2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4gPiAtICdTZXNzaW9uIFRyYXZlcnNhbCBV dGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgRXh0ZW5zaW9uIGZvciBUaGlyZA0KPiA+IFBhcnR5DQo+ ID4gICAgQXV0aG9yaXphdGlvbicNCj4gPiAgIDxkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1w YXJ0eS1hdXRoei0wNy50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4NCj4gPiBUaGUgSUVT RyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29s aWNpdHMNCj4gPiBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vi c3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQo+ID4gaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3Rz IGJ5IDIwMTUtMDItMDQuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heQ0KPiA+IGJlDQo+ID4g c2VudCB0byBpZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0 YWluIHRoZQ0KPiA+IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9t YXRlZCBzb3J0aW5nLg0KPiA+DQo+ID4gQWJzdHJhY3QNCj4gPg0KPiA+DQo+ID4gVGhpcyBkb2N1 bWVudCBwcm9wb3NlcyB0aGUgdXNlIG9mIE9BdXRoIHRvIG9idGFpbiBhbmQgdmFsaWRhdGUNCj4g PiBlcGhlbWVyYWwgdG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFNlc3Npb24gVHJhdmVyc2Fs IFV0aWxpdGllcyBmb3INCj4gPiBOQVQgKFNUVU4pIGF1dGhlbnRpY2F0aW9uLiAgVGhlIHVzYWdl IG9mIGVwaGVtZXJhbCB0b2tlbnMgZW5zdXJlIHRoYXQNCj4gPiBhY2Nlc3MgdG8gYSBTVFVOIHNl cnZlciBjYW4gYmUgY29udHJvbGxlZCBldmVuIGlmIHRoZSB0b2tlbnMgYXJlDQo+ID4gY29tcHJv bWlzZWQuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQg dmlhDQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0t dHVybi10aGlyZC1wYXJ0eS0NCj4gPiBhdXRoei8NCj4gPg0KPiA+IElFU0cgZGlzY3Vzc2lvbiBj YW4gYmUgdHJhY2tlZCB2aWENCj4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPiA+IGF1dGh6L2JhbGxvdC8NCj4gPg0K PiA+DQo+ID4gTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5 IG9uIHRoaXMgSS1ELg0KDQo= From nobody Wed Jan 28 18:34:17 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E531A8ADA; Wed, 28 Jan 2015 18:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0kw07kZUu_U4; Wed, 28 Jan 2015 18:34:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DEC1A00BB; Wed, 28 Jan 2015 18:34:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129023411.19142.99300.idtracker@ietfa.amsl.com> Date: Wed, 28 Jan 2015 18:34:11 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-08.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 02:34:13 -0000 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 Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-08.txt Pages : 20 Date : 2015-01-28 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensure that access to a STUN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-08 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/ From nobody Wed Jan 28 18:38:35 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D21A8AD8; Wed, 28 Jan 2015 18:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3nIMtEh6ei3u; Wed, 28 Jan 2015 18:38:28 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F481A8AC0; Wed, 28 Jan 2015 18:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9516; q=dns/txt; s=iport; t=1422499109; x=1423708709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t+ubz9bY5f7p3/1o/CXG6HxnAlLCL3gJDVi5zPganZw=; b=SP4afaz2ckQNppBdXfTeZZ/BvBcnY9Ed/hgg9IeiFIBRmds6CQcdjCq/ K1tilFX6nhbgwWuLLRk+VBQXPEe7/V9H1+5KBBiD2RUixEc5J9rWf1+y2 icwgukB4OpqtnQ5WH13/T/3BFTCy6o73hhcqvx2DwOGKuZ4MWNIt7N/bB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3BQArnMlU/4oNJK1agwZSWQSCfb82giWFcQIcfEMBAQEBAX2EDAEBAQMBIxE3AwsMBAIBCBEEAQEBAgIGGQQDAgICMBQBCAgCBA4FCAGIGwgNv36WBQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYsngn8WGwcGgmIugRMFjnSDS4ZuNoJLji4igjKBPG+BBCQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,484,1418083200"; d="scan'208";a="118514252" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 29 Jan 2015 02:38:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0T2cRj7025251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 02:38:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 20:38:27 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "iana-issues@iana.org" Thread-Topic: [IANA #806090] RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard Thread-Index: AQHQO0H4znOz8j6meUOQyFsnVU2dN5zWXa/A Date: Thu, 29 Jan 2015 02:38:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553364C@xmb-rcd-x10.cisco.com> References: <20150121200309.32037.30290.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35532FF8@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.64.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "liang@icann.org" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "tram@ietf.org" , "tram-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [tram] [IANA #806090] RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 02:38:30 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZWFybCBMaWFuZyB2aWEgUlQg W21haWx0bzppYW5hLWlzc3Vlc0BpYW5hLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkg MjksIDIwMTUgMzowMiBBTQ0KPiBDYzogdHJhbUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi10cmFtLXR1 cm4tdGhpcmQtcGFydHktYXV0aHpAdG9vbHMuaWV0Zi5vcmc7DQo+IHRyYW0tY2hhaXJzQHRvb2xz LmlldGYub3JnOyBpZXNnQGlldGYub3JnOyBsaWFuZ0BpY2Fubi5vcmcNCj4gU3ViamVjdDogW0lB TkEgIzgwNjA5MF0gUkU6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBh cnR5LWF1dGh6LQ0KPiAwNy50eHQ+IChTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5B VCAoU1RVTikgRXh0ZW5zaW9uIGZvciBUaGlyZCBQYXJ0eQ0KPiBBdXRob3JpemF0aW9uKSB0byBQ cm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gT24gV2VkIEphbiAyOCAwNDo1MTowNiAyMDE1LCB0aXJl ZGR5QGNpc2NvLmNvbSB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiBGcm9tOiBQZWFybCBMaWFuZyB2aWEgUlQgW21haWx0bzpkcmFmdHMtbGFzdGNhbGxAaWFu YS5vcmddDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgNTowNyBBTQ0K PiA+ID4gQ2M6IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6QHRvb2xzLmll dGYub3JnOyB0cmFtLQ0KPiA+ID4gY2hhaXJzQHRvb2xzLmlldGYub3JnOyBpZXNnQGlldGYub3Jn DQo+ID4gPiBTdWJqZWN0OiBbSUFOQSAjODA0OTY4XSBMYXN0IENhbGw6DQo+ID4gPiA8ZHJhZnQt aWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+ID4gPiBhdXRoei0NCj4gPiA+IDA3LnR4dD4g KFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKSBFeHRlbnNpb24gZm9y DQo+ID4gPiBUaGlyZCBQYXJ0eQ0KPiA+ID4gQXV0aG9yaXphdGlvbikgdG8gUHJvcG9zZWQgU3Rh bmRhcmQNCj4gPiA+DQo+ID4gPiAoQkVHSU4gSUFOQSBMQVNUIENBTEwgQ09NTUVOVFMpDQo+ID4g Pg0KPiA+ID4gSUVTRy9BdXRob3JzL1dHIENoYWlyczoNCj4gPiA+DQo+ID4gPiBJQU5BIGhhcyBy ZXZpZXdlZCBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wNyAgQXV0aG9y cw0KPiA+ID4gc2hvdWxkIHJldmlldyB0aGUgY29tbWVudHMgYW5kL29yIHF1ZXN0aW9ucyBiZWxv dy4gIFBsZWFzZSByZXBvcnQNCj4gPiA+IGFueSBpbmFjY3VyYWNpZXMgYW5kIHJlc3BvbmQgdG8g YW55IHF1ZXN0aW9ucyBhcyBzb29uIGFzIHBvc3NpYmxlLg0KPiA+ID4NCj4gPiA+IElBTkEgaGFz IHF1ZXN0aW9ucyBhYm91dCBzb21lIG9mIHRoZSBJQU5BIGFjdGlvbnMgcmVxdWVzdGVkIGluIHRo ZQ0KPiA+ID4gSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQo+ ID4gPg0KPiA+ID4gV2UgcmVjZWl2ZWQgdGhlIGZvbGxvd2luZyBjb21tZW50cy9xdWVzdGlvbnMg ZnJvbSB0aGUgSUFOQSdzDQo+ID4gPiByZXZpZXdlcjoNCj4gPiA+DQo+ID4gPiBJQU5BIHVuZGVy c3RhbmRzIHRoYXQsIHVwb24gYXBwcm92YWwgb2YgdGhpcyBkb2N1bWVudCwgdGhlcmUgaXMgYQ0K PiA+ID4gc2luZ2xlIGFjdGlvbiB3aGljaCBJQU5BIG11c3QgY29tcGxldGUuDQo+ID4gPg0KPiA+ ID4gSW4gdGhlIFNUVU4gQXR0cmlidXRlcyBzdWJyZWdpc3RyeSBvZiB0aGUgU2Vzc2lvbiBUcmF2 ZXJzYWwNCj4gPiA+IFV0aWxpdGllcyBmb3IgTkFUDQo+ID4gPiAoU1RVTikgUGFyYW1ldGVycyBy ZWdpc3RyeSBsb2NhdGVkIGF0Og0KPiA+ID4NCj4gPiA+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvc3R1bi1wYXJhbWV0ZXJzLw0KPiA+ID4NCj4gPiA+IHR3byBuZXcgU1RVTiBhdHRy aWJ1dGVzIGFyZSB0byBiZSByZWdpc3RlcmVkIGFzIGZvbGxvd3M6DQo+ID4gPg0KPiA+ID4gVmFs dWU6IFsgVEJELWF0LXJlZ2lzdHJhdGlvbiBdDQo+ID4gPiBOYW1lOiBUSElSRC1QQVJUWS1BVVRI T1JJWkFUSU9ODQo+ID4gPiBSZWZlcmVuY2U6IFsgUkZDLXRvLWJlIF0NCj4gPiA+DQo+ID4gPiBW YWx1ZTogWyBUQkQtYXQtcmVnaXN0cmF0aW9uIF0NCj4gPiA+IE5hbWU6IEFDQ0VTUy1UT0tFTg0K PiA+ID4gUmVmZXJlbmNlOiBbIFJGQy10by1iZSBdDQo+ID4gPg0KPiA+ID4gUXVlc3Rpb246IHdo aWNoIHJhbmdlIG9yIHJhbmdlcyBpbiB0aGUgU1RVTiBBdHRyaWJ1dGVzIHJlZ2lzdHJ5IHRoZQ0K PiA+ID4gYWJvdmUgdHdvIG5ldw0KPiA+ID4gYXR0cmlidXRlcyBzaG91bGQgYmUgcmVnaXN0ZXJl ZD8gICBUaGUgcmVnaXN0cnkgZGVmaW5lcyB0aGUgZm9sbG93aW5nDQo+ID4gPiByYW5nZXM6DQo+ ID4gPg0KPiA+ID4gUmFuZ2UgICAgICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlcyAgICAgICAg IE5vdGUNCj4gPiA+IDB4MDAwMC0weDNGRkYgSUVURiBSZXZpZXcgICAgIGNvbXByZWhlbnNpb24t cmVxdWlyZWQgcmFuZ2UNCj4gPiA+IDB4NDAwMC0weDdGRkYgRGVzaWduYXRlZCBFeHBlcnQgICAg ICAgY29tcHJlaGVuc2lvbi1yZXF1aXJlZCByYW5nZQ0KPiA+ID4gMHg4MDAwLTB4QkZGRiBJRVRG IFJldmlldyAgICAgY29tcHJlaGVuc2lvbi1vcHRpb25hbCByYW5nZQ0KPiA+ID4gMHhDMDAwLTB4 RkZGRiBEZXNpZ25hdGVkIEV4cGVydCAgICAgICBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIHJhbmdl DQo+ID4gPg0KPiA+ID4gSXQgYXBwZWFycyB0aGF0IHNlY3Rpb24gNiBkZWZpbmVzIHRoZSBuZXcg YXR0cmlidXRlcyB0byBiZSBpbiB0d28NCj4gPiA+IGRpZmZlcmVudCByYW5nZXMsIGNvbXByZWhl bnNpb24tb3B0aW9uYWwgYW5kIGNvbXByZWhlbnNpb24tcmVxdWlyZWQuDQo+ID4gPiBJcyB0aGF0 DQo+ID4gPiAgIGNvcnJlY3Q/DQo+ID4NCj4gPiBZZXMuDQo+ID4NCj4gPiA+IElmIHNvLCBwbGVh c2UgZWl0aGVyIGFkZCB0aGUgcmFuZ2VzIGluIHRoZSBJQyBzZWN0aW9uIG9yIGFkZCBhDQo+ID4g PiBwb2ludGVyIHRvIHNlY3Rpb24gNiBpbiB0aGUgSUMgc2VjdGlvbi4NCj4gPg0KPiA+IE5FVyAo SUMgc2VjdGlvbik6DQo+ID4NCj4gPiBbUGFyYWdyYXBocyBiZWxvdyBpbiBicmFjZXMgc2hvdWxk IGJlIHJlbW92ZWQgYnkgdGhlIFJGQyBFZGl0b3IgdXBvbg0KPiA+IHB1YmxpY2F0aW9uXQ0KPiA+ DQo+ID4gW1RoZSBUSElSRC1QQVJUWS1BVVRIT1JJWkFUSU9OIGF0dHJpYnV0ZSByZXF1aXJlcyB0 aGF0IElBTkEgYWxsb2NhdGUgYQ0KPiA+IHZhbHVlIGluIHRoZSAiU1RVTiBhdHRyaWJ1dGVzIFJl Z2lzdHJ5IiBmcm9tIHRoZQ0KPiA+IGNvbXByZWhlbnNpb24tb3B0aW9uYWwgcmFuZ2UgKDB4ODAw MC0weEZGRkYpXQ0KPiA+DQo+IA0KPiBBcyBkZXNjcmliZWQgYWJvdmUsIHRoZSByYW5nZSAweDgw MDAtMHhGRkZGIGhhcyB0d28gZGlmZmVyZW50IHJlZ2lzdHJhdGlvbg0KPiBydWxlcyBhcyBkZWZp bmVkIGJ5IFJGQzUzODkuICBXaGljaCBvbmUgb2YgdGhlIGZvbGxvd2luZyB0aGUgbmV3IFNUVU4N Cj4gYXR0cmlidXRlIHNob3VsZCBiZSByZWdpc3RlcmVkOg0KPiANCj4gMHg4MDAwLTB4QkZGRglJ RVRGIFJldmlldwljb21wcmVoZW5zaW9uLW9wdGlvbmFsIHJhbmdlDQo+IDB4QzAwMC0weEZGRkYJ RGVzaWduYXRlZCBFeHBlcnQJY29tcHJlaGVuc2lvbi1vcHRpb25hbCByYW5nZQ0KPiANCj4gPw0K PiANCj4gU2hvdWxkIGl0IGJlIGluIDB4ODAwMC0weEJGRkY/DQoNClllcywgdXBkYXRlZCBJQyBz ZWN0aW9uIGFuZCBwdWJsaXNoZWQgcmV2aXNpb24gdG8gYWRkcmVzcyB0aGUgY29tbWVudC4NCg0K VGhhbmtzLA0KLVRpcnUNCg0KPiANCj4gVGhhbmtzLA0KPiB+cGwNCj4gDQo+IA0KPiA+IFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyB0aGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiBTVFVOIGF0dHJp YnV0ZSwNCj4gPiBkZXNjcmliZWQgaW4gU2VjdGlvbiA2LiAgSUFOQSBoYXMgYWxsb2NhdGVkIHRo ZSBjb21wcmVoZW5zaW9uLW9wdGlvbmFsDQo+ID4gY29kZXBvaW50IFRCRCBmb3IgdGhpcyBhdHRy aWJ1dGUuDQo+ID4NCj4gPiBbVGhlIEFDQ0VTUy1UT0tFTiBhdHRyaWJ1dGUgcmVxdWlyZXMgdGhh dCBJQU5BIGFsbG9jYXRlIGEgdmFsdWUgaW4gdGhlDQo+ID4gIlNUVU4gYXR0cmlidXRlcyBSZWdp c3RyeSIgZnJvbSB0aGUgY29tcHJlaGVuc2lvbi1yZXF1aXJlZCByYW5nZQ0KPiA+ICgweDAwMDAt MHgzRkZGKV0NCj4gPg0KPiA+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgQUNDRVNTLVRPS0VO IFNUVU4gYXR0cmlidXRlLCBkZXNjcmliZWQgaW4NCj4gPiBTZWN0aW9uIDYuICBJQU5BIGhhcyBh bGxvY2F0ZWQgdGhlIGNvbXByZWhlbnNpb24tcmVxdWlyZWQgY29kZXBvaW50DQo+ID4gVEJEIGZv ciB0aGlzIGF0dHJpYnV0ZS4NCj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPiA+DQo+ID4gPiBGdXJ0 aGVyLCBpZiBhIG5ldyBhdHRyaWJ1dGUgaXMgaW4gdGhlIGNvbXByZWhlbnNpb24tb3B0aW9uYWwg cmFuZ2UsDQo+ID4gPiB0aGUgYXV0aG9ycyBuZWVkIHRvIGRlZmluZSB3aGljaCBvZiB0aGUgY29t cHJlaGVuc2lvbi1vcHRpb25hbA0KPiA+ID4gcmFuZ2VzLCAweDgwMDAtMHhCRkZGIG9yIDB4QzAw MC0weEZGRkYsIHRoZSBuZXcgYXR0cmlidXRlIHNob3VsZCBiZQ0KPiA+ID4gcmVnaXN0ZXJlZC4N Cj4gPiA+IFNvLCBpZiB0aGUgYXV0aG9ycyBwaWNrICIweDgwMDAtMHhCRkZGIiBvZiB0aGUNCj4g PiA+IGNvbXByZWhlbnNpb24tb3B0aW9uYWwgcmFuZ2UsIElFVEYgUmV2aWV3IHJlZ2lzdHJhdGlv biBydWxlIHdpbGwgYmUNCj4gPiA+IHVzZWQuICBUaGUgSUMgc2VjdGlvbiBoYXMgbm8gY2xlYXIg dGV4dHMgYWJvdXQgdGhlc2UuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IElBTkEgdW5kZXJzdGFuZHMg dGhhdCB0aGlzIGlzIHRoZSBvbmx5IGFjdGlvbiB0aGF0IG5lZWRzIHRvIGJlDQo+ID4gPiBjb21w bGV0ZWQgdXBvbiBhcHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50Lg0KPiA+ID4NCj4gPiA+IE5vdGU6 ICBUaGUgYWN0aW9ucyByZXF1ZXN0ZWQgaW4gdGhpcyBkb2N1bWVudCB3aWxsIG5vdCBiZSBjb21w bGV0ZWQNCj4gPiA+IHVudGlsIHRoZSBkb2N1bWVudCBoYXMgYmVlbiBhcHByb3ZlZCBmb3IgcHVi bGljYXRpb24gYXMgYW4gUkZDLiBUaGlzDQo+ID4gPiBtZXNzYWdlIGlzIG9ubHkgdG8gY29uZmly bSB3aGF0IGFjdGlvbnMgd2lsbCBiZSBwZXJmb3JtZWQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRo YW5rcywNCj4gPiA+DQo+ID4gPiBQZWFybCBMaWFuZw0KPiA+ID4gSUNBTk4NCj4gPiA+DQo+ID4g PiAoRU5EIElBTkEgTEFTVCBDQUxMIENPTU1FTlRTKQ0KPiA+ID4NCj4gPiA+IE9uIFdlZCBKYW4g MjEgMjA6MDM6MzMgMjAxNSwgaWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmcgd3JvdGU6DQo+ID4gPiA+ DQo+ID4gPiA+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgVFVSTiBS ZXZpc2VkIGFuZA0KPiA+ID4gPiBNb2Rlcm5pemVkIFdHDQo+ID4gPiA+ICh0cmFtKSB0byBjb25z aWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiA+ID4gPiAtICdTZXNzaW9uIFRyYXZlcnNh bCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgRXh0ZW5zaW9uIGZvciBUaGlyZA0KPiA+ID4gPiBQ YXJ0eQ0KPiA+ID4gPiAgICBBdXRob3JpemF0aW9uJw0KPiA+ID4gPiAgIDxkcmFmdC1pZXRmLXRy YW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wNy50eHQ+IGFzIFByb3Bvc2VkDQo+ID4gPiA+IFN0 YW5kYXJkDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lv biBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZA0KPiA+ID4gPiBzb2xpY2l0cyBmaW5hbCBjb21t ZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUNCj4gPiA+ID4gY29t bWVudHMgdG8gdGhlIGlldGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDE1LTAyLTA0Lg0K PiA+ID4gPiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmUgc2VudCB0byBpZXNnQGlldGYu b3JnIGluc3RlYWQuIEluDQo+ID4gPiA+IGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBi ZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0bw0KPiA+ID4gPiBhbGxvdyBhdXRvbWF0ZWQg c29ydGluZy4NCj4gPiA+ID4NCj4gPiA+ID4gQWJzdHJhY3QNCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4gVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0aGUgdXNlIG9mIE9BdXRoIHRvIG9idGFpbiBh bmQgdmFsaWRhdGUNCj4gPiA+ID4gZXBoZW1lcmFsIHRva2VucyB0aGF0IGNhbiBiZSB1c2VkIGZv ciBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMNCj4gPiA+ID4gZm9yIE5BVCAoU1RVTikgYXV0 aGVudGljYXRpb24uICBUaGUgdXNhZ2Ugb2YgZXBoZW1lcmFsIHRva2Vucw0KPiA+ID4gPiBlbnN1 cmUgdGhhdCBhY2Nlc3MgdG8gYSBTVFVOIHNlcnZlciBjYW4gYmUgY29udHJvbGxlZCBldmVuIGlm IHRoZQ0KPiA+ID4gPiB0b2tlbnMgYXJlIGNvbXByb21pc2VkLg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+ ID4gPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1 cm4tdGhpcmQtcGFydHktDQo+ID4gPiA+IGF1dGh6Lw0KPiA+ID4gPg0KPiA+ID4gPiBJRVNHIGRp c2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+ID4gPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+ID4gPiA+IGF1 dGh6L2JhbGxvdC8NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gTm8gSVBSIGRlY2xhcmF0aW9u cyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KPiA+DQo+IA0KDQo= From nobody Wed Jan 28 21:01:33 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647A01A8BB1; Wed, 28 Jan 2015 21:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gig4iNekuW-1; Wed, 28 Jan 2015 21:01:27 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A621A1BAE; Wed, 28 Jan 2015 21:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12086; q=dns/txt; s=iport; t=1422507687; x=1423717287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rRUNO/xvhM5Pbqd5JVESZp4m/7oJ5b1vfA+u1uzMdvM=; b=QPX5rPE1pDw2fQfKRFsO9kEWnfera2g/QO/37bamWs9OBa5i3dKMq2AH wJrF50LGPP/pi569pBkypOvMnubD7MVR5f5xF92AHXMeJpZQPjXgMM8Ke bnO6R0kRB7tl2UYK3SeY4j2Ds8rfUe2W0lEE2OFFuzPg20GiTTHKaJ/1w c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFACK+yVStJA2M/2dsb2JhbABagwZSWQSCfb83giWFcQIcfUMBAQEBAX2EDAEBAQMBIxE3AwsMBAIBCBEEAQEBAgIGGQQDAgICMBQBCAgCBA4FCAGIGwgNv3SWCQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYsngn8WGwcGgmIugRMFjnSDS4ZuNoJLh3iGNiKCMoE8b4EEJBx+AQEB X-IronPort-AV: E=Sophos;i="5.09,484,1418083200"; d="scan'208";a="391645639" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jan 2015 05:01:26 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0T51QN9016848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 05:01:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 23:01:25 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "iana-issues@iana.org" Thread-Topic: [IANA #806090] RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard Thread-Index: AQHQO0H4znOz8j6meUOQyFsnVU2dN5zWXa/AgAATyVOAABi0sA== Date: Thu, 29 Jan 2015 05:01:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553387B@xmb-rcd-x10.cisco.com> References: <20150121200309.32037.30290.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35532FF8@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553364C@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.64.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "liang@icann.org" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "tram@ietf.org" , "tram-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [tram] [IANA #806090] RE: Last Call: (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 05:01:30 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZWFybCBMaWFuZyB2aWEgUlQg W21haWx0bzppYW5hLWlzc3Vlc0BpYW5hLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkg MjksIDIwMTUgOTowMSBBTQ0KPiBDYzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJh bUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtDQo+IHBhcnR5LWF1dGh6QHRv b2xzLmlldGYub3JnOyBpZXNnQGlldGYub3JnOyB0cmFtLWNoYWlyc0B0b29scy5pZXRmLm9yZzsN Cj4gbGlhbmdAaWNhbm4ub3JnDQo+IFN1YmplY3Q6IFtJQU5BICM4MDYwOTBdIFJFOiBMYXN0IENh bGw6IDxkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0NCj4gMDcudHh0PiAo U2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIEV4dGVuc2lvbiBmb3Ig VGhpcmQgUGFydHkNCj4gQXV0aG9yaXphdGlvbikgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+ IE9uIFRodSBKYW4gMjkgMDI6Mzk6NTYgMjAxNSwgdGlyZWRkeUBjaXNjby5jb20gd3JvdGU6DQo+ ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogUGVhcmwgTGlhbmcg dmlhIFJUIFttYWlsdG86aWFuYS1pc3N1ZXNAaWFuYS5vcmddDQo+ID4gPiBTZW50OiBUaHVyc2Rh eSwgSmFudWFyeSAyOSwgMjAxNSAzOjAyIEFNDQo+ID4gPiBDYzogdHJhbUBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+ID4gPiBhdXRoekB0b29scy5pZXRmLm9y ZzsgdHJhbS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc7DQo+ID4gPiBsaWFu Z0BpY2Fubi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtJQU5BICM4MDYwOTBdIFJFOiBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC0NCj4gPiA+IHBhcnR5LWF1dGh6LQ0KPiA+ID4g MDcudHh0PiAoU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIEV4dGVu c2lvbiBmb3INCj4gPiA+IFRoaXJkIFBhcnR5DQo+ID4gPiBBdXRob3JpemF0aW9uKSB0byBQcm9w b3NlZCBTdGFuZGFyZA0KPiA+ID4NCj4gPiA+IE9uIFdlZCBKYW4gMjggMDQ6NTE6MDYgMjAxNSwg dGlyZWRkeUBjaXNjby5jb20gd3JvdGU6DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBQZWFybCBMaWFuZyB2aWEgUlQgW21haWx0bzpkcmFmdHMt bGFzdGNhbGxAaWFuYS5vcmddDQo+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI4 LCAyMDE1IDU6MDcgQU0NCj4gPiA+ID4gPiBDYzogZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQt cGFydHktYXV0aHpAdG9vbHMuaWV0Zi5vcmc7IHRyYW0tDQo+ID4gPiA+ID4gY2hhaXJzQHRvb2xz LmlldGYub3JnOyBpZXNnQGlldGYub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogW0lBTkEgIzgwNDk2 OF0gTGFzdCBDYWxsOg0KPiA+ID4gPiA+IDxkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0 eS0NCj4gPiA+ID4gPiBhdXRoei0NCj4gPiA+ID4gPiAwNy50eHQ+IChTZXNzaW9uIFRyYXZlcnNh bCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgRXh0ZW5zaW9uDQo+ID4gPiA+ID4gZm9yIFRoaXJk IFBhcnR5DQo+ID4gPiA+ID4gQXV0aG9yaXphdGlvbikgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IChCRUdJTiBJQU5BIExBU1QgQ0FMTCBDT01NRU5UUykNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IElFU0cvQXV0aG9ycy9XRyBDaGFpcnM6DQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBJQU5BIGhhcyByZXZpZXdlZCBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1h dXRoei0wNw0KPiA+ID4gPiA+IEF1dGhvcnMNCj4gPiA+ID4gPiBzaG91bGQgcmV2aWV3IHRoZSBj b21tZW50cyBhbmQvb3IgcXVlc3Rpb25zIGJlbG93LiAgUGxlYXNlDQo+ID4gPiA+ID4gcmVwb3J0 IGFueSBpbmFjY3VyYWNpZXMgYW5kIHJlc3BvbmQgdG8gYW55IHF1ZXN0aW9ucyBhcyBzb29uIGFz DQo+ID4gPiA+ID4gcG9zc2libGUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJQU5BIGhhcyBxdWVz dGlvbnMgYWJvdXQgc29tZSBvZiB0aGUgSUFOQSBhY3Rpb25zIHJlcXVlc3RlZCBpbg0KPiA+ID4g PiA+IHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudC4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IFdlIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVl c3Rpb25zIGZyb20gdGhlIElBTkEncw0KPiA+ID4gPiA+IHJldmlld2VyOg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gSUFOQSB1bmRlcnN0YW5kcyB0aGF0LCB1cG9uIGFwcHJvdmFsIG9mIHRoaXMgZG9j dW1lbnQsIHRoZXJlIGlzDQo+ID4gPiA+ID4gYSBzaW5nbGUgYWN0aW9uIHdoaWNoIElBTkEgbXVz dCBjb21wbGV0ZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluIHRoZSBTVFVOIEF0dHJpYnV0ZXMg c3VicmVnaXN0cnkgb2YgdGhlIFNlc3Npb24gVHJhdmVyc2FsDQo+ID4gPiA+ID4gVXRpbGl0aWVz IGZvciBOQVQNCj4gPiA+ID4gPiAoU1RVTikgUGFyYW1ldGVycyByZWdpc3RyeSBsb2NhdGVkIGF0 Og0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9z dHVuLXBhcmFtZXRlcnMvDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiB0d28gbmV3IFNUVU4gYXR0cmli dXRlcyBhcmUgdG8gYmUgcmVnaXN0ZXJlZCBhcyBmb2xsb3dzOg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gVmFsdWU6IFsgVEJELWF0LXJlZ2lzdHJhdGlvbiBdDQo+ID4gPiA+ID4gTmFtZTogVEhJUkQt UEFSVFktQVVUSE9SSVpBVElPTg0KPiA+ID4gPiA+IFJlZmVyZW5jZTogWyBSRkMtdG8tYmUgXQ0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gVmFsdWU6IFsgVEJELWF0LXJlZ2lzdHJhdGlvbiBdDQo+ID4g PiA+ID4gTmFtZTogQUNDRVNTLVRPS0VODQo+ID4gPiA+ID4gUmVmZXJlbmNlOiBbIFJGQy10by1i ZSBdDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBRdWVzdGlvbjogd2hpY2ggcmFuZ2Ugb3IgcmFuZ2Vz IGluIHRoZSBTVFVOIEF0dHJpYnV0ZXMgcmVnaXN0cnkNCj4gPiA+ID4gPiB0aGUgYWJvdmUgdHdv IG5ldw0KPiA+ID4gPiA+IGF0dHJpYnV0ZXMgc2hvdWxkIGJlIHJlZ2lzdGVyZWQ/ICAgVGhlIHJl Z2lzdHJ5IGRlZmluZXMgdGhlDQo+ID4gPiA+ID4gZm9sbG93aW5nDQo+ID4gPiA+ID4gcmFuZ2Vz Og0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmFuZ2UgICAgICAgICBSZWdpc3RyYXRpb24gUHJvY2Vk dXJlcyAgICAgICAgIE5vdGUNCj4gPiA+ID4gPiAweDAwMDAtMHgzRkZGIElFVEYgUmV2aWV3ICAg ICBjb21wcmVoZW5zaW9uLXJlcXVpcmVkIHJhbmdlDQo+ID4gPiA+ID4gMHg0MDAwLTB4N0ZGRiBE ZXNpZ25hdGVkIEV4cGVydCAgICAgICBjb21wcmVoZW5zaW9uLXJlcXVpcmVkDQo+ID4gPiA+ID4g cmFuZ2UNCj4gPiA+ID4gPiAweDgwMDAtMHhCRkZGIElFVEYgUmV2aWV3ICAgICBjb21wcmVoZW5z aW9uLW9wdGlvbmFsIHJhbmdlDQo+ID4gPiA+ID4gMHhDMDAwLTB4RkZGRiBEZXNpZ25hdGVkIEV4 cGVydCAgICAgICBjb21wcmVoZW5zaW9uLW9wdGlvbmFsDQo+ID4gPiA+ID4gcmFuZ2UNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEl0IGFwcGVhcnMgdGhhdCBzZWN0aW9uIDYgZGVmaW5lcyB0aGUgbmV3 IGF0dHJpYnV0ZXMgdG8gYmUgaW4NCj4gPiA+ID4gPiB0d28gZGlmZmVyZW50IHJhbmdlcywgY29t cHJlaGVuc2lvbi1vcHRpb25hbCBhbmQgY29tcHJlaGVuc2lvbi0NCj4gPiA+ID4gPiByZXF1aXJl ZC4NCj4gPiA+ID4gPiBJcyB0aGF0DQo+ID4gPiA+ID4gICBjb3JyZWN0Pw0KPiA+ID4gPg0KPiA+ ID4gPiBZZXMuDQo+ID4gPiA+DQo+ID4gPiA+ID4gSWYgc28sIHBsZWFzZSBlaXRoZXIgYWRkIHRo ZSByYW5nZXMgaW4gdGhlIElDIHNlY3Rpb24gb3IgYWRkIGENCj4gPiA+ID4gPiBwb2ludGVyIHRv IHNlY3Rpb24gNiBpbiB0aGUgSUMgc2VjdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4gTkVXIChJQyBz ZWN0aW9uKToNCj4gPiA+ID4NCj4gPiA+ID4gW1BhcmFncmFwaHMgYmVsb3cgaW4gYnJhY2VzIHNo b3VsZCBiZSByZW1vdmVkIGJ5IHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+IHVwb24gcHVibGljYXRp b25dDQo+ID4gPiA+DQo+ID4gPiA+IFtUaGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiBhdHRy aWJ1dGUgcmVxdWlyZXMgdGhhdCBJQU5BDQo+ID4gPiA+IGFsbG9jYXRlIGEgdmFsdWUgaW4gdGhl ICJTVFVOIGF0dHJpYnV0ZXMgUmVnaXN0cnkiIGZyb20gdGhlDQo+ID4gPiA+IGNvbXByZWhlbnNp b24tb3B0aW9uYWwgcmFuZ2UgKDB4ODAwMC0weEZGRkYpXQ0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+ IEFzIGRlc2NyaWJlZCBhYm92ZSwgdGhlIHJhbmdlIDB4ODAwMC0weEZGRkYgaGFzIHR3byBkaWZm ZXJlbnQNCj4gPiA+IHJlZ2lzdHJhdGlvbg0KPiA+ID4gcnVsZXMgYXMgZGVmaW5lZCBieSBSRkM1 Mzg5LiAgV2hpY2ggb25lIG9mIHRoZSBmb2xsb3dpbmcgdGhlIG5ldyBTVFVODQo+ID4gPiBhdHRy aWJ1dGUgc2hvdWxkIGJlIHJlZ2lzdGVyZWQ6DQo+ID4gPg0KPiA+ID4gMHg4MDAwLTB4QkZGRiBJ RVRGIFJldmlldyAgICAgY29tcHJlaGVuc2lvbi1vcHRpb25hbCByYW5nZQ0KPiA+ID4gMHhDMDAw LTB4RkZGRiBEZXNpZ25hdGVkIEV4cGVydCAgICAgICBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIHJh bmdlDQo+ID4gPg0KPiA+ID4gPw0KPiA+ID4NCj4gPiA+IFNob3VsZCBpdCBiZSBpbiAweDgwMDAt MHhCRkZGPw0KPiA+DQo+ID4gWWVzLCB1cGRhdGVkIElDIHNlY3Rpb24gYW5kIHB1Ymxpc2hlZCBy ZXZpc2lvbiB0byBhZGRyZXNzIHRoZSBjb21tZW50Lg0KPiA+DQo+IA0KPiBHcmVhdC4gIFRoZW4g SUVURiBSZXZpZXcgYXBwbGllcy4gIFBsZWFzZSB1cGRhdGUgdGhlIElDIHNlY3Rpb24gaW4gdGhl IG5leHQNCj4gdmVyc2lvbg0KPiB0byBpbmNsdWRlIHRoZSB0ZXh0cyB3ZSBkaXNjdXNzZWQuDQoN ClJldmlzaW9uIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVy bi10aGlyZC1wYXJ0eS1hdXRoei0wOCBpbmNsdWRlcyB0aGUgdGV4dCBkaXNjdXNzZWQuDQoNCkNo ZWVycywNCi1UaXJ1DQoNCj4gDQo+IFRoYW5rcywNCj4gfnBsDQo+IA0KPiANCj4gPiBUaGFua3Ms DQo+ID4gLVRpcnUNCj4gPg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+IH5wbA0KPiA+ID4N Cj4gPiA+DQo+ID4gPiA+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgVEhJUkQtUEFSVFktQVVU SE9SSVpBVElPTiBTVFVODQo+IGF0dHJpYnV0ZSwNCj4gPiA+ID4gZGVzY3JpYmVkIGluIFNlY3Rp b24gNi4gIElBTkEgaGFzIGFsbG9jYXRlZCB0aGUgY29tcHJlaGVuc2lvbi0NCj4gPiA+ID4gb3B0 aW9uYWwNCj4gPiA+ID4gY29kZXBvaW50IFRCRCBmb3IgdGhpcyBhdHRyaWJ1dGUuDQo+ID4gPiA+ DQo+ID4gPiA+IFtUaGUgQUNDRVNTLVRPS0VOIGF0dHJpYnV0ZSByZXF1aXJlcyB0aGF0IElBTkEg YWxsb2NhdGUgYSB2YWx1ZSBpbg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gIlNUVU4gYXR0cmlidXRl cyBSZWdpc3RyeSIgZnJvbSB0aGUgY29tcHJlaGVuc2lvbi1yZXF1aXJlZCByYW5nZQ0KPiA+ID4g PiAoMHgwMDAwLTB4M0ZGRildDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgZG9jdW1lbnQgZGVmaW5l cyB0aGUgQUNDRVNTLVRPS0VOIFNUVU4gYXR0cmlidXRlLCBkZXNjcmliZWQgaW4NCj4gPiA+ID4g U2VjdGlvbiA2LiAgSUFOQSBoYXMgYWxsb2NhdGVkIHRoZSBjb21wcmVoZW5zaW9uLXJlcXVpcmVk IGNvZGVwb2ludA0KPiA+ID4gPiBUQkQgZm9yIHRoaXMgYXR0cmlidXRlLg0KPiA+ID4gPg0KPiA+ ID4gPiAtVGlydQ0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRnVydGhlciwgaWYgYSBu ZXcgYXR0cmlidXRlIGlzIGluIHRoZSBjb21wcmVoZW5zaW9uLW9wdGlvbmFsDQo+ID4gPiA+ID4g cmFuZ2UsDQo+ID4gPiA+ID4gdGhlIGF1dGhvcnMgbmVlZCB0byBkZWZpbmUgd2hpY2ggb2YgdGhl IGNvbXByZWhlbnNpb24tb3B0aW9uYWwNCj4gPiA+ID4gPiByYW5nZXMsIDB4ODAwMC0weEJGRkYg b3IgMHhDMDAwLTB4RkZGRiwgdGhlIG5ldyBhdHRyaWJ1dGUgc2hvdWxkDQo+ID4gPiA+ID4gYmUN Cj4gPiA+ID4gPiByZWdpc3RlcmVkLg0KPiA+ID4gPiA+IFNvLCBpZiB0aGUgYXV0aG9ycyBwaWNr ICIweDgwMDAtMHhCRkZGIiBvZiB0aGUNCj4gPiA+ID4gPiBjb21wcmVoZW5zaW9uLW9wdGlvbmFs IHJhbmdlLCBJRVRGIFJldmlldyByZWdpc3RyYXRpb24gcnVsZSB3aWxsDQo+ID4gPiA+ID4gYmUN Cj4gPiA+ID4gPiB1c2VkLiAgVGhlIElDIHNlY3Rpb24gaGFzIG5vIGNsZWFyIHRleHRzIGFib3V0 IHRoZXNlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJQU5BIHVuZGVyc3RhbmRz IHRoYXQgdGhpcyBpcyB0aGUgb25seSBhY3Rpb24gdGhhdCBuZWVkcyB0byBiZQ0KPiA+ID4gPiA+ IGNvbXBsZXRlZCB1cG9uIGFwcHJvdmFsIG9mIHRoaXMgZG9jdW1lbnQuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBOb3RlOiAgVGhlIGFjdGlvbnMgcmVxdWVzdGVkIGluIHRoaXMgZG9jdW1lbnQgd2ls bCBub3QgYmUNCj4gPiA+ID4gPiBjb21wbGV0ZWQNCj4gPiA+ID4gPiB1bnRpbCB0aGUgZG9jdW1l bnQgaGFzIGJlZW4gYXBwcm92ZWQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQy4NCj4gPiA+ID4g PiBUaGlzDQo+ID4gPiA+ID4gbWVzc2FnZSBpcyBvbmx5IHRvIGNvbmZpcm0gd2hhdCBhY3Rpb25z IHdpbGwgYmUgcGVyZm9ybWVkLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGFu a3MsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBQZWFybCBMaWFuZw0KPiA+ID4gPiA+IElDQU5ODQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiAoRU5EIElBTkEgTEFTVCBDQUxMIENPTU1FTlRTKQ0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gT24gV2VkIEphbiAyMSAyMDowMzozMyAyMDE1LCBpZXNnLXNlY3JldGFy eUBpZXRmLm9yZyB3cm90ZToNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGUgSUVTRyBoYXMg cmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFRVUk4gUmV2aXNlZCBhbmQNCj4gPiA+ID4gPiA+ IE1vZGVybml6ZWQgV0cNCj4gPiA+ID4gPiA+ICh0cmFtKSB0byBjb25zaWRlciB0aGUgZm9sbG93 aW5nIGRvY3VtZW50Og0KPiA+ID4gPiA+ID4gLSAnU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVz IGZvciBOQVQgKFNUVU4pIEV4dGVuc2lvbiBmb3INCj4gPiA+ID4gPiA+IFRoaXJkDQo+ID4gPiA+ ID4gPiBQYXJ0eQ0KPiA+ID4gPiA+ID4gICAgQXV0aG9yaXphdGlvbicNCj4gPiA+ID4gPiA+ICAg PGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTA3LnR4dD4gYXMgUHJvcG9z ZWQNCj4gPiA+ID4gPiA+IFN0YW5kYXJkDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhlIElF U0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kDQo+ ID4gPiA+ID4gPiBzb2xpY2l0cyBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNl IHNlbmQgc3Vic3RhbnRpdmUNCj4gPiA+ID4gPiA+IGNvbW1lbnRzIHRvIHRoZSBpZXRmQGlldGYu b3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxNS0wMi0wNC4NCj4gPiA+ID4gPiA+IEV4Y2VwdGlvbmFs bHksIGNvbW1lbnRzIG1heSBiZSBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4NCj4gPiA+ ID4gPiA+IEluDQo+ID4gPiA+ID4gPiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUgYmVn aW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8NCj4gPiA+ID4gPiA+IGFsbG93IGF1dG9tYXRl ZCBzb3J0aW5nLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEFic3RyYWN0DQo+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVz ZSBvZiBPQXV0aCB0byBvYnRhaW4gYW5kIHZhbGlkYXRlDQo+ID4gPiA+ID4gPiBlcGhlbWVyYWwg dG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFNlc3Npb24gVHJhdmVyc2FsDQo+ID4gPiA+ID4g PiBVdGlsaXRpZXMNCj4gPiA+ID4gPiA+IGZvciBOQVQgKFNUVU4pIGF1dGhlbnRpY2F0aW9uLiAg VGhlIHVzYWdlIG9mIGVwaGVtZXJhbCB0b2tlbnMNCj4gPiA+ID4gPiA+IGVuc3VyZSB0aGF0IGFj Y2VzcyB0byBhIFNUVU4gc2VydmVyIGNhbiBiZSBjb250cm9sbGVkIGV2ZW4gaWYNCj4gPiA+ID4g PiA+IHRoZQ0KPiA+ID4gPiA+ID4gdG9rZW5zIGFyZSBjb21wcm9taXNlZC4NCj4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGUg ZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+ID4gPiA+ID4gPiBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLQ0KPiA+ID4gPiA+ID4gcGFy dHktDQo+ID4gPiA+ID4gPiBhdXRoei8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJRVNHIGRp c2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+ID4gPiA+ID4gPiBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLQ0KPiA+ID4gPiA+ID4g cGFydHktDQo+ID4gPiA+ID4gPiBhdXRoei9iYWxsb3QvDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBk aXJlY3RseSBvbiB0aGlzIEktRC4NCj4gPiA+ID4NCj4gPiA+DQo+ID4NCj4gDQo+IA0KDQo= From nobody Thu Jan 29 12:22:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522B51A701C for ; Thu, 29 Jan 2015 12:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 YAkqESAccut6 for ; Thu, 29 Jan 2015 12:22:44 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0A11A01A9 for ; Thu, 29 Jan 2015 12:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7358; q=dns/txt; s=iport; t=1422562965; x=1423772565; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=a3Os1S7O1y0G15KCx9udDoYrq441M5kBeX74xyw96oE=; b=ma1aJT8+W/dKRlmcMJE8OyhDnWT7xvMlmoTXMv+A9n/jbIsL5k9SOawh Ct79tLMFkFHzKsK1kDb4SAlBW73Zwu2fV+UjVuGsmmB8PrTy505oq3F9G nqCosEGOEC6xBniYslI4WePJQ5KLRaVCIwOfS3bzG7Bs92H21XoumS+Cs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAMqVylStJV2Q/2dsb2JhbABagwZSWQSCfb86giWFcQIcgQlDAQEBAQF9hA0CBDRXAQgcKAQwJQIEARIbiBENpGScZAaVewEBAQEBAQQBAQEBAQEBARqBG45kgmKBRwWOfINLgg2DSoEXNoJLjjkiggEdgVBvgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,487,1418083200"; d="scan'208";a="388761729" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jan 2015 20:22:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0TKMhwP021147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 20:22:43 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.100]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 14:22:42 -0600 From: "Prashanth Patil (praspati)" To: tshields , "Tirumaleswar Reddy (tireddy)" , "Dan Wing (dwing)" , "tram@ietf.org" Thread-Topic: Review of draft-ietf-tram-turn-server-discovery-01 Thread-Index: AQHQOa7Z1VAkRuNPJkO18InGF1QwiJzXbceA Date: Thu, 29 Jan 2015 20:22:42 +0000 Message-ID: In-Reply-To: <54C6B12E.6030403@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.209.70] Content-Type: text/plain; charset="euc-kr" Content-ID: <720341D5706E954B9E695A7509E911B9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Review of draft-ietf-tram-turn-server-discovery-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 20:22:52 -0000 SGkgVG9yeSwNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gSW5saW5loaYNCg0KT24gMS8yNi8xNSwg MToyNyBQTSwgInRzaGllbGRzIiA8dHNoaWVsZHNAaml2ZS5jb20+IHdyb3RlOg0KDQo+LS0tLS1C RUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KPkhhc2g6IFNIQTUxMg0KPg0KPk92ZXJ2aWV3 DQo+DQo+T3ZlcmFsbCB0aGlzIGRyYWZ0IHdhcyB2ZXJ5IGNsZWFyIGFuZCBzdHJhaWdodC1mb3J3 YXJkLiBUaGVyZSB3YXMgb25lDQo+bW9yZSBpbXBvcnRhbnQgcXVlc3Rpb24gdGhhdCBqdW1wZWQg b3V0IGF0IG1lIGFzIEkgd2FzIHJldmlld2luZzsgaXQNCj53YXMgc29tZXdoYXQgdW5jbGVhciB0 byBtZSB3aGV0aGVyIG9yIG5vdCBib3RoIG1lY2hhbmlzbXMgZm9yIFRVUk4NCj5zZXJ2ZXIgZGlz Y292ZXJ5IGFyZSByZWFsbHkgcmVxdWlyZWQsIHdoaWNoIG9uZSBpcyBwcmVmZXJlZCwgYW5kIHdo eS4NCj4NCj4NCj5NYWpvciBJc3N1ZXMvUXVlc3Rpb25zOg0KPg0KPlNlY3Rpb24gMSwgUGFyYWdy YXBoIDINCj4NCj4+IFRoZSByZWFzb24gZm9yIHByb3ZpZGluZyB0d28gbWVjaGFuaXNtcyBpcyB0 byBtYXhpbWl6ZSB0aGUNCj4+IG9wcG9ydHVuaXR5IGZvciBkaXNjb3ZlcnksIGJhc2VkIG9uIHRo ZSBuZXR3b3JrIGluIHRoZSB3aGljaCB0aGUNCj4+IFRVUk4gY2xpZW50IHNlZXMgaXRzZWxmLg0K Pg0KPlNvIHdvdWxkIHNvbWVvbmUgaW1wbGVtZW50aW5nIHRoaXMgdXNlIGJvdGggbWVjaGFuaXNt cyBpbiBvcmRlciB0bw0KPm1heGltaXplIHRoZSBvcHBvcnR1bml0eSBmb3IgZGlzY292ZXJ5LCBv ciB3b3VsZCB0aGV5IGNob29zZSB0aGUgb25lDQo+dGhhdCBtYWtlcyBzZW5zZSBmb3IgdGhlbT8g QW0gSSBicmVha2luZyB0aGUgc3RhbmRhcmQgaWYgSSBqdXN0DQo+aW1wbGVtZW50IG9uZT8gSSB0 aGluayB0aGUgd29yZGluZyBoZXJlIGNvdWxkIGJlIGEgbGl0dGxlIG1vcmUNCj5leHBsaWNpdC4g SWYgSSBNVVNUIGltcGxlbWVudCBib3RoIG1lY2hhbmlzbXMgdGhlbiB0aGUgZG9jdW1lbnQgc2hv dWxkDQo+bWFrZSB0aGF0IGNsZWFyLg0KPg0KPlNlY3Rpb24gMywgUGFyYWdyYXBoIDEgZG9lcyBz cGVjaWZ5IHRoYXQgdGhlIGF1dG8gZGlzY292ZXJ5IGFsZ29yaXRobQ0KPk1VU1QgdHJ5IHNlcnZp Y2UgcmVzb2x1dGlvbiBmaXJzdCBhbmQgdGhlbiBBbnljYXN0IChzdGVwcyAyICYgMykuIFNvDQo+ YXQgdGhpcyBwb2ludCBpdCBiZWNvbWVzIGNsZWFyIHRoYXQgYm90aCBtZWNoYW5pc21zIG11c3Qg YmUgaW1wbGVtZW50ZWQuDQo+DQo+SG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgKGJhc2VkIG9uIHRo ZSBkb2N1bWVudCkgdGhhdCBEaXNjb3ZlcnkgdXNpbmcNCj5BbnljYXN0IGlzIGEgbXVjaCBzaW1w bGVyLCBtb3JlICJlbGVnYW50IiBzb2x1dGlvbi4gRG9lcyB0aGUgZG9jdW1lbnQNCj5yZWFsbHkg Y2FyZSB0aGF0IEkgdHJ5IHRvIHVzZSBEaXNjb3ZlcnkgVXNpbmcgU2VydmljZSBSZXNvbHV0aW9u DQo+Zmlyc3QsIG9yIG1heSBJIGNob29zZSB0aGUgb3JkZXIgdGhhdCBtYWtlcyBzZW5zZSB0byBt ZSBhcyBhbg0KPmltcGxlbWVudGVyPyBJZiBpdCBkb2VzIGNhcmUsIEkgdGhpbmsgdGhlIHJlYXNv biBzaG91bGQgYmUgc3RhdGVkIGluDQo+UGFyYWdyYXBoIDEgb2YgU2VjdGlvbiAzIChvciBzb21l d2hlcmUgZWxzZSB0aGF0IG1ha2VzIHNlbnNlKS4NCg0KDQpCb3RoIG1lY2hhbmlzbXMgTVVTVCBi ZSBpbXBsZW1lbnRlZC4gTm90IGFsbCBUVVJOIHNlcnZlcnMgbWF5IGJlDQpkaXNjb3ZlcmVkIHVz aW5nIERIQ1AvTkFQVFIgcmVjb3JkczsgU2ltaWxhcmx5LCBub3QgYWxsIFRVUk4gc2VydmVycyBt YXkNCnN1cHBvcnQgYW55Y2FzdC4gRm9yIGJlc3QgcmVzdWx0cywgdGhlIGNsaWVudCBNVVNUIGlt cGxlbWVudCBib3RoLiBXZan2bGwNCm1ha2UgdGhpcyBhIE1VU1QgaW4gdGhlIG5leHQgcmV2aXNp b24uDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgaXMgbm90IG1hbmRhdG9yeSB0byBzd2l0Y2ggdG8g RGlzY292ZXJ5IHVzaW5nIEFueWNhc3QNCm9ubHkgYWZ0ZXIgZGlzY292ZXJ5IHVzaW5nIFNlcnZp Y2UgcmVzb2x1dGlvbi4gQm90aCBtZWNoYW5pc21zIGNhbiBiZQ0KcGVyZm9ybWVkIGluIHBhcmFs bGVsLg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0IHlvdSBlbmQgdXAgZGlzY292ZXJpbmcgbW9yZSB0 aGFuIG9uZSBUVVJOIHNlcnZlcnMsIGluDQp3aGljaCBjYXNlIHdlqfZyZSBwcm9wb3NpbmcNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxl Y3Rpb24tMDAgdGhhdA0KcHJvdmlkZXMgZ3VpZGVsaW5lcyB0aGF0IGEgY2xpZW50IGNhbiBmb2xs b3cgdG8gcGljayBhbiBhcHByb3ByaWF0ZSBUVVJODQpzZXJ2ZXIuDQoNCg0KPg0KPg0KPlNlY3Rp b24gNC4yLjEsIFBhcmFncmFwaCAzDQo+DQo+PiBJZiB0aGlzIGxvb2t1cCBmYWlscywgdGhlIGRp c2NvdmVyeSBwcm9jZWR1cmUgaXMgYWJvcnRlZCB3aXRob3V0IGENCj4+IHJlc3VsdC4NCj4NCj5J ZiB0aGlzIGxvb2t1cCBmYWlscyB0aGVuIHdlIGdpdmUgdXAgZW50aXJlbHkgd2l0aCBkaWNvdmVy aW5nIGEgVFVSTg0KPnNlcnZlciwgb3IganVzdCBmb3IgdGhpcyBkb21haW4vaW50ZXJmYWNlL2Fk ZHJlc3MgZmFtaWx5IGNvbWJpbmF0aW9uPw0KPkRvIHdlIG1vdmUgb24gdG8gRGlzY292ZXJ5IHVz aW5nIEFueWNhc3QgYXQgdGhpcyBwb2ludD8gU2hvdWxkIGJlIG1hZGUNCj5tb3JlIGNsZWFyLg0K DQpMb29rdXAgZmFpbHMgb25seSBmb3IgdGhhdCBwYXJ0aWN1bGFyIGRvbWFpbi9pbnRlcmZhY2Uv YWRkcmVzcw0KY29tYmluYXRpb24uIFRoZSBjbGllbnQgc2hvdWxkIG1vdmUgb24gdG8gdHJ5IG90 aGVyIGNvbWJpbmF0aW9ucy4NCg0KDQo+DQo+DQo+TWlub3IgSXNzdWVzL1F1ZXN0aW9uczoNCj4N Cj5TZWN0aW9uIDQsIFBhcmFncmFwaCA0DQo+DQo+PiBPbiBob3N0cyB3aXRoIG1vcmUgdGhhbiBv bmUgaW50ZXJmYWNlIG9yIGFkZHJlc3MgZmFtaWx5IChJUHY0L3Y2KSwNCj4+IHRoZSBUVVJOIHNl cnZlciBkaXNjb3ZlcnkgcHJvY2VkdXJlIGhhcyB0byBiZSBydW4gZm9yIGVhY2gNCj4+IGNvbWJp bmF0aW9uIG9mIGludGVyZmFjZSBhbmQgYWRkcmVzcyBmYW1pbHkuDQo+DQo+T3V0IG9mIGN1cmlv c2l0eSwgd2hhdCBpcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgaW50ZXJmYWNlcyBhbmQgYWRkcmVz cw0KPmZhbWlsaWVzIHRoYXQgY291bGQgYmUgZXhwZWN0ZWQ/IElzIHRoZXJlIGFueSBjb25jZXJu IHRoYXQgY2hlY2tpbmcNCj5ldmVyeSBjb21iaW5hdGlvbiBvZiBpbnRlcmZhY2UgYW5kIGFkZHJl c3MgZmFtaWx5IGNvdWxkIGJlIHRvbw0KPmV4cGVuc2l2ZSBvZiBhIHRhc2s/IE15IGd1dCB0ZWxs cyBtZSBpdCdzIG5vdCBhIHByb2JsZW0gYnV0IEkgdGhvdWdodA0KPkkgd291bGQgYXQgbGVhc3Qg YXNrIHRoZSBxdWVzdGlvbi4NCg0KWW91IGNvdWxkIGhhdmUgdHdvIGFkZHJlc3MgZmFtaWxpZXMg cGVyIGludGVyZmFjZS4gSSBkb26p9nQgZXhwZWN0IHRoZQ0KbnVtYmVyIG9mIGFkZHJlc3NlcyB0 byBiZSB0b28gbWFueSB0byBiZSBhIGNhdXNlIGZvciBjb25jZXJuLg0KDQpJIHN1cHBvc2Ugd2Ug Y291bGQgc3VnZ2VzdCB0aGF0IGEgY2xpZW50IGNvdWxkIGNob29zZSB0byBkaXNjb3ZlciBhIFRV Uk4NCnNlcnZlciBvbmx5IGZvciB0aGUgZGVzaXJlZCBpbnRlcmZhY2UvYWRkcmVzcyBjb21iaW5h dGlvbiwgYnV0IGl0IHNlZW1zDQpsaWtlIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4NCg0KDQo+ DQo+DQo+Tml0czoNCj4NCj5TZWN0aW9uIDMsIFBhcmFncmFwaCAzDQo+DQo+PiBTZXJ2aWNlIFJl c29sdXRpb24gOiBUaGUgVFVSTiBjbGllbnQgYXR0ZW1wdHMgdG8gcGVyZm9ybSBUVVJODQo+PiBz ZXJ2aWNlIHJlc29sdXRpb24gdXNpbmcgdGhlIEROUyBkb21haW4gbmFtZSB0aGF0IHRoZSBob3N0 IGJlbG9uZ3MNCj4+IHRvIE9SIHRoZSBob3N0cycgZ2xvYmFsIElQIGFkZHJlc3MuDQo+DQo+SXMg aXQgcmVhbGx5IG11bHRpcGxlIGhvc3RzICgiaG9zdHMnIikgb3IgYSBpcyBpdCBhIHNpbmdsZSBo b3N0DQo+KCJob3N0J3MiKS4gQWxzbywgaW0gbXkgb3BpbmlvbiwgdGhlIHNlbnRlbmNlIGNhbiBi ZSBhbHRlcmVkIHRvIG1ha2UNCj5pdCBzbGlnaHRseSBtb3JlIHJlYWRhYmxlOg0KPg0KPiJTZXJ2 aWNlIFJlc29sdXRpb24gOiBUaGUgVFVSTiBjbGllbnQgYXR0ZW1wdHMgdG8gcGVyZm9ybSBUVVJO IHNlcnZpY2UNCj5yZXNvbHV0aW9uIHVzaW5nIHRoZSBob3N0J3MgRE5TIGRvbWFpbiBPUiB0aGUg aG9zdCdzIGdsb2JhbCBJUCBhZGRyZXNzLiINCg0KVGhhbmtzLCB3aWxsIGRvLg0KDQotUHJhc2hh bnRoDQoNCj4NCj4NCj4tIC0tIA0KPlRyb3kgU2hpZWxkcw0KPkRldmVsb3BlciBvZiBBd2Vzb21l IHwgSml2ZSBDb21tdW5pY2F0aW9ucywgSW5jLg0KPkppdmUuY29tIHwgdHNoaWVsZHNAaml2ZS5j b20NCj4NCj4NCj4tLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KPlZlcnNpb246IEdudVBH L01hY0dQRzIgdjIuMC4yMiAoRGFyd2luKQ0KPkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6Ly9n cGd0b29scy5vcmcNCj4NCj5pUUljQkFFQkNnQUdCUUpVeHJFdEFBb0pFUHBIQnZ2UGFYbFFQZThQ L1JqNHFqMTlqUVJpZWZ6aWJRNkVZWHFjDQo+MjlPV0JoSWtzMVlDZFFodXkzSklFTUw4OTVIWnJ3 MXBDSkVLUTZ5Y2tpeEw5TmYwekJDRVpDZTJIUGVqeFNnTw0KPnBnZVo2eTd4ellUQ09HbTIrS01C MEl4dDltZE9QZ2xScFlzQnFaYUNlZGlDejFWYnFVOHZSWlhweTdkY0ZwekUNCj5wcHpyY1loTjV1 NzFCNmFwTitqRUM5YTFGbzlKMDlqV2xzU0Y0Y0ZIWGQyWlVCYmU3THFtZWlZOEI5MjkyY0Z0DQo+ UmVUVmk4bHRZNFJiTGtvZWtjdWM4OHBoWldJRFBiRzI3SVYvczVCWkNlY0xOWnBnYXJNSTRvdGJu bkQ1TVg5eA0KPkNHQ1pBQ3RUUGtXcEd6ck4xRVJsbEIvNkJHdGd0K2U1MkV5bVloMnVsY2hDWUV3 L3laZlFYSGU1OFVUY2M5bzANCj5ZQ1hUSGppWjdKNTdPSDlFR2NaMFZmTEU5VnVtYVdJWWNpd2Ro Y1g3NTl5R0hBWjFtUm1wU3BUY1hyNTRTYTA5DQo+QzRiczh3ME1RNk02MmVKNHBIbk5MKzdKd1pP Z0hRVmkzbGVWaEltcVpHQWtNK29ZZnh5OG9TT0V0RFUvU1UraA0KPm5kejN2YlhWUzgzVWZOczR3 djV0UDlVcGpqTkZzQjBCMHFxZURacGtoNXBXRWRoSnhPSjNuRXArRTZQeUp1aHMNCj5zWEZscGxZ Mko5NjM3N3ZBMWlROVRldmFvUkhESzl4dm1JQTMyeXF4dWQya1h5ZjJjSlBTT1hMdVRZNHlZKzFC DQo+RmdKeFcrTEdKK1RpbE9YQWU5N0RweG1lcThEbUFNY3BKQXZoU2NzSTczc2x6TWtKN3hWWVFI UGN1a0Z2L0NXbw0KPmppREdKbHEvWVJxUm9mVzQyZmhrDQo+PXZHYmMNCj4tLS0tLUVORCBQR1Ag U0lHTkFUVVJFLS0tLS0NCg0K From nobody Thu Jan 29 21:18:29 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3D1A8961; Thu, 29 Jan 2015 21:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham 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 eD4iQWdRYv3u; Thu, 29 Jan 2015 21:18:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3511A00F1; Thu, 29 Jan 2015 21:18:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 21:18:24 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 05:18:26 -0000 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 Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-01.txt Pages : 77 Date : 2015-01-29 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01 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/ From nobody Thu Jan 29 21:39:43 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DA61A1B67 for ; Thu, 29 Jan 2015 21:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 U_N75JqQgtFS for ; Thu, 29 Jan 2015 21:39:39 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BE11A00F1 for ; Thu, 29 Jan 2015 21:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2847; q=dns/txt; s=iport; t=1422596379; x=1423805979; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+oXL/zlDziUwvZ1MuQ4bOrz+CpLxVfF4LZ7CaHCsUPo=; b=K2zOC1XM0x/4BZ9uWtp8BCfaAyVcQDhTZ/iyrnPhJO75ArV4WolQSQdh QdB5zYnzH4pMKXvbt29szvSb5ac+QFWcuEh/6DT+EDA5rzvBnaYJK6J2x uuGpWSg6sJ3r9Rmi6HPQgU2V81slBLRphBZZzOW1Vb0K+kHRUKMkyVzxb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAIQYy1StJA2M/2dsb2JhbABagwZSVAUEwj+CGwyFbwKBHUMBAQEBAX2EDAEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEEwgBiCMIBdY3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF49HOAaDEIETBY58g0uGbjaCS4p8gz0ig25vAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,490,1418083200"; d="scan'208";a="391993766" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jan 2015 05:39:38 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0U5dc29003487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 30 Jan 2015 05:39:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 23:39:37 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdg Date: Fri, 30 Jan 2015 05:39:37 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> In-Reply-To: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.76.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 05:39:41 -0000 Major changes in this revision are support for SSODA and merged RFC6156. Pl= ease review and provide your valuable comments.=20 Diff from previous version : http://tools.ietf.org/rfcdiff?difftype=3D--hwd= iff&url2=3Ddraft-ietf-tram-turnbis-01.txt=20 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, January 30, 2015 10:48 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-01.txt > Pages : 77 > Date : 2015-01-29 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sat Jan 31 15:10:08 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68AA1A0196 for ; Sat, 31 Jan 2015 15:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 Ytw219zIdZ9w for ; Sat, 31 Jan 2015 15:10:03 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435C21A0195 for ; Sat, 31 Jan 2015 15:10:03 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so32924280wes.7 for ; Sat, 31 Jan 2015 15:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ytWvBZ+PtVgjvILkRuuOCpvu0foKzIn/SE6Ir+AnhcA=; b=xMvuOTw0XnUzV3a7g5mnn6WqtbazHjPO8yeM87m5F3De66x3v0GrgZGnKjOyeJHNFO cFKtIW8wmXgKbx/KmAOUS9wOuDcwPvIyLOJw0D1FlK/6kKzu7CSg0ZwgpmgEqYPqiD23 aEU+xju22PHbeAo4JXpddNwdYjwCQVpZj2jSjvVZig6dDUoOXzg/lTFnp2360m5YTUKJ Dac3VPnWhgSwsEs+PK3zdekzTQjpIMAV68yavlcOysd0EDRW3e0Z7u+TorQpcdEwrGVC tXLHqc+ajZLSLMKFtE61bfq0Dt006KE+GVNNrty5mOKbjwURqHTdY+tF4jdl2WG28Cjf +Mrg== MIME-Version: 1.0 X-Received: by 10.194.2.240 with SMTP id 16mr28074987wjx.108.1422745801772; Sat, 31 Jan 2015 15:10:01 -0800 (PST) Received: by 10.194.87.98 with HTTP; Sat, 31 Jan 2015 15:10:01 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> Date: Sat, 31 Jan 2015 15:10:01 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b343d841ed4bf050dfad2d4 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 23:10:06 -0000 --047d7b343d841ed4bf050dfad2d4 Content-Type: text/plain; charset=UTF-8 Hi Tiru as the turnbis written, in its current form, it allows EVEN-PORT attribute in the ALLOCATE request together with the ADDITIONAL-ADDRESS-FAMILY attribute. If this is really what you want, then the RESERVATION-TOKEN handling must be changed in the ALLOCATE response - because there will be two RESERVATION-TOKEN attributes included into the response (when EVEN-PORT=1). Or the EVEN-PORT must be prohibited in the same request with ADDITIONAL-ADDRESS-FAMILY. As of now, there is inherent inconsistency. Thanks Oleg On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Major changes in this revision are support for SSODA and merged RFC6156. > Please review and provide your valuable comments. > Diff from previous version : > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tram-turnbis-01.txt > > -Tiru > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Friday, January 30, 2015 10:48 AM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.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 Working > > Group of the IETF. > > > > Title : Traversal Using Relays around NAT (TURN): > Relay Extensions > > to Session Traversal Utilities for NAT (STUN) > > Authors : Tirumaleswar Reddy > > Alan Johnston > > Philip Matthews > > Jonathan Rosenberg > > Filename : draft-ietf-tram-turnbis-01.txt > > Pages : 77 > > Date : 2015-01-29 > > > > Abstract: > > If a host is located behind a NAT, then in certain situations it can > > be impossible for that host to communicate directly with other hosts > > (peers). In these situations, it is necessary for the host to use > > the services of an intermediate node that acts as a communication > > relay. This specification defines a protocol, called TURN (Traversal > > Using Relays around NAT), that allows the host to control the > > operation of the relay and to exchange packets with its peers using > > the relay. TURN differs from some other relay control protocols in > > that it allows a client to communicate with multiple peers using a > > single relay address. > > > > The TURN protocol was designed to be used as part of the ICE > > (Interactive Connectivity Establishment) approach to NAT traversal, > > though it also can be used without ICE. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01 > > > > > > 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 > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b343d841ed4bf050dfad2d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tiru

as the turnbis written, in = its current form, it allows EVEN-PORT attribute in the ALLOCATE request tog= ether with the ADDITIONAL-ADDRESS-FAMILY attribute. If this is really what = you want, then the RESERVATION-TOKEN handling must be changed in the ALLOCA= TE response - because there will be two RESERVATION-TOKEN attributes includ= ed into the response (when EVEN-PORT=3D1).

Or the EVEN-PO= RT must be prohibited in the same request with ADDITIONAL-ADDRESS-FAMILY.

As of now, there is inherent inconsistency.=

Thanks
Oleg



On Thu, Jan 29, 2015 at = 9:39 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wr= ote:
Major changes in this revision are s= upport for SSODA and merged RFC6156. Please review and provide your valuabl= e comments.
Diff from previous version : http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tr= am-turnbis-01.txt

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, January 30, 2015 10:48 AM
> To: i-d-announce@ietf.org=
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the TURN Revised and Modernized Wor= king
> Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Traversal Using Relays around NAT (TURN): Relay Extensions
> to Session Traversal Utilities for NAT (STUN)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Tirumaleswar Reddy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Alan Johnston
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Philip Matthews
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jonathan Rosenberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turnbis-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 77
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-29
>
> Abstract:
>=C2=A0 =C2=A0 If a host is located behind a NAT, then in certain situat= ions it can
>=C2=A0 =C2=A0 be impossible for that host to communicate directly with = other hosts
>=C2=A0 =C2=A0 (peers).=C2=A0 In these situations, it is necessary for t= he host to use
>=C2=A0 =C2=A0 the services of an intermediate node that acts as a commu= nication
>=C2=A0 =C2=A0 relay.=C2=A0 This specification defines a protocol, calle= d TURN (Traversal
>=C2=A0 =C2=A0 Using Relays around NAT), that allows the host to control= the
>=C2=A0 =C2=A0 operation of the relay and to exchange packets with its p= eers using
>=C2=A0 =C2=A0 the relay.=C2=A0 TURN differs from some other relay contr= ol protocols in
>=C2=A0 =C2=A0 that it allows a client to communicate with multiple peer= s using a
>=C2=A0 =C2=A0 single relay address.
>
>=C2=A0 =C2=A0 The TURN protocol was designed to be used as part of the = ICE
>=C2=A0 =C2=A0 (Interactive Connectivity Establishment) approach to NAT = traversal,
>=C2=A0 =C2=A0 though it also can be used without ICE.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/=
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turnbis-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-tu= rnbis-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b343d841ed4bf050dfad2d4-- From nobody Sat Jan 31 18:36:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5991A702D for ; Sat, 31 Jan 2015 18:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QKGBpgM3r0Os for ; Sat, 31 Jan 2015 18:36:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723261A7028 for ; Sat, 31 Jan 2015 18:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18260; q=dns/txt; s=iport; t=1422758171; x=1423967771; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qttBFaQ5ZaKDoQodI39ENbuJ1VTK73pU4iVp6I3teQ0=; b=d9juMzQl8u1WGi3rhw9C2dAb+kviRsm1NdebFAc88oQfIT5HExu9HZJB X+arbgwsbwlsHWNf7bx//2ULd6LBK5rN4rwiDnCwE3yvw1wul7nIdXulU jmSGeWcniQOh6ch3xrMZqE63j5fR4gKtjcHek55JxmDWLDcPanYxNJ70k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6BwAPkM1U/5ldJa1bgkNDUlQFBIJ9v0k8gV8BC4VvAhx1QwEBAQEBfYQMAQEBBAEBASAKQQsMBAIBCA4DBAEBCx0DAgICHwYLFAkIAgQOBQgBiBADEQgFvQqPOA2FUAEBAQEBAQEBAQEBAQEBAQEBAQEBAReNToF5FhcEBgEGA4JfLoETBY8Jg06EEYJdNoJNiAg9gkCDPSKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,499,1418083200"; d="scan'208,217";a="119358356" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 01 Feb 2015 02:36:08 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t112a8Sl021791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Feb 2015 02:36:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 31 Jan 2015 20:36:08 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt Thread-Index: AQHQPEw30UXpKS+dFk6Udma1HT7B3pzYIAdggAMiCYD//9HbMA== Date: Sun, 1 Feb 2015 02:36:07 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.245] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3553506Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 02:36:14 -0000 --_000_913383AAA69FF945B8F946018B75898A3553506Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbV0NClNlbnQ6 IFN1bmRheSwgRmVicnVhcnkgMDEsIDIwMTUgNDo0MCBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1dIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dA0KDQpIaSBUaXJ1DQphcyB0aGUg dHVybmJpcyB3cml0dGVuLCBpbiBpdHMgY3VycmVudCBmb3JtLCBpdCBhbGxvd3MgRVZFTi1QT1JU IGF0dHJpYnV0ZSBpbiB0aGUgQUxMT0NBVEUgcmVxdWVzdCB0b2dldGhlciB3aXRoIHRoZSBBRERJ VElPTkFMLUFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZS4gSWYgdGhpcyBpcyByZWFsbHkgd2hhdCB5 b3Ugd2FudCwgdGhlbiB0aGUgUkVTRVJWQVRJT04tVE9LRU4gaGFuZGxpbmcgbXVzdCBiZSBjaGFu Z2VkIGluIHRoZSBBTExPQ0FURSByZXNwb25zZSAtIGJlY2F1c2UgdGhlcmUgd2lsbCBiZSB0d28g UkVTRVJWQVRJT04tVE9LRU4gYXR0cmlidXRlcyBpbmNsdWRlZCBpbnRvIHRoZSByZXNwb25zZSAo d2hlbiBFVkVOLVBPUlQ9MSkuDQpPciB0aGUgRVZFTi1QT1JUIG11c3QgYmUgcHJvaGliaXRlZCBp biB0aGUgc2FtZSByZXF1ZXN0IHdpdGggQURESVRJT05BTC1BRERSRVNTLUZBTUlMWS4NCkFzIG9m IG5vdywgdGhlcmUgaXMgaW5oZXJlbnQgaW5jb25zaXN0ZW5jeS4NCltUUl0gQWdyZWVkLCB3aWxs IHVwZGF0ZSB0aGUgZHJhZnQgdGhhdCBBQUYgbXVzdCBub3QgYmUgdXNlZCB3aXRoIGV2ZW4gcG9y dC4NCi1UaXJ1DQpUaGFua3MNCk9sZWcNCg0KDQpPbiBUaHUsIEphbiAyOSwgMjAxNSBhdCA5OjM5 IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWls dG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCk1ham9yIGNoYW5nZXMgaW4gdGhpcyByZXZp c2lvbiBhcmUgc3VwcG9ydCBmb3IgU1NPREEgYW5kIG1lcmdlZCBSRkM2MTU2LiBQbGVhc2UgcmV2 aWV3IGFuZCBwcm92aWRlIHlvdXIgdmFsdWFibGUgY29tbWVudHMuDQpEaWZmIGZyb20gcHJldmlv dXMgdmVyc2lvbiA6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdk aWZmJnVybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDEudHh0DQoNCi1UaXJ1DQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIGlu dGVybmV0LQ0KPiBkcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0c0BpZXRmLm9yZz4NCj4gU2Vu dDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IDEwOjQ4IEFNDQo+IFRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gQ2M6IHRyYW1AaWV0Zi5v cmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFt0cmFtXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQNCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLg0KPiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVFVSTiBSZXZpc2VkIGFu ZCBNb2Rlcm5pemVkIFdvcmtpbmcNCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogVHJhdmVyc2FsIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFUIChUVVJO KTogUmVsYXkgRXh0ZW5zaW9ucw0KPiB0byBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9y IE5BVCAoU1RVTikNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBUaXJ1bWFsZXN3YXIgUmVk ZHkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBBbGFuIEpvaG5zdG9uDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgUGhpbGlwIE1hdHRoZXdzDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgSm9uYXRoYW4gUm9zZW5iZXJnDQo+ICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiA3Nw0K PiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE1LTAxLTI5DQo+DQo+IEFic3RyYWN0Og0KPiAg ICBJZiBhIGhvc3QgaXMgbG9jYXRlZCBiZWhpbmQgYSBOQVQsIHRoZW4gaW4gY2VydGFpbiBzaXR1 YXRpb25zIGl0IGNhbg0KPiAgICBiZSBpbXBvc3NpYmxlIGZvciB0aGF0IGhvc3QgdG8gY29tbXVu aWNhdGUgZGlyZWN0bHkgd2l0aCBvdGhlciBob3N0cw0KPiAgICAocGVlcnMpLiAgSW4gdGhlc2Ug c2l0dWF0aW9ucywgaXQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgaG9zdCB0byB1c2UNCj4gICAgdGhl IHNlcnZpY2VzIG9mIGFuIGludGVybWVkaWF0ZSBub2RlIHRoYXQgYWN0cyBhcyBhIGNvbW11bmlj YXRpb24NCj4gICAgcmVsYXkuICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHByb3RvY29s LCBjYWxsZWQgVFVSTiAoVHJhdmVyc2FsDQo+ICAgIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFUKSwg dGhhdCBhbGxvd3MgdGhlIGhvc3QgdG8gY29udHJvbCB0aGUNCj4gICAgb3BlcmF0aW9uIG9mIHRo ZSByZWxheSBhbmQgdG8gZXhjaGFuZ2UgcGFja2V0cyB3aXRoIGl0cyBwZWVycyB1c2luZw0KPiAg ICB0aGUgcmVsYXkuICBUVVJOIGRpZmZlcnMgZnJvbSBzb21lIG90aGVyIHJlbGF5IGNvbnRyb2wg cHJvdG9jb2xzIGluDQo+ICAgIHRoYXQgaXQgYWxsb3dzIGEgY2xpZW50IHRvIGNvbW11bmljYXRl IHdpdGggbXVsdGlwbGUgcGVlcnMgdXNpbmcgYQ0KPiAgICBzaW5nbGUgcmVsYXkgYWRkcmVzcy4N Cj4NCj4gICAgVGhlIFRVUk4gcHJvdG9jb2wgd2FzIGRlc2lnbmVkIHRvIGJlIHVzZWQgYXMgcGFy dCBvZiB0aGUgSUNFDQo+ICAgIChJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVu dCkgYXBwcm9hY2ggdG8gTkFUIHRyYXZlcnNhbCwNCj4gICAgdGhvdWdoIGl0IGFsc28gY2FuIGJl IHVzZWQgd2l0aG91dCBJQ0UuDQo+DQo+DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy8NCj4NCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdHJhbS10dXJuYmlzLTAxDQo+DQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDENCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+DQo+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9y ZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= --_000_913383AAA69FF945B8F946018B75898A3553506Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21h aWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgRmVicnVhcnkgMDEsIDIwMTUgNDo0 MCBBTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxi PkNjOjwvYj4gdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgVGlydTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPmFzIHRoZSB0 dXJuYmlzIHdyaXR0ZW4sIGluIGl0cyBjdXJyZW50IGZvcm0sIGl0IGFsbG93cyBFVkVOLVBPUlQg YXR0cmlidXRlIGluIHRoZSBBTExPQ0FURSByZXF1ZXN0IHRvZ2V0aGVyIHdpdGggdGhlIEFERElU SU9OQUwtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRlLiBJZiB0aGlzIGlzIHJlYWxseSB3aGF0IHlv dSB3YW50LCB0aGVuIHRoZSBSRVNFUlZBVElPTi1UT0tFTg0KIGhhbmRsaW5nIG11c3QgYmUgY2hh bmdlZCBpbiB0aGUgQUxMT0NBVEUgcmVzcG9uc2UgLSBiZWNhdXNlIHRoZXJlIHdpbGwgYmUgdHdv IFJFU0VSVkFUSU9OLVRPS0VOIGF0dHJpYnV0ZXMgaW5jbHVkZWQgaW50byB0aGUgcmVzcG9uc2Ug KHdoZW4gRVZFTi1QT1JUPTEpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PciB0aGUgRVZFTi1Q T1JUIG11c3QgYmUgcHJvaGliaXRlZCBpbiB0aGUgc2FtZSByZXF1ZXN0IHdpdGggQURESVRJT05B TC1BRERSRVNTLUZBTUlMWS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QXMgb2Ygbm93LCB0aGVy ZSBpcyBpbmhlcmVudCBpbmNvbnNpc3RlbmN5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBBZ3JlZWQsIHdpbGwgdXBkYXRlIHRoZSBkcmFm dCB0aGF0IEFBRiBtdXN0IG5vdCBiZSB1c2VkIHdpdGggZXZlbiBwb3J0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3M8YnI+DQpPbGVnPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMjks IDIwMTUgYXQgOTozOSBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNj by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1ham9yIGNoYW5nZXMgaW4gdGhpcyByZXZpc2lvbiBhcmUgc3VwcG9ydCBmb3IgU1NPREEgYW5k IG1lcmdlZCBSRkM2MTU2LiBQbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIHlvdXIgdmFsdWFibGUg Y29tbWVudHMuPGJyPg0KRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gOiA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZhbXA7dXJsMj1kcmFm dC1pZXRmLXRyYW0tdHVybmJpcy0wMS50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZmJmFtcDt1cmwyPWRyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTAxLnR4dDwvYT48YnI+DQo8YnI+DQotVGlydTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiB0cmFtIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIGludGVybmV0LTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0c0BpZXRm Lm9yZyI+ZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBKYW51YXJ5 IDMwLCAyMDE1IDEwOjQ4IEFNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5v dW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgQ2M6IDxh IGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCiZndDsg U3ViamVjdDogW3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4 dDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJy Pg0KJmd0OyZuYnNwOyBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUVVJOIFJldmlz ZWQgYW5kIE1vZGVybml6ZWQgV29ya2luZzxicj4NCiZndDsgR3JvdXAgb2YgdGhlIElFVEYuPGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0bGUm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogVHJhdmVyc2FsIFVzaW5n IFJlbGF5cyBhcm91bmQgTkFUIChUVVJOKTogUmVsYXkgRXh0ZW5zaW9uczxicj4NCiZndDsgdG8g U2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogVGlydW1hbGVzd2FyIFJlZGR5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbGFuIEpvaG5zdG9uPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQaGlsaXAgTWF0dGhld3M8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0pvbmF0aGFuIFJvc2VuYmVy Zzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxLnR4dDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OiA3Nzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE1LTAx LTI5PGJyPg0KJmd0Ozxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg SWYgYSBob3N0IGlzIGxvY2F0ZWQgYmVoaW5kIGEgTkFULCB0aGVuIGluIGNlcnRhaW4gc2l0dWF0 aW9ucyBpdCBjYW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBiZSBpbXBvc3NpYmxlIGZvciB0aGF0 IGhvc3QgdG8gY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBvdGhlciBob3N0czxicj4NCiZndDsm bmJzcDsgJm5ic3A7IChwZWVycykuJm5ic3A7IEluIHRoZXNlIHNpdHVhdGlvbnMsIGl0IGlzIG5l Y2Vzc2FyeSBmb3IgdGhlIGhvc3QgdG8gdXNlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdGhlIHNl cnZpY2VzIG9mIGFuIGludGVybWVkaWF0ZSBub2RlIHRoYXQgYWN0cyBhcyBhIGNvbW11bmljYXRp b248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyByZWxheS4mbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9u IGRlZmluZXMgYSBwcm90b2NvbCwgY2FsbGVkIFRVUk4gKFRyYXZlcnNhbDxicj4NCiZndDsmbmJz cDsgJm5ic3A7IFVzaW5nIFJlbGF5cyBhcm91bmQgTkFUKSwgdGhhdCBhbGxvd3MgdGhlIGhvc3Qg dG8gY29udHJvbCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBvcGVyYXRpb24gb2YgdGhlIHJl bGF5IGFuZCB0byBleGNoYW5nZSBwYWNrZXRzIHdpdGggaXRzIHBlZXJzIHVzaW5nPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgdGhlIHJlbGF5LiZuYnNwOyBUVVJOIGRpZmZlcnMgZnJvbSBzb21lIG90 aGVyIHJlbGF5IGNvbnRyb2wgcHJvdG9jb2xzIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdGhh dCBpdCBhbGxvd3MgYSBjbGllbnQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBwZWVycyB1 c2luZyBhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgc2luZ2xlIHJlbGF5IGFkZHJlc3MuPGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IFRoZSBUVVJOIHByb3RvY29sIHdhcyBkZXNpZ25l ZCB0byBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlIElDRTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IChJ bnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCkgYXBwcm9hY2ggdG8gTkFUIHRy YXZlcnNhbCw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aG91Z2ggaXQgYWxzbyBjYW4gYmUgdXNl ZCB3aXRob3V0IElDRS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybmJp cy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtdHJhbS10dXJuYmlzLzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSdzIGFs c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t dHVybmJpcy0wMTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMSIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10 cmFtLXR1cm5iaXMtMDE8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb248YnI+DQomZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KJmd0Ozxicj4NCiZndDsgSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZn dDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0i X2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzp0 cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A3553506Fxmbrcdx10ciscoc_-- From nobody Sat Jan 31 23:07:21 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA121A873A for ; Sat, 31 Jan 2015 23:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 ch0jaLpEe4iY for ; Sat, 31 Jan 2015 23:07:16 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944031A8738 for ; Sat, 31 Jan 2015 23:07:15 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so9578303wib.5 for ; Sat, 31 Jan 2015 23:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5qTys44YA6Lm/46uWP/evM58eyvjD/9WQoLNcOqFvIw=; b=r/i1DauFbIaLi9ZJ9lRXunAUNa4sLfx9d8P9U6e7j9GEpxFC3hlQe8+oQ5j91Whvkt TP0Xykj3mJFK8cyiP1hgE4sUOOx45mDiDyaB7GX8ue+g3Ww+y1IL5QJHoptKBFN7BONO Q9cnvtFmIdxQhGc+QuWesCY1IEp5aob6kXfTUAURwDnqOMsgHlyONcmpUSNhaAYlQjSS AeG90FXanWYGqd3syWXCsf2Ylo/kKpUvgOO2vJGtGXxTXi5NopUvs4r/yVa4OBcIfJYo kHesn2STWJDAZMLjRdzmESHI8znfSWOU8Ej7OkPm+IROK67Kp3Y2GMkR4VoYwNRqzdTI U7Zg== MIME-Version: 1.0 X-Received: by 10.194.81.104 with SMTP id z8mr29871017wjx.45.1422774434283; Sat, 31 Jan 2015 23:07:14 -0800 (PST) Received: by 10.194.87.98 with HTTP; Sat, 31 Jan 2015 23:07:14 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> References: <20150130051824.31557.69215.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A3553414F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A3553506F@xmb-rcd-x10.cisco.com> Date: Sat, 31 Jan 2015 23:07:14 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bf0c58ec044e3050e017c08 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 07:07:18 -0000 --047d7bf0c58ec044e3050e017c08 Content-Type: text/plain; charset=UTF-8 Tiru, I do not see any problem with EVEN-PORT when its value is 0. The problem only arises when EVEN-PORT is equals 0x80 (reserved allocation required). So I'd suggest for forbid only the situation when the highest bit of EVEN-PORT is 1. Thanks Oleg On Sat, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Sunday, February 01, 2015 4:40 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt > > > > Hi Tiru > > as the turnbis written, in its current form, it allows EVEN-PORT attribute > in the ALLOCATE request together with the ADDITIONAL-ADDRESS-FAMILY > attribute. If this is really what you want, then the RESERVATION-TOKEN > handling must be changed in the ALLOCATE response - because there will be > two RESERVATION-TOKEN attributes included into the response (when > EVEN-PORT=1). > > Or the EVEN-PORT must be prohibited in the same request with > ADDITIONAL-ADDRESS-FAMILY. > > As of now, there is inherent inconsistency. > > [TR] Agreed, will update the draft that AAF must not be used with even > port. > > -Tiru > > Thanks > Oleg > > > > > > On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Major changes in this revision are support for SSODA and merged RFC6156. > Please review and provide your valuable comments. > Diff from previous version : > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tram-turnbis-01.txt > > -Tiru > > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Friday, January 30, 2015 10:48 AM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.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 Working > > Group of the IETF. > > > > Title : Traversal Using Relays around NAT (TURN): > Relay Extensions > > to Session Traversal Utilities for NAT (STUN) > > Authors : Tirumaleswar Reddy > > Alan Johnston > > Philip Matthews > > Jonathan Rosenberg > > Filename : draft-ietf-tram-turnbis-01.txt > > Pages : 77 > > Date : 2015-01-29 > > > > Abstract: > > If a host is located behind a NAT, then in certain situations it can > > be impossible for that host to communicate directly with other hosts > > (peers). In these situations, it is necessary for the host to use > > the services of an intermediate node that acts as a communication > > relay. This specification defines a protocol, called TURN (Traversal > > Using Relays around NAT), that allows the host to control the > > operation of the relay and to exchange packets with its peers using > > the relay. TURN differs from some other relay control protocols in > > that it allows a client to communicate with multiple peers using a > > single relay address. > > > > The TURN protocol was designed to be used as part of the ICE > > (Interactive Connectivity Establishment) approach to NAT traversal, > > though it also can be used without ICE. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-turnbis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-01 > > > > > > 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 > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --047d7bf0c58ec044e3050e017c08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tiru, I do not see any problem with EVEN-PORT wh= en its value is 0. The problem only arises when EVEN-PORT is equals 0x80 (r= eserved allocation required). So I'd suggest for forbid only the situat= ion when the highest bit of EVEN-PORT is 1.

Thanks
Ol= eg

On Sa= t, Jan 31, 2015 at 6:36 PM, Tirumaleswar Reddy (tireddy) = <tireddy@cisco.co= m> wrote:

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Sunday, February 01, 2015 4:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt

=C2=A0

Hi Tiru=

as the turnbis writte= n, in its current form, it allows EVEN-PORT attribute in the ALLOCATE reque= st together with the ADDITIONAL-ADDRESS-FAMILY attribute. If this is really= what you want, then the RESERVATION-TOKEN handling must be changed in the ALLOCATE response - because there will be = two RESERVATION-TOKEN attributes included into the response (when EVEN-PORT= =3D1).

Or the EVEN-PORT must= be prohibited in the same request with ADDITIONAL-ADDRESS-FAMILY.

As of now, there is i= nherent inconsistency.

[TR] Agreed, will update the draft that AAF must not be used w= ith even port.

-Tiru

Thanks
Oleg

=C2=A0

=C2=A0

On Thu, Jan 29, 2015 at 9:39 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Major changes in this revision are support for SSODA= and merged RFC6156. Please review and provide your valuable comments.
Diff from previous version : http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tra= m-turnbis-01.txt

-Tiru


> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, January 30, 2015 10:48 AM
> To: i-d-ann= ounce@ietf.org
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the TURN Revised and Modernized Wor= king
> Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Traversal Using Relays around NAT (TURN): Relay Extensions
> to Session Traversal Utilities for NAT (STUN)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Tirumaleswar Reddy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Alan Johnston
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Philip Matthews
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jonathan Rosenberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-turnbis-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 77
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-29
>
> Abstract:
>=C2=A0 =C2=A0 If a host is located behind a NAT, then in certain situat= ions it can
>=C2=A0 =C2=A0 be impossible for that host to communicate directly with = other hosts
>=C2=A0 =C2=A0 (peers).=C2=A0 In these situations, it is necessary for t= he host to use
>=C2=A0 =C2=A0 the services of an intermediate node that acts as a commu= nication
>=C2=A0 =C2=A0 relay.=C2=A0 This specification defines a protocol, calle= d TURN (Traversal
>=C2=A0 =C2=A0 Using Relays around NAT), that allows the host to control= the
>=C2=A0 =C2=A0 operation of the relay and to exchange packets with its p= eers using
>=C2=A0 =C2=A0 the relay.=C2=A0 TURN differs from some other relay contr= ol protocols in
>=C2=A0 =C2=A0 that it allows a client to communicate with multiple peer= s using a
>=C2=A0 =C2=A0 single relay address.
>
>=C2=A0 =C2=A0 The TURN protocol was designed to be used as part of the = ICE
>=C2=A0 =C2=A0 (Interactive Connectivity Establishment) approach to NAT = traversal,
>=C2=A0 =C2=A0 though it also can be used without ICE.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-turnbis-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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
> tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0


--047d7bf0c58ec044e3050e017c08--