From nobody Tue Jun 3 01:01:50 2014 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 6E8B21A016E for ; Tue, 3 Jun 2014 01:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 HE-FheOmefdd for ; Tue, 3 Jun 2014 01:01:47 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A9EC01A0162 for ; Tue, 3 Jun 2014 01:01:46 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 2EBD21EB8438; Tue, 3 Jun 2014 10:01:40 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 10:01:40 +0200 From: "Stach, Thomas" To: "draft-ietf-tram-stun-dtls@tools.ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-stun-dtls-03.txt Thread-Index: AQHPfCVV7SVw+tktiE+jugVCu3l6DJtfBIRg Date: Tue, 3 Jun 2014 08:01:38 +0000 Message-ID: References: <20140530163625.18998.88986.idtracker@ietfa.amsl.com> In-Reply-To: <20140530163625.18998.88986.idtracker@ietfa.amsl.com> Accept-Language: de-AT, 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: http://mailarchive.ietf.org/arch/msg/tram/nMaktWKByL06I-wN_2NVlewnEAY Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-dtls-03.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, 03 Jun 2014 08:01:48 -0000 This resolves my comments. Thanks Thomas > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Freitag, 30. Mai 2014 18:36 > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-03.txt >=20 >=20 > 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 Gro= up of > the IETF. >=20 > Title : Datagram Transport Layer Security (DTLS) as > Transport for Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Filename : draft-ietf-tram-stun-dtls-03.txt > Pages : 16 > Date : 2014-05-30 >=20 > Abstract: > This document specifies the usage of Datagram Transport Layer > Security (DTLS) as a transport protocol for Session Traversal > Utilities for NAT (STUN). It provides guidances on when and how to > use DTLS with the currently standardized STUN Usages. It also > specifies modifications to the STUN URIs and TURN URIs and to the > TURN resolution mechanism to facilitate the resolution of STUN URIs > and TURN URIs into the IP address and port of STUN and TURN servers > supporting DTLS as a transport protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stun-dtls-03 >=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 Wed Jun 4 04:06:32 2014 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 437421A016D for ; Wed, 4 Jun 2014 04:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 9pMUn3lbhm5y for ; Wed, 4 Jun 2014 04:06:28 -0700 (PDT) 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 879A21A032C for ; Wed, 4 Jun 2014 04:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2970; q=dns/txt; s=iport; t=1401879983; x=1403089583; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=Dm0QTAP08WfafEevaxl4ydGt93e8nNlumpI/fJuc/h4=; b=D4SecCk6bwVh7HQsdBOo9ZDiDlQbxiJosJLNTuvK9tcfcf4jErc+VbCK KpFljOmQgKz6C7UIQ+qmcvM2aQNx1eVa5J9ArDisgdL82z7DTjDYwEFLM ueMuRJ6gHiFf5Gu20DJ5qTWne6yw6mN9ckJAo7RxmSOprHUdGVq6tHdz0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALf8jlOtJV2T/2dsb2JhbABZgwdSWIJswAcBGXIWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYg5Daw4pXAXgSqMdz6CbzaBFQSbTpF3gzhsgUM X-IronPort-AV: E=Sophos;i="4.98,972,1392163200"; d="scan'208";a="330425453" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 04 Jun 2014 11:06:21 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s54B6LAK018374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Jun 2014 11:06:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 06:06:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.txt Thread-Index: AQHPf+MyUHdmQIZk4UaV4Ec4CXcVNptgxt4QgAADPOA= Date: Wed, 4 Jun 2014 11:06:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C8046@xmb-rcd-x10.cisco.com> References: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iiXHRwDo-96GWefDvICUNF0S6ZU Subject: [tram] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-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, 04 Jun 2014 11:06:30 -0000 SGkgYWxsLA0KDQpUcmF2ZXJzYWwgVXNpbmcgUmVsYXkgTkFUIChUVVJOKSBzZXJ2ZXIgYW5kIHRo ZSBuZXR3b3JrIGluIHdoaWNoIGl0IGlzIGhvc3RlZCBkdWUgdG8gbG9hZCBjb3VsZCBhZHZlcnNl bHkgaW1wYWN0IHRoZSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdC4gIER1cmluZyBzdWNoIGhp Z2ggbG9hZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljIGJ1dCBU VVJOIHNlcnZlciBsYWNrIHJlcXVpcmVtZW50cyBhYm91dCB0aGUgZmxvd3MgdG8gcHJpb3JpdGl6 ZSB0aGVtLiBUaGlzIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmct dHN2d2ctdHVybi1mbG93ZGF0YS0wMCBkZWZpbmVzIGEgbWVjaGFuaXNtIHRvIGNvbW11bmljYXRl IGZsb3cgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIFRVUk4gY2xpZW50IHRvIGl0cyBUVVJOIHNl cnZlci4NCg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0K IA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXks IEp1bmUgMDQsIDIwMTQgNDoyMyBQTQ0KVG86IFJhbSBNb2hhbiBSIChybW9oYW5yKTsgQnJhbmRv biBXaWxsaWFtczsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5n KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5nKTsgUmFtIE1v aGFuIFIgKHJtb2hhbnIpOyBCcmFuZG9uIFdpbGxpYW1zDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2luZy10c3Z3Zy10dXJuLWZsb3dkYXRhLTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVk ZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtd2lu Zy10c3Z3Zy10dXJuLWZsb3dkYXRhDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJVFVSTiBleHRlbnNp b24gdG8gY29udmV5IGZsb3cgY2hhcmFjdGVyaXN0aWNzDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA2 LTA0DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbmctdHN2 d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLXRzdndnLXR1cm4tZmxvd2RhdGEvDQpIdG1saXpl ZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy10c3Z3Zy10dXJu LWZsb3dkYXRhLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUVVJOIHNlcnZlciBhbmQgdGhlIG5ldHdv cmsgaW4gd2hpY2ggaXQgaXMgaG9zdGVkIGR1ZSB0byBsb2FkIGNvdWxkDQogICBhZHZlcnNlbHkg aW1wYWN0IHRoZSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdC4gIER1cmluZyBzdWNoIGhpZ2gN CiAgIGxvYWQgZXZlbnQsIGl0IGlzIGRlc2lyYWJsZSB0byBzaGVkIHNvbWUgdHJhZmZpYyBidXQg VFVSTiBzZXJ2ZXIgbGFjaw0KICAgcmVxdWlyZW1lbnRzIGFib3V0IHRoZSBmbG93cyB0byBwcmlv cml0aXplIHRoZW0uICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIHN1Y2ggYSBtZWNoYW5pc20g dG8gY29tbXVuaWNhdGUgZmxvdyBjaGFyYWN0ZXJpc3RpY3MgZnJvbSB0aGUNCiAgIFRVUk4gY2xp ZW50IHRvIGl0cyBUVVJOIHNlcnZlci4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Wed Jun 4 07:18:55 2014 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 163B91A023E for ; Wed, 4 Jun 2014 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 wrnbJ0BGENCU for ; Wed, 4 Jun 2014 07:18:52 -0700 (PDT) Received: from nomis80.org (nomis80.org [IPv6:2600:3c03::f03c:91ff:fe69:7108]) by ietfa.amsl.com (Postfix) with ESMTP id CB52D1A01F6 for ; Wed, 4 Jun 2014 07:18:52 -0700 (PDT) Received: from [IPv6:2001:470:1d:bc0:98be:bec1:41d1:4c93] (unknown [IPv6:2001:470:1d:bc0:98be:bec1:41d1:4c93]) by nomis80.org (Postfix) with ESMTPSA id 18F8C10EA6 for ; Wed, 4 Jun 2014 14:20:42 +0000 (UTC) Message-ID: <538F2AC5.3010806@per.reau.lt> Date: Wed, 04 Jun 2014 10:18:45 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <53688A4D.8050208@ericsson.com> In-Reply-To: <53688A4D.8050208@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/1MfilPZ46yfTLvzuJEnSP2NxPgk Subject: Re: [tram] WGLC: draft-ietf-tram-stun-dtls-02 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, 04 Jun 2014 14:18:54 -0000 WG, To keep you informed about progress on this doc... Since the WGLC ended we have been in contact with the authors, ensuring that all issues had been addressed. Version -03 was published by the authors, and we just today sent it to IESG. I will be shepherding the doc through the RFC publication process. In other news, there are only two days left on the WGLC for draft-ietf-tram-auth-problems! Send those comments ASAP! :) Simon Le 2014-05-06 03:07, Gonzalo Camarillo a écrit : > Folks, > > we are starting a Working Group Last Call (WGLC) on the following draft: > > http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ > > This WGLC will end on May 21st. Please, send your comments to this list. > > Thanks, > > Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Wed Jun 4 20:16:47 2014 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 2AD871A0406; Wed, 4 Jun 2014 20:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, 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 jtpR1vbgq_K0; Wed, 4 Jun 2014 20:16:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA131A0409; Wed, 4 Jun 2014 20:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4854; q=dns/txt; s=iport; t=1401938194; x=1403147794; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=pVGqo+PikiYQhxFz/LuY2PTJLHBheh4EviNLqy1PY6E=; b=ImMo93+rsH1AVd0wavf/5neXpmh3XAT+swuw/1OlhIyZ7zeLj2MT05hj 6aNLYNS1GEuBxgMI23eYWhHrFPK1YPjmWOY7laecf7RFiUV4FvQaqOoDc /LxPc9+viIxVWaE+SOABowDIyyZS2rRPm5IsAP4x1FZOIyoOBbpFO0/Zn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIPgj1OtJA2K/2dsb2JhbABZgwdSWIJswBABGXMWdIIlAQEBAwEjEToJDgYBCBEEAQEDAgYdAwIEMBQBBwEJAQQBEggBiDEIDaxtpWkXgSqMdz6CbzaBFQSbUpF6gXiBQIIv X-IronPort-AV: E=Sophos;i="4.98,977,1392163200"; d="scan'208";a="330708154" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jun 2014 03:16:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s553GXWV015808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 03:16:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 22:16:33 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Black, David" , "tsvwg@ietf.org" , "tram@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.txt Thread-Index: Ac+AbIsvygIpPj7WTI6V1Y1abQyLAg== Date: Thu, 5 Jun 2014 03:16:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C856D@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.21.78.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tnfT61LxVggPqa9lWC2r5SrF2KU Subject: Re: [tram] [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-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, 05 Jun 2014 03:16:46 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCbGFjaywgRGF2aWQgW21haWx0 bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQg OToyMiBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHN2d2dAaWV0Zi5v cmc7IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFt0c3Z3Z10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2luZy10c3Z3Zy10dXJuLQ0KPiBmbG93ZGF0YS0wMC50 eHQNCj4gDQo+IFF1ZXN0aW9uOiBTaG91bGQgdGhpcyBkcmFmdCBiZSBjb25zaWRlcmVkIGJ5IHRo ZSB0c3Z3ZyBXRyBvciB0aGUgdHJhbSBXRz8NCg0KUHJpb3IgdG8gcHVibGljYXRpb24gb2YgdGhl IGRyYWZ0LCB3ZSBoYWQgY29uc3VsdGVkIHdpdGggVFJBTSBXRyBjaGFpcnMgd2hvIGFza2VkIHRo ZSBBRCBmb3IgYWR2aWNlIGFuZCB0aGUgZGVjaXNpb24gd2FzIHRvIHB1Ymxpc2ggdGhpcyBkcmFm dCBpbiB0c3Z3Zy4NCg0KLVRpcnUNCg0KPiANCj4gVGhlIGRyYWZ0IG5hbWUgc3VnZ2VzdHMgdHN2 d2csIGJ1dCB0cmFtIGlzIHRoZSBmb2N1cyBvZiBUVVJOIGFjdGl2aXR5IGFuZA0KPiAiZXh0ZW5z aW9ucyB0byBUVVJOIGFuZCBTVFVOIiBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0cmFtJ3MgYWN0 aXZpdHkuDQo+IA0KPiBBdCBhIG1pbmltdW0gSSB3b3VsZCBzdWdnZXN0IHRoZSB0cmFtQGlldGYu b3JnIG1haWxpbmcgbGlzdCBhcyB0aGUgcHJlZmVycmVkDQo+IGZvcnVtIGZvciBkaXNjdXNzaW9u IG9mIHRoaXMgZHJhZnQgYmVjYXVzZSB0aGF0IGlzIHdoZXJlIFRVUk4gYWN0aXZpdHkgaXMNCj4g Y3VycmVudGx5IGZvY3VzZWQuDQo+IA0KPiBUaGFua3MsDQo+IC0tRGF2aWQgKHRzdndnIFdHIGNv LWNoYWlyKQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHRz dndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpcnVtYWxl c3dhcg0KPiA+IFJlZGR5DQo+ID4gKHRpcmVkZHkpDQo+ID4gU2VudDogV2VkbmVzZGF5LCBKdW5l IDA0LCAyMDE0IDc6MDMgQU0NCj4gPiBUbzogdHN2d2dAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBb dHN2d2ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtd2luZy10 c3Z3Zy10dXJuLSBmbG93ZGF0YS0wMC50eHQNCj4gPg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFRy YXZlcnNhbCBVc2luZyBSZWxheSBOQVQgKFRVUk4pIHNlcnZlciBhbmQgdGhlIG5ldHdvcmsgaW4g d2hpY2ggaXQgaXMNCj4gPiBob3N0ZWQgZHVlIHRvIGxvYWQgY291bGQgYWR2ZXJzZWx5IGltcGFj dCB0aGUgdHJhZmZpYyByZWxheWVkIHRocm91Z2gNCj4gPiBpdC4gIER1cmluZyBzdWNoIGhpZ2gg bG9hZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljDQo+ID4gYnV0 IFRVUk4gc2VydmVyIGxhY2sgcmVxdWlyZW1lbnRzIGFib3V0IHRoZSBmbG93cyB0byBwcmlvcml0 aXplIHRoZW0uDQo+ID4gVGhpcyBkcmFmdA0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMCBkZWZpbmVzIGENCj4gPiBtZWNoYW5p c20gdG8gY29tbXVuaWNhdGUgZmxvdyBjaGFyYWN0ZXJpc3RpY3MgZnJvbSB0aGUgVFVSTiBjbGll bnQgdG8NCj4gPiBpdHMgVFVSTiBzZXJ2ZXIuDQo+ID4NCj4gPiBDb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMgYXJlIHdlbGNvbWUuDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0 LCAyMDE0IDQ6MjMgUE0NCj4gPiBUbzogUmFtIE1vaGFuIFIgKHJtb2hhbnIpOyBCcmFuZG9uIFdp bGxpYW1zOyBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPiAodGlyZWRkeSk7IERhbiBXaW5nIChkd2lu Zyk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IERhbiBXaW5nDQo+ID4gKGR3aW5nKTsg UmFtIE1vaGFuIFIgKHJtb2hhbnIpOyBCcmFuZG9uIFdpbGxpYW1zDQo+ID4gU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93 ZGF0YS0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdp bmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNCj4gPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvDQo+ID4gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC13aW5nLXRzdndnLXR1cm4tZmxv d2RhdGENCj4gPiBSZXZpc2lvbjoJMDANCj4gPiBUaXRsZToJCVRVUk4gZXh0ZW5zaW9uIHRvIGNv bnZleSBmbG93IGNoYXJhY3RlcmlzdGljcw0KPiA+IERvY3VtZW50IGRhdGU6CTIwMTQtMDYtMDQN Cj4gPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOgkJMTENCj4gPiBV Ukw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt d2luZy10c3Z3Zy10dXJuLQ0KPiA+IGZsb3dkYXRhLTAwLnR4dA0KPiA+IFN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLXRzdndnLXR1cm4t DQo+ID4gZmxvd2RhdGEvDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdpbmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMA0KPiA+DQo+ID4NCj4gPiBB YnN0cmFjdDoNCj4gPiAgICBUVVJOIHNlcnZlciBhbmQgdGhlIG5ldHdvcmsgaW4gd2hpY2ggaXQg aXMgaG9zdGVkIGR1ZSB0byBsb2FkIGNvdWxkDQo+ID4gICAgYWR2ZXJzZWx5IGltcGFjdCB0aGUg dHJhZmZpYyByZWxheWVkIHRocm91Z2ggaXQuICBEdXJpbmcgc3VjaCBoaWdoDQo+ID4gICAgbG9h ZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljIGJ1dCBUVVJOIHNl cnZlciBsYWNrDQo+ID4gICAgcmVxdWlyZW1lbnRzIGFib3V0IHRoZSBmbG93cyB0byBwcmlvcml0 aXplIHRoZW0uICBUaGlzIGRvY3VtZW50DQo+ID4gICAgZGVmaW5lcyBzdWNoIGEgbWVjaGFuaXNt IHRvIGNvbW11bmljYXRlIGZsb3cgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlDQo+ID4gICAgVFVS TiBjbGllbnQgdG8gaXRzIFRVUk4gc2VydmVyLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From nobody Thu Jun 5 07:20:11 2014 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 B1C701A01EB for ; Thu, 5 Jun 2014 07:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 naoqT13xnfOM for ; Thu, 5 Jun 2014 07:19:56 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id DB5681A0201 for ; Thu, 5 Jun 2014 07:19:45 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 01DF523F0588; Thu, 5 Jun 2014 16:19:39 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 16:19:38 +0200 From: "Hutton, Andrew" To: Alan Johnston , "tram@ietf.org" Thread-Topic: [tram] Review of draft-johnston-tram-stun-origin-02 Thread-Index: AQHPahzB4IMeNSxSMk2xnnCULaae0JtivROQ Date: Thu, 5 Jun 2014 14:19:37 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17DE3241@MCHP04MSX.global-ad.net> References: <5368BF90.2070307@getjive.com> In-Reply-To: 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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17DE3241MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/QbLPABYUadRBeKsd085zXXsp37k Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 05 Jun 2014 14:20:03 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17DE3241MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGFkIGFub3RoZXIgcmVhZCB0aHJvdWdoIHRoaXMgZHJhZnQgYW5kIGhvcGUgd2Ug Y2FuIG1vdmUgdGhpcyBmb3J3YXJkIGFuZCBhZG9wdCB0aGUgZHJhZnQgc29vbi4NCg0KSSBvbmx5 IGhhdmUgb25lIGFkZGl0aW9uYWwgY29tbWVudCBhdCB0aGlzIHRpbWUgYW5kIHRoYXQgaXMgdGhh dCBJIGFzc3VtZSBpdCBzaG91bGQgYmUgcG9zc2libGUgZm9yIHRoZSBjbGllbnQgdG8gaW5jbHVk ZSBtb3JlIHRoYW4gb25lIG9yaWdpbiBpbiB0aGUgT3JpZ2luIGhlYWRlciBmaWVsZCBhbmQgaWYg c28gdGhlIHByb2NlZHVyZXMgYXJvdW5kIHRoaXMgc2hvdWxkIGV4cGxhaW5lZCBpbiB0aGUgZHJh ZnQuDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gSm9obnN0b24NClNlbnQ6IDA3IE1heSAy MDE0IDE4OjUwDQpUbzogTWFyYyBQZXRpdC1IdWd1ZW5pbg0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbdHJhbV0gUmV2aWV3IG9mIGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmln aW4tMDINCg0KTWFyYywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU2VlIG15IGNvbW1lbnRz IGJlbG93Lg0KDQotIEFsYW4gLQ0KDQpPbiBUdWUsIE1heSA2LCAyMDE0IGF0IDU6NTUgQU0sIE1h cmMgUGV0aXQtSHVndWVuaW4gPG1hcmNwaEBnZXRqaXZlLmNvbTxtYWlsdG86bWFyY3BoQGdldGpp dmUuY29tPj4gd3JvdGU6DQpBMS4gSW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsDQoNClNo b3VsZG4ndCB0aGlzIGJlIFN0YW5kYXJkIFRyYWNrPw0KDQpZZXMuDQoNCkEyLiBTZWN0aW9uIDEs IDJuZCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6ICJhcyBnZW5lcmF0aW5nIHRoZSByZXNwb25z ZS4uLiINCg0KSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgcmVhc29uIGZvciBubyBhdXRoZW50aWNh dGlvbiBmb3IgdGhlIE5BVA0KRGlzY292ZXJ5IFVzYWdlIGlzIGJlY2F1c2UgaXQgaXMgbGVzcyB3 b3JrLCBidXQgYmVjYXVzZSB0aGVyZSBpcyBubw0KcmVzb3VyY2UgdG8gcHJvdGVjdCBzbyBhZGRp bmcgbW9yZSB3b3JrIGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQoNCkkgZGlzYWdyZWUgdGhhdCB0aGVy ZSBpcyAqbm8qIHJlc291cmNlIHRvIHByb3RlY3QuICBBIFNUVU4gc2VydmVyIG1pZ2h0IGJlIG1p bmltYWwgcmVzb3VyY2VzLCBidXQgbm90IG5vbmUuICBJZiBhIHNpbXBsZSBhdXRoZW50aWNhdGlv biBzY2hlbWUgd2VyZSBhdmFpbGFibGUsIEknbSBzdXJlIHNvbWUgcGVvcGxlIHdvdWxkIHVzZSBp dCBzbyB0aGV5IGNvdWxkIG1pbmltaXplIHRoZSBjb3N0IG9mIHRoZWlyIHNlcnZlciBmb290cHJp bnQgYnkgZW5zdXJpbmcgdGhhdCBvbmx5IGF1dGhlbnRpY2F0ZWQgdXNlcnMgd2VyZSB1dGlsaXpp bmcgaXQuICBJIHdpbGwgYWRkIHNvbWUgdGV4dCBwb2ludGluZyBvdXQgdGhhdCB0aGUgbWluaW1h bCByZXNvdXJjZXMuDQoNCkEzLiBTZWN0aW9uIDEsIDh0aCBwYXJhZ3JhcGgNCg0KSSBkbyBub3Qg dGhpbmsgdGhhdCB0aGUgT1JJR0lOIHNob3VsZCBiZSB1c2VkIHRvIHNlbGVjdCB0aGUgY2VydGlm aWNhdGUNCndoZW4gKEQpVExTIGlzIHVzZWQuICBGaXJzdCBpdCBkb2VzIG5vdCB3b3JrIHdpdGgg REFORSwgYXMgd2hlbiBhbiBTUlYNCihhbmQgcHJvYmFibHkgTkFQVFIgdG9vLCBidXQgdGhhdCdz IHVuZGVmaW5lZCB5ZXQpIFJSIHJlZGlyZWN0cyB0byBhDQpkaWZmZXJlbnQgZG9tYWluLCB0aGUg ZG9tYWluIHRvIGJlIGNoZWNrZWQgd2l0aCBpcyB0aGUgaG9zdCBuYW1lLCBub3QNCnRoZSBzZXJ2 aWNlIGRvbWFpbiAoc2VlIGRyYWZ0LWlldGYtZGFuZS1zcnYpLiAgRm9yIG5vbi1EQU5FIGNhc2Vz LCBJDQp0aGluayB0aGF0IHRoZSBjb3JyZWN0IHdheSB0byBzZWxlY3QgdGhlIGNlcnRpZmljYXRl IGlzIHRvIHVzZSBTTkkuDQoNClRoZSBkcmFmdCBkb2VzIG5vdCBzdWdnZXN0IHRoYXQgT1JJR0lO IGJlIHVzZWQgdG8gc2VsZWN0IGNlcnRpZmljYXRlcyAtIGFzIE9sZWcgcG9pbnRlZCBvdXQgaXQg aXNuJ3QgcG9zc2libGUuICBUaGlzIHBhcmFncmFwaCB3YXMgZGVzY3JpYmluZyBob3cgUkZDIDYw NjYgZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0sIGFzIGhhZCBiZWVuIHN1Z2dlc3RlZCBvbiB0 aGUgbGlzdC4NCg0KDQpTbyBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVzdHJpY3QgdGhlIG5vcm1hdGl2 ZSB1c2Ugb2YgT1JJR0lOIG9ubHkgdG8NCnNlbGVjdCByZWFsbXMuDQoNCkE0LiBTZWN0aW9uIDIu Mi4gT1JJR0lOIGF0dHJpYnV0ZSB1c2FnZQ0KDQpUaGUgdGV4dCBkb2VzIG5vdCBzYXkgaWYgdGhl IE9SSUdJTiBhdHRyaWJ1dGUgc2hvdWxkL2NhbiBiZSBwcm92aWRlZA0KYWZ0ZXIgdGhlIGF1dGhl bnRpY2F0aW9uIChpLmUuIHJlZnJlc2gsIGRhdGEgcGFja2V0cywgZXRjLi4uKQ0KDQpDdXJyZW50 bHksIHRoZSB0ZXh0IHNheXMgU0hPVUxEIGluY2x1ZGUsIGZvciBhIGNvbmZvcm1hbnQgY2xpZW50 LiAgRm9yIGxvZ2dpbmcsIGl0IGhhcyB2YWx1ZSBldmVuIGFmdGVyIHRoZSBpbml0aWFsIGF1dGhl bnRpY2F0aW9uLg0KDQoNCkE1LiBTZWN0aW9uIDIuMi4gIE1hbmRhdG9yeSBzdXBwb3J0IGZvciBz ZXJ2ZXINCg0KSG93IGEgVFVSTiBzZXJ2ZXIgdGhhdCByZXF1aXJlcyB0aGUgdXNhZ2Ugb2YgT1JJ R0lOIGNhbiBzaWduYWwgdGhpcz8NCg0KUmlnaHQgbm93IHRoZXJlIGlzIG5vIHdheSB0byBkbyB0 aGlzLiAgSSBhZ3JlZSB3aXRoIE9sZWcgdGhhdCBpdCBpcyB1cCB0byB0aGUgc2VydmVyIHdoYXQg dG8gZG8gaWYgT1JJR0lOIGlzIG5vIHByZXNlbnQuDQoNCkE2LiBTZWN0aW9uIDIuIE90aGVyIFVz YWdlcw0KDQpJIHRoaW5rIHRoYXQgb3RoZXIgU1RVTiBVc2FnZXMgc2hvdWxkIGJlIGxpc3RlZCBh ZnRlciBzZWN0aW9uIDIuMzoNCg0KLSBNZWRpYSBLZWVwLUFsaXZlIFVzYWdlIChTZWN0aW9uIDIw IG9mIFJGQzUyNDUpDQotIFNJUCBLZWVwLUFsaXZlIFVzYWdlIChSRkMgNTYyNikNCi0gTkFUIEJl aGF2aW9yIERpc2NvdmVyeSBVc2FnZSAoUkZDIDU3ODApDQoNCkknbGwgdGFrZSBhIGxvb2sgYXQg dGhlc2Ugc2NlbmFyaW9zLiAgSSBzdXNwZWN0IHRoYXQgaXQgd291bGQgYmUgYSByZWFzb25hYmxl IHVzYWdlIGZvciBjbGllbnQtdG8tc2VydmVyIHVzYWdlcywgYnV0IG5vdCBmb3IgcGVlci10by1w ZWVyIHVzYWdlcy4NCg0KQTcuIFNlY3Rpb24gNCwgM3JkIHBhcmFncmFwaDogIklmIHRoZSBTVFVO IE1FU1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0ZQ0KaXMgcHJlc2VudCwgdGhlIGNvbnRlbnRzIG9m IHRoZSBPUklHSU4gYXR0cmlidXRlIGFyZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiINCg0KV2hpY2gg bmV2ZXIgaGFwcGVuIGluIHRoZSB1c2FnZXMgbGlzdGVkIGluIHRoZSBkb2N1bWVudDogIGZvciBz ZWN0aW9uDQoyLjEsIHRoZXJlIGlzIG5ldmVyIGFuIGludGVncml0eSBwcm90ZWN0aW9uLCBhbmQg Zm9yIDIuMiwgdGhlIE9SSUdJTiBpcw0KbmVlZGVkIHRvIHNlbGVjdCB0aGUgcmVhbG0sIHNvIHRo ZSBPUklHSU4gaXMgc2VudCBiZWZvcmUgaXQgY2FuIGJlDQpwcm90ZWN0ZWQuICBQZXJoYXBzIDIu MiBzaG91bGQgc2F5IHRoYXQgaWYgT1JJR0lOIHdhcyBzZW50IHRvIHNlbGVjdCB0aGUNCnJlYWxt LCBpdCBNVVNUIGJlIHJlcGVhdGVkIGF0IGlkZW50aWNhbCBvbiB0aGUgc2Vjb25kIEFsbG9jYXRl ICh0aGUgb25lDQp0aGF0IGhhcyBhbiBNLUkpIGFuZCB0aGF0IHRoZSBzZXJ2ZXIgTVVTVCByZWpl Y3QgaXQgaWYgaXQgaXMgbm90DQppZGVudGljYWwgdG8gdGhlIGZpcnN0IG9uZS4gIE5vdCBzdXJl IGl0IG1hdHRlcnMgdGhvdWdoLg0KDQpJIGFncmVlIHRoYXQgdGhlcmUgaXMgbm8gaW50ZWdyaXR5 IHByb3RlY3Rpb24gb2YgdGhlIE9SSUdJTiBhdHRyaWJ1dGUgKG9yIGFueSBvdGhlciBhdHRyaWJ1 dGUpIHVudGlsIGFmdGVyIGF1dGhlbnRpY2F0aW9uLiAgSG93ZXZlciwgT1JJR0lOIGNhbiBiZSB1 c2VkIGJvdGggYmVmb3JlIGFuZCBhZnRlciBhdXRoZW50aWNhdGlvbi4gIEknbGwgcmV2aWV3IHRo aXMgdGV4dCBhbmQgbWFrZSBzdXJlIHRoaXMgaXMgY2xlYXIuICBJIGRvbid0IGJlbGlldmUgd2Ug bmVlZCBhbnkgc3BlY2lhbCBydWxlcywgYXMgdGhpcyBhcHBsaWVzIHRvIGFueSBTVFVOIGF0dHJp YnV0ZS4NCg0KTml0cw0KLS0tLQ0KDQotIFNlY3Rpb24gMiwgMm5kIHBhcmFncmFwaDogIlRoZSBu dW1iZXIgdXNlZCBmb3IgdGhlIHRoaXMgaW4gdGhlIC4uLiINCg0KRG9lcyBub3QgcGFyc2UuDQoN ClRoZSBtaWRkbGUgInRoZSIgc2hvdWxkbid0IGJlIHRoZXJlLg0KDQoNCi0tDQpNYXJjIFBldGl0 LUh1Z3VlbmluDQpEZXZlbG9wZXIgIHwgIEppdmUgQ29tbXVuaWNhdGlvbnMsIEluYy4NCkppdmUu Y29tICB8ICBtYXJjcGhAZ2V0aml2ZS5jb208bWFpbHRvOm1hcmNwaEBnZXRqaXZlLmNvbT4NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBt YWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF17DE3241MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYWQgYW5vdGhlciByZWFkIHRocm91Z2ggdGhp cyBkcmFmdCBhbmQgaG9wZSB3ZSBjYW4gbW92ZSB0aGlzIGZvcndhcmQgYW5kIGFkb3B0IHRoZSBk cmFmdCBzb29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBvbmx5IGhhdmUgb25lIGFkZGl0aW9uYWwgY29tbWVudCBh dCB0aGlzIHRpbWUgYW5kIHRoYXQgaXMgdGhhdCBJIGFzc3VtZSBpdCBzaG91bGQgYmUgcG9zc2li bGUgZm9yIHRoZSBjbGllbnQgdG8gaW5jbHVkZSBtb3JlIHRoYW4gb25lIG9yaWdpbiBpbiB0aGUg T3JpZ2luDQogaGVhZGVyIGZpZWxkIGFuZCBpZiBzbyB0aGUgcHJvY2VkdXJlcyBhcm91bmQgdGhp cyBzaG91bGQgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5BbGFuIEpvaG5zdG9uPGJyPg0KPGI+U2VudDo8L2I+IDA3IE1heSAyMDE0 IDE4OjUwPGJyPg0KPGI+VG86PC9iPiBNYXJjIFBldGl0LUh1Z3VlbmluPGJyPg0KPGI+Q2M6PC9i PiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gUmV2aWV3IG9m IGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyYyw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHJldmlldy4gJm5ic3A7 U2VlIG15IGNvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEFsYW4gLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1h eSA2LCAyMDE0IGF0IDU6NTUgQU0sIE1hcmMgUGV0aXQtSHVndWVuaW4gJmx0OzxhIGhyZWY9Im1h aWx0bzptYXJjcGhAZ2V0aml2ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJjcGhAZ2V0aml2ZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QTEuIEludGVuZGVkIFN0YXR1czogSW5mb3JtYXRp b25hbDxicj4NCjxicj4NClNob3VsZG4ndCB0aGlzIGJlIFN0YW5kYXJkIFRyYWNrPzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkEyLiBTZWN0aW9uIDEsIDJuZCBwYXJhZ3JhcGgsIGxhc3Qgc2Vu dGVuY2U6ICZxdW90O2FzIGdlbmVyYXRpbmcgdGhlIHJlc3BvbnNlLi4uJnF1b3Q7PGJyPg0KPGJy Pg0KSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgcmVhc29uIGZvciBubyBhdXRoZW50aWNhdGlvbiBm b3IgdGhlIE5BVDxicj4NCkRpc2NvdmVyeSBVc2FnZSBpcyBiZWNhdXNlIGl0IGlzIGxlc3Mgd29y aywgYnV0IGJlY2F1c2UgdGhlcmUgaXMgbm88YnI+DQpyZXNvdXJjZSB0byBwcm90ZWN0IHNvIGFk ZGluZyBtb3JlIHdvcmsgZG9lcyBub3QgbWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlzYWdyZWUgdGhhdCB0 aGVyZSBpcyAqbm8qIHJlc291cmNlIHRvIHByb3RlY3QuICZuYnNwO0EgU1RVTiBzZXJ2ZXIgbWln aHQgYmUgbWluaW1hbCByZXNvdXJjZXMsIGJ1dCBub3Qgbm9uZS4gJm5ic3A7SWYgYSBzaW1wbGUg YXV0aGVudGljYXRpb24gc2NoZW1lIHdlcmUgYXZhaWxhYmxlLCBJJ20gc3VyZSBzb21lIHBlb3Bs ZSB3b3VsZCB1c2UgaXQgc28gdGhleSBjb3VsZCBtaW5pbWl6ZSB0aGUgY29zdCBvZiB0aGVpciBz ZXJ2ZXINCiBmb290cHJpbnQgYnkgZW5zdXJpbmcgdGhhdCBvbmx5IGF1dGhlbnRpY2F0ZWQgdXNl cnMgd2VyZSB1dGlsaXppbmcgaXQuICZuYnNwO0kgd2lsbCBhZGQgc29tZSB0ZXh0IHBvaW50aW5n IG91dCB0aGF0IHRoZSBtaW5pbWFsIHJlc291cmNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QTMuIFNlY3Rpb24gMSwgOHRoIHBh cmFncmFwaDxicj4NCjxicj4NCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIE9SSUdJTiBzaG91bGQg YmUgdXNlZCB0byBzZWxlY3QgdGhlIGNlcnRpZmljYXRlPGJyPg0Kd2hlbiAoRClUTFMgaXMgdXNl ZC4gJm5ic3A7Rmlyc3QgaXQgZG9lcyBub3Qgd29yayB3aXRoIERBTkUsIGFzIHdoZW4gYW4gU1JW PGJyPg0KKGFuZCBwcm9iYWJseSBOQVBUUiB0b28sIGJ1dCB0aGF0J3MgdW5kZWZpbmVkIHlldCkg UlIgcmVkaXJlY3RzIHRvIGE8YnI+DQpkaWZmZXJlbnQgZG9tYWluLCB0aGUgZG9tYWluIHRvIGJl IGNoZWNrZWQgd2l0aCBpcyB0aGUgaG9zdCBuYW1lLCBub3Q8YnI+DQp0aGUgc2VydmljZSBkb21h aW4gKHNlZSBkcmFmdC1pZXRmLWRhbmUtc3J2KS4gJm5ic3A7Rm9yIG5vbi1EQU5FIGNhc2VzLCBJ PGJyPg0KdGhpbmsgdGhhdCB0aGUgY29ycmVjdCB3YXkgdG8gc2VsZWN0IHRoZSBjZXJ0aWZpY2F0 ZSBpcyB0byB1c2UgU05JLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IGRvZXMgbm90IHN1Z2dlc3QgdGhhdCBPUklH SU4gYmUgdXNlZCB0byBzZWxlY3QgY2VydGlmaWNhdGVzIC0gYXMgT2xlZyBwb2ludGVkIG91dCBp dCBpc24ndCBwb3NzaWJsZS4gJm5ic3A7VGhpcyBwYXJhZ3JhcGggd2FzIGRlc2NyaWJpbmcgaG93 IFJGQyA2MDY2IGRvZXMgbm90IHNvbHZlIHRoZSBwcm9ibGVtLCBhcyBoYWQgYmVlbiBzdWdnZXN0 ZWQgb24gdGhlIGxpc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNvIEkgd291bGQgc3VnZ2VzdCB0byByZXN0cmljdCB0 aGUgbm9ybWF0aXZlIHVzZSBvZiBPUklHSU4gb25seSB0bzxicj4NCnNlbGVjdCByZWFsbXMuPGJy Pg0KPGJyPg0KQTQuIFNlY3Rpb24gMi4yLiBPUklHSU4gYXR0cmlidXRlIHVzYWdlPGJyPg0KPGJy Pg0KVGhlIHRleHQgZG9lcyBub3Qgc2F5IGlmIHRoZSBPUklHSU4gYXR0cmlidXRlIHNob3VsZC9j YW4gYmUgcHJvdmlkZWQ8YnI+DQphZnRlciB0aGUgYXV0aGVudGljYXRpb24gKGkuZS4gcmVmcmVz aCwgZGF0YSBwYWNrZXRzLCBldGMuLi4pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DdXJyZW50bHksIHRoZSB0ZXh0IHNheXMgU0hP VUxEIGluY2x1ZGUsIGZvciBhIGNvbmZvcm1hbnQgY2xpZW50LiAmbmJzcDtGb3IgbG9nZ2luZywg aXQgaGFzIHZhbHVlIGV2ZW4gYWZ0ZXIgdGhlIGluaXRpYWwgYXV0aGVudGljYXRpb24uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQTUuIFNlY3Rpb24gMi4yLiAmbmJzcDtN YW5kYXRvcnkgc3VwcG9ydCBmb3Igc2VydmVyPGJyPg0KPGJyPg0KSG93IGEgVFVSTiBzZXJ2ZXIg dGhhdCByZXF1aXJlcyB0aGUgdXNhZ2Ugb2YgT1JJR0lOIGNhbiBzaWduYWwgdGhpcz88bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJp Z2h0IG5vdyB0aGVyZSBpcyBubyB3YXkgdG8gZG8gdGhpcy4gJm5ic3A7SSBhZ3JlZSB3aXRoIE9s ZWcgdGhhdCBpdCBpcyB1cCB0byB0aGUgc2VydmVyIHdoYXQgdG8gZG8gaWYgT1JJR0lOIGlzIG5v IHByZXNlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QTYuIFNlY3Rpb24gMi4g T3RoZXIgVXNhZ2VzPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IG90aGVyIFNUVU4gVXNhZ2VzIHNo b3VsZCBiZSBsaXN0ZWQgYWZ0ZXIgc2VjdGlvbiAyLjM6PGJyPg0KPGJyPg0KLSBNZWRpYSBLZWVw LUFsaXZlIFVzYWdlIChTZWN0aW9uIDIwIG9mIFJGQzUyNDUpPGJyPg0KLSBTSVAgS2VlcC1BbGl2 ZSBVc2FnZSAoUkZDIDU2MjYpPGJyPg0KLSBOQVQgQmVoYXZpb3IgRGlzY292ZXJ5IFVzYWdlIChS RkMgNTc4MCk8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkknbGwgdGFrZSBhIGxvb2sgYXQgdGhlc2Ugc2NlbmFyaW9zLiAmbmJzcDtJ IHN1c3BlY3QgdGhhdCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgdXNhZ2UgZm9yIGNsaWVudC10 by1zZXJ2ZXIgdXNhZ2VzLCBidXQgbm90IGZvciBwZWVyLXRvLXBlZXIgdXNhZ2VzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkE3LiBTZWN0aW9uIDQsIDNyZCBwYXJhZ3JhcGg6ICZx dW90O0lmIHRoZSBTVFVOIE1FU1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0ZTxicj4NCmlzIHByZXNl bnQsIHRoZSBjb250ZW50cyBvZiB0aGUgT1JJR0lOIGF0dHJpYnV0ZSBhcmUgaW50ZWdyaXR5IHBy b3RlY3RlZC4mcXVvdDs8YnI+DQo8YnI+DQpXaGljaCBuZXZlciBoYXBwZW4gaW4gdGhlIHVzYWdl cyBsaXN0ZWQgaW4gdGhlIGRvY3VtZW50OiAmbmJzcDtmb3Igc2VjdGlvbjxicj4NCjIuMSwgdGhl cmUgaXMgbmV2ZXIgYW4gaW50ZWdyaXR5IHByb3RlY3Rpb24sIGFuZCBmb3IgMi4yLCB0aGUgT1JJ R0lOIGlzPGJyPg0KbmVlZGVkIHRvIHNlbGVjdCB0aGUgcmVhbG0sIHNvIHRoZSBPUklHSU4gaXMg c2VudCBiZWZvcmUgaXQgY2FuIGJlPGJyPg0KcHJvdGVjdGVkLiAmbmJzcDtQZXJoYXBzIDIuMiBz aG91bGQgc2F5IHRoYXQgaWYgT1JJR0lOIHdhcyBzZW50IHRvIHNlbGVjdCB0aGU8YnI+DQpyZWFs bSwgaXQgTVVTVCBiZSByZXBlYXRlZCBhdCBpZGVudGljYWwgb24gdGhlIHNlY29uZCBBbGxvY2F0 ZSAodGhlIG9uZTxicj4NCnRoYXQgaGFzIGFuIE0tSSkgYW5kIHRoYXQgdGhlIHNlcnZlciBNVVNU IHJlamVjdCBpdCBpZiBpdCBpcyBub3Q8YnI+DQppZGVudGljYWwgdG8gdGhlIGZpcnN0IG9uZS4g Jm5ic3A7Tm90IHN1cmUgaXQgbWF0dGVycyB0aG91Z2guPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdGhlcmUg aXMgbm8gaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIE9SSUdJTiBhdHRyaWJ1dGUgKG9yIGFu eSBvdGhlciBhdHRyaWJ1dGUpIHVudGlsIGFmdGVyIGF1dGhlbnRpY2F0aW9uLiAmbmJzcDtIb3dl dmVyLCBPUklHSU4gY2FuIGJlIHVzZWQgYm90aCBiZWZvcmUgYW5kIGFmdGVyIGF1dGhlbnRpY2F0 aW9uLiAmbmJzcDtJJ2xsIHJldmlldyB0aGlzIHRleHQgYW5kIG1ha2Ugc3VyZSB0aGlzIGlzIGNs ZWFyLg0KICZuYnNwO0kgZG9uJ3QgYmVsaWV2ZSB3ZSBuZWVkIGFueSBzcGVjaWFsIHJ1bGVzLCBh cyB0aGlzIGFwcGxpZXMgdG8gYW55IFNUVU4gYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OaXRzPGJyPg0KLS0tLTxi cj4NCjxicj4NCi0gU2VjdGlvbiAyLCAybmQgcGFyYWdyYXBoOiAmcXVvdDtUaGUgbnVtYmVyIHVz ZWQgZm9yIHRoZSB0aGlzIGluIHRoZSAuLi4mcXVvdDs8YnI+DQo8YnI+DQpEb2VzIG5vdCBwYXJz ZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBtaWRkbGUgJnF1b3Q7dGhlJnF1b3Q7IHNob3VsZG4ndCBiZSB0aGVyZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imhv ZW56YiI+TWFyYyBQZXRpdC1IdWd1ZW5pbjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpi Ij5EZXZlbG9wZXIgJm5ic3A7fCAmbmJzcDtKaXZlIENvbW11bmljYXRpb25zLCBJbmMuPC9zcGFu Pjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkppdmUuY29tICZuYnNwO3wgJm5ic3A7PGEgaHJl Zj0ibWFpbHRvOm1hcmNwaEBnZXRqaXZlLmNvbSI+bWFyY3BoQGdldGppdmUuY29tPC9hPjwvc3Bh bj48YnI+DQo8YnI+DQo8L3NwYW4+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17DE3241MCHP04MSXglobal_-- From nobody Thu Jun 5 07:26:44 2014 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 24D6C1A016C for ; Thu, 5 Jun 2014 07:26:38 -0700 (PDT) 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 d0zUZaqXyYPR for ; Thu, 5 Jun 2014 07:26:36 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE8D1A0167 for ; Thu, 5 Jun 2014 07:26:34 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so1157700pde.28 for ; Thu, 05 Jun 2014 07:26:27 -0700 (PDT) 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=nynNX0a7jdlJquX1d+gH+rsW8Dw/69KVTK6Es9drHhs=; b=UnYe2wuyR3xdAxAQvUlEN0NpJRgnUi0YRpUW6Ln6NyasmBa6TjAuSCTRtyVDmjzKIc 0nftqFmsD4XaA5ELfIK5RgVf1z3Pm6TtDjNmnNEuyl9xL30lLTupE8UakDXphqCA42Eg Nnck5qyC4TZG/QEmUf9R1ynQjKv8L+T5btitM34p5SacLSzoap6t4XPefL8X212q8xEK m+7H2NCDEDIbYrfpxzESBYnPY9qAfmjv9rPCdlUT/K9pcwGTkP0cfZLPyb+yJf8F1HhF s8TtFA5fGi2DLzfwMT5utpbf4rEvjXUHIzi/dPKMCnH54SD9IGh8uTmR1nsmC/YmSn1M 0Ovg== X-Received: by 10.68.135.100 with SMTP id pr4mr10689444pbb.46.1401978387783; Thu, 05 Jun 2014 07:26:27 -0700 (PDT) Received: from [172.17.17.106] (c-76-126-9-134.hsd1.ca.comcast.net. [76.126.9.134]) by mx.google.com with ESMTPSA id qj3sm23490561pbc.91.2014.06.05.07.26.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 07:26:26 -0700 (PDT) References: <5368BF90.2070307@getjive.com> <9F33F40F6F2CD847824537F3C4E37DDF17DE3241@MCHP04MSX.global-ad.net> Mime-Version: 1.0 (1.0) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17DE3241@MCHP04MSX.global-ad.net> Content-Type: multipart/alternative; boundary=Apple-Mail-68668793-D0EB-4E6B-B6F4-3439ACCFECA7 Content-Transfer-Encoding: 7bit Message-Id: <166C39DF-CA68-4C9C-8553-197C2C75B382@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Thu, 5 Jun 2014 07:26:21 -0700 To: "Hutton, Andrew" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sKySV2ddg_65IjVDiNL9Y5HXph4 Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 05 Jun 2014 14:26:38 -0000 --Apple-Mail-68668793-D0EB-4E6B-B6F4-3439ACCFECA7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable What would be the purpose of multiple origins ? Oleg > On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" wro= te: >=20 > Hi, > =20 > I had another read through this draft and hope we can move this forward an= d adopt the draft soon. > =20 > I only have one additional comment at this time and that is that I assume i= t should be possible for the client to include more than one origin in the O= rigin header field and if so the procedures around this should explained in t= he draft. > =20 > Regards > Andy > =20 > =20 > =20 > =20 > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: 07 May 2014 18:50 > To: Marc Petit-Huguenin > Cc: tram@ietf.org > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 > =20 > Marc, > =20 > Thanks for the review. See my comments below. > =20 > - Alan - > =20 >=20 > On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin w= rote: > A1. Intended Status: Informational >=20 > Shouldn't this be Standard Track? >=20 > =20 > Yes. > =20 > A2. Section 1, 2nd paragraph, last sentence: "as generating the response..= ." >=20 > I do not think that the reason for no authentication for the NAT > Discovery Usage is because it is less work, but because there is no > resource to protect so adding more work does not make sense. >=20 > =20 > I disagree that there is *no* resource to protect. A STUN server might be= minimal resources, but not none. If a simple authentication scheme were av= ailable, I'm sure some people would use it so they could minimize the cost o= f their server footprint by ensuring that only authenticated users were util= izing it. I will add some text pointing out that the minimal resources. > =20 > A3. Section 1, 8th paragraph >=20 > I do not think that the ORIGIN should be used to select the certificate > when (D)TLS is used. First it does not work with DANE, as when an SRV > (and probably NAPTR too, but that's undefined yet) RR redirects to a > different domain, the domain to be checked with is the host name, not > the service domain (see draft-ietf-dane-srv). For non-DANE cases, I > think that the correct way to select the certificate is to use SNI. > =20 > The draft does not suggest that ORIGIN be used to select certificates - as= Oleg pointed out it isn't possible. This paragraph was describing how RFC 6= 066 does not solve the problem, as had been suggested on the list. > =20 >=20 > So I would suggest to restrict the normative use of ORIGIN only to > select realms. >=20 > A4. Section 2.2. ORIGIN attribute usage >=20 > The text does not say if the ORIGIN attribute should/can be provided > after the authentication (i.e. refresh, data packets, etc...) > =20 > Currently, the text says SHOULD include, for a conformant client. For log= ging, it has value even after the initial authentication. > =20 >=20 > A5. Section 2.2. Mandatory support for server >=20 > How a TURN server that requires the usage of ORIGIN can signal this? >=20 > =20 > Right now there is no way to do this. I agree with Oleg that it is up to t= he server what to do if ORIGIN is no present. > =20 > A6. Section 2. Other Usages >=20 > I think that other STUN Usages should be listed after section 2.3: >=20 > - Media Keep-Alive Usage (Section 20 of RFC5245) > - SIP Keep-Alive Usage (RFC 5626) > - NAT Behavior Discovery Usage (RFC 5780) >=20 > =20 > I'll take a look at these scenarios. I suspect that it would be a reasona= ble usage for client-to-server usages, but not for peer-to-peer usages. > =20 > A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute > is present, the contents of the ORIGIN attribute are integrity protected."= >=20 > Which never happen in the usages listed in the document: for section > 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is > needed to select the realm, so the ORIGIN is sent before it can be > protected. Perhaps 2.2 should say that if ORIGIN was sent to select the > realm, it MUST be repeated at identical on the second Allocate (the one > that has an M-I) and that the server MUST reject it if it is not > identical to the first one. Not sure it matters though. >=20 > =20 > I agree that there is no integrity protection of the ORIGIN attribute (or a= ny other attribute) until after authentication. However, ORIGIN can be used= both before and after authentication. I'll review this text and make sure t= his is clear. I don't believe we need any special rules, as this applies to= any STUN attribute. > =20 > Nits > ---- >=20 > - Section 2, 2nd paragraph: "The number used for the this in the ..." >=20 > Does not parse. > =20 > The middle "the" shouldn't be there. > =20 >=20 > -- > Marc Petit-Huguenin > Developer | Jive Communications, Inc. > Jive.com | marcph@getjive.com >=20 >=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 --Apple-Mail-68668793-D0EB-4E6B-B6F4-3439ACCFECA7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
What would be the purpose of multiple origins ?

Oleg

On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" <andrew.hutton@unify.com> wrote:

Hi,

 

I had another read through this draft and hope we can move this forward and adopt the draft soon.

 

I only have one additional comment at this time and that is that I assume it should be possible for the client to include more than one origin in the Origin header field and if so the procedures around this should explained in the draft.

 

Regards

Andy

 

 

 

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston
Sent: 07 May 2014 18:50
To: Marc Petit-Huguenin
Cc: tram@ietf.org
Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02

 

Marc,

 

Thanks for the review.  See my comments below.

 

- Alan -

 

On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin <marcph@getjive.com> wrote:

A1. Intended Status: Informational

Shouldn't this be Standard Track?

 

Yes.

 

A2. Section 1, 2nd paragraph, last sentence: "as generating the response..."

I do not think that the reason for no authentication for the NAT
Discovery Usage is because it is less work, but because there is no
resource to protect so adding more work does not make sense.

 

I disagree that there is *no* resource to protect.  A STUN server might be minimal resources, but not none.  If a simple authentication scheme were available, I'm sure some people would use it so they could minimize the cost of their server footprint by ensuring that only authenticated users were utilizing it.  I will add some text pointing out that the minimal resources.

 

A3. Section 1, 8th paragraph

I do not think that the ORIGIN should be used to select the certificate
when (D)TLS is used.  First it does not work with DANE, as when an SRV
(and probably NAPTR too, but that's undefined yet) RR redirects to a
different domain, the domain to be checked with is the host name, not
the service domain (see draft-ietf-dane-srv).  For non-DANE cases, I
think that the correct way to select the certificate is to use SNI.

 

The draft does not suggest that ORIGIN be used to select certificates - as Oleg pointed out it isn't possible.  This paragraph was describing how RFC 6066 does not solve the problem, as had been suggested on the list.

 


So I would suggest to restrict the normative use of ORIGIN only to
select realms.

A4. Section 2.2. ORIGIN attribute usage

The text does not say if the ORIGIN attribute should/can be provided
after the authentication (i.e. refresh, data packets, etc...)

 

Currently, the text says SHOULD include, for a conformant client.  For logging, it has value even after the initial authentication.

 


A5. Section 2.2.  Mandatory support for server

How a TURN server that requires the usage of ORIGIN can signal this?

 

Right now there is no way to do this.  I agree with Oleg that it is up to the server what to do if ORIGIN is no present.

 

A6. Section 2. Other Usages

I think that other STUN Usages should be listed after section 2.3:

- Media Keep-Alive Usage (Section 20 of RFC5245)
- SIP Keep-Alive Usage (RFC 5626)
- NAT Behavior Discovery Usage (RFC 5780)

 

I'll take a look at these scenarios.  I suspect that it would be a reasonable usage for client-to-server usages, but not for peer-to-peer usages.

 

A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute
is present, the contents of the ORIGIN attribute are integrity protected."

Which never happen in the usages listed in the document:  for section
2.1, there is never an integrity protection, and for 2.2, the ORIGIN is
needed to select the realm, so the ORIGIN is sent before it can be
protected.  Perhaps 2.2 should say that if ORIGIN was sent to select the
realm, it MUST be repeated at identical on the second Allocate (the one
that has an M-I) and that the server MUST reject it if it is not
identical to the first one.  Not sure it matters though.

 

I agree that there is no integrity protection of the ORIGIN attribute (or any other attribute) until after authentication.  However, ORIGIN can be used both before and after authentication.  I'll review this text and make sure this is clear.  I don't believe we need any special rules, as this applies to any STUN attribute.

 

Nits
----

- Section 2, 2nd paragraph: "The number used for the this in the ..."

Does not parse.

 

The middle "the" shouldn't be there.

 


--
Marc Petit-Huguenin
Developer  |  Jive Communications, Inc.
Jive.com  |  marcph@getjive.com


_______________________________________________
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
--Apple-Mail-68668793-D0EB-4E6B-B6F4-3439ACCFECA7-- From nobody Thu Jun 5 07:50:08 2014 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 AD7AC1A0239 for ; Thu, 5 Jun 2014 07:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 VPBV4Ovs9ZD8 for ; Thu, 5 Jun 2014 07:50:00 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2C1A0269 for ; Thu, 5 Jun 2014 07:49:01 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 47AF91EB8635; Thu, 5 Jun 2014 16:48:54 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.222]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 16:48:54 +0200 From: "Hutton, Andrew" To: Oleg Moskalenko Thread-Topic: [tram] Review of draft-johnston-tram-stun-origin-02 Thread-Index: AQHPahzB4IMeNSxSMk2xnnCULaae0JtivROQ///haoCAACdVAA== Date: Thu, 5 Jun 2014 14:48:53 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17DE3355@MCHP04MSX.global-ad.net> References: <5368BF90.2070307@getjive.com> <9F33F40F6F2CD847824537F3C4E37DDF17DE3241@MCHP04MSX.global-ad.net> <166C39DF-CA68-4C9C-8553-197C2C75B382@gmail.com> In-Reply-To: <166C39DF-CA68-4C9C-8553-197C2C75B382@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fOM2T9zYgWJzmh7q9efSUq9zWS0 Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 05 Jun 2014 14:50:02 -0000 TXVsdGlwbGUgT3JpZ2lucyBmb3IgSFRUUCBSZXF1ZXN0cyBhcmUgY292ZXJlZCBpbiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NDU0I3NlY3Rpb24tNy4yIEkganVzdCBhc3N1bWVkIHRo ZSBzYW1lIHdvdWxkIGFwcGx5IHRvIHRoZSB1c2FnZSBpbiB0aGlzIGNvbnRleHQuDQoNCkFuZHkN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGVnIE1vc2thbGVua28g W21haWx0bzptb20wNDAyNjdAZ21haWwuY29tXQ0KPiBTZW50OiAwNSBKdW5lIDIwMTQgMTU6MjYN Cj4gVG86IEh1dHRvbiwgQW5kcmV3DQo+IENjOiBBbGFuIEpvaG5zdG9uOyB0cmFtQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gUmV2aWV3IG9mIGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1 bi1vcmlnaW4tMDINCj4gDQo+IFdoYXQgd291bGQgYmUgdGhlIHB1cnBvc2Ugb2YgbXVsdGlwbGUg b3JpZ2lucyA/DQo+IA0KPiBPbGVnDQo+IA0KPiBPbiBKdW4gNSwgMjAxNCwgYXQgNzoxOSBBTSwg Ikh1dHRvbiwgQW5kcmV3IiA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20+DQo+IHdyb3RlOg0KPiBI aSwNCj4gDQo+IEkgaGFkIGFub3RoZXIgcmVhZCB0aHJvdWdoIHRoaXMgZHJhZnQgYW5kIGhvcGUg d2UgY2FuIG1vdmUgdGhpcyBmb3J3YXJkDQo+IGFuZCBhZG9wdCB0aGUgZHJhZnQgc29vbi4NCj4g DQo+IEkgb25seSBoYXZlIG9uZSBhZGRpdGlvbmFsIGNvbW1lbnQgYXQgdGhpcyB0aW1lIGFuZCB0 aGF0IGlzIHRoYXQgSQ0KPiBhc3N1bWUgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIGZvciB0aGUgY2xp ZW50IHRvIGluY2x1ZGUgbW9yZSB0aGFuIG9uZQ0KPiBvcmlnaW4gaW4gdGhlIE9yaWdpbiBoZWFk ZXIgZmllbGQgYW5kIGlmIHNvIHRoZSBwcm9jZWR1cmVzIGFyb3VuZCB0aGlzDQo+IHNob3VsZCBl eHBsYWluZWQgaW4gdGhlIGRyYWZ0Lg0KPiANCj4gUmVnYXJkcw0KPiBBbmR5DQo+IA0KPiANCj4g DQo+IA0KPiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWxhbiBKb2huc3Rvbg0KPiBTZW50OiAwNyBNYXkgMjAxNCAxODo1MA0KPiBUbzogTWFy YyBQZXRpdC1IdWd1ZW5pbg0KPiBDYzogdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Ry YW1dIFJldmlldyBvZiBkcmFmdC1qb2huc3Rvbi10cmFtLXN0dW4tb3JpZ2luLTAyDQo+IA0KPiBN YXJjLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgcmV2aWV3LiDCoFNlZSBteSBjb21tZW50cyBiZWxv dy4NCj4gDQo+IC0gQWxhbiAtDQo+IA0KPiBPbiBUdWUsIE1heSA2LCAyMDE0IGF0IDU6NTUgQU0s IE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gPG1hcmNwaEBnZXRqaXZlLmNvbT4gd3JvdGU6DQo+IEEx LiBJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWwNCj4gDQo+IFNob3VsZG4ndCB0aGlzIGJl IFN0YW5kYXJkIFRyYWNrPw0KPiANCj4gWWVzLg0KPiANCj4gQTIuIFNlY3Rpb24gMSwgMm5kIHBh cmFncmFwaCwgbGFzdCBzZW50ZW5jZTogImFzIGdlbmVyYXRpbmcgdGhlDQo+IHJlc3BvbnNlLi4u Ig0KPiANCj4gSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgcmVhc29uIGZvciBubyBhdXRoZW50aWNh dGlvbiBmb3IgdGhlIE5BVA0KPiBEaXNjb3ZlcnkgVXNhZ2UgaXMgYmVjYXVzZSBpdCBpcyBsZXNz IHdvcmssIGJ1dCBiZWNhdXNlIHRoZXJlIGlzIG5vDQo+IHJlc291cmNlIHRvIHByb3RlY3Qgc28g YWRkaW5nIG1vcmUgd29yayBkb2VzIG5vdCBtYWtlIHNlbnNlLg0KPiANCj4gSSBkaXNhZ3JlZSB0 aGF0IHRoZXJlIGlzICpubyogcmVzb3VyY2UgdG8gcHJvdGVjdC4gwqBBIFNUVU4gc2VydmVyIG1p Z2h0DQo+IGJlIG1pbmltYWwgcmVzb3VyY2VzLCBidXQgbm90IG5vbmUuIMKgSWYgYSBzaW1wbGUg YXV0aGVudGljYXRpb24gc2NoZW1lDQo+IHdlcmUgYXZhaWxhYmxlLCBJJ20gc3VyZSBzb21lIHBl b3BsZSB3b3VsZCB1c2UgaXQgc28gdGhleSBjb3VsZA0KPiBtaW5pbWl6ZSB0aGUgY29zdCBvZiB0 aGVpciBzZXJ2ZXIgZm9vdHByaW50IGJ5IGVuc3VyaW5nIHRoYXQgb25seQ0KPiBhdXRoZW50aWNh dGVkIHVzZXJzIHdlcmUgdXRpbGl6aW5nIGl0LiDCoEkgd2lsbCBhZGQgc29tZSB0ZXh0IHBvaW50 aW5nDQo+IG91dCB0aGF0IHRoZSBtaW5pbWFsIHJlc291cmNlcy4NCj4gDQo+IEEzLiBTZWN0aW9u IDEsIDh0aCBwYXJhZ3JhcGgNCj4gDQo+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIE9SSUdJTiBz aG91bGQgYmUgdXNlZCB0byBzZWxlY3QgdGhlIGNlcnRpZmljYXRlDQo+IHdoZW4gKEQpVExTIGlz IHVzZWQuIMKgRmlyc3QgaXQgZG9lcyBub3Qgd29yayB3aXRoIERBTkUsIGFzIHdoZW4gYW4gU1JW DQo+IChhbmQgcHJvYmFibHkgTkFQVFIgdG9vLCBidXQgdGhhdCdzIHVuZGVmaW5lZCB5ZXQpIFJS IHJlZGlyZWN0cyB0byBhDQo+IGRpZmZlcmVudCBkb21haW4sIHRoZSBkb21haW4gdG8gYmUgY2hl Y2tlZCB3aXRoIGlzIHRoZSBob3N0IG5hbWUsIG5vdA0KPiB0aGUgc2VydmljZSBkb21haW4gKHNl ZSBkcmFmdC1pZXRmLWRhbmUtc3J2KS4gwqBGb3Igbm9uLURBTkUgY2FzZXMsIEkNCj4gdGhpbmsg dGhhdCB0aGUgY29ycmVjdCB3YXkgdG8gc2VsZWN0IHRoZSBjZXJ0aWZpY2F0ZSBpcyB0byB1c2Ug U05JLg0KPiANCj4gVGhlIGRyYWZ0IGRvZXMgbm90IHN1Z2dlc3QgdGhhdCBPUklHSU4gYmUgdXNl ZCB0byBzZWxlY3QgY2VydGlmaWNhdGVzIC0NCj4gYXMgT2xlZyBwb2ludGVkIG91dCBpdCBpc24n dCBwb3NzaWJsZS4gwqBUaGlzIHBhcmFncmFwaCB3YXMgZGVzY3JpYmluZw0KPiBob3cgUkZDIDYw NjYgZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0sIGFzIGhhZCBiZWVuIHN1Z2dlc3RlZCBvbiB0 aGUNCj4gbGlzdC4NCj4gDQo+IA0KPiBTbyBJIHdvdWxkIHN1Z2dlc3QgdG8gcmVzdHJpY3QgdGhl IG5vcm1hdGl2ZSB1c2Ugb2YgT1JJR0lOIG9ubHkgdG8NCj4gc2VsZWN0IHJlYWxtcy4NCj4gDQo+ IEE0LiBTZWN0aW9uIDIuMi4gT1JJR0lOIGF0dHJpYnV0ZSB1c2FnZQ0KPiANCj4gVGhlIHRleHQg ZG9lcyBub3Qgc2F5IGlmIHRoZSBPUklHSU4gYXR0cmlidXRlIHNob3VsZC9jYW4gYmUgcHJvdmlk ZWQNCj4gYWZ0ZXIgdGhlIGF1dGhlbnRpY2F0aW9uIChpLmUuIHJlZnJlc2gsIGRhdGEgcGFja2V0 cywgZXRjLi4uKQ0KPiANCj4gQ3VycmVudGx5LCB0aGUgdGV4dCBzYXlzIFNIT1VMRCBpbmNsdWRl LCBmb3IgYSBjb25mb3JtYW50IGNsaWVudC4gwqBGb3INCj4gbG9nZ2luZywgaXQgaGFzIHZhbHVl IGV2ZW4gYWZ0ZXIgdGhlIGluaXRpYWwgYXV0aGVudGljYXRpb24uDQo+IA0KPiANCj4gQTUuIFNl Y3Rpb24gMi4yLiDCoE1hbmRhdG9yeSBzdXBwb3J0IGZvciBzZXJ2ZXINCj4gDQo+IEhvdyBhIFRV Uk4gc2VydmVyIHRoYXQgcmVxdWlyZXMgdGhlIHVzYWdlIG9mIE9SSUdJTiBjYW4gc2lnbmFsIHRo aXM/DQo+IA0KPiBSaWdodCBub3cgdGhlcmUgaXMgbm8gd2F5IHRvIGRvIHRoaXMuIMKgSSBhZ3Jl ZSB3aXRoIE9sZWcgdGhhdCBpdCBpcyB1cA0KPiB0byB0aGUgc2VydmVyIHdoYXQgdG8gZG8gaWYg T1JJR0lOIGlzIG5vIHByZXNlbnQuDQo+IA0KPiBBNi4gU2VjdGlvbiAyLiBPdGhlciBVc2FnZXMN Cj4gDQo+IEkgdGhpbmsgdGhhdCBvdGhlciBTVFVOIFVzYWdlcyBzaG91bGQgYmUgbGlzdGVkIGFm dGVyIHNlY3Rpb24gMi4zOg0KPiANCj4gLSBNZWRpYSBLZWVwLUFsaXZlIFVzYWdlIChTZWN0aW9u IDIwIG9mIFJGQzUyNDUpDQo+IC0gU0lQIEtlZXAtQWxpdmUgVXNhZ2UgKFJGQyA1NjI2KQ0KPiAt IE5BVCBCZWhhdmlvciBEaXNjb3ZlcnkgVXNhZ2UgKFJGQyA1NzgwKQ0KPiANCj4gSSdsbCB0YWtl IGEgbG9vayBhdCB0aGVzZSBzY2VuYXJpb3MuIMKgSSBzdXNwZWN0IHRoYXQgaXQgd291bGQgYmUg YQ0KPiByZWFzb25hYmxlIHVzYWdlIGZvciBjbGllbnQtdG8tc2VydmVyIHVzYWdlcywgYnV0IG5v dCBmb3IgcGVlci10by1wZWVyDQo+IHVzYWdlcy4NCj4gDQo+IEE3LiBTZWN0aW9uIDQsIDNyZCBw YXJhZ3JhcGg6ICJJZiB0aGUgU1RVTiBNRVNTQUdFLUlOVEVHUklUWSBhdHRyaWJ1dGUNCj4gaXMg cHJlc2VudCwgdGhlIGNvbnRlbnRzIG9mIHRoZSBPUklHSU4gYXR0cmlidXRlIGFyZSBpbnRlZ3Jp dHkNCj4gcHJvdGVjdGVkLiINCj4gDQo+IFdoaWNoIG5ldmVyIGhhcHBlbiBpbiB0aGUgdXNhZ2Vz IGxpc3RlZCBpbiB0aGUgZG9jdW1lbnQ6IMKgZm9yIHNlY3Rpb24NCj4gMi4xLCB0aGVyZSBpcyBu ZXZlciBhbiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgYW5kIGZvciAyLjIsIHRoZSBPUklHSU4gaXMN Cj4gbmVlZGVkIHRvIHNlbGVjdCB0aGUgcmVhbG0sIHNvIHRoZSBPUklHSU4gaXMgc2VudCBiZWZv cmUgaXQgY2FuIGJlDQo+IHByb3RlY3RlZC4gwqBQZXJoYXBzIDIuMiBzaG91bGQgc2F5IHRoYXQg aWYgT1JJR0lOIHdhcyBzZW50IHRvIHNlbGVjdA0KPiB0aGUNCj4gcmVhbG0sIGl0IE1VU1QgYmUg cmVwZWF0ZWQgYXQgaWRlbnRpY2FsIG9uIHRoZSBzZWNvbmQgQWxsb2NhdGUgKHRoZSBvbmUNCj4g dGhhdCBoYXMgYW4gTS1JKSBhbmQgdGhhdCB0aGUgc2VydmVyIE1VU1QgcmVqZWN0IGl0IGlmIGl0 IGlzIG5vdA0KPiBpZGVudGljYWwgdG8gdGhlIGZpcnN0IG9uZS4gwqBOb3Qgc3VyZSBpdCBtYXR0 ZXJzIHRob3VnaC4NCj4gDQo+IEkgYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBpbnRlZ3JpdHkgcHJv dGVjdGlvbiBvZiB0aGUgT1JJR0lOIGF0dHJpYnV0ZQ0KPiAob3IgYW55IG90aGVyIGF0dHJpYnV0 ZSkgdW50aWwgYWZ0ZXIgYXV0aGVudGljYXRpb24uIMKgSG93ZXZlciwgT1JJR0lODQo+IGNhbiBi ZSB1c2VkIGJvdGggYmVmb3JlIGFuZCBhZnRlciBhdXRoZW50aWNhdGlvbi4gwqBJJ2xsIHJldmll dyB0aGlzDQo+IHRleHQgYW5kIG1ha2Ugc3VyZSB0aGlzIGlzIGNsZWFyLiDCoEkgZG9uJ3QgYmVs aWV2ZSB3ZSBuZWVkIGFueSBzcGVjaWFsDQo+IHJ1bGVzLCBhcyB0aGlzIGFwcGxpZXMgdG8gYW55 IFNUVU4gYXR0cmlidXRlLg0KPiANCj4gTml0cw0KPiAtLS0tDQo+IA0KPiAtIFNlY3Rpb24gMiwg Mm5kIHBhcmFncmFwaDogIlRoZSBudW1iZXIgdXNlZCBmb3IgdGhlIHRoaXMgaW4gdGhlIC4uLiIN Cj4gDQo+IERvZXMgbm90IHBhcnNlLg0KPiANCj4gVGhlIG1pZGRsZSAidGhlIiBzaG91bGRuJ3Qg YmUgdGhlcmUuDQo+IA0KPiANCj4gLS0NCj4gTWFyYyBQZXRpdC1IdWd1ZW5pbg0KPiBEZXZlbG9w ZXIgwqB8IMKgSml2ZSBDb21tdW5pY2F0aW9ucywgSW5jLg0KPiBKaXZlLmNvbSDCoHwgwqBtYXJj cGhAZ2V0aml2ZS5jb20NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5n IGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyYW0NCg== From nobody Thu Jun 5 12:56:05 2014 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 CBDB81A025B for ; Thu, 5 Jun 2014 12:55:56 -0700 (PDT) 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 1aZLtEpkp0V7 for ; Thu, 5 Jun 2014 12:55:55 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8152F1A018E for ; Thu, 5 Jun 2014 12:55:54 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so1687536wes.40 for ; Thu, 05 Jun 2014 12:55:46 -0700 (PDT) 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=jEUtiPaEdOWPGZB3wGLstAdu9rles9lXznsf876tSH0=; b=UPSqsTrOtY/3R6Geg31/mg7+mKzncoSLltdYt1isPOpP0Jv4c4IzCpYisEjvutBnvS p63OwWcAoGViR2lTGfxF3jLT0PkNk+qYUhK14Rk+JMjFs2RdnZ8pk0YPJyA4YPypZVq6 cY46Xu2lgfguiZdnEFZmALVsyTZWMMBm0HrWptURRb6njep5K0Om4qJbqsafbyu8b1FU f5sBLlLPfESBVEA/zS3zQtQOnLpP6939DbX9lBmPzigZ5XXH1mEt3QQwRN6tl8vkJJZ5 hX4oaT3tdq4a8I6MbA/OfiSclTE25DdvYTUw/iPoVSuwE8Y99bSVpySVs5869ifCTgig 965g== MIME-Version: 1.0 X-Received: by 10.194.82.170 with SMTP id j10mr85776998wjy.63.1401998146802; Thu, 05 Jun 2014 12:55:46 -0700 (PDT) Received: by 10.194.120.71 with HTTP; Thu, 5 Jun 2014 12:55:46 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17DE3355@MCHP04MSX.global-ad.net> References: <5368BF90.2070307@getjive.com> <9F33F40F6F2CD847824537F3C4E37DDF17DE3241@MCHP04MSX.global-ad.net> <166C39DF-CA68-4C9C-8553-197C2C75B382@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17DE3355@MCHP04MSX.global-ad.net> Date: Thu, 5 Jun 2014 12:55:46 -0700 Message-ID: From: Oleg Moskalenko To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=047d7bb04fee843af704fb1c2177 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/R_p0uJniSxbZaymU1XWnEAAbeLY Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 05 Jun 2014 19:55:57 -0000 --047d7bb04fee843af704fb1c2177 Content-Type: text/plain; charset=UTF-8 If we do want to support multiple origins per request then we have to state, clearly, three things: 1) Use cases. 2) How we use multiple origins when we process the request. 3) How we format multiple origins in the request - as comma-separated single field or multiple origin attributes. As STUN/TURN is a binary protocol, I think that the second option is better. The usefulness of multiple origins in TURN is not very obvious to me. I implemented ORIGIN in a pilot implementation https://code.google.com/p/coturn/ but I assumed a single ORIGIN field per request. Oleg On Thu, Jun 5, 2014 at 7:48 AM, Hutton, Andrew wrote: > Multiple Origins for HTTP Requests are covered in > http://tools.ietf.org/html/rfc6454#section-7.2 I just assumed the same > would apply to the usage in this context. > > Andy > > > -----Original Message----- > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > > Sent: 05 June 2014 15:26 > > To: Hutton, Andrew > > Cc: Alan Johnston; tram@ietf.org > > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 > > > > What would be the purpose of multiple origins ? > > > > Oleg > > > > On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" > > wrote: > > Hi, > > > > I had another read through this draft and hope we can move this forward > > and adopt the draft soon. > > > > I only have one additional comment at this time and that is that I > > assume it should be possible for the client to include more than one > > origin in the Origin header field and if so the procedures around this > > should explained in the draft. > > > > Regards > > Andy > > > > > > > > > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston > > Sent: 07 May 2014 18:50 > > To: Marc Petit-Huguenin > > Cc: tram@ietf.org > > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 > > > > Marc, > > > > Thanks for the review. See my comments below. > > > > - Alan - > > > > On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin > > wrote: > > A1. Intended Status: Informational > > > > Shouldn't this be Standard Track? > > > > Yes. > > > > A2. Section 1, 2nd paragraph, last sentence: "as generating the > > response..." > > > > I do not think that the reason for no authentication for the NAT > > Discovery Usage is because it is less work, but because there is no > > resource to protect so adding more work does not make sense. > > > > I disagree that there is *no* resource to protect. A STUN server might > > be minimal resources, but not none. If a simple authentication scheme > > were available, I'm sure some people would use it so they could > > minimize the cost of their server footprint by ensuring that only > > authenticated users were utilizing it. I will add some text pointing > > out that the minimal resources. > > > > A3. Section 1, 8th paragraph > > > > I do not think that the ORIGIN should be used to select the certificate > > when (D)TLS is used. First it does not work with DANE, as when an SRV > > (and probably NAPTR too, but that's undefined yet) RR redirects to a > > different domain, the domain to be checked with is the host name, not > > the service domain (see draft-ietf-dane-srv). For non-DANE cases, I > > think that the correct way to select the certificate is to use SNI. > > > > The draft does not suggest that ORIGIN be used to select certificates - > > as Oleg pointed out it isn't possible. This paragraph was describing > > how RFC 6066 does not solve the problem, as had been suggested on the > > list. > > > > > > So I would suggest to restrict the normative use of ORIGIN only to > > select realms. > > > > A4. Section 2.2. ORIGIN attribute usage > > > > The text does not say if the ORIGIN attribute should/can be provided > > after the authentication (i.e. refresh, data packets, etc...) > > > > Currently, the text says SHOULD include, for a conformant client. For > > logging, it has value even after the initial authentication. > > > > > > A5. Section 2.2. Mandatory support for server > > > > How a TURN server that requires the usage of ORIGIN can signal this? > > > > Right now there is no way to do this. I agree with Oleg that it is up > > to the server what to do if ORIGIN is no present. > > > > A6. Section 2. Other Usages > > > > I think that other STUN Usages should be listed after section 2.3: > > > > - Media Keep-Alive Usage (Section 20 of RFC5245) > > - SIP Keep-Alive Usage (RFC 5626) > > - NAT Behavior Discovery Usage (RFC 5780) > > > > I'll take a look at these scenarios. I suspect that it would be a > > reasonable usage for client-to-server usages, but not for peer-to-peer > > usages. > > > > A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute > > is present, the contents of the ORIGIN attribute are integrity > > protected." > > > > Which never happen in the usages listed in the document: for section > > 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is > > needed to select the realm, so the ORIGIN is sent before it can be > > protected. Perhaps 2.2 should say that if ORIGIN was sent to select > > the > > realm, it MUST be repeated at identical on the second Allocate (the one > > that has an M-I) and that the server MUST reject it if it is not > > identical to the first one. Not sure it matters though. > > > > I agree that there is no integrity protection of the ORIGIN attribute > > (or any other attribute) until after authentication. However, ORIGIN > > can be used both before and after authentication. I'll review this > > text and make sure this is clear. I don't believe we need any special > > rules, as this applies to any STUN attribute. > > > > Nits > > ---- > > > > - Section 2, 2nd paragraph: "The number used for the this in the ..." > > > > Does not parse. > > > > The middle "the" shouldn't be there. > > > > > > -- > > Marc Petit-Huguenin > > Developer | Jive Communications, Inc. > > Jive.com | marcph@getjive.com > > > > > > _______________________________________________ > > 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 > --047d7bb04fee843af704fb1c2177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we do want to support multiple= origins per request then we have to state, clearly, three things:

<= /div>=C2=A0 1) Use cases.
=C2=A0 2) How we use multiple origins wh= en we process the request.
=C2=A0 3) How we format multiple origins in the request - as comma-se= parated single field or multiple origin attributes. As STUN/TURN is a binar= y protocol, I think that the second option is better.

The usef= ulness of multiple origins in TURN is not very obvious to me. I implemented= ORIGIN in a pilot implementation https://code.google.com/p/coturn/ but I assumed a single ORIGIN fi= eld per request.

Oleg


=C2=A0


On Thu, Jun 5, 2014 at = 7:48 AM, Hutton, Andrew <andrew.hutton@unify.com> wrot= e:
Multiple Origins for HTTP Requests are cover= ed in http://tools.ietf.org/html/rfc6454#section-7.2 I just assumed t= he same would apply to the usage in this context.

Andy

> -----Original Message-----
> From: Oleg Moskalenko [mailto:m= om040267@gmail.com]
> Sent: 05 June 2014 15:26
> To: Hutton, Andrew
> Cc: Alan Johnston; tram@ietf.org<= br> > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02
>
> What would be the purpose of multiple origins ?
>
> Oleg
>
> On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" <andrew.hutton@unify.com>
> wrote:
> Hi,
>
> I had another read through this draft and hope we can move this forwar= d
> and adopt the draft soon.
>
> I only have one additional comment at this time and that is that I
> assume it should be possible for the client to include more than one > origin in the Origin header field and if so the procedures around this=
> should explained in the draft.
>
> Regards
> Andy
>
>
>
>
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of Alan Johnston
> Sent: 07 May 2014 18:50
> To: Marc Petit-Huguenin
> Cc: tram@ietf.org
> Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02
>
> Marc,
>
> Thanks for the review. =C2=A0See my comments below.
>
> - Alan -
>
> On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin
> <marcph@getjive.com> w= rote:
> A1. Intended Status: Informational
>
> Shouldn't this be Standard Track?
>
> Yes.
>
> A2. Section 1, 2nd paragraph, last sentence: "as generating the > response..."
>
> I do not think that the reason for no authentication for the NAT
> Discovery Usage is because it is less work, but because there is no > resource to protect so adding more work does not make sense.
>
> I disagree that there is *no* resource to protect. =C2=A0A STUN server= might
> be minimal resources, but not none. =C2=A0If a simple authentication s= cheme
> were available, I'm sure some people would use it so they could > minimize the cost of their server footprint by ensuring that only
> authenticated users were utilizing it. =C2=A0I will add some text poin= ting
> out that the minimal resources.
>
> A3. Section 1, 8th paragraph
>
> I do not think that the ORIGIN should be used to select the certificat= e
> when (D)TLS is used. =C2=A0First it does not work with DANE, as when a= n SRV
> (and probably NAPTR too, but that's undefined yet) RR redirects to= a
> different domain, the domain to be checked with is the host name, not<= br> > the service domain (see draft-ietf-dane-srv). =C2=A0For non-DANE cases= , I
> think that the correct way to select the certificate is to use SNI. >
> The draft does not suggest that ORIGIN be used to select certificates = -
> as Oleg pointed out it isn't possible. =C2=A0This paragraph was de= scribing
> how RFC 6066 does not solve the problem, as had been suggested on the<= br> > list.
>
>
> So I would suggest to restrict the normative use of ORIGIN only to
> select realms.
>
> A4. Section 2.2. ORIGIN attribute usage
>
> The text does not say if the ORIGIN attribute should/can be provided > after the authentication (i.e. refresh, data packets, etc...)
>
> Currently, the text says SHOULD include, for a conformant client. =C2= =A0For
> logging, it has value even after the initial authentication.
>
>
> A5. Section 2.2. =C2=A0Mandatory support for server
>
> How a TURN server that requires the usage of ORIGIN can signal this? >
> Right now there is no way to do this. =C2=A0I agree with Oleg that it = is up
> to the server what to do if ORIGIN is no present.
>
> A6. Section 2. Other Usages
>
> I think that other STUN Usages should be listed after section 2.3:
>
> - Media Keep-Alive Usage (Section 20 of RFC5245)
> - SIP Keep-Alive Usage (RFC 5626)
> - NAT Behavior Discovery Usage (RFC 5780)
>
> I'll take a look at these scenarios. =C2=A0I suspect that it would= be a
> reasonable usage for client-to-server usages, but not for peer-to-peer=
> usages.
>
> A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attr= ibute
> is present, the contents of the ORIGIN attribute are integrity
> protected."
>
> Which never happen in the usages listed in the document: =C2=A0for sec= tion
> 2.1, there is never an integrity protection, and for 2.2, the ORIGIN i= s
> needed to select the realm, so the ORIGIN is sent before it can be
> protected. =C2=A0Perhaps 2.2 should say that if ORIGIN was sent to sel= ect
> the
> realm, it MUST be repeated at identical on the second Allocate (the on= e
> that has an M-I) and that the server MUST reject it if it is not
> identical to the first one. =C2=A0Not sure it matters though.
>
> I agree that there is no integrity protection of the ORIGIN attribute<= br> > (or any other attribute) until after authentication. =C2=A0However, OR= IGIN
> can be used both before and after authentication. =C2=A0I'll revie= w this
> text and make sure this is clear. =C2=A0I don't believe we need an= y special
> rules, as this applies to any STUN attribute.
>
> Nits
> ----
>
> - Section 2, 2nd paragraph: "The number used for the this in the = ..."
>
> Does not parse.
>
> The middle "the" shouldn't be there.
>
>
> --
> Marc Petit-Huguenin
> Developer =C2=A0| =C2=A0Jive Communications, Inc.
> Jive.com =C2=A0| =C2=A0marcph@ge= tjive.com
>
>
> _______________________________________________
> 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

--047d7bb04fee843af704fb1c2177-- From nobody Thu Jun 5 13:28:42 2014 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 19DC01A031C for ; Thu, 5 Jun 2014 13:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 pIv0sHrqZOQ0 for ; Thu, 5 Jun 2014 13:28:28 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9231A0305 for ; Thu, 5 Jun 2014 13:28:26 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j15so2180170qaq.9 for ; Thu, 05 Jun 2014 13:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jQTr+fhasSr8QU59c75C1Ac/zshV73+Ux7aZXsp+iwE=; b=AojRHzdnZ+sQLwidfqm35Xhk00rarFrH065F6tqydH/rIzQq99sPTyimlibBBKZrSl I8mMTd32DMMiVdKJmYl9WS6f8PdADS+xnlmGqqeIgMs6Sp769/Jl4hVwK1HHGyTzgBVk kHm1XykXNV5VepfIjEjhqSGeY/LJCVrHbAdHDxRmCSNXKqqXOf8CiK07JbeLrpgzWbRP vzMvQCLywNWGXjgxvxweL8VJXXFFTRCQ3AImOz94EZ/aem7Vhk9TcMb6oN0JH/LXPHIm J8qpMBzrNBLPn66Mog1jXFID0aM2MZKt7d5G668JOpErEPj5qXZq4cSEOM0H94Y2YfeF bjUg== X-Received: by 10.229.212.196 with SMTP id gt4mr186556qcb.18.1402000098940; Thu, 05 Jun 2014 13:28:18 -0700 (PDT) Received: from [192.168.1.5] (24-241-75-164.dhcp.stls.mo.charter.com. [24.241.75.164]) by mx.google.com with ESMTPSA id z67sm10400498yhk.50.2014.06.05.13.28.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:28:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E448B49C-F6E7-4950-A242-9560E0AD28DD Mime-Version: 1.0 (1.0) From: Alan Johnston X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Thu, 5 Jun 2014 15:28:16 -0500 Content-Transfer-Encoding: 7bit Message-Id: <2356C6CE-16ED-4823-800F-5DD1CE5DFBB8@gmail.com> References: <5368BF90.2070307@getjive.com> <9F33F40F6F2CD847824537F3C4E37DDF17DE3241@MCHP04MSX.global-ad.net> <166C39DF-CA68-4C9C-8553-197C2C75B382@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17DE3355@MCHP04MSX.global-ad.net> To: Oleg Moskalenko Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2GiPbMKGfHsyNGZHbOrKQing6X8 Cc: "Hutton, Andrew" , "tram@ietf.org" Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 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, 05 Jun 2014 20:28:33 -0000 --Apple-Mail-E448B49C-F6E7-4950-A242-9560E0AD28DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Andy, Thanks for your review and comments.=20 When you mentioned multiple origins, I thought you were referring to a SIP o= rigin and an HTTP origin, but it seems the HTTP origin has the concept of mo= re than one. I wonder if browsers ever generate this? I will add some discussion of this in the next version, including Oleg's use= ful set of issues below.=20 - Alan - > On Jun 5, 2014, at 2:55 PM, Oleg Moskalenko wrote: >=20 > If we do want to support multiple origins per request then we have to stat= e, clearly, three things: >=20 > 1) Use cases. > 2) How we use multiple origins when we process the request. > 3) How we format multiple origins in the request - as comma-separated si= ngle field or multiple origin attributes. As STUN/TURN is a binary protocol,= I think that the second option is better. >=20 > The usefulness of multiple origins in TURN is not very obvious to me. I im= plemented ORIGIN in a pilot implementation https://code.google.com/p/coturn/= but I assumed a single ORIGIN field per request. >=20 > Oleg >=20 >=20 > =20 >=20 >=20 >> On Thu, Jun 5, 2014 at 7:48 AM, Hutton, Andrew w= rote: >> Multiple Origins for HTTP Requests are covered in http://tools.ietf.org/h= tml/rfc6454#section-7.2 I just assumed the same would apply to the usage in t= his context. >>=20 >> Andy >>=20 >> > -----Original Message----- >> > From: Oleg Moskalenko [mailto:mom040267@gmail.com] >> > Sent: 05 June 2014 15:26 >> > To: Hutton, Andrew >> > Cc: Alan Johnston; tram@ietf.org >> > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 >> > >> > What would be the purpose of multiple origins ? >> > >> > Oleg >> > >> > On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" >> > wrote: >> > Hi, >> > >> > I had another read through this draft and hope we can move this forward= >> > and adopt the draft soon. >> > >> > I only have one additional comment at this time and that is that I >> > assume it should be possible for the client to include more than one >> > origin in the Origin header field and if so the procedures around this >> > should explained in the draft. >> > >> > Regards >> > Andy >> > >> > >> > >> > >> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston >> > Sent: 07 May 2014 18:50 >> > To: Marc Petit-Huguenin >> > Cc: tram@ietf.org >> > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02 >> > >> > Marc, >> > >> > Thanks for the review. See my comments below. >> > >> > - Alan - >> > >> > On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin >> > wrote: >> > A1. Intended Status: Informational >> > >> > Shouldn't this be Standard Track? >> > >> > Yes. >> > >> > A2. Section 1, 2nd paragraph, last sentence: "as generating the >> > response..." >> > >> > I do not think that the reason for no authentication for the NAT >> > Discovery Usage is because it is less work, but because there is no >> > resource to protect so adding more work does not make sense. >> > >> > I disagree that there is *no* resource to protect. A STUN server might= >> > be minimal resources, but not none. If a simple authentication scheme >> > were available, I'm sure some people would use it so they could >> > minimize the cost of their server footprint by ensuring that only >> > authenticated users were utilizing it. I will add some text pointing >> > out that the minimal resources. >> > >> > A3. Section 1, 8th paragraph >> > >> > I do not think that the ORIGIN should be used to select the certificate= >> > when (D)TLS is used. First it does not work with DANE, as when an SRV >> > (and probably NAPTR too, but that's undefined yet) RR redirects to a >> > different domain, the domain to be checked with is the host name, not >> > the service domain (see draft-ietf-dane-srv). For non-DANE cases, I >> > think that the correct way to select the certificate is to use SNI. >> > >> > The draft does not suggest that ORIGIN be used to select certificates -= >> > as Oleg pointed out it isn't possible. This paragraph was describing >> > how RFC 6066 does not solve the problem, as had been suggested on the >> > list. >> > >> > >> > So I would suggest to restrict the normative use of ORIGIN only to >> > select realms. >> > >> > A4. Section 2.2. ORIGIN attribute usage >> > >> > The text does not say if the ORIGIN attribute should/can be provided >> > after the authentication (i.e. refresh, data packets, etc...) >> > >> > Currently, the text says SHOULD include, for a conformant client. For >> > logging, it has value even after the initial authentication. >> > >> > >> > A5. Section 2.2. Mandatory support for server >> > >> > How a TURN server that requires the usage of ORIGIN can signal this? >> > >> > Right now there is no way to do this. I agree with Oleg that it is up >> > to the server what to do if ORIGIN is no present. >> > >> > A6. Section 2. Other Usages >> > >> > I think that other STUN Usages should be listed after section 2.3: >> > >> > - Media Keep-Alive Usage (Section 20 of RFC5245) >> > - SIP Keep-Alive Usage (RFC 5626) >> > - NAT Behavior Discovery Usage (RFC 5780) >> > >> > I'll take a look at these scenarios. I suspect that it would be a >> > reasonable usage for client-to-server usages, but not for peer-to-peer >> > usages. >> > >> > A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute >> > is present, the contents of the ORIGIN attribute are integrity >> > protected." >> > >> > Which never happen in the usages listed in the document: for section >> > 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is= >> > needed to select the realm, so the ORIGIN is sent before it can be >> > protected. Perhaps 2.2 should say that if ORIGIN was sent to select >> > the >> > realm, it MUST be repeated at identical on the second Allocate (the one= >> > that has an M-I) and that the server MUST reject it if it is not >> > identical to the first one. Not sure it matters though. >> > >> > I agree that there is no integrity protection of the ORIGIN attribute >> > (or any other attribute) until after authentication. However, ORIGIN >> > can be used both before and after authentication. I'll review this >> > text and make sure this is clear. I don't believe we need any special >> > rules, as this applies to any STUN attribute. >> > >> > Nits >> > ---- >> > >> > - Section 2, 2nd paragraph: "The number used for the this in the ..." >> > >> > Does not parse. >> > >> > The middle "the" shouldn't be there. >> > >> > >> > -- >> > Marc Petit-Huguenin >> > Developer | Jive Communications, Inc. >> > Jive.com | marcph@getjive.com >> > >> > >> > _______________________________________________ >> > 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 --Apple-Mail-E448B49C-F6E7-4950-A242-9560E0AD28DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Andy,

Thanks f= or your review and comments. 

When you mention= ed multiple origins, I thought you were referring to a SIP origin and an HTT= P origin, but it seems the HTTP origin has the concept of more than one. I w= onder if browsers ever generate this?

I will add so= me discussion of this in the next version, including Oleg's useful set of is= sues below. 

- Alan -

On Jun 5, 2= 014, at 2:55 PM, Oleg Moskalenko <= mom040267@gmail.com> wrote:

If we do want to support multip= le origins per request then we have to state, clearly, three things:

=
  1) Use cases.
  2) How we use multiple origins wh= en we process the request.
  3) How we format multiple origins in the request - as comma-sep= arated single field or multiple origin attributes. As STUN/TURN is a binary p= rotocol, I think that the second option is better.

The usefulne= ss of multiple origins in TURN is not very obvious to me. I implemented ORIG= IN in a pilot implementation h= ttps://code.google.com/p/coturn/ but I assumed a single ORIGIN field per= request.

Oleg


 


On Thu, Jun 5, 2014 at 7:48= AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
=
Multiple Origins for HTTP Requests are covered= in http://tools.ietf.org/html/rfc6454#section-7.2 I just assumed the s= ame would apply to the usage in this context.

Andy

> -----Original Message-----
> From: Oleg Moskalenko [mailto:mo= m040267@gmail.com]
> Sent: 05 June 2014 15:26
> To: Hutton, Andrew
> Cc: Alan Johnston; tram@ietf.org > Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02
>
> What would be the purpose of multiple origins ?
>
> Oleg
>
> On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" <andrew.hutton@unify.com>
> wrote:
> Hi,
>
> I had another read through this draft and hope we can move this forward=
> and adopt the draft soon.
>
> I only have one additional comment at this time and that is that I
> assume it should be possible for the client to include more than one > origin in the Origin header field and if so the procedures around this<= br> > should explained in the draft.
>
> Regards
> Andy
>
>
>
>
> From: tram [mailto:tram-bounce= s@ietf.org] On Behalf Of Alan Johnston
> Sent: 07 May 2014 18:50
> To: Marc Petit-Huguenin
> Cc: tram@ietf.org
> Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02
>
> Marc,
>
> Thanks for the review.  See my comments below.
>
> - Alan -
>
> On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin
> <marcph@getjive.com> wr= ote:
> A1. Intended Status: Informational
>
> Shouldn't this be Standard Track?
>
> Yes.
>
> A2. Section 1, 2nd paragraph, last sentence: "as generating the
> response..."
>
> I do not think that the reason for no authentication for the NAT
> Discovery Usage is because it is less work, but because there is no
= > resource to protect so adding more work does not make sense.
>
> I disagree that there is *no* resource to protect.  A STUN server m= ight
> be minimal resources, but not none.  If a simple authentication sc= heme
> were available, I'm sure some people would use it so they could
> minimize the cost of their server footprint by ensuring that only
> authenticated users were utilizing it.  I will add some text point= ing
> out that the minimal resources.
>
> A3. Section 1, 8th paragraph
>
> I do not think that the ORIGIN should be used to select the certificate=
> when (D)TLS is used.  First it does not work with DANE, as when an= SRV
> (and probably NAPTR too, but that's undefined yet) RR redirects to a > different domain, the domain to be checked with is the host name, not > the service domain (see draft-ietf-dane-srv).  For non-DANE cases,= I
> think that the correct way to select the certificate is to use SNI.
= >
> The draft does not suggest that ORIGIN be used to select certificates -=
> as Oleg pointed out it isn't possible.  This paragraph was describ= ing
> how RFC 6066 does not solve the problem, as had been suggested on the > list.
>
>
> So I would suggest to restrict the normative use of ORIGIN only to
> select realms.
>
> A4. Section 2.2. ORIGIN attribute usage
>
> The text does not say if the ORIGIN attribute should/can be provided > after the authentication (i.e. refresh, data packets, etc...)
>
> Currently, the text says SHOULD include, for a conformant client.  = ;For
> logging, it has value even after the initial authentication.
>
>
> A5. Section 2.2.  Mandatory support for server
>
> How a TURN server that requires the usage of ORIGIN can signal this? >
> Right now there is no way to do this.  I agree with Oleg that it i= s up
> to the server what to do if ORIGIN is no present.
>
> A6. Section 2. Other Usages
>
> I think that other STUN Usages should be listed after section 2.3:
>
> - Media Keep-Alive Usage (Section 20 of RFC5245)
> - SIP Keep-Alive Usage (RFC 5626)
> - NAT Behavior Discovery Usage (RFC 5780)
>
> I'll take a look at these scenarios.  I suspect that it would be a=
> reasonable usage for client-to-server usages, but not for peer-to-peer<= br> > usages.
>
> A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute<= br> > is present, the contents of the ORIGIN attribute are integrity
> protected."
>
> Which never happen in the usages listed in the document:  for sect= ion
> 2.1, there is never an integrity protection, and for 2.2, the ORIGIN is=
> needed to select the realm, so the ORIGIN is sent before it can be
> protected.  Perhaps 2.2 should say that if ORIGIN was sent to sele= ct
> the
> realm, it MUST be repeated at identical on the second Allocate (the one=
> that has an M-I) and that the server MUST reject it if it is not
> identical to the first one.  Not sure it matters though.
>
> I agree that there is no integrity protection of the ORIGIN attribute > (or any other attribute) until after authentication.  However, ORI= GIN
> can be used both before and after authentication.  I'll review thi= s
> text and make sure this is clear.  I don't believe we need any spe= cial
> rules, as this applies to any STUN attribute.
>
> Nits
> ----
>
> - Section 2, 2nd paragraph: "The number used for the this in the ..." >
> Does not parse.
>
> The middle "the" shouldn't be there.
>
>
> --
> Marc Petit-Huguenin
> Developer  |  Jive Communications, Inc.
> Jive.com  |  marcph@getjive.com
>
>
> _______________________________________________
> 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

= --Apple-Mail-E448B49C-F6E7-4950-A242-9560E0AD28DD-- From nobody Tue Jun 10 14:12:09 2014 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 0E39B1B289D for ; Tue, 10 Jun 2014 14:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 KbQPjFLlirjJ for ; Tue, 10 Jun 2014 14:12:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A42DD1B2880 for ; Tue, 10 Jun 2014 14:12:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 235E2476F6 for ; Tue, 10 Jun 2014 21:12:01 +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 168FB4758A for ; Tue, 10 Jun 2014 21:12:01 +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 123088003C for ; Tue, 10 Jun 2014 21:12:01 +0000 (GMT) Message-ID: <539774A1.9000406@akamai.com> Date: Tue, 10 Jun 2014 17:12:01 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <20140610175452.20711.23197.idtracker@ietfa.amsl.com> In-Reply-To: <20140610175452.20711.23197.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140610175452.20711.23197.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/h39SvFF7slNbeqIqlwqErwyTAE0 Subject: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: brandon.williams@akamai.com 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, 10 Jun 2014 21:12:08 -0000 Hi all, A new version of our draft has been submitted. This version attempts to provide more detailed guidance around use of the proposed attributes. This particular effort isn't currently on the working group's road map, but the authors see this capability as one that is critical for a 3rd party TURN service, and we welcome all feedback from the list. Thanks, --Brandon -------- Original Message -------- Subject: New Version Notification for draft-williams-peer-redirect-01.txt Date: Tue, 10 Jun 2014 13:54:52 -0400 From: internet-drafts@ietf.org A new version of I-D, draft-williams-peer-redirect-01.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-peer-redirect Revision: 01 Title: Peer-specific Redirection for Traversal Using Relays around NAT (TURN) Document date: 2014-06-10 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-01.txt Status: https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-01 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. From nobody Wed Jun 11 06:15:10 2014 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 212461A00DD; Wed, 11 Jun 2014 06:15:04 -0700 (PDT) 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 OEAyE16etUZJ; Wed, 11 Jun 2014 06:15:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 381111A00F9; Wed, 11 Jun 2014 06:15:00 -0700 (PDT) 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.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140611131500.19101.10427.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 06:15:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SPTbtdnJknbne2apTovC_4WhlvQ Cc: tram@ietf.org Subject: [tram] Last Call: (Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)) 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, 11 Jun 2014 13:15:04 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)' 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 2014-06-25. 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 specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 12 08:59:25 2014 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 520B11A028D; Wed, 4 Jun 2014 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 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_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Gcu7KmIsP5h0; Wed, 4 Jun 2014 08:52:00 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEF11A0227; Wed, 4 Jun 2014 08:52:00 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s54FpnBL000372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2014 11:51:50 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s54FpnBL000372 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401897110; bh=gdkKm4Ts34ABjZc6V7vwW71Q1ps=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LAj7stqeo1vDLLvQu3peJr+4aM8YvON1PB5mpUHsWIJiw8Zpzko3Uqh/1Z0YfnJRH lTCzu8Jdsw+XcorcTtsgTpAHXCjWJEoRGmzDqA+Sz8prEMzmeJ2qtzzEBGUVBHMt1v rLf10XnCQHbnOss/fz5ljbkJEyNHehwU1Ewk0OZU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s54FpnBL000372 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 4 Jun 2014 11:51:34 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s54FpX6c004529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 11:51:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.248]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Wed, 4 Jun 2014 11:51:33 -0400 From: "Black, David" To: "Tirumaleswar Reddy (tireddy)" , "tsvwg@ietf.org" , "tram@ietf.org" Date: Wed, 4 Jun 2014 11:51:32 -0400 Thread-Topic: [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-00.txt Thread-Index: AQHPf+MyUHdmQIZk4UaV4Ec4CXcVNptgxt4QgABRtEA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076FD33E4A@MX15A.corp.emc.com> References: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bfsIn-WC7G61HlxK3DTKJmR8NbY X-Mailman-Approved-At: Thu, 12 Jun 2014 08:59:20 -0700 Subject: Re: [tram] [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-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, 04 Jun 2014 15:52:04 -0000 UXVlc3Rpb246IFNob3VsZCB0aGlzIGRyYWZ0IGJlIGNvbnNpZGVyZWQgYnkgdGhlIHRzdndnIFdH IG9yIHRoZSB0cmFtIFdHPw0KDQpUaGUgZHJhZnQgbmFtZSBzdWdnZXN0cyB0c3Z3ZywgYnV0IHRy YW0gaXMgdGhlIGZvY3VzIG9mIFRVUk4gYWN0aXZpdHkNCmFuZCAiZXh0ZW5zaW9ucyB0byBUVVJO IGFuZCBTVFVOIiBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0cmFtJ3MgYWN0aXZpdHkuDQoNCkF0 IGEgbWluaW11bSBJIHdvdWxkIHN1Z2dlc3QgdGhlIHRyYW1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0 IGFzIHRoZSBwcmVmZXJyZWQNCmZvcnVtIGZvciBkaXNjdXNzaW9uIG9mIHRoaXMgZHJhZnQgYmVj YXVzZSB0aGF0IGlzIHdoZXJlIFRVUk4gYWN0aXZpdHkgaXMNCmN1cnJlbnRseSBmb2N1c2VkLg0K DQpUaGFua3MsDQotLURhdmlkICh0c3Z3ZyBXRyBjby1jaGFpcikNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gKHRpcmVkZHkpDQo+IFNlbnQ6 IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA3OjAzIEFNDQo+IFRvOiB0c3Z3Z0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBbdHN2d2ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXdpbmctdHN2d2ctdHVybi0NCj4gZmxvd2RhdGEtMDAudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0K PiBUcmF2ZXJzYWwgVXNpbmcgUmVsYXkgTkFUIChUVVJOKSBzZXJ2ZXIgYW5kIHRoZSBuZXR3b3Jr IGluIHdoaWNoIGl0IGlzIGhvc3RlZA0KPiBkdWUgdG8gbG9hZCBjb3VsZCBhZHZlcnNlbHkgaW1w YWN0IHRoZSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdC4gIER1cmluZw0KPiBzdWNoIGhpZ2gg bG9hZCBldmVudCwgaXQgaXMgZGVzaXJhYmxlIHRvIHNoZWQgc29tZSB0cmFmZmljIGJ1dCBUVVJO IHNlcnZlcg0KPiBsYWNrIHJlcXVpcmVtZW50cyBhYm91dCB0aGUgZmxvd3MgdG8gcHJpb3JpdGl6 ZSB0aGVtLiBUaGlzIGRyYWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdp bmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMCBkZWZpbmVzIGENCj4gbWVjaGFuaXNtIHRvIGNvbW11 bmljYXRlIGZsb3cgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIFRVUk4gY2xpZW50IHRvIGl0cyBU VVJODQo+IHNlcnZlci4NCj4gDQo+IENvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29t ZS4NCj4gDQo+IC1UaXJ1DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCA0OjIzIFBNDQo+IFRvOiBSYW0g TW9oYW4gUiAocm1vaGFucik7IEJyYW5kb24gV2lsbGlhbXM7IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7IERhbg0KPiBXaW5nIChkd2luZyk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSk7IERhbiBXaW5nIChkd2luZyk7IFJhbSBNb2hhbiBSDQo+IChybW9oYW5yKTsgQnJhbmRvbiBX aWxsaWFtcw0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdp bmctdHN2d2ctdHVybi1mbG93ZGF0YS0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtd2luZy10c3Z3Zy10dXJuLWZsb3dkYXRhLTAwLnR4dA0KPiBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtd2luZy10c3Z3Zy10 dXJuLWZsb3dkYXRhDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVRVUk4gZXh0ZW5zaW9uIHRv IGNvbnZleSBmbG93IGNoYXJhY3RlcmlzdGljcw0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA2LTA0 DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTENCj4gVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbmct dHN2d2ctdHVybi0NCj4gZmxvd2RhdGEtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLXRzdndnLXR1cm4tDQo+IGZsb3dk YXRhLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt d2luZy10c3Z3Zy10dXJuLWZsb3dkYXRhLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRV Uk4gc2VydmVyIGFuZCB0aGUgbmV0d29yayBpbiB3aGljaCBpdCBpcyBob3N0ZWQgZHVlIHRvIGxv YWQgY291bGQNCj4gICAgYWR2ZXJzZWx5IGltcGFjdCB0aGUgdHJhZmZpYyByZWxheWVkIHRocm91 Z2ggaXQuICBEdXJpbmcgc3VjaCBoaWdoDQo+ICAgIGxvYWQgZXZlbnQsIGl0IGlzIGRlc2lyYWJs ZSB0byBzaGVkIHNvbWUgdHJhZmZpYyBidXQgVFVSTiBzZXJ2ZXIgbGFjaw0KPiAgICByZXF1aXJl bWVudHMgYWJvdXQgdGhlIGZsb3dzIHRvIHByaW9yaXRpemUgdGhlbS4gIFRoaXMgZG9jdW1lbnQN Cj4gICAgZGVmaW5lcyBzdWNoIGEgbWVjaGFuaXNtIHRvIGNvbW11bmljYXRlIGZsb3cgY2hhcmFj dGVyaXN0aWNzIGZyb20gdGhlDQo+ICAgIFRVUk4gY2xpZW50IHRvIGl0cyBUVVJOIHNlcnZlci4N Cj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4g DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Jun 12 08:59:27 2014 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 26A101A02D9; Wed, 4 Jun 2014 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 iA5njZ0uFC-o; Wed, 4 Jun 2014 09:58:28 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 15B831A0369; Wed, 4 Jun 2014 09:58:22 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 803B92B40B9; Wed, 4 Jun 2014 17:58:15 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 4 Jun 2014 17:58:15 +0100 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD33E4A@MX15A.corp.emc.com> References: <20140604105319.14661.62945.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A282C8024@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076FD33E4A@MX15A.corp.emc.com> Date: Wed, 4 Jun 2014 17:58:15 +0100 From: gorry@erg.abdn.ac.uk To: "Black, David" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W9Nc2RunSZn3CfJOGGI9VKQkgmU X-Mailman-Approved-At: Thu, 12 Jun 2014 08:59:20 -0700 Cc: "tsvwg@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] [tsvwg] FW: New Version Notification for draft-wing-tsvwg-turn-flowdata-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, 04 Jun 2014 16:58:30 -0000 As TSVWG Chair: - It is fine to discuss this draft in TSVWG and get a feeling for the flow data and QoS interactions. If anything significant is discovered - then TSVWG is a great place to get that attention. TSVWG'ers - please do look at this draft! Authors please consider this an offer of Agenda time (even if, as my Co-chair David notes, the adopted work may happen to be finished elsewhere) - the main thing at this time is to clearly set out the proposal and get eyes to look at this - our ADs will for sure to advise on the final place for the work to finish. Gorry :-) > > Question: Should this draft be considered by the tsvwg WG or the tram WG? > > The draft name suggests tsvwg, but tram is the focus of TURN activity > and "extensions to TURN and STUN" are within the scope of tram's > activity. > > At a minimum I would suggest the tram@ietf.org mailing list as the > preferred > forum for discussion of this draft because that is where TURN activity is > currently focused. > > Thanks, > --David (tsvwg WG co-chair) > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Tirumaleswar >> Reddy >> (tireddy) >> Sent: Wednesday, June 04, 2014 7:03 AM >> To: tsvwg@ietf.org >> Subject: [tsvwg] FW: New Version Notification for >> draft-wing-tsvwg-turn- >> flowdata-00.txt >> >> Hi all, >> >> Traversal Using Relay NAT (TURN) server and the network in which it is >> hosted >> due to load could adversely impact the traffic relayed through it. >> During >> such high load event, it is desirable to shed some traffic but TURN >> server >> lack requirements about the flows to prioritize them. This draft >> http://tools.ietf.org/html/draft-wing-tsvwg-turn-flowdata-00 defines a >> mechanism to communicate flow characteristics from the TURN client to >> its TURN >> server. >> >> Comments and suggestions are welcome. >> >> -Tiru >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 04, 2014 4:23 PM >> To: Ram Mohan R (rmohanr); Brandon Williams; Tirumaleswar Reddy >> (tireddy); Dan >> Wing (dwing); Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Ram Mohan >> R >> (rmohanr); Brandon Williams >> Subject: New Version Notification for >> draft-wing-tsvwg-turn-flowdata-00.txt >> >> >> A new version of I-D, draft-wing-tsvwg-turn-flowdata-00.txt >> has been successfully submitted by Tirumaleswar Reddy and posted to the >> IETF >> repository. >> >> Name: draft-wing-tsvwg-turn-flowdata >> Revision: 00 >> Title: TURN extension to convey flow characteristics >> Document date: 2014-06-04 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-wing-tsvwg-turn- >> flowdata-00.txt >> Status: https://datatracker.ietf.org/doc/draft-wing-tsvwg-turn- >> flowdata/ >> Htmlized: >> http://tools.ietf.org/html/draft-wing-tsvwg-turn-flowdata-00 >> >> >> Abstract: >> TURN server and the network in which it is hosted due to load could >> adversely impact the traffic relayed through it. During such high >> load event, it is desirable to shed some traffic but TURN server >> lack >> requirements about the flows to prioritize them. This document >> defines such a mechanism to communicate flow characteristics from >> the >> TURN client to its TURN server. >> >> >> >> >> 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 > > From nobody Sun Jun 15 21:45:32 2014 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 700C51B2898 for ; Sun, 15 Jun 2014 21:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 DuuDbipTrbny for ; Sun, 15 Jun 2014 21:45:28 -0700 (PDT) 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 C0F591B2897 for ; Sun, 15 Jun 2014 21:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3306; q=dns/txt; s=iport; t=1402893928; x=1404103528; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZPAuxjRf4RxhrjuqdPKaAJGHTaYYNq4vM520h9aQzVM=; b=Urhwt3PGC9Z52PPc+LCgxcpJ+4GHpjNwnTEsIJoT+w/JAruD0I7PHPBK HOgvkH+1HrgxB+2AN6yj4zAqzzqgvXsqY1oLNZfEfJyqdLjMeRs/FGGCs PpQgJH1Py7zEWQXrGiIlT582atg9+vRMgsy3BWpw0s8MlcK7wnksc1s0/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0FAPh0nlOtJV2T/2dsb2JhbABagw1SWoJspnoBAQEDBQGZJAEZcBZ1hAMBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBEognDbBxnWoXgSqEOYhiFiIGgnE2gRYEhGMClyGSFYNAbIFE X-IronPort-AV: E=Sophos;i="5.01,483,1400025600"; d="scan'208";a="53293147" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 16 Jun 2014 04:45:27 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5G4jRTv027059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Jun 2014 04:45:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 15 Jun 2014 23:45:26 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-wing-tram-turn-mobility-00.txt Thread-Index: AQHPiFiltre1QbutvUqK8cvFFV4jjptzKTSg Date: Mon, 16 Jun 2014 04:45:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282DC90F@xmb-rcd-x10.cisco.com> References: <20140615051406.27076.65467.idtracker@ietfa.amsl.com> In-Reply-To: <20140615051406.27076.65467.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.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/c2E9puKjDYMwm16ot502ybqz3FU Subject: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-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, 16 Jun 2014 04:45:30 -0000 V2UndmUgcHVibGlzaGVkIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgYW4gSVAgYWRkcmVzcyBtb2Jp bGl0eSBzb2x1dGlvbiB1c2luZyBUVVJOLiAgVFVSTiBNb2JpbGl0eSB3YXMgb3JpZ2luYWxseSBw YXJ0IG9mIE1JQ0UgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1tbXVzaWMt aWNlLW1vYmlsaXR5LTA2LiANCldlJ3ZlIHNlcGFyYXRlZCBvdXQgc2VjdGlvbnMgdGhhdCBkZWFs IHdpdGggVFVSTiBtb2JpbGl0eSAoYW5kIGNoYW5nZXMgdGhhdCBhZmZlY3QgVFVSTiksIHRvIGEg bmV3IGRyYWZ0LiBUaGlzIG5vdyBtYWtlcyB0aGUgdHdvIGRyYWZ0cyBmYWlybHkgaW5kZXBlbmRl bnQuDQoNClRoZXJlIGhhcyBhbHJlYWR5IGJlZW4gc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoaXMg dGVjaG5pcXVlIGluIFRSQU0sIE9sZWcgaGFzIGltcGxlbWVudGVkIHRoaXMgZHJhZnQgYW5kIHB1 Ymxpc2hlZCB0aGUgc291cmNlIGNvZGUgaW4gaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3JmYzU3 NjYtdHVybi1zZXJ2ZXIvIA0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUu DQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCi1BdXRob3JzDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTdW5kYXksIEp1bmUgMTUsIDIwMTQgMTA6NDQgQU0N ClRvOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5nKTsgRGFu IFdpbmcgKGR3aW5nKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBQcmFzaGFudGggUGF0aWwg KHByYXNwYXRpKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdpbmctdHJhbS10dXJuLW1vYmlsaXR5LTAwLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aW5nLXRyYW0tdHVybi1tb2JpbGl0eS0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJl ZGR5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13 aW5nLXRyYW0tdHVybi1tb2JpbGl0eQ0KUmV2aXNpb246CTAwDQpUaXRsZToJCU1vYmlsaXR5IHdp dGggVFVSTg0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMTANClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC13aW5nLXRyYW0tdHVybi1tb2JpbGl0eS0wMC50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5n LXRyYW0tdHVybi1tb2JpbGl0eS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13aW5nLXRyYW0tdHVybi1tb2JpbGl0eS0wMA0KDQoNCkFic3RyYWN0Og0K ICAgSXQgaXMgZGVzaXJhYmxlIHRvIG1pbmltaXplIHRyYWZmaWMgZGlzcnVwdGlvbiBjYXVzZWQg YnkgY2hhbmdpbmcgSVANCiAgIGFkZHJlc3MgZHVyaW5nIGEgbW9iaWxpdHkgZXZlbnQuICBPbmUg bWVjaGFuaXNtIHRvIG1pbmltaXplDQogICBkaXNydXB0aW9uIGlzIHRvIGV4cG9zZSBhIHNob3J0 ZXIgbmV0d29yayBwYXRoIHRvIHRoZSBtb2JpbGl0eSBldmVudA0KICAgc28gb25seSB0aGUgbG9j YWwgbmV0d29yayBlbGVtZW50cyBhcmUgYXdhcmUgb2YgdGhlIGNoYW5nZWQgSVANCiAgIGFkZHJl c3MgYnV0IHRoZSByZW1vdGUgcGVlciBpcyB1bmF3YXJlIG9mIHRoZSBjaGFuZ2VkIElQIGFkZHJl c3MuDQoNCiAgIFRoaXMgZHJhZnQgcHJvdmlkZXMgc3VjaCBhbiBJUCBhZGRyZXNzIG1vYmlsaXR5 IHNvbHV0aW9uIHVzaW5nIFRVUk4uDQogICBUaGlzIGlzIGFjaGlldmVkIGJ5IGFsbG93aW5nIGEg Y2xpZW50IHRvIHJldGFpbiBhbiBhbGxvY2F0aW9uIG9uIHRoZQ0KICAgVFVSTiBzZXJ2ZXIgd2hl biB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgY2xpZW50IGNoYW5nZXMuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jun 19 21:49:08 2014 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 B1C791A04B7 for ; Thu, 19 Jun 2014 21:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 16bz5bTJNINj for ; Thu, 19 Jun 2014 21:49:05 -0700 (PDT) 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 C00661A0401 for ; Thu, 19 Jun 2014 21:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2632; q=dns/txt; s=iport; t=1403239744; x=1404449344; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7QQgZ+abh5HLmlGm8ndTy8tsNJUyf1p7Eo+nhnwKjiA=; b=eOdF8SKWk3pt5VcwRl5BXiyott+BeCuowF5GQjYRpn5fNi+DNUO7P3lI dmo/71rdRihyaKkUg8qai1/2Gwj0fKsk52TMghDMkQMAV643tUhoMIbdc 6TRSE3JNcWd7IXvPFwdsrgVg9HwuczcED7g/dWNYEvFpCT6KhVi3VBTuT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQMABe8o1OtJV2S/2dsb2JhbABZgw1SUweCbacvAQEBAQEBBQGZKQEZcRZ1hAMBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBiDkIBaxPnmEXgSqEOIhjOAaCcTaBFgScBpIVg0JsgQQkHA X-IronPort-AV: E=Sophos;i="5.01,511,1400025600"; d="scan'208";a="54609157" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 20 Jun 2014 04:49:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5K4n4IF022141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Jun 2014 04:49:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 23:49:03 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-turn-third-party-authz-03.txt Thread-Index: AQHPjD9RC+392k2kGkmj5yBcW/sP5Jt5Z0bw Date: Fri, 20 Jun 2014 04:49:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282E28FD@xmb-rcd-x10.cisco.com> References: <20140620042251.30503.24056.idtracker@ietfa.amsl.com> In-Reply-To: <20140620042251.30503.24056.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.54.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/f-83FPVP6MQp4oBWLNsVm60XWhA Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-03.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, 20 Jun 2014 04:49:06 -0000 UmV2aXNlZCBkcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHogaGFzIGJlZW4g cHVibGlzaGVkLiBUaGlzIHZlcnNpb24gYWRkcmVzc2VzIHBlbmRpbmcgY29tbWVudHMgcmVjZWl2 ZWQgZnJvbSB0aGUgV0cuDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCi1BdXRob3JzDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBKdW5lIDIwLCAy MDE0IDk6NTMgQU0NClRvOiBSYW0gTW9oYW4gUiAocm1vaGFucik7IFByYXNoYW50aCBQYXRpbCAo cHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQcmFzaGFudGggUGF0aWwg KHByYXNwYXRpKTsgSnVzdGluIFViZXJ0aTsgSnVzdGluIFViZXJ0aTsgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTsgUmFtIE1vaGFuIFIgKHJtb2hhbnIpDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRo ei0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktdHJhbS10dXJu LXRoaXJkLXBhcnR5LWF1dGh6LTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOgkJZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6DQpSZXZp c2lvbjoJMDMNClRpdGxlOgkJVFVSTiBFeHRlbnNpb24gZm9yIFRoaXJkIFBhcnR5IEF1dGhvcml6 YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMTkNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTE2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAz LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFy dHktYXV0aHotMDMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMNCg0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgT0F1dGggdG8gb2J0YWlu IGFuZCB2YWxpZGF0ZQ0KICAgZXBoZW1lcmFsIHRva2VucyB0aGF0IGNhbiBiZSB1c2VkIGZvciBU VVJOIGF1dGhlbnRpY2F0aW9uLiAgVGhlIHVzYWdlDQogICBvZiBlcGhlbWVyYWwgdG9rZW5zIGVu c3VyZSB0aGF0IGFjY2VzcyB0byBhIFRVUk4gc2VydmVyIGNhbiBiZQ0KICAgY29udHJvbGxlZCBl dmVuIGlmIHRoZSB0b2tlbnMgYXJlIGNvbXByb21pc2VkLCBhcyBpcyB0aGUgY2FzZSBpbg0KICAg V2ViUlRDIHdoZXJlIFRVUk4gY3JlZGVudGlhbHMgbXVzdCBiZSBzcGVjaWZpZWQgaW4gSmF2YXNj cmlwdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Jun 23 13:20:14 2014 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 5ED051B2C20; Mon, 23 Jun 2014 13:20:07 -0700 (PDT) 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 orV4sDJAaZyN; Mon, 23 Jun 2014 13:20:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7E91A0308; Mon, 23 Jun 2014 13:20:05 -0700 (PDT) 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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623202005.28717.49193.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 13:20:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KDQQ--DaFTDXIsufWYBvEhspwjM Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-04.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: Mon, 23 Jun 2014 20:20:07 -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 : Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-dtls-04.txt Pages : 17 Date : 2014-06-23 Abstract: This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-04 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 Jun 25 18:11:51 2014 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 4B74D1B2E9D for ; Wed, 25 Jun 2014 18:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 6L78MM0zMF2v for ; Wed, 25 Jun 2014 18:11:10 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8431B2E96 for ; Wed, 25 Jun 2014 18:11:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAD9yq1OHCzIm/2dsb2JhbABVA4JGIyQfM1q6SoE3HgGHPwGBCBZ1hAUBAQMSG14BFRVWJgEEGxMHiCABDJYUhFyodBeOSyEogiUPRCSBFgWcF4VhjESDQoIw X-IronPort-AV: E=Sophos; i="5.01,548,1400040000"; d="scan'208,217"; a="62152613" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jun 2014 21:11:07 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 25 Jun 2014 21:08:14 -0400 Received: from AZ-US1EXMB06.global.avaya.com ([fe80::38da:dafb:7358:e6f5]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 21:11:06 -0400 From: "Yoakum, John H (John)" To: "tram@ietf.org" Thread-Topic: Chrome STUN Origin proof-of-concept... Thread-Index: Ac+Q2Bm/29VW8CF3RTKIGa2IcrvGcQ== Date: Thu, 26 Jun 2014 01:11:05 +0000 Message-ID: <93BEDDC39A54294B9E78C7860516FA474396523F@AZ-US1EXMB06.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_93BEDDC39A54294B9E78C7860516FA474396523FAZUS1EXMB06glob_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/aX3LSmBXvEWWmIGgegztni9DG94 Subject: [tram] Chrome STUN Origin proof-of-concept... 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, 26 Jun 2014 01:11:34 -0000 --_000_93BEDDC39A54294B9E78C7860516FA474396523FAZUS1EXMB06glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We now have a proof-of-concept version of the Chrome browser (nicknamed 'Ch= romeo') that sends Origin insight in STUN and TURN messages (hopefully in f= ull compliance with the proposed standards draft). It uses a new STUN attr= ibute with a value of 0x802F as initially proposed. It has been implemente= d with a Chrome flag to enable and disable this unique feature (and is by d= efault disabled to prevent any non-intentional use of this feature until th= e standard is finalized). We have built 'Chromeo' for Linux and have verified with WireShark that pro= per STUN Origin attributes are being included in STUN/TURN messages sent by= the browser to servers (screen captures of STUN messages illustrating the = Origin attribute and content are available however I was not sure if it is = considered appropriate to attach any images to a post of this nature). Coordinated changes to both the WebRTC and Chromium open source projects ha= ve been submitted for consideration. The two submitted change lists togeth= er implement a proof-of-concept of the browser portion of the STUN Origin d= raft: http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 and Ole= g has previously posted that he has provided a proof-of-concept for the TUR= N sever end of the solution. Hopefully these two proof-of-concept efforts will help us quickly drive the= STUN Origin standard effort to fruition and help browsers quickly implemen= t STUN Origin enhancements. Cheers, John AVAYA 1.919.425.8446 --_000_93BEDDC39A54294B9E78C7860516FA474396523FAZUS1EXMB06glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We now have a proof-of-concept version of the Chrome= browser (nicknamed ‘Chromeo’) that sends Origin insight in STU= N and TURN messages (hopefully in full compliance with the proposed standar= ds draft).  It uses a new STUN attribute with a value of 0x802F as initially proposed.  It has been implemented wit= h a Chrome flag to enable and disable this unique feature (and is by defaul= t disabled to prevent any non-intentional use of this feature until the sta= ndard is finalized). 

 

We have built ‘Chromeo’ for Linux and ha= ve verified with WireShark that proper STUN Origin attributes are being inc= luded in STUN/TURN messages sent by the browser to servers (screen captures= of STUN messages illustrating the Origin attribute and content are available however I was not sure if it is considered appro= priate to attach any images to a post of this nature).

 

Coordinated changes to both the WebRTC and Chromium = open source projects have been submitted for consideration.  The two s= ubmitted change lists together implement a proof-of-concept of the browser = portion of the STUN Origin draft: h= ttp://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 and Oleg h= as previously posted that he has provided a proof-of-concept for the TURN s= ever end of the solution.

 

Hopefully these two pr= oof-of-concept efforts will help us quickly drive the STUN Origin standard = effort to fruition and help browsers quickly implement STUN Origin enhancem= ents.

 

 

= Cheers,

John

<= o:p> 

AV= AYA
1.919.425.8446

 

--_000_93BEDDC39A54294B9E78C7860516FA474396523FAZUS1EXMB06glob_-- From nobody Thu Jun 26 06:07:25 2014 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 C3E641B2C56 for ; Thu, 26 Jun 2014 06:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 ZrAPQkxeh86Q for ; Thu, 26 Jun 2014 06:07:18 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4D31B2F8C for ; Thu, 26 Jun 2014 06:06:08 -0700 (PDT) Received: from porto.nomis80.org (modemcable233.42-178-173.mc.videotron.ca [173.178.42.233]) by nomis80.org (Postfix) with ESMTPSA id D7CC410EAB for ; Thu, 26 Jun 2014 13:09:06 +0000 (UTC) Message-ID: <53AC1AC0.8060903@per.reau.lt> Date: Thu, 26 Jun 2014 09:06:08 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tram@ietf.org References: <93BEDDC39A54294B9E78C7860516FA474396523F@AZ-US1EXMB06.global.avaya.com> In-Reply-To: <93BEDDC39A54294B9E78C7860516FA474396523F@AZ-US1EXMB06.global.avaya.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AURjLtX3xCO7BQstAtUCuHhZC_o Subject: Re: [tram] Chrome STUN Origin proof-of-concept... 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, 26 Jun 2014 13:07:22 -0000 This is great! You need to add an Implementation Status section to your draft! http://tools.ietf.org/html/rfc6982 Simon Le 2014-06-25 21:11, Yoakum, John H (John) a écrit : > We now have a proof-of-concept version of the Chrome browser (nicknamed > ‘Chromeo’) that sends Origin insight in STUN and TURN messages > (hopefully in full compliance with the proposed standards draft). It > uses a new STUN attribute with a value of 0x802F as initially proposed. > It has been implemented with a Chrome flag to enable and disable this > unique feature (and is by default disabled to prevent any > non-intentional use of this feature until the standard is finalized). > > > > We have built ‘Chromeo’ for Linux and have verified with WireShark that > proper STUN Origin attributes are being included in STUN/TURN messages > sent by the browser to servers (screen captures of STUN messages > illustrating the Origin attribute and content are available however I > was not sure if it is considered appropriate to attach any images to a > post of this nature). > > > > Coordinated changes to both the WebRTC and Chromium open source projects > have been submitted for consideration. The two submitted change lists > together implement a proof-of-concept of the browser portion of the STUN > Origin draft: > http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 and Oleg > has previously posted that he has provided a proof-of-concept for the > TURN sever end of the solution. > > > > Hopefully these two proof-of-concept efforts will help us quickly drive > the STUN Origin standard effort to fruition and help browsers quickly > implement STUN Origin enhancements. > > > > > > Cheers, > > /John/ > > > > AVAYA > 1.919.425.8446 > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Thu Jun 26 07:31:50 2014 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 556441B304F for ; Thu, 26 Jun 2014 07:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 UyPUhdF1Dg4t for ; Thu, 26 Jun 2014 07:31:42 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c: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 29E991B30C8 for ; Thu, 26 Jun 2014 06:58:05 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so3740274wes.23 for ; Thu, 26 Jun 2014 06:58:03 -0700 (PDT) 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=lrxWLcTF46qhJPkWnpeOiNsAJ2uGGpBPZMcV1rf58Ek=; b=Y8GjrzbzFOgVhUmNLeKJiwr/lmPDQjyrXq+Pkwmbq6N7ml4QGiEL+YjhFb8z7uTD5M 5zk3E4dRUx7DMBr8J0UhaQenldSOeGncCciDMHo5NX3vFL8IZHQ5xy77avPUA7Qjl/sF XC+B+qxXjM4fkqRgzDjypqIijfDlYaxibp7odxMOJ2/bHe5GXkvus5fPE74KJs8QRi1A Hhutz/Ntk/u5sk4arrvU7ukGNsDOfcBoJ3q1u6JLBwQ1Hp9JmblRfqXgVXqGi2WOfFlr +F7xG1tWV/GtKHP/lGkfnNHmboEekBhZiyFR1xjcKj9yZvEGa6RGhb9mkgq6J/a5U9Ha 25JQ== MIME-Version: 1.0 X-Received: by 10.180.149.175 with SMTP id ub15mr4567100wib.53.1403791082599; Thu, 26 Jun 2014 06:58:02 -0700 (PDT) Received: by 10.217.152.200 with HTTP; Thu, 26 Jun 2014 06:58:02 -0700 (PDT) In-Reply-To: <53AC1AC0.8060903@per.reau.lt> References: <93BEDDC39A54294B9E78C7860516FA474396523F@AZ-US1EXMB06.global.avaya.com> <53AC1AC0.8060903@per.reau.lt> Date: Thu, 26 Jun 2014 08:58:02 -0500 Message-ID: From: Alan Johnston To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c38118d13e1204fcbd9465 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9DVEQYFUKLzPAxzz5x6avjCQkcs Cc: "tram@ietf.org" Subject: Re: [tram] Chrome STUN Origin proof-of-concept... 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, 26 Jun 2014 14:31:49 -0000 --001a11c38118d13e1204fcbd9465 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Will do. We are working on a revision now. - Alan - On Thu, Jun 26, 2014 at 8:06 AM, Simon Perreault wrote: > This is great! > > You need to add an Implementation Status section to your draft! > http://tools.ietf.org/html/rfc6982 > > Simon > > Le 2014-06-25 21:11, Yoakum, John H (John) a =C3=A9crit : > > We now have a proof-of-concept version of the Chrome browser (nicknamed > > =E2=80=98Chromeo=E2=80=99) that sends Origin insight in STUN and TURN m= essages > > (hopefully in full compliance with the proposed standards draft). It > > uses a new STUN attribute with a value of 0x802F as initially proposed. > > It has been implemented with a Chrome flag to enable and disable this > > unique feature (and is by default disabled to prevent any > > non-intentional use of this feature until the standard is finalized). > > > > > > > > We have built =E2=80=98Chromeo=E2=80=99 for Linux and have verified wit= h WireShark that > > proper STUN Origin attributes are being included in STUN/TURN messages > > sent by the browser to servers (screen captures of STUN messages > > illustrating the Origin attribute and content are available however I > > was not sure if it is considered appropriate to attach any images to a > > post of this nature). > > > > > > > > Coordinated changes to both the WebRTC and Chromium open source project= s > > have been submitted for consideration. The two submitted change lists > > together implement a proof-of-concept of the browser portion of the STU= N > > Origin draft: > > http://tools.ietf.org/html/draft-johnston-tram-stun-origin-02 and Oleg > > has previously posted that he has provided a proof-of-concept for the > > TURN sever end of the solution. > > > > > > > > Hopefully these two proof-of-concept efforts will help us quickly drive > > the STUN Origin standard effort to fruition and help browsers quickly > > implement STUN Origin enhancements. > > > > > > > > > > > > Cheers, > > > > /John/ > > > > > > > > AVAYA > > 1.919.425.8446 > > > > > > > > > > > > _______________________________________________ > > 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 > --001a11c38118d13e1204fcbd9465 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Will do. =C2=A0We are working on a revision now.

<= /div>
- Alan -


On Thu, Jun 26, 2014 at 8:06 AM, Simon Perreault <simon@p= er.reau.lt> wrote:
This is great!

You need to add an Implementation Status section to your draft!
http://too= ls.ietf.org/html/rfc6982

Simon

Le 2014-06-25 21:11, Yoakum, John H (John) a =C3=A9crit :
> We now have a proof-of-concept version of the Chrome browser (nickname= d
> =E2=80=98Chromeo=E2=80=99) that sends Origin insight in STUN and TURN = messages
> (hopefully in full compliance with the proposed standards draft). =C2= =A0It
> uses a new STUN attribute with a value of 0x802F as initially proposed= .
> It has been implemented with a Chrome flag to enable and disable this<= br> > unique feature (and is by default disabled to prevent any
> non-intentional use of this feature until the standard is finalized).<= br> >
>
>
> We have built =E2=80=98Chromeo=E2=80=99 for Linux and have verified wi= th WireShark that
> proper STUN Origin attributes are being included in STUN/TURN messages=
> sent by the browser to servers (screen captures of STUN messages
> illustrating the Origin attribute and content are available however I<= br> > was not sure if it is considered appropriate to attach any images to a=
> post of this nature).
>
>
>
> Coordinated changes to both the WebRTC and Chromium open source projec= ts
> have been submitted for consideration. =C2=A0The two submitted change = lists
> together implement a proof-of-concept of the browser portion of the ST= UN
> Origin draft:
> http://tools.ietf.org/html/draft-johnston-tram-stun-o= rigin-02 and Oleg
> has previously posted that he has provided a proof-of-concept for the<= br> > TURN sever end of the solution.
>
>
>
> Hopefully these two proof-of-concept efforts will help us quickly driv= e
> the STUN Origin standard effort to fruition and help browsers quickly<= br> > implement STUN Origin enhancements.
>
>
>
>
>
> Cheers,
>
> /John/
>
>
>
> AVAYA
> 1.919.425.8446
>
>
>
>
>
> _______________________________________________
> 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

--001a11c38118d13e1204fcbd9465-- From nobody Fri Jun 27 01:25:12 2014 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 5C26D1B3129 for ; Fri, 27 Jun 2014 01:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 G2Kr-Gvkx0UX for ; Fri, 27 Jun 2014 01:25:05 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 82AFB1B2CCA for ; Fri, 27 Jun 2014 01:25:05 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id A325723F0826 for ; Fri, 27 Jun 2014 10:25:04 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 27 Jun 2014 10:25:04 +0200 From: "Hutton, Andrew" To: "tram@ietf.org" Thread-Topic: draft-hutton-httpbis-connect-protocol-00.txt Thread-Index: AQHPkeFLNG6i9YxDtEKkOGppCRDA/w== Date: Fri, 27 Jun 2014 08:25:03 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E0CF30@MCHP04MSX.global-ad.net> 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: http://mailarchive.ietf.org/arch/msg/tram/L9OxCMdhL7N_oAF_Zhw8CnF9egU Subject: [tram] draft-hutton-httpbis-connect-protocol-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, 27 Jun 2014 08:25:07 -0000 I just submitted this draft for which there is a short agenda slot in Toron= to httpbis wg meeting. The draft proposes adding an indication in to HTTP Connect as to what proto= col is used with the tunnel and specifically for use with WebRTC (I.e. TURN= /ICE-TCP) so should be of interest to this group. Discussion should be on the HTTPBIS list. Regards Andy Title : HTTP Connect - Tunnel Protocol For WebRTC Authors : Andrew Hutton Justin Uberti Martin Thomson Filename : draft-hutton-httpbis-connect-protocol-00.txt Pages : 7 Date : 2014-06-27 Abstract: This document describes a mechanism to enable HTTP Clients to provide an indication within a HTTP Connect request as to which protocol will be used within the tunnel established to the Server identified by the target resource. The tunneled protocol is declared using the Tunnel- Protocol HTTP Request header field. Label usage relating to the use of HTTP Connect by WebRTC clients (e.g. turn, webrtc) are described in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hutton-httpbis-connect-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-hutton-httpbis-connect-protocol-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jun 27 06:21:30 2014 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 494891B319C for ; Fri, 27 Jun 2014 06:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 1ojDBvmWqb7t for ; Fri, 27 Jun 2014 06:21:27 -0700 (PDT) Received: from nomis80.org (nomis80.org [IPv6:2600:3c03::f03c:91ff:fe69:7108]) by ietfa.amsl.com (Postfix) with ESMTP id 743881B319B for ; Fri, 27 Jun 2014 06:21:27 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca [173.178.42.233]) by nomis80.org (Postfix) with ESMTPSA id 3354810EAB for ; Fri, 27 Jun 2014 13:24:28 +0000 (UTC) Message-ID: <53AD6FD6.3080205@per.reau.lt> Date: Fri, 27 Jun 2014 09:21:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oXzGoBHs-n9qTV8Pb70kYL29Q2U Subject: [tram] Two new authentication mechanisms 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, 27 Jun 2014 13:21:29 -0000 TRAMsters, We are soliciting discussion on the potential adoption as working-group documents of these two drafts: http://tools.ietf.org/html/draft-johnston-tram-stun-origin http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new authentication mechanism(s) to IESG for publication as Proposed Standard"). If you would like to see one or both of the drafts adopted, or if you are opposed, please explain why. Authors, we will assume you are for adoption of your own drafts. Please consider the interactions between the two drafts. Is there anything interesting or problematic? What about overlap in function? Is there any? If so, is it necessary or problematic? Let's take two weeks to discuss this. Thanks, Simon & Gonzalo From nobody Fri Jun 27 11:15:30 2014 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 0F5471B2861; Fri, 27 Jun 2014 11:15:25 -0700 (PDT) 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 kPhMtbbc-RVf; Fri, 27 Jun 2014 11:15:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A32951B27E1; Fri, 27 Jun 2014 11:15:22 -0700 (PDT) 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.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627181522.14525.77216.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 11:15:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/371eavCiNnOHKJ8I4fUIFc1_DTc Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-dtls-05.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, 27 Jun 2014 18:15:25 -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 : Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-dtls-05.txt Pages : 18 Date : 2014-06-27 Abstract: This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidances on when and how to use DTLS with the currently standardized STUN Usages. It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFC 5389 and RFC 5928. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-dtls-05 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 Sat Jun 28 10:04:56 2014 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 E10081A0382 for ; Sat, 28 Jun 2014 10:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 FGOezGcEknmo for ; Sat, 28 Jun 2014 10:04:51 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E2A1A0380 for ; Sat, 28 Jun 2014 10:04:50 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so6428638wes.26 for ; Sat, 28 Jun 2014 10:04:49 -0700 (PDT) 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 :content-type; bh=jpGma+qX06FaFhX9qyG3ImqMq8R7lawDGYQzBcbcgZ0=; b=vN+QqypcZqsFae77y4qbqDp5FVhr1o2UAsO4Zoah6SbBrlkS9kluUv3eTokgUhd2qr TyXWPK2k+jDNwNzQ09BX7KFmHQTFo1GqW5QDwBES5vgbNAzu0tYG/ML8SvkT6ZFCR/hV toX4hnyT+RmDZ7BpaEkAZcM9ottqajGPMc81wU7aLv+eKnqgIVRU/lH6FN3+2khj8bJh Qt0yJDSl89Z3UsEdCyiyn9kwQfRvsAsJxIK4Wc43cTio+eGWh1olRwDRlhy8O5PgGASs cKWEbK1iGjOw0v4UU/Tm5Td1yCNyvoFNfM2murb3xtjleOm7aUGIFccXHQMXYLxDPECG UYFA== MIME-Version: 1.0 X-Received: by 10.180.79.201 with SMTP id l9mr19157446wix.60.1403975089310; Sat, 28 Jun 2014 10:04:49 -0700 (PDT) Received: by 10.217.152.200 with HTTP; Sat, 28 Jun 2014 10:04:49 -0700 (PDT) In-Reply-To: <20140628165007.32702.46107.idtracker@ietfa.amsl.com> References: <20140628165007.32702.46107.idtracker@ietfa.amsl.com> Date: Sat, 28 Jun 2014 12:04:49 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428cbe78d3a804fce86c1d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YrDgyE13_CBv2TdjjXDIxoJHmSw Subject: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.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, 28 Jun 2014 17:04:54 -0000 --f46d04428cbe78d3a804fce86c1d Content-Type: text/plain; charset=UTF-8 All, We have updated the STUN Origin draft. The major changes relate to: 1. Adding sections on media keep-alive and SIP keep-alive usages 2. Adding a section on multiple origins 3. Adding a section on Implementation Status about the open source implementations of the browser and STUN/TURN server that support the ORIGIN attribute 4. Clarified integrity protection of the attribute in the Security Considerations section. These changes are based on all recent reviews and mailing list comments. As always, comments are most welcome! - Alan - ---------- Forwarded message ---------- From: Date: Sat, Jun 28, 2014 at 11:50 AM Subject: New Version Notification for draft-johnston-tram-stun-origin-03.txt To: Kundan Singh , Alan Johnston < alan.b.johnston@gmail.com>, John Yoakum , Justin Uberti < justin@uberti.name> A new version of I-D, draft-johnston-tram-stun-origin-03.txt has been successfully submitted by Alan Johnston and posted to the IETF repository. Name: draft-johnston-tram-stun-origin Revision: 03 Title: An Origin Attribute for the STUN Protocol Document date: 2014-06-28 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt Status: https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ Htmlized: http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web and SIP contexts. 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 --f46d04428cbe78d3a804fce86c1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

We have updated the STUN Origin dr= aft. =C2=A0The major changes relate to:

1. Adding = sections on media keep-alive and SIP keep-alive usages
2. Adding = a section on multiple origins
3. Adding a section on Implementation Status about the open source imp= lementations of the browser and STUN/TURN server that support the ORIGIN at= tribute
4. Clarified integrity protection of the attribute in the= Security Considerations section.

These changes are based on all recent reviews and maili= ng list comments.

As always, comments are most wel= come!

- Alan -

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Sat, Jun 28, 2014 at 11:50= AM
Subject: New Version Notification for draft-johnston-tram-stun-origin-03.tx= t
To: Kundan Singh <kundan10@gm= ail.com>, Alan Johnston <alan.b.johnston@gmail.com>, John Yoakum <yoakum@avaya.com>, Justin Uberti <justin@uberti.name>



A new version of I-D, draft-johnston-tram-stun-origin-03.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-johnston-tram-stun-origin Revision: =C2=A0 =C2=A0 =C2=A0 03
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An Origin Attribute for the STUN P= rotocol
Document date: =C2=A02014-06-28
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracke= r.ietf.org/doc/draft-johnston-tram-stun-origin/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/= draft-johnston-tram-stun-origin-03
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-johnston-tram-stun-origin-03

Abstract:
=C2=A0 =C2=A0STUN, or Session Traversal Utilities for NAT, is a protocol us= ed to
=C2=A0 =C2=A0assist other protocols traverse Network Address Translators or= NATs.
=C2=A0 =C2=A0STUN, and STUN extensions such as TURN, or Traversal Using Rel= ays
=C2=A0 =C2=A0around NAT, and ICE, Interactive Communications Establishment,= have
=C2=A0 =C2=A0been around for many years but with WebRTC, Web Real-Time
=C2=A0 =C2=A0Communications, STUN and related extensions are about to see m= ajor
=C2=A0 =C2=A0deployments and implementation due to these protocols being =C2=A0 =C2=A0implemented in browsers. =C2=A0This specification defines an O= RIGIN
=C2=A0 =C2=A0attribute for STUN that can be used in similar ways to the HTT= P
=C2=A0 =C2=A0header field of the same name. =C2=A0WebRTC browsers utilizing= STUN and
=C2=A0 =C2=A0TURN would include this attribute which would provide servers = with
=C2=A0 =C2=A0additional information about the STUN and TURN requests they r= eceive.
=C2=A0 =C2=A0This specification defines the usage of the STUN ORIGIN attrib= ute for
=C2=A0 =C2=A0web and SIP contexts.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--f46d04428cbe78d3a804fce86c1d-- From nobody Mon Jun 30 09:24:52 2014 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 D22521A0392 for ; Mon, 30 Jun 2014 09:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 A0EBTXJylqQ2 for ; Mon, 30 Jun 2014 09:24:49 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E1F1A03A4 for ; Mon, 30 Jun 2014 09:24:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAA+OsVPGmAcV/2dsb2JhbABXA4JpJFJavXweh0ABgQ4WdYQDAQEBAQMBAQEPKDQXBAIBCA0EBAEBCxQJBycLFAkIAgQBEggaiCABDKBqpwUXjjAmIRcGC4McgRYFhGMClz+FaYxOg0KBb0E X-IronPort-AV: E=Sophos; i="5.01,575,1400040000"; d="scan'208,223"; a="74173813" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 30 Jun 2014 12:24:47 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 30 Jun 2014 12:05:13 -0400 Received: from AZ-US1EXMB06.global.avaya.com ([fe80::38da:dafb:7358:e6f5]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 12:24:46 -0400 From: "Yoakum, John H (John)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Two new authentication mechanisms Thread-Index: AQHPkgq2eBenJRMQWkeiRRvjwbNiwpuJ1Ehg Date: Mon, 30 Jun 2014 16:24:46 +0000 Message-ID: <93BEDDC39A54294B9E78C7860516FA4743965A82@AZ-US1EXMB06.global.avaya.com> References: <53AD6FD6.3080205@per.reau.lt> In-Reply-To: <53AD6FD6.3080205@per.reau.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] 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/KrwOMkyy-eus1mu4mPzLJHtRW44 Subject: Re: [tram] Two new authentication mechanisms 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, 30 Jun 2014 16:24:51 -0000 >From my perspective, we should keep these two drafts separate as both are i= nteresting but the Origin draft is reasonably mature already, and conceptua= lly very straight forward as it is currently defined. It would seem the Or= igin draft could be approved now as we already have both browser and TURN s= erver proof-of-concept implementations (see latest draft update) that demon= strate feasibility, desirability, and usefulness. Of course the effort to = figure out how to add this to a browser was mentally significant but the ac= tual code changes required for a proof-of-concept total just over 100 lines= out of ~10M lines in Chrome. Now that those changes have been made public= ally available it is straight forward for Google, and reasonably simple for= everyone else, to comply with this draft and enable its various value prop= ositions. The additional bits in the STUN messages are typically quite sma= ll and insignificant for the value delivered. Once we get this draft appro= ved it is likely this functionality can be in browsers quickly, but the bro= wser vendors will probably wait for draft approval to implement it (and we = want to limit the use of that attribute value proposed before approval anyw= ay). In addition to various use cases previously discussed, it will prove = to be highly useful to know Origin in various customer service systems wher= e customers are reaching out to contact centers as it helps provide custome= r context. Cheers, John AVAYA 1.919.425.8446=20 -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Friday, June 27, 2014 9:21 AM To: tram@ietf.org Subject: [tram] Two new authentication mechanisms TRAMsters, We are soliciting discussion on the potential adoption as working-group doc= uments of these two drafts: http://tools.ietf.org/html/draft-johnston-tram-stun-origin http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new auth= entication mechanism(s) to IESG for publication as Proposed Standard"). If you would like to see one or both of the drafts adopted, or if you are o= pposed, please explain why. Authors, we will assume you are for adoption of= your own drafts. Please consider the interactions between the two drafts. Is there anything = interesting or problematic? What about overlap in function? Is there any? I= f so, is it necessary or problematic? Let's take two weeks to discuss this. Thanks, Simon & Gonzalo _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon Jun 30 10:17:12 2014 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 E3BAA1A011B for ; Mon, 30 Jun 2014 10:17:03 -0700 (PDT) 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 z8ZkHlSrJu-K for ; Mon, 30 Jun 2014 10:17:01 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450: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 BEF751A03A5 for ; Mon, 30 Jun 2014 10:17:00 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so8499639wes.11 for ; Mon, 30 Jun 2014 10:16:59 -0700 (PDT) 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=BiuNHDCIBp11GQIvfTJg9IsGvPoNWLShl8QNo5a15wc=; b=oK7OIkwidknyoQXZlU2YJYjVjAp4/wZ8sFtqBBsdGHTguBgNvkVzUObG8twjpsFNk0 8g4hhkGJ7x8MEcSQnrbJC+uAkYpKZZa/ldeA6ihe7mgU7YrGC0un4mVXQKFWGOiXn9qS SwV7j9qZnMhTmo7zKYrfFPw9dlgmbIX8TE5+zIh1DdhQP6gc5sEAAhEG5T3RBt3vdIZm S33Abc5seWAP9Ab605Lqq7mYKdZub8k4v5j+8tav0iM0+2rIAeSXz/ekp8CrLLr3NTdp skD+uVwPXjozmK97vJwhMCuqZboFuRFsZ5KYf7WRGs4bASeM89fOfooH6xFTVm8z6UX2 MzqA== MIME-Version: 1.0 X-Received: by 10.180.76.132 with SMTP id k4mr30972615wiw.1.1404148619412; Mon, 30 Jun 2014 10:16:59 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 30 Jun 2014 10:16:59 -0700 (PDT) In-Reply-To: References: <20140628165007.32702.46107.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 10:16:59 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XoqH4C39HN37YQHX18Orc-VnoZc Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.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, 30 Jun 2014 17:17:04 -0000 Some nits on this sentence: For a web browser (HTTP User Agent), the contents of the ORIGIN attribute is the unicode-serialization of an origin defined in Section 6.1 of [RFC6454]. I think that using "for a web browser" here is redundant, since the entire point of the document is that web browsers are the ones adding this (other users are going to add whatever gets them what they want). The second is that it's the UTF-8 encoding of the unicode-serialization. And this sentence: [...] It MUST contain a UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. The value of 268 is chosen to be larger than the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number. This arbitrary restriction doesn't seem like a great idea. If the coding efficiency of UTF-8 is strictly better than punycode, then it's probably OK, but why be so strict? Is there a strict need to limit this to URIs with 5-character-or-less schemes? On 28 June 2014 10:04, Alan Johnston wrote: > All, > > We have updated the STUN Origin draft. The major changes relate to: > > 1. Adding sections on media keep-alive and SIP keep-alive usages > 2. Adding a section on multiple origins > 3. Adding a section on Implementation Status about the open source > implementations of the browser and STUN/TURN server that support the ORIGIN > attribute > 4. Clarified integrity protection of the attribute in the Security > Considerations section. > > These changes are based on all recent reviews and mailing list comments. > > As always, comments are most welcome! > > - Alan - > > ---------- Forwarded message ---------- > From: > Date: Sat, Jun 28, 2014 at 11:50 AM > Subject: New Version Notification for draft-johnston-tram-stun-origin-03.txt > To: Kundan Singh , Alan Johnston > , John Yoakum , Justin Uberti > > > > > A new version of I-D, draft-johnston-tram-stun-origin-03.txt > has been successfully submitted by Alan Johnston and posted to the > IETF repository. > > Name: draft-johnston-tram-stun-origin > Revision: 03 > Title: An Origin Attribute for the STUN Protocol > Document date: 2014-06-28 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt > Status: > https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ > Htmlized: > http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03 > > Abstract: > STUN, or Session Traversal Utilities for NAT, is a protocol used to > assist other protocols traverse Network Address Translators or NATs. > STUN, and STUN extensions such as TURN, or Traversal Using Relays > around NAT, and ICE, Interactive Communications Establishment, have > been around for many years but with WebRTC, Web Real-Time > Communications, STUN and related extensions are about to see major > deployments and implementation due to these protocols being > implemented in browsers. This specification defines an ORIGIN > attribute for STUN that can be used in similar ways to the HTTP > header field of the same name. WebRTC browsers utilizing STUN and > TURN would include this attribute which would provide servers with > additional information about the STUN and TURN requests they receive. > This specification defines the usage of the STUN ORIGIN attribute for > web and SIP contexts. > > > > > 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 > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Mon Jun 30 10:53:12 2014 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 E73D31A0400 for ; Mon, 30 Jun 2014 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 Y4XD6QViV6Yi for ; Mon, 30 Jun 2014 10:53:07 -0700 (PDT) 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 050ED1A03F8 for ; Mon, 30 Jun 2014 10:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1522; q=dns/txt; s=iport; t=1404150787; x=1405360387; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sbThheFQs6GmOD3RF19dwC0QRCQvWDozCuMArKpIQnk=; b=UM0QP+5bBuhecdwni8Tw3k74m0thXQIb+PqLv/gWYrFecbX/b6VWlOyg HddFJnPgdF7g0ZS7WUJIjnPp6u72XnzfvC/GlO4WImNT5xirHG+CviQpv SKy0IXw4cTWmt01nyLDuJOkbjpqyk3wDbLAZgdBebz4rRqgyULMRMuOO1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8HACSjsVOtJV2c/2dsb2JhbABagw1SWqsaAQEBAQEBBQECbAGSBodAAYESFnWEAwEBAQQBAQE3NBcGAQgRBAEBCxQJLgsUCQkBBAESCIg6DcgoF4VkiHI+gyeBFgWcJJI3g0KCMA X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57194572" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 30 Jun 2014 17:53:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5UHr6aE031778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 17:53:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 12:53:05 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Two new authentication mechanisms Thread-Index: Ac+UjCJk7Vw1mgRQSQyCT9rqQ0aMTQ== Date: Mon, 30 Jun 2014 17:53:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282E8207@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.70.52] 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/nMR4QOOoxiPATtKIfuAKV3eIKpo Subject: Re: [tram] Two new authentication mechanisms 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, 30 Jun 2014 17:53:09 -0000 I support adoption of both drafts. I think there is no interaction required= between these two drafts. For example If third party authorization is used= then ORIGIN attribute could be used by the TURN server for logging purpose= . -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Friday, June 27, 2014 6:51 PM > To: tram@ietf.org > Subject: [tram] Two new authentication mechanisms >=20 > TRAMsters, >=20 > We are soliciting discussion on the potential adoption as working-group > documents of these two drafts: >=20 > http://tools.ietf.org/html/draft-johnston-tram-stun-origin > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz >=20 > They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new > authentication mechanism(s) to IESG for publication as Proposed Standard"= ). >=20 > If you would like to see one or both of the drafts adopted, or if you are= opposed, > please explain why. Authors, we will assume you are for adoption of your = own > drafts. >=20 > Please consider the interactions between the two drafts. Is there anythin= g > interesting or problematic? What about overlap in function? Is there any?= If so, > is it necessary or problematic? >=20 > Let's take two weeks to discuss this. >=20 > Thanks, > Simon & Gonzalo >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Jun 30 11:14:04 2014 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 BE19A1A0444 for ; Mon, 30 Jun 2014 11:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 KTcZO8tC2KDK for ; Mon, 30 Jun 2014 11:13:54 -0700 (PDT) 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 8266F1A0428 for ; Mon, 30 Jun 2014 11:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22650; q=dns/txt; s=iport; t=1404152030; x=1405361630; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5KBtLUCWBbDY/DN8QABqQT6TMD12f4my3/nJNoeuSYA=; b=eQ0YgcDEZxJLa0Cc38v2bDNv663ylw4gUvT6GVnRtntolyqOEI+6Qjtv UoSbKcq3Nk0VFUI2hlRtcCQDzjs+gPn3cT3RBZ+HMQvWSIG7n0XZU17PM tjrCeRtZT9Nimn47zRLRGI9q7kz4jDYOQBysZfnjEtVlN+OOAsldWy7JM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMOAJCnsVOtJA2M/2dsb2JhbABagkZHUlMHgm6oLAEBAQEBAQUBbgGQMYkVARl5FnWEAwEBAQQjCkEJEgIBCBEDAQEBCx0DAgICHxEUCQgCBAESCAGIJQMRCAWrVJViDYZSF4VkhnyBUCYPBwoNCgEGgnE2gRYFhWKSfoNEjCWGEoIAgUJsgQNB X-IronPort-AV: E=Sophos; i="5.01,576,1400025600"; d="scan'208,217"; a="57187198" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 30 Jun 2014 18:13:49 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5UIDnxb010273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 18:13:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 13:13:49 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston , "tram@ietf.org" Thread-Topic: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.txt Thread-Index: AQHPkvMYW5mQAuZhekOtlhou66HbqZuJ8/1g Date: Mon, 30 Jun 2014 18:13:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282E82BC@xmb-rcd-x10.cisco.com> References: <20140628165007.32702.46107.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.70.52] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A282E82BCxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/12QMhtjxCMw60hqGowTbISzXsIQ Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.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, 30 Jun 2014 18:14:00 -0000 --_000_913383AAA69FF945B8F946018B75898A282E82BCxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxhbiwNCg0KDQoNCk15IGNvbW1lbnRzOg0KDQoNCg0KWzFdIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zOg0KDQoNCg0KQ29tbWVudD4gWW91IG1heSB3YW50IHRvIGFkZCB0aGF0IElmIChEKVRM UyBpcyB1c2VkIHRoZW4gU1RVUk4gT1JJR0lOIGF0dHJpYnV0ZSBjYW5ub3QgYmUgbW9kaWZpZWQg YnkgYW4gaW50ZXJtZWRpYXJ5Lg0KDQoNCg0KWzJdIFRoaXMgaW5mb3JtYXRpb24gaXMgb2Z0ZW4g YXZhaWxhYmxlIGluIG90aGVyIG1lc3NhZ2VzIHNlbnQgYnkgdGhlIGJyb3dzZXIsIHN1Y2ggYXMg RE5TIG9yIEhUVFAgcmVxdWVzdHMuDQoNCg0KDQpDb21tZW50PiAgWWVzLCBidXQgYWxsIHRoZXNl IHByb2JsZW1zIHdpbGwgbW9zdCBsaWtlbHkgYmUgYWRkcmVzc2VkIGluIGZ1dHVyZS4gIEROU09Q IFdHIGlzIGRpc2N1c3NpbmcgdmFyaW91cyBtZWNoYW5pc21zIGZvciBETlMgcHJpdmFjeSBsaWtl IEROUyBvdmVyIChEKVRMUyBhbmQgSFRUUC8yLjAgbWFuZGF0ZXMgVExTLiAgTmV3IFRMUyBleHRl bnNpb25zIGFyZSBkaXNjdXNzZWQgaW4gVExTIFdHIHRvIGVuY3J5cHQgVExTIGhhbmRzaGFrZSBm b3IgcHJpdmFjeSByZWFzb25zDQoNCg0KDQpbM10gU2VjdGlvbiAyLjQgSUNFIHVzYWdlDQoNCg0K DQpDb21tZW50PiBZb3UgbWF5IGFsc28gc2F5IHRoYXQgZm9yIGNvbnNlbnQgY2hlY2tzIChodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJl c2huZXNzLTA0KSwgU1RVTiBPUklHSU4gYXR0cmlidXRlIGlzIG5vdCByZXF1aXJlZC4NCg0KDQoN Cls0XSAyLjQuIElDRSBVc2FnZQ0KDQoNCg0KQ29tbWVudD4gQW55IHNwZWNpZmljIHJlYXNvbiB0 byBzYXkgIk5PVCBSRUNPTU1FTkRFRCIgPyB3aHkgbm90IHNheSAiTVVTVCBOT1QgdXNlIE9SSUdJ TiBhdHRyaWJ1dGUiID8NCg0KDQoNCls1XSBTZW5kZXJzIE1BWSBpbmNsdWRlIG11bHRpcGxlIE9S SUdJTiBhdHRyaWJ1dGVzIGluIGEgcmVxdWVzdCwgYW5kIHJlY2VpdmVycyBNVVNUIHN1cHBvcnQg cGFyc2luZyBhbmQgcmVjZWl2aW5nIG11bHRpcGxlIE9SSUdJTiBhdHRyaWJ1dGVzLg0KDQoNCg0K Q29tbWVudD4gSWYgcGF0aCBNVFUgaXMgdW5rbm93biB0aGVuIFNUVU4gbWVzc2FnZXMgb3ZlciBJ UHY0IHdvdWxkIG5lZWQgdG8gYmUgbGVzcyB0aGFuIDU0OCBieXRlcyAoU2VjdGlvbiA3LjEgb2Yg W1JGQzUzODldKS4gU2VuZGVyIG11c3QgdXNlIHRoaXMgbGVuZ3RoIHJlc3RyaWN0aW9uIHRvIGxp bWl0IHRoZSBudW1iZXIgb2YgT1JJR0lOIGF0dHJpYnV0ZXMgaW4gdGhlIFNUVU4gcmVxdWVzdC4N Cg0KDQoNCls2XSAgIFNUVU4gZGVmaW5lcyB0aHJlZSBhdXRoZW50aWNhdGlvbiBtb2RlcywgZGVw ZW5kaW5nIG9uIHRoZSBTVFVOIHVzYWdlLg0KDQoNCg0KQ29tbWVudD4gVGhlcmUgYXJlIG9ubHkg dHdvIGF1dGhlbnRpY2F0aW9uIG1vZGVzICENCg0KDQoNCls3XSBTdWdnZXN0IHRvIHNwbGl0IElu dHJvZHVjdGlvbiwgaGF2ZSBhIHNlcGFyYXRlIHNlY3Rpb24gdG8gZGlzY3VzcyB0aGUgcHJvYmxl bS4NCg0KDQoNCls4XSBJbiBhZGRpdGlvbiB0byBleHBsaWNpdGx5IHByb3Zpc2lvbmluZyB0aGUg cmVhbG0gdmFsdWUgaW4gdGhlIGphdmEgc2NyaXB0IHRoZSBvdGhlciBwcm9ibGVtIGlzIGV4cG9z aW5nIHRoZSB1c2VyIGNyZWRlbnRpYWxzIHRvIHRoZSBKYXZhU2NyaXB0LiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDIg YWRkcmVzc2VzIHRoaXMgcHJvYmxlbS4NCg0KDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCg0KLVRp cnUNCg0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWxhbiBKb2huc3Rvbg0KU2VudDogU2F0dXJkYXksIEp1bmUgMjgsIDIwMTQgMTA6MzUg UE0NClRvOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBbdHJhbV0gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDMudHh0DQoN CkFsbCwNCg0KV2UgaGF2ZSB1cGRhdGVkIHRoZSBTVFVOIE9yaWdpbiBkcmFmdC4gIFRoZSBtYWpv ciBjaGFuZ2VzIHJlbGF0ZSB0bzoNCg0KMS4gQWRkaW5nIHNlY3Rpb25zIG9uIG1lZGlhIGtlZXAt YWxpdmUgYW5kIFNJUCBrZWVwLWFsaXZlIHVzYWdlcw0KMi4gQWRkaW5nIGEgc2VjdGlvbiBvbiBt dWx0aXBsZSBvcmlnaW5zDQozLiBBZGRpbmcgYSBzZWN0aW9uIG9uIEltcGxlbWVudGF0aW9uIFN0 YXR1cyBhYm91dCB0aGUgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBicm93c2Vy IGFuZCBTVFVOL1RVUk4gc2VydmVyIHRoYXQgc3VwcG9ydCB0aGUgT1JJR0lOIGF0dHJpYnV0ZQ0K NC4gQ2xhcmlmaWVkIGludGVncml0eSBwcm90ZWN0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgaW4gdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClRoZXNlIGNoYW5nZXMgYXJlIGJh c2VkIG9uIGFsbCByZWNlbnQgcmV2aWV3cyBhbmQgbWFpbGluZyBsaXN0IGNvbW1lbnRzLg0KDQpB cyBhbHdheXMsIGNvbW1lbnRzIGFyZSBtb3N0IHdlbGNvbWUhDQoNCi0gQWxhbiAtDQoNCi0tLS0t LS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IFNhdCwg SnVuIDI4LCAyMDE0IGF0IDExOjUwIEFNDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDMudHh0DQpUbzogS3VuZGFu IFNpbmdoIDxrdW5kYW4xMEBnbWFpbC5jb208bWFpbHRvOmt1bmRhbjEwQGdtYWlsLmNvbT4+LCBB bGFuIEpvaG5zdG9uIDxhbGFuLmIuam9obnN0b25AZ21haWwuY29tPG1haWx0bzphbGFuLmIuam9o bnN0b25AZ21haWwuY29tPj4sIEpvaG4gWW9ha3VtIDx5b2FrdW1AYXZheWEuY29tPG1haWx0bzp5 b2FrdW1AYXZheWEuY29tPj4sIEp1c3RpbiBVYmVydGkgPGp1c3RpbkB1YmVydGkubmFtZTxtYWls dG86anVzdGluQHViZXJ0aS5uYW1lPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1qb2huc3Rvbi10cmFtLXN0dW4tb3JpZ2luLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBBbGFuIEpvaG5zdG9uIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1qb2huc3Rvbi10cmFtLXN0dW4tb3JpZ2lu DQpSZXZpc2lvbjogICAgICAgMDMNClRpdGxlOiAgICAgICAgICBBbiBPcmlnaW4gQXR0cmlidXRl IGZvciB0aGUgU1RVTiBQcm90b2NvbA0KRG9jdW1lbnQgZGF0ZTogIDIwMTQtMDYtMjgNCkdyb3Vw OiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMw0KVVJM OiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpv aG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9obnN0b24tdHJhbS1zdHVuLW9yaWdpbi8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2huc3Rv bi10cmFtLXN0dW4tb3JpZ2luLTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtam9obnN0b24tdHJhbS1zdHVuLW9yaWdpbi0wMw0KDQpBYnN0 cmFjdDoNCiAgIFNUVU4sIG9yIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFULCBp cyBhIHByb3RvY29sIHVzZWQgdG8NCiAgIGFzc2lzdCBvdGhlciBwcm90b2NvbHMgdHJhdmVyc2Ug TmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3JzIG9yIE5BVHMuDQogICBTVFVOLCBhbmQgU1RVTiBl eHRlbnNpb25zIHN1Y2ggYXMgVFVSTiwgb3IgVHJhdmVyc2FsIFVzaW5nIFJlbGF5cw0KICAgYXJv dW5kIE5BVCwgYW5kIElDRSwgSW50ZXJhY3RpdmUgQ29tbXVuaWNhdGlvbnMgRXN0YWJsaXNobWVu dCwgaGF2ZQ0KICAgYmVlbiBhcm91bmQgZm9yIG1hbnkgeWVhcnMgYnV0IHdpdGggV2ViUlRDLCBX ZWIgUmVhbC1UaW1lDQogICBDb21tdW5pY2F0aW9ucywgU1RVTiBhbmQgcmVsYXRlZCBleHRlbnNp b25zIGFyZSBhYm91dCB0byBzZWUgbWFqb3INCiAgIGRlcGxveW1lbnRzIGFuZCBpbXBsZW1lbnRh dGlvbiBkdWUgdG8gdGhlc2UgcHJvdG9jb2xzIGJlaW5nDQogICBpbXBsZW1lbnRlZCBpbiBicm93 c2Vycy4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuIE9SSUdJTg0KICAgYXR0cmlidXRl IGZvciBTVFVOIHRoYXQgY2FuIGJlIHVzZWQgaW4gc2ltaWxhciB3YXlzIHRvIHRoZSBIVFRQDQog ICBoZWFkZXIgZmllbGQgb2YgdGhlIHNhbWUgbmFtZS4gIFdlYlJUQyBicm93c2VycyB1dGlsaXpp bmcgU1RVTiBhbmQNCiAgIFRVUk4gd291bGQgaW5jbHVkZSB0aGlzIGF0dHJpYnV0ZSB3aGljaCB3 b3VsZCBwcm92aWRlIHNlcnZlcnMgd2l0aA0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgU1RVTiBhbmQgVFVSTiByZXF1ZXN0cyB0aGV5IHJlY2VpdmUuDQogICBUaGlzIHNwZWNp ZmljYXRpb24gZGVmaW5lcyB0aGUgdXNhZ2Ugb2YgdGhlIFNUVU4gT1JJR0lOIGF0dHJpYnV0ZSBm b3INCiAgIHdlYiBhbmQgU0lQIGNvbnRleHRzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== --_000_913383AAA69FF945B8F946018B75898A282E82BCxmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBBbGFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5NeSBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WzFdIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Db21tZW50 Jmd0OyBZb3UgbWF5IHdhbnQgdG8gYWRkIHRoYXQgSWYgKEQpVExTIGlzIHVzZWQgdGhlbiBTVFVS TiBPUklHSU4gYXR0cmlidXRlIGNhbm5vdCBiZSBtb2RpZmllZCBieSBhbiBpbnRlcm1lZGlhcnku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlsyXSBUaGlzIGluZm9ybWF0aW9uIGlzIG9m dGVuIGF2YWlsYWJsZSBpbiBvdGhlciBtZXNzYWdlcyBzZW50IGJ5IHRoZSBicm93c2VyLCBzdWNo IGFzIEROUyBvciBIVFRQIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5D b21tZW50Jmd0OyZuYnNwOyBZZXMsIGJ1dCBhbGwgdGhlc2UgcHJvYmxlbXMgd2lsbCBtb3N0IGxp a2VseSBiZSBhZGRyZXNzZWQgaW4gZnV0dXJlLiZuYnNwOyBETlNPUCBXRyBpcyBkaXNjdXNzaW5n IHZhcmlvdXMgbWVjaGFuaXNtcyBmb3IgRE5TIHByaXZhY3kgbGlrZSBETlMgb3ZlciAoRClUTFMg YW5kIEhUVFAvMi4wIG1hbmRhdGVzIFRMUy4mbmJzcDsgTmV3IFRMUyBleHRlbnNpb25zIGFyZSBk aXNjdXNzZWQgaW4gVExTIFdHIHRvDQogZW5jcnlwdCBUTFMgaGFuZHNoYWtlIGZvciBwcml2YWN5 IHJlYXNvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WzNdIFNlY3Rpb24gMi40IElD RSB1c2FnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Db21tZW50Jmd0OyBZb3UgbWF5 IGFsc28gc2F5IHRoYXQgZm9yIGNvbnNlbnQgY2hlY2tzICg8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTA0 Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNl bnQtZnJlc2huZXNzLTA0PC9hPiksIFNUVU4gT1JJR0lOIGF0dHJpYnV0ZSBpcw0KIG5vdCByZXF1 aXJlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WzRdIDIuNC4gSUNFIFVzYWdlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNvbW1lbnQmZ3Q7IEFueSBzcGVjaWZpYyByZWFz b24gdG8gc2F5ICZxdW90O05PVCBSRUNPTU1FTkRFRCZxdW90OyA/IHdoeSBub3Qgc2F5ICZxdW90 O01VU1QgTk9UIHVzZSBPUklHSU4gYXR0cmlidXRlJnF1b3Q7ID88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+WzVdIFNlbmRlcnMgTUFZIGluY2x1ZGUgbXVsdGlwbGUgT1JJR0lOIGF0dHJp YnV0ZXMgaW4gYSByZXF1ZXN0LCBhbmQgcmVjZWl2ZXJzIE1VU1Qgc3VwcG9ydCBwYXJzaW5nIGFu ZCByZWNlaXZpbmcgbXVsdGlwbGUgT1JJR0lOIGF0dHJpYnV0ZXMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkNvbW1lbnQmZ3Q7IElmIHBhdGggTVRVIGlzIHVua25vd24gdGhlbiBTVFVO IG1lc3NhZ2VzIG92ZXIgSVB2NCB3b3VsZCBuZWVkIHRvIGJlIGxlc3MgdGhhbiA1NDggYnl0ZXMg KFNlY3Rpb24gNy4xIG9mIFtSRkM1Mzg5XSkuIFNlbmRlciBtdXN0IHVzZSB0aGlzIGxlbmd0aCBy ZXN0cmljdGlvbiB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIE9SSUdJTiBhdHRyaWJ1dGVzIGluIHRo ZSBTVFVOIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPls2XSZuYnNwOyZu YnNwOyBTVFVOIGRlZmluZXMgdGhyZWUgYXV0aGVudGljYXRpb24gbW9kZXMsIGRlcGVuZGluZyBv biB0aGUgU1RVTiB1c2FnZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q29tbWVudCZn dDsgVGhlcmUgYXJlIG9ubHkgdHdvIGF1dGhlbnRpY2F0aW9uIG1vZGVzICE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+WzddIFN1Z2dlc3QgdG8gc3BsaXQgSW50cm9kdWN0aW9uLCBoYXZl IGEgc2VwYXJhdGUgc2VjdGlvbiB0byBkaXNjdXNzIHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5bOF0gSW4gYWRkaXRpb24gdG8gZXhwbGljaXRseSBwcm92aXNpb25p bmcgdGhlIHJlYWxtIHZhbHVlIGluIHRoZSBqYXZhIHNjcmlwdCB0aGUgb3RoZXIgcHJvYmxlbSBp cyBleHBvc2luZyB0aGUgdXNlciBjcmVkZW50aWFscyB0byB0aGUgSmF2YVNjcmlwdC4NCjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGly ZC1wYXJ0eS1hdXRoei0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHkt dHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAyPC9hPiBhZGRyZXNzZXMgdGhpcyBwcm9ibGVt LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgYW5kIFJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tVGlydTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5BbGFuIEpvaG5zdG9uPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdW5lIDI4LCAyMDE0 IDEwOjM1IFBNPGJyPg0KPGI+VG86PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFt0cmFtXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9obnN0 b24tdHJhbS1zdHVuLW9yaWdpbi0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSB1cGRhdGVkIHRoZSBTVFVOIE9yaWdpbiBkcmFmdC4g Jm5ic3A7VGhlIG1ham9yIGNoYW5nZXMgcmVsYXRlIHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBBZGRpbmcgc2VjdGlvbnMgb24gbWVk aWEga2VlcC1hbGl2ZSBhbmQgU0lQIGtlZXAtYWxpdmUgdXNhZ2VzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBBZGRpbmcgYSBzZWN0aW9uIG9u IG11bHRpcGxlIG9yaWdpbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjMuIEFkZGluZyBhIHNlY3Rpb24gb24gSW1wbGVtZW50YXRpb24gU3RhdHVz IGFib3V0IHRoZSBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGJyb3dzZXIgYW5k IFNUVU4vVFVSTiBzZXJ2ZXIgdGhhdCBzdXBwb3J0IHRoZSBPUklHSU4gYXR0cmlidXRlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBDbGFyaWZp ZWQgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIGF0dHJpYnV0ZSBpbiB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgY2hhbmdlcyBhcmUgYmFzZWQgb24gYWxsIHJlY2Vu dCByZXZpZXdzIGFuZCBtYWlsaW5nIGxpc3QgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGFsd2F5cywgY29tbWVudHMgYXJl IG1vc3Qgd2VsY29tZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSBBbGFuIC08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KRGF0ZTogU2F0LCBKdW4gMjgsIDIwMTQgYXQgMTE6NTAgQU08YnI+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4t MDMudHh0PGJyPg0KVG86IEt1bmRhbiBTaW5naCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt1bmRhbjEw QGdtYWlsLmNvbSI+a3VuZGFuMTBAZ21haWwuY29tPC9hPiZndDssIEFsYW4gSm9obnN0b24gJmx0 OzxhIGhyZWY9Im1haWx0bzphbGFuLmIuam9obnN0b25AZ21haWwuY29tIj5hbGFuLmIuam9obnN0 b25AZ21haWwuY29tPC9hPiZndDssIEpvaG4gWW9ha3VtICZsdDs8YSBocmVmPSJtYWlsdG86eW9h a3VtQGF2YXlhLmNvbSI+eW9ha3VtQGF2YXlhLmNvbTwvYT4mZ3Q7LCBKdXN0aW4gVWJlcnRpICZs dDs8YSBocmVmPSJtYWlsdG86anVzdGluQHViZXJ0aS5uYW1lIj5qdXN0aW5AdWJlcnRpLm5hbWU8 L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1qb2huc3Rvbi10cmFtLXN0dW4tb3JpZ2luLTAzLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgQWxhbiBKb2huc3RvbiBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW48YnI+DQpSZXZpc2lvbjog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMDM8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0FuIE9yaWdpbiBBdHRyaWJ1dGUgZm9yIHRoZSBTVFVOIFByb3RvY29sPGJy Pg0KRG9jdW1lbnQgZGF0ZTogJm5ic3A7MjAxNC0wNi0yODxicj4NCkdyb3VwOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxMzxicj4NClVSTDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qb2huc3Rvbi10cmFtLXN0dW4tb3JpZ2luLTAzLnR4 dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDMudHh0PC9hPjxicj4NClN0YXR1czogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4vIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb2huc3Rvbi10cmFt LXN0dW4tb3JpZ2luLzwvYT48YnI+DQpIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9obnN0b24tdHJhbS1zdHVu LW9yaWdpbi0wMyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtam9obnN0b24tdHJhbS1zdHVuLW9yaWdpbi0wMzwvYT48YnI+DQpEaWZmOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDMiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWpvaG5zdG9u LXRyYW0tc3R1bi1vcmlnaW4tMDM8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7 ICZuYnNwO1NUVU4sIG9yIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFULCBpcyBh IHByb3RvY29sIHVzZWQgdG88YnI+DQombmJzcDsgJm5ic3A7YXNzaXN0IG90aGVyIHByb3RvY29s cyB0cmF2ZXJzZSBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvcnMgb3IgTkFUcy48YnI+DQombmJz cDsgJm5ic3A7U1RVTiwgYW5kIFNUVU4gZXh0ZW5zaW9ucyBzdWNoIGFzIFRVUk4sIG9yIFRyYXZl cnNhbCBVc2luZyBSZWxheXM8YnI+DQombmJzcDsgJm5ic3A7YXJvdW5kIE5BVCwgYW5kIElDRSwg SW50ZXJhY3RpdmUgQ29tbXVuaWNhdGlvbnMgRXN0YWJsaXNobWVudCwgaGF2ZTxicj4NCiZuYnNw OyAmbmJzcDtiZWVuIGFyb3VuZCBmb3IgbWFueSB5ZWFycyBidXQgd2l0aCBXZWJSVEMsIFdlYiBS ZWFsLVRpbWU8YnI+DQombmJzcDsgJm5ic3A7Q29tbXVuaWNhdGlvbnMsIFNUVU4gYW5kIHJlbGF0 ZWQgZXh0ZW5zaW9ucyBhcmUgYWJvdXQgdG8gc2VlIG1ham9yPGJyPg0KJm5ic3A7ICZuYnNwO2Rl cGxveW1lbnRzIGFuZCBpbXBsZW1lbnRhdGlvbiBkdWUgdG8gdGhlc2UgcHJvdG9jb2xzIGJlaW5n PGJyPg0KJm5ic3A7ICZuYnNwO2ltcGxlbWVudGVkIGluIGJyb3dzZXJzLiAmbmJzcDtUaGlzIHNw ZWNpZmljYXRpb24gZGVmaW5lcyBhbiBPUklHSU48YnI+DQombmJzcDsgJm5ic3A7YXR0cmlidXRl IGZvciBTVFVOIHRoYXQgY2FuIGJlIHVzZWQgaW4gc2ltaWxhciB3YXlzIHRvIHRoZSBIVFRQPGJy Pg0KJm5ic3A7ICZuYnNwO2hlYWRlciBmaWVsZCBvZiB0aGUgc2FtZSBuYW1lLiAmbmJzcDtXZWJS VEMgYnJvd3NlcnMgdXRpbGl6aW5nIFNUVU4gYW5kPGJyPg0KJm5ic3A7ICZuYnNwO1RVUk4gd291 bGQgaW5jbHVkZSB0aGlzIGF0dHJpYnV0ZSB3aGljaCB3b3VsZCBwcm92aWRlIHNlcnZlcnMgd2l0 aDxicj4NCiZuYnNwOyAmbmJzcDthZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBTVFVO IGFuZCBUVVJOIHJlcXVlc3RzIHRoZXkgcmVjZWl2ZS48YnI+DQombmJzcDsgJm5ic3A7VGhpcyBz cGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIHVzYWdlIG9mIHRoZSBTVFVOIE9SSUdJTiBhdHRyaWJ1 dGUgZm9yPGJyPg0KJm5ic3A7ICZuYnNwO3dlYiBhbmQgU0lQIGNvbnRleHRzLjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4N Cjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A282E82BCxmbrcdx10ciscoc_-- From nobody Mon Jun 30 11:45:26 2014 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 7B33A1A063C for ; Mon, 30 Jun 2014 11:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 w0tCtYlTv12T for ; Mon, 30 Jun 2014 11:45:19 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450: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 926281A0601 for ; Mon, 30 Jun 2014 11:45:18 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so8438976wes.8 for ; Mon, 30 Jun 2014 11:45:16 -0700 (PDT) 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=W5eIZVKRxfZAWlBcrCC7ZdmA/hoPfJJuANloZEKDRiY=; b=N8+0wfrc2sbJOTwduvd+1IKrIvht4ARWDLxuW5wfFP9js84uMbKW/uXam2SzHWEUIk KHN6QxMJIicIAZ5dK69CYB+iRx7ra9+a6qR2SISpKrBB9RS9T08/4auvzs7BrCZKlSv4 V89AiuE8+aJC5QkQZ4dqdf48c7YJLmpVEfV3D7Rvcyn/Up5sRV6t7x4ejRDVkO8wM4cQ jPiG54MVsaxih2XtMD75IXK5Uo04ICpWL2fcx47Xkz9GgDuICk2vF1xdWLN8rLhvRDH+ g+XomEka4+6GWulXDlk7oShB9XVmHsbfLXghX+VxjCu+gtVI3ctmj0kR1b857dyEfzsQ fTWw== MIME-Version: 1.0 X-Received: by 10.180.20.15 with SMTP id j15mr31789943wie.60.1404153916081; Mon, 30 Jun 2014 11:45:16 -0700 (PDT) Received: by 10.217.152.200 with HTTP; Mon, 30 Jun 2014 11:45:16 -0700 (PDT) In-Reply-To: References: <20140628165007.32702.46107.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 13:45:16 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec53f398560d4d004fd120f4b Archived-At: http://mailarchive.ietf.org/arch/msg/tram/UYAq6c0l5yuuRegtECgi1_wdFgI Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.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, 30 Jun 2014 18:45:23 -0000 --bcaec53f398560d4d004fd120f4b Content-Type: text/plain; charset=UTF-8 Martin, Thanks for the feedback on the draft - see my replies below. - Alan - On Mon, Jun 30, 2014 at 12:16 PM, Martin Thomson wrote: > Some nits on this sentence: > > For a web browser (HTTP User Agent), the contents of the ORIGIN > attribute is the unicode-serialization of an origin defined in > Section 6.1 of [RFC6454]. > > I think that using "for a web browser" here is redundant, since the > entire point of the document is that web browsers are the ones adding > this (other users are going to add whatever gets them what they want). > > The second is that it's the UTF-8 encoding of the unicode-serialization. > > This paragraph, and the two following it define what this new attribute carries. (The other two paragraphs begin "For a SIP User Agent..." and "For a Jabber client...") How about if I say instead: "If inserted by a web browser, the ORIGIN attribute contains the UTF-8 encoding of the unicode-serialization of an origin defined in Section 6.1 of [RFC6454]." > And this sentence: > > [...] It MUST contain a > UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. > The value of 268 is chosen to be larger than the maximum 253 > character domain name plus 8 characters for the URI scheme plus 5 > characters for the port number. > > This arbitrary restriction doesn't seem like a great idea. If the > coding efficiency of UTF-8 is strictly better than punycode, then it's > probably OK, but why be so strict? Is there a strict need to limit > this to URIs with 5-character-or-less schemes? > > > I agree we don't want to limit it to 5-character-or-less URI schemes. The reason this text is there is because of concerns that this attribute will make STUN messages too big. How much extra space should we allow. Up to 280 octets? Or should we just point out that origin strings from RFC6454 are likely to be around 253 octets long, and using strings that are significantly longer is NOT RECOMMENDED. > > On 28 June 2014 10:04, Alan Johnston wrote: > > All, > > > > We have updated the STUN Origin draft. The major changes relate to: > > > > 1. Adding sections on media keep-alive and SIP keep-alive usages > > 2. Adding a section on multiple origins > > 3. Adding a section on Implementation Status about the open source > > implementations of the browser and STUN/TURN server that support the > ORIGIN > > attribute > > 4. Clarified integrity protection of the attribute in the Security > > Considerations section. > > > > These changes are based on all recent reviews and mailing list comments. > > > > As always, comments are most welcome! > > > > - Alan - > > > > ---------- Forwarded message ---------- > > From: > > Date: Sat, Jun 28, 2014 at 11:50 AM > > Subject: New Version Notification for > draft-johnston-tram-stun-origin-03.txt > > To: Kundan Singh , Alan Johnston > > , John Yoakum , Justin > Uberti > > > > > > > > > > A new version of I-D, draft-johnston-tram-stun-origin-03.txt > > has been successfully submitted by Alan Johnston and posted to the > > IETF repository. > > > > Name: draft-johnston-tram-stun-origin > > Revision: 03 > > Title: An Origin Attribute for the STUN Protocol > > Document date: 2014-06-28 > > Group: Individual Submission > > Pages: 13 > > URL: > > > http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt > > Status: > > https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ > > Htmlized: > > http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03 > > > > Abstract: > > STUN, or Session Traversal Utilities for NAT, is a protocol used to > > assist other protocols traverse Network Address Translators or NATs. > > STUN, and STUN extensions such as TURN, or Traversal Using Relays > > around NAT, and ICE, Interactive Communications Establishment, have > > been around for many years but with WebRTC, Web Real-Time > > Communications, STUN and related extensions are about to see major > > deployments and implementation due to these protocols being > > implemented in browsers. This specification defines an ORIGIN > > attribute for STUN that can be used in similar ways to the HTTP > > header field of the same name. WebRTC browsers utilizing STUN and > > TURN would include this attribute which would provide servers with > > additional information about the STUN and TURN requests they receive. > > This specification defines the usage of the STUN ORIGIN attribute for > > web and SIP contexts. > > > > > > > > > > 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 > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > --bcaec53f398560d4d004fd120f4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

Thanks for the feedback on the draft - see= my replies below.

- Alan -


On Mon, Jun 30, 2014 at 12:16 = PM, Martin Thomson <martin.thomson@gmail.com> wrote:<= br>
Some nits on this sentence:

=C2=A0 =C2=A0For a web browser (HTTP User Agent), the contents of the ORIGI= N
=C2=A0 =C2=A0attribute is the unicode-serialization of an origin defined in=
=C2=A0 =C2=A0Section 6.1 of [RFC6454].

I think that using "for a web browser" here is redundant, since t= he
entire point of the document is that web browsers are the ones adding
this (other users are going to add whatever gets them what they want).

The second is that it's the UTF-8 encoding of the unicode-serialization= .


This paragraph, and the two following = it define what this new attribute carries. (The other two paragraphs begin = "For a SIP User Agent..." and "For a Jabber client...")= =C2=A0How about if I say instead:

"If inserted by a web browser, the ORIGIN attribut= e contains the UTF-8 encoding of the unicode-serialization of an origin def= ined in Section 6.1 of [RFC6454]."

=C2=A0
And this sentence:

=C2=A0 =C2=A0[...] =C2=A0It MUST contain a
=C2=A0 =C2=A0UTF-8 [RFC3629] encoded sequence of characters less than 268 b= ytes.
=C2=A0 =C2=A0The value of 268 is chosen to be larger than the maximum 253 =C2=A0 =C2=A0character domain name plus 8 characters for the URI scheme plu= s 5
=C2=A0 =C2=A0characters for the port number.

This arbitrary restriction doesn't seem like a great idea. =C2=A0If the=
coding efficiency of UTF-8 is strictly better than punycode, then it's<= br> probably OK, but why be so strict? =C2=A0Is there a strict need to limit this to URIs with 5-character-or-less schemes?



I agree we don't want to limit it = to 5-character-or-less URI schemes. =C2=A0The reason this text is there is = because of concerns that this attribute will make STUN messages too big. Ho= w much extra space should we allow. =C2=A0Up to 280 octets? =C2=A0Or should= we just point out that origin strings from RFC6454 are likely to be around= 253 octets long, and using strings that are significantly longer is NOT RE= COMMENDED.
=C2=A0

On 28 June 2014 10:04, Alan Johnston <alan.b.johnston@gmail.com> wrote:
> All,
>
> We have updated the STUN Origin draft. =C2=A0The major changes relate = to:
>
> 1. Adding sections on media keep-alive and SIP keep-alive usages
> 2. Adding a section on multiple origins
> 3. Adding a section on Implementation Status about the open source
> implementations of the browser and STUN/TURN server that support the O= RIGIN
> attribute
> 4. Clarified integrity protection of the attribute in the Security
> Considerations section.
>
> These changes are based on all recent reviews and mailing list comment= s.
>
> As always, comments are most welcome!
>
> - Alan -
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Sat, Jun 28, 2014 at 11:50 AM
> Subject: New Version Notification for draft-johnston-tram-stun-origin-= 03.txt
> To: Kundan Singh <kundan10@gm= ail.com>, Alan Johnston
> <alan.b.johnston@gmail= .com>, John Yoakum <yoakum@av= aya.com>, Justin Uberti
> <justin@uberti.name> >
>
>
> A new version of I-D, draft-johnston-tram-stun-origin-03.txt
> has been successfully submitted by Alan Johnston and posted to the
> IETF repository.
>
> Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-johnston-tram-stun-orig= in
> Revision: =C2=A0 =C2=A0 =C2=A0 03
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An Origin Attribute for the S= TUN Protocol
> Document date: =C2=A02014-06-28
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
> Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013
> URL:
> http://www.ietf.org/internet-drafts/draf= t-johnston-tram-stun-origin-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-johnston-t= ram-stun-origin/
> Htmlized:
> http://tools.ietf.org/html/draft-johnston-tram-stun-o= rigin-03
> Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-john= ston-tram-stun-origin-03
>
> Abstract:
> =C2=A0 =C2=A0STUN, or Session Traversal Utilities for NAT, is a protoc= ol used to
> =C2=A0 =C2=A0assist other protocols traverse Network Address Translato= rs or NATs.
> =C2=A0 =C2=A0STUN, and STUN extensions such as TURN, or Traversal Usin= g Relays
> =C2=A0 =C2=A0around NAT, and ICE, Interactive Communications Establish= ment, have
> =C2=A0 =C2=A0been around for many years but with WebRTC, Web Real-Time=
> =C2=A0 =C2=A0Communications, STUN and related extensions are about to = see major
> =C2=A0 =C2=A0deployments and implementation due to these protocols bei= ng
> =C2=A0 =C2=A0implemented in browsers. =C2=A0This specification defines= an ORIGIN
> =C2=A0 =C2=A0attribute for STUN that can be used in similar ways to th= e HTTP
> =C2=A0 =C2=A0header field of the same name. =C2=A0WebRTC browsers util= izing STUN and
> =C2=A0 =C2=A0TURN would include this attribute which would provide ser= vers with
> =C2=A0 =C2=A0additional information about the STUN and TURN requests t= hey receive.
> =C2=A0 =C2=A0This specification defines the usage of the STUN ORIGIN a= ttribute for
> =C2=A0 =C2=A0web and SIP contexts.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

--bcaec53f398560d4d004fd120f4b-- From nobody Mon Jun 30 11:47:00 2014 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 A463D1A061D for ; Mon, 30 Jun 2014 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 JAZ4JbRq_TmG for ; Mon, 30 Jun 2014 11:46:50 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450: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 5F4261A0658 for ; Mon, 30 Jun 2014 11:46:31 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so8598035wev.34 for ; Mon, 30 Jun 2014 11:46:30 -0700 (PDT) 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=8oSN4mS4Rm13MlfH98rmZQuQkpy1CzmnGkDpGwx2UoE=; b=TXpqu8b9Vdj6IAjH4/UntMdrvvPn0oWc33yr0HMPfn6bHOzzSjt4DwKqm8b+4L7yqd 5ouMhHTqwEvOEVe3+xUiPVq0DSw2ZhMyeoJIZxa4t2TlCeDqhxsZSKm8N7vHTc4YHGt4 5CGm4uVwFGGuDkAKoaWpBw2EAD+s9f/8jyVI4csTfmHwSgNaVoxcBSNKQuU4Il3gWS6d jCNZ4v6FPWYJKjdEM8h5MIwfS8erjXyHJLuX23LkLVfUHfhaOcabve6xhj3o9zSNQvhF 1czBjR3/Tcm4Gc9ZsWr8R43fk2xc7zKnfkcKQrnCBvKiyVvcqeIMmFVoeS4e0oQ9mKbM s1pQ== MIME-Version: 1.0 X-Received: by 10.180.101.39 with SMTP id fd7mr31009099wib.65.1404153990019; Mon, 30 Jun 2014 11:46:30 -0700 (PDT) Received: by 10.217.152.200 with HTTP; Mon, 30 Jun 2014 11:46:29 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A282E8207@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A282E8207@xmb-rcd-x10.cisco.com> Date: Mon, 30 Jun 2014 13:46:29 -0500 Message-ID: From: Alan Johnston To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=f46d041825d2c905a904fd1213b9 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/n4fziR2h7rHDeJZbfdgy2u_umA4 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Two new authentication mechanisms 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, 30 Jun 2014 18:46:52 -0000 --f46d041825d2c905a904fd1213b9 Content-Type: text/plain; charset=UTF-8 Agree with Tiru on both points. - Alan - On Mon, Jun 30, 2014 at 12:53 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > I support adoption of both drafts. I think there is no interaction > required between these two drafts. For example If third party authorization > is used then ORIGIN attribute could be used by the TURN server for logging > purpose. > > -Tiru > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > > Sent: Friday, June 27, 2014 6:51 PM > > To: tram@ietf.org > > Subject: [tram] Two new authentication mechanisms > > > > TRAMsters, > > > > We are soliciting discussion on the potential adoption as working-group > > documents of these two drafts: > > > > http://tools.ietf.org/html/draft-johnston-tram-stun-origin > > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz > > > > They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new > > authentication mechanism(s) to IESG for publication as Proposed > Standard"). > > > > If you would like to see one or both of the drafts adopted, or if you > are opposed, > > please explain why. Authors, we will assume you are for adoption of your > own > > drafts. > > > > Please consider the interactions between the two drafts. Is there > anything > > interesting or problematic? What about overlap in function? Is there > any? If so, > > is it necessary or problematic? > > > > Let's take two weeks to discuss this. > > > > Thanks, > > Simon & Gonzalo > > > > _______________________________________________ > > 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 > --f46d041825d2c905a904fd1213b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with Tiru on both points.

- Alan = -


= On Mon, Jun 30, 2014 at 12:53 PM, Tirumaleswar Reddy (tireddy) <tireddy@ci= sco.com> wrote:
I support adoption of both drafts. I think t= here is no interaction required between these two drafts. For example If th= ird party authorization is used then ORIGIN attribute could be used by the = TURN server for logging purpose.

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of Simon Perreault
> Sent: Friday, June 27, 2014 6:51 PM
> To: tram@ietf.org
> Subject: [tram] Two new authentication mechanisms
>
> TRAMsters,
>
> We are soliciting discussion on the potential adoption as working-grou= p
> documents of these two drafts:
>
> http://tools.ietf.org/html/draft-johnston-tram-stun-orig= in
> http://tools.ietf.org/html/draft-reddy-tram-turn= -third-party-authz
>
> They would be targeted at fulfilling milestone 4 ("Nov 2014 - Sen= d new
> authentication mechanism(s) to IESG for publication as Proposed Standa= rd").
>
> If you would like to see one or both of the drafts adopted, or if you = are opposed,
> please explain why. Authors, we will assume you are for adoption of yo= ur own
> drafts.
>
> Please consider the interactions between the two drafts. Is there anyt= hing
> interesting or problematic? What about overlap in function? Is there a= ny? If so,
> is it necessary or problematic?
>
> Let's take two weeks to discuss this.
>
> Thanks,
> Simon & Gonzalo
>
> _______________________________________________
> 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

--f46d041825d2c905a904fd1213b9-- From nobody Mon Jun 30 11:56:04 2014 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 688D81A040F for ; Mon, 30 Jun 2014 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 DxPRR-Ri2Yka for ; Mon, 30 Jun 2014 11:55:59 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACB01A03FD for ; Mon, 30 Jun 2014 11:55:58 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so6556977wiv.14 for ; Mon, 30 Jun 2014 11:55:57 -0700 (PDT) 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=5DeNh8uMR6Z7nlyLj2n7sJcaalCwjiorRgNNh8/QPb0=; b=0m/qEXuTYgYjgwrV6k8LukpLLrFE12+F6XAdRAjz/n2rA6JIY9cRJZKMn2D787CZ8G UrmMCS2DPDe/VYRyNXLOi0+B266I44o1iBUkavPUknu5v4Ic3aZ/mPPQuR4+baMO6Gg7 4tt8z6GbbSYbbzN6uKLf60bDPvT8gMNlv8RK335bw/8aDt6BH1MNhCmTT+f41BXe9h28 mNAYNwWr73tThz5oryfKP24e/4/epCUn4xh4WEoIX7GvWrv+pUOO+gcNgT/7JpUmEg/Y igPWsO5C43NYw0HZa13OhoJeqwoDKmtfXfWw45fb8RxBXyUbjLC7CsuZfvw5mHXD+7LN MoSg== MIME-Version: 1.0 X-Received: by 10.194.133.67 with SMTP id pa3mr4636279wjb.134.1404154557201; Mon, 30 Jun 2014 11:55:57 -0700 (PDT) Received: by 10.217.152.200 with HTTP; Mon, 30 Jun 2014 11:55:57 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A282E82BC@xmb-rcd-x10.cisco.com> References: <20140628165007.32702.46107.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A282E82BC@xmb-rcd-x10.cisco.com> Date: Mon, 30 Jun 2014 13:55:57 -0500 Message-ID: From: Alan Johnston To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e012281a697848104fd1235e6 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oZK243ba4kO0PLkz2tKJrPjKP40 Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.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, 30 Jun 2014 18:56:02 -0000 --089e012281a697848104fd1235e6 Content-Type: text/plain; charset=UTF-8 Hi Tiru, Thanks for the close reading - see my comments below. - Alan - On Mon, Jun 30, 2014 at 1:13 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Alan, > > > > My comments: > > > > [1] Security Considerations: > > > > Comment> You may want to add that If (D)TLS is used then STURN ORIGIN > attribute cannot be modified by an intermediary. > > Right. I'll point this out. > > > [2] This information is often available in other messages sent by the > browser, such as DNS or HTTP requests. > > > > Comment> Yes, but all these problems will most likely be addressed in > future. DNSOP WG is discussing various mechanisms for DNS privacy like DNS > over (D)TLS and HTTP/2.0 mandates TLS. New TLS extensions are discussed in > TLS WG to encrypt TLS handshake for privacy reasons > > > Right. I can soften this a bit to say "This information can be available in other messages sent by the browser, such as DNS or HTTP request, unless those protocols are using encryption." > [3] Section 2.4 ICE usage > > > > Comment> You may also say that for consent checks ( > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04), > STUN ORIGIN attribute is not required. > > > Agreed. This is an extension to ICE, so I think it still counts as an ICE usage, but I think it is worth saying explicitly. > [4] 2.4. ICE Usage > > > > Comment> Any specific reason to say "NOT RECOMMENDED" ? why not say "MUST > NOT use ORIGIN attribute" ? > > I think NOT RECOMMENDED, effectively SHOULD NOT, is the right level here. There is no harm done (i.e. it doesn't cause any interop failures or issues) if it is included, and we may come up with use cases in the future. I think ICE stacks should be prepared to receive an ORIGIN attribute, and should just ignore it. > > > [5] Senders MAY include multiple ORIGIN attributes in a request, and > receivers MUST support parsing and receiving multiple ORIGIN attributes. > > > > Comment> If path MTU is unknown then STUN messages over IPv4 would need to > be less than 548 bytes (Section 7.1 of [RFC5389]). Sender must use this > length restriction to limit the number of ORIGIN attributes in the STUN > request. > > > Good point. I'll mention that including multiple Origin attributes increases the size of STUN packets. [6] STUN defines three authentication modes, depending on the STUN usage. > > > > Comment> There are only two authentication modes ! > > Well, there are three described in this paragraph: short term credential, long term credential, and no credential (NULL). I can make this clearer in the text. > > > [7] Suggest to split Introduction, have a separate section to discuss the > problem. > > > Yes, it is a bit large. Some of this text, I think, can probably be dropped, as it discusses alternative approaches which aren't described in the document. I can reorganize or condense. > [8] In addition to explicitly provisioning the realm value in the java > script the other problem is exposing the user credentials to the > JavaScript. > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-02 > addresses this problem. > > > Sure, this draft does nothing to solve that problem - it only addresses the multi-realm issue. > Thanks and Regards, > > -Tiru > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Alan Johnston > *Sent:* Saturday, June 28, 2014 10:35 PM > *To:* tram@ietf.org > *Subject:* [tram] Fwd: New Version Notification for > draft-johnston-tram-stun-origin-03.txt > > > > All, > > > > We have updated the STUN Origin draft. The major changes relate to: > > > > 1. Adding sections on media keep-alive and SIP keep-alive usages > > 2. Adding a section on multiple origins > > 3. Adding a section on Implementation Status about the open source > implementations of the browser and STUN/TURN server that support the ORIGIN > attribute > > 4. Clarified integrity protection of the attribute in the Security > Considerations section. > > > > These changes are based on all recent reviews and mailing list comments. > > > > As always, comments are most welcome! > > > > - Alan - > > > > ---------- Forwarded message ---------- > From: > Date: Sat, Jun 28, 2014 at 11:50 AM > Subject: New Version Notification for > draft-johnston-tram-stun-origin-03.txt > To: Kundan Singh , Alan Johnston < > alan.b.johnston@gmail.com>, John Yoakum , Justin Uberti > > > > > A new version of I-D, draft-johnston-tram-stun-origin-03.txt > has been successfully submitted by Alan Johnston and posted to the > IETF repository. > > Name: draft-johnston-tram-stun-origin > Revision: 03 > Title: An Origin Attribute for the STUN Protocol > Document date: 2014-06-28 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt > Status: > https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ > Htmlized: > http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03 > > Abstract: > STUN, or Session Traversal Utilities for NAT, is a protocol used to > assist other protocols traverse Network Address Translators or NATs. > STUN, and STUN extensions such as TURN, or Traversal Using Relays > around NAT, and ICE, Interactive Communications Establishment, have > been around for many years but with WebRTC, Web Real-Time > Communications, STUN and related extensions are about to see major > deployments and implementation due to these protocols being > implemented in browsers. This specification defines an ORIGIN > attribute for STUN that can be used in similar ways to the HTTP > header field of the same name. WebRTC browsers utilizing STUN and > TURN would include this attribute which would provide servers with > additional information about the STUN and TURN requests they receive. > This specification defines the usage of the STUN ORIGIN attribute for > web and SIP contexts. > > > > > 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 > > > --089e012281a697848104fd1235e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tiru,

Thanks for the close reading -= see my comments below.

- Alan -


On Mon, Jun 30, 2014 at= 1:13 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> w= rote:

Hi Alan,

=C2=A0

My comments:

=C2=A0

[1] Security Considerations:

=C2=A0

Comment> You may want to add that If (D)TLS is used then STURN ORIGIN= attribute cannot be modified by an intermediary.


Right. =C2=A0I&#= 39;ll point this out.
=C2=A0
=

=C2=A0

[2] This information is often available in other messages sent by the br= owser, such as DNS or HTTP requests.

=C2=A0

Comment>=C2=A0 Yes, but all these problems will most likely be addres= sed in future.=C2=A0 DNSOP WG is discussing various mechanisms for DNS priv= acy like DNS over (D)TLS and HTTP/2.0 mandates TLS.=C2=A0 New TLS extension= s are discussed in TLS WG to encrypt TLS handshake for privacy reasons

=C2=A0


Right. =C2= =A0I can soften this a bit to say "This information can be available i= n other messages sent by the browser, such as DNS or HTTP request, unless t= hose protocols are using encryption."

=C2=A0

[3] Section 2.4 ICE usage

=C2=A0

Comment> You may also say that for consent checks (http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness= -04), STUN ORIGIN attribute is not required.

=C2=A0

Agreed. =C2=A0This is an = extension to ICE, so I think it still counts as an ICE usage, but I think i= t is worth saying explicitly.
=C2=A0

[4] 2.4. ICE Usage

=C2=A0

Comment> Any specific reason to say "NOT RECOMMENDED" ? why= not say "MUST NOT use ORIGIN attribute" ?


I think NOT RECO= MMENDED, effectively SHOULD NOT, is the right level here. =C2=A0There is no= harm done (i.e. it doesn't cause any interop failures or issues) if it= is included, and we may come up with use cases in the future. =C2=A0I thin= k ICE stacks should be prepared to receive an ORIGIN attribute, and should = just ignore it.=C2=A0

=C2=A0

[5] Senders MAY include multiple ORIGIN attributes in a request, and rec= eivers MUST support parsing and receiving multiple ORIGIN attributes.

=C2=A0

Comment> If path MTU is unknown then STUN messages over IPv4 would ne= ed to be less than 548 bytes (Section 7.1 of [RFC5389]). Sender must use th= is length restriction to limit the number of ORIGIN attributes in the STUN = request.

=C2=A0


Good point= . =C2=A0I'll mention that including multiple Origin attributes increase= s the size of STUN packets.=C2=A0

[6]=C2=A0=C2=A0 STUN defines three authentication modes, depending on th= e STUN usage.

=C2=A0

Comment> There are only two authentication modes !


Well, there are = three described in this paragraph: short term credential, long term credent= ial, and no credential (NULL). =C2=A0I can make this clearer in the text.= =C2=A0

=C2=A0

[7] Suggest to split Introduction, have a separate section to discuss th= e problem.

=C2=A0

Yes, it is a bit large. = =C2=A0Some of this text, I think, can probably be dropped, as it discusses = alternative approaches which aren't described in the document. =C2=A0I = can reorganize or condense.
=C2=A0

[8] In addition to explicitly provisioning the realm value in the java s= cript the other problem is exposing the user credentials to the JavaScript. http://tools.ietf.org/html/draft-reddy-tram-turn-t= hird-party-authz-02 addresses this problem.

=C2=A0

Sure, this draft does not= hing to solve that problem - it only addresses the multi-realm issue.
=
=C2=A0

Thanks and Regards,

-Tiru

=C2=A0

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Alan Johnston
Sent: Saturday, June 28, 2014 10:35 PM
To: tram@ietf.org=
Subject: [tram] Fwd: New Version Notification for draft-johnston-tra= m-stun-origin-03.txt

=C2=A0

All,

=C2=A0

We have updated the STUN Origin draft. =C2=A0The maj= or changes relate to:

=C2=A0

1. Adding sections on media keep-alive and SIP keep-= alive usages

2. Adding a section on multiple origins

3. Adding a section on Implementation Status about t= he open source implementations of the browser and STUN/TURN server that sup= port the ORIGIN attribute

4. Clarified integrity protection of the attribute i= n the Security Considerations section.

=C2=A0

These changes are based on all recent reviews and ma= iling list comments.

=C2=A0

As always, comments are most welcome!<= /p>

=C2=A0

- Alan -

=C2=A0

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Sat, Jun 28, 2014 at 11:50 AM
Subject: New Version Notification for draft-johnston-tram-stun-origin-03.tx= t
To: Kundan Singh <kundan10@gmail.com>, Alan Johnston <alan.b.johnston@gmail.com>, John= Yoakum <yoakum@av= aya.com>, Justin Uberti <justin@uberti.name>



A new version of I-D, draft-johnston-tram-stun-origin-03.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-johnston-tram-stun-origin Revision: =C2=A0 =C2=A0 =C2=A0 03
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An Origin Attribute for the STUN P= rotocol
Document date: =C2=A02014-06-28
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-johnston-tram-stun-origin-03
Abstract:
=C2=A0 =C2=A0STUN, or Session Traversal Utilities for NAT, is a protocol us= ed to
=C2=A0 =C2=A0assist other protocols traverse Network Address Translators or= NATs.
=C2=A0 =C2=A0STUN, and STUN extensions such as TURN, or Traversal Using Rel= ays
=C2=A0 =C2=A0around NAT, and ICE, Interactive Communications Establishment,= have
=C2=A0 =C2=A0been around for many years but with WebRTC, Web Real-Time
=C2=A0 =C2=A0Communications, STUN and related extensions are about to see m= ajor
=C2=A0 =C2=A0deployments and implementation due to these protocols being =C2=A0 =C2=A0implemented in browsers. =C2=A0This specification defines an O= RIGIN
=C2=A0 =C2=A0attribute for STUN that can be used in similar ways to the HTT= P
=C2=A0 =C2=A0header field of the same name. =C2=A0WebRTC browsers utilizing= STUN and
=C2=A0 =C2=A0TURN would include this attribute which would provide servers = with
=C2=A0 =C2=A0additional information about the STUN and TURN requests they r= eceive.
=C2=A0 =C2=A0This specification defines the usage of the STUN ORIGIN attrib= ute for
=C2=A0 =C2=A0web and SIP contexts.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0


--089e012281a697848104fd1235e6-- From nobody Mon Jun 30 11:58:07 2014 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 20CAF1A040F for ; Mon, 30 Jun 2014 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 6SWYVhSOJUNv for ; Mon, 30 Jun 2014 11:58:03 -0700 (PDT) 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 87BFC1A02E9 for ; Mon, 30 Jun 2014 11:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2202; q=dns/txt; s=iport; t=1404154683; x=1405364283; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PFjzQ3QE4tTx6uYKDwD/ROBoptmkrGDe0TWe15xVLdg=; b=Phd56zJK1j2PPut5UwPKW2KsZ5WC8h2uADU1+dpqb/7NUzUdYcBPnUX9 /gBQyJI4OR2x4jlhu55b+nfrmUhRl2aU0bRAdA6Z3tFwYo/pISm0mPJ6I q3dwiNgQmc8K8KHDScLVPv5+ScXZ4hSJiX/LVObHH8rrrvmVejN6i+f33 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHAB+ysVOtJA2J/2dsb2JhbABagw1SWqsaAQEBAQEBBQFuAZIGh0ABgRIWdYQDAQEBAwEBAQE3NAsFBwQCAQgRBAEBAR4JByEGCxQJCAEBBA4FiC4DCQgNwVINhlIXhWSGfIF0MwcGgyeBFgWYYIF+gUaMJYYSg0JsgUQ X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="336740352" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jun 2014 18:58:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5UIw2fi011080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 18:58:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 13:58:02 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] Two new authentication mechanisms Thread-Index: Ac+UjCJk5vAAlzbsL0u8BKfRol6LCgAMWDuAAABnRAA= Date: Mon, 30 Jun 2014 18:58:02 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A282E8207@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: [64.102.154.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/qpwKIGXuFAyk7h3gO4CWYVImcQ8 Cc: "tram@ietf.org" Subject: Re: [tram] Two new authentication mechanisms 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, 30 Jun 2014 18:58:05 -0000 +1 Support adoption of both docs and they should be left as separate. Cheers, Gonzalo On Jun 30, 2014, at 2:46 PM, Alan Johnston wrot= e: > Agree with Tiru on both points. >=20 > - Alan - >=20 >=20 > On Mon, Jun 30, 2014 at 12:53 PM, Tirumaleswar Reddy (tireddy) wrote: > I support adoption of both drafts. I think there is no interaction requir= ed between these two drafts. For example If third party authorization is us= ed then ORIGIN attribute could be used by the TURN server for logging purpo= se. >=20 > -Tiru >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > > Sent: Friday, June 27, 2014 6:51 PM > > To: tram@ietf.org > > Subject: [tram] Two new authentication mechanisms > > > > TRAMsters, > > > > We are soliciting discussion on the potential adoption as working-group > > documents of these two drafts: > > > > http://tools.ietf.org/html/draft-johnston-tram-stun-origin > > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz > > > > They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new > > authentication mechanism(s) to IESG for publication as Proposed Standar= d"). > > > > If you would like to see one or both of the drafts adopted, or if you a= re opposed, > > please explain why. Authors, we will assume you are for adoption of you= r own > > drafts. > > > > Please consider the interactions between the two drafts. Is there anyth= ing > > interesting or problematic? What about overlap in function? Is there an= y? If so, > > is it necessary or problematic? > > > > Let's take two weeks to discuss this. > > > > Thanks, > > Simon & Gonzalo > > > > _______________________________________________ > > 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 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Jun 30 12:43:06 2014 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 824331A0A89 for ; Mon, 30 Jun 2014 12:43:03 -0700 (PDT) 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 IqukI-x6G9Gy for ; Mon, 30 Jun 2014 12:43:02 -0700 (PDT) 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 E76201A0A88 for ; Mon, 30 Jun 2014 12:43:01 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so6600584wib.15 for ; Mon, 30 Jun 2014 12:43:00 -0700 (PDT) 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=cB/ngnxewvx8mRTYebSKiYG8hsHTC7ued/yOaFSZkok=; b=YRAlVHIvANzxLQ8h+NYa5svAVg3XG/iQRShPqzfMRqu00eIHHN4vU6+CzojIPq5bJX +x0CHmz4O5Zpi9q9vjoUeqehd1LZYO+N0YNmKi8oENMUbT/vHGRxllIsargFgPPrgpwG 2cD+NS1znQDTEGGlhD4DXrhCPx+3wrHt0lA6fdyDqYDe8XFHpIrFN3bFpSRUlEwLk87H MD2TuzjwCg+g4kdHGiLR207OA19XaXQgq4Cg+48d/+s3dbFPbWUgk1kEuNszJG0tqUUA RqzvciIY1Ij10hVHhaYUow1l+RI1aWXGB8LFH/5c4HGZ4AdzKLbaOzsUO0SsRL9xUJM8 5qFA== MIME-Version: 1.0 X-Received: by 10.194.161.136 with SMTP id xs8mr45538079wjb.31.1404157380475; Mon, 30 Jun 2014 12:43:00 -0700 (PDT) Received: by 10.194.120.71 with HTTP; Mon, 30 Jun 2014 12:43:00 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A282E8207@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A282E8207@xmb-rcd-x10.cisco.com> Date: Mon, 30 Jun 2014 12:43:00 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e013cc30adf414004fd12ddff Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mE9clsqYad1FI8bdJ7kfNBRP_n8 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Two new authentication mechanisms 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, 30 Jun 2014 19:43:03 -0000 --089e013cc30adf414004fd12ddff Content-Type: text/plain; charset=UTF-8 I agree that two drafts can be kept independently. As for the ORIGIN attribute in the third-party authorization environment - don't we still need realm in the third-party authorization ? Am I missing something ? I was under impression that we still have realms, together with the tokens. Thanks Oleg On Mon, Jun 30, 2014 at 10:53 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > I support adoption of both drafts. I think there is no interaction > required between these two drafts. For example If third party authorization > is used then ORIGIN attribute could be used by the TURN server for logging > purpose. > > -Tiru > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > > Sent: Friday, June 27, 2014 6:51 PM > > To: tram@ietf.org > > Subject: [tram] Two new authentication mechanisms > > > > TRAMsters, > > > > We are soliciting discussion on the potential adoption as working-group > > documents of these two drafts: > > > > http://tools.ietf.org/html/draft-johnston-tram-stun-origin > > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz > > > > They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new > > authentication mechanism(s) to IESG for publication as Proposed > Standard"). > > > > If you would like to see one or both of the drafts adopted, or if you > are opposed, > > please explain why. Authors, we will assume you are for adoption of your > own > > drafts. > > > > Please consider the interactions between the two drafts. Is there > anything > > interesting or problematic? What about overlap in function? Is there > any? If so, > > is it necessary or problematic? > > > > Let's take two weeks to discuss this. > > > > Thanks, > > Simon & Gonzalo > > > > _______________________________________________ > > 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 > --089e013cc30adf414004fd12ddff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that two drafts can be kept independentl= y.

As for the ORIGIN attribute in the third-party authorizatio= n environment - don't we still need realm in the third-party authorizat= ion ? Am I missing something ? I was under impression that we still have re= alms, together with the tokens.

Thanks
Oleg



On Mon, Jun 30, 2014 at 10:53 AM, Tirumaleswar Red= dy (tireddy) <tireddy@cisco.com> wrote:
I support adoption of both drafts. I think t= here is no interaction required between these two drafts. For example If th= ird party authorization is used then ORIGIN attribute could be used by the = TURN server for logging purpose.

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of Simon Perreault
> Sent: Friday, June 27, 2= 014 6:51 PM
> To: tram@ietf.org
> Subject: [tram] Two new authentication mechanisms
>
> TRAMsters,
>
> We are soliciting discussion on the potential adoption as working-grou= p
> documents of these two drafts:
>
> http://tools.ietf.org/html/draft-johnston-tram-stun-orig= in
> http://tools.ietf.org/html/draft-reddy-tram-turn= -third-party-authz
>
> They would be targeted at fulfilling milestone 4 ("Nov 2014 - Sen= d new
> authentication mechanism(s) to IESG for publication as Proposed Standa= rd").
>
> If you would like to see one or both of the drafts adopted, or if you = are opposed,
> please explain why. Authors, we will assume you are for adoption of yo= ur own
> drafts.
>
> Please consider the interactions between the two drafts. Is there anyt= hing
> interesting or problematic? What about overlap in function? Is there a= ny? If so,
> is it necessary or problematic?
>
> Let's take two weeks to discuss this.
>
> Thanks,
> Simon & Gonzalo
>
> _______________________________________________
> 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

--089e013cc30adf414004fd12ddff-- From nobody Mon Jun 30 13:23:32 2014 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 C6F141A04A3 for ; Mon, 30 Jun 2014 13:23:30 -0700 (PDT) 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 B6awxcKAvHwp for ; Mon, 30 Jun 2014 13:23:28 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450: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 D21361A02FB for ; Mon, 30 Jun 2014 13:23:26 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so8715866wes.11 for ; Mon, 30 Jun 2014 13:23:25 -0700 (PDT) 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=ZeY4BitteYKlGeqFpRKz9d9Bb5GoXx/0PWea3FfYhEg=; b=0+ojZ7/JYxFKYMNqwwhK1mId/ZcBKLs1rkMwCJXv7SSmYgyQzWpER8c6ip/PPtKy4R uIB7G/eCt2dne4l6++8OSxJhQYmuywMmbUSyH3+Wt9uk6SSJLVb7JUK8POn1+0VQk6Wq /JyRgdTFsKRxBDBPgVk8YhgpoksPuHyx4WZ92jsQ+PfXcAVUR7JL17u8Xcm+2P0HAEgJ yO2sx8iGaQikgrH+ZgenkIpqAnTBwWFllrcaDBIVLdmHHOp4+sazR/X6bDPXaXvFx7c4 W8fkcSvQgS4RyspSwQff55ZSmUEi3ewUt9s2POcRuaE3FQHSbkK39/DxN11kqu1CsuD7 +KQQ== MIME-Version: 1.0 X-Received: by 10.180.81.37 with SMTP id w5mr31468563wix.65.1404159805419; Mon, 30 Jun 2014 13:23:25 -0700 (PDT) Received: by 10.194.165.6 with HTTP; Mon, 30 Jun 2014 13:23:25 -0700 (PDT) In-Reply-To: References: <20140628165007.32702.46107.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 13:23:25 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KzH2WR4vLjehC4h8wKaOgprU_BA Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.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, 30 Jun 2014 20:23:30 -0000 On 30 June 2014 11:45, Alan Johnston wrote: >> > > I agree we don't want to limit it to 5-character-or-less URI schemes. The > reason this text is there is because of concerns that this attribute will > make STUN messages too big. How much extra space should we allow. Up to 280 > octets? Or should we just point out that origin strings from RFC6454 are > likely to be around 253 octets long, and using strings that are > significantly longer is NOT RECOMMENDED. That's probably best. I don't think that people intentionally create long names, but sometimes you have no choice. IDN names do get pretty large. From nobody Mon Jun 30 14:09:03 2014 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 6A1001A03D9; Mon, 30 Jun 2014 14:08:58 -0700 (PDT) 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 HZ6TwfHAjmXf; Mon, 30 Jun 2014 14:08:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2471A0AAA; Mon, 30 Jun 2014 14:08:55 -0700 (PDT) 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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140630210855.11916.90781.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 14:08:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ay_xPSIExhTzHz9Jx3hWF6UCIK0 Cc: tram mailing list , tram chair , RFC Editor Subject: [tram] Protocol Action: 'Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)' to Proposed Standard (draft-ietf-tram-stun-dtls-05.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: Mon, 30 Jun 2014 21:08:58 -0000 The IESG has approved the following document: - 'Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)' (draft-ietf-tram-stun-dtls-05.txt) as Proposed Standard This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ Technical Summary This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It also specifies modifications to the STUN URIs and TURN URIs and to the TURN resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. Working Group Summary This is the first document produced by the TRAM working group. No controversy was experienced. Many different people have provided feedback and guidance. Some of the harder questions: - What cipher suite to specify as mandatory? - How to ensure that a hostname is available for certificate validation? Document Quality Two existing implementations are listed in section 5. RTCWEB implementers have demonstrated interest. This draft has continuously been reviewed by many different people throughout its history. While the TRAM WG is composed primarily of NAT traversal experts, TLS experts have been solicited and have provided very helpful feedback, particularly at the IETF 89 meeting. Personnel Document Shepherd: Simon Perreault Responsible Area Director: Spencer Dawkins From nobody Mon Jun 30 14:21:25 2014 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 E48051A0AD2 for ; Mon, 30 Jun 2014 14:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 6D-lKVDh-pFN for ; Mon, 30 Jun 2014 14:21:19 -0700 (PDT) Received: from nomis80.org (nomis80.org [23.92.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 20D701A0AA2 for ; Mon, 30 Jun 2014 14:21:19 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca [173.178.42.233]) by nomis80.org (Postfix) with ESMTPSA id 607C110EA6 for ; Mon, 30 Jun 2014 21:24:29 +0000 (UTC) Message-ID: <53B1D4CD.8090300@per.reau.lt> Date: Mon, 30 Jun 2014 17:21:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140630210855.11916.90781.idtracker@ietfa.amsl.com> In-Reply-To: <20140630210855.11916.90781.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-n1b9IlKzzSSaA1OTY0DfI17lcQ Subject: Re: [tram] Protocol Action: 'Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)' to Proposed Standard (draft-ietf-tram-stun-dtls-05.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, 30 Jun 2014 21:21:23 -0000 Congrats all! We're ahead of schedule, this is unreal! :) Simon Le 2014-06-30 17:08, The IESG a écrit : > The IESG has approved the following document: > - 'Datagram Transport Layer Security (DTLS) as Transport for Session > Traversal Utilities for NAT (STUN)' > (draft-ietf-tram-stun-dtls-05.txt) as Proposed Standard > > This document is the product of the TURN Revised and Modernized Working > Group. > > The IESG contact persons are Spencer Dawkins and Martin Stiemerling. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/ > > > > > > Technical Summary > > This document specifies the usage of Datagram Transport Layer Security (DTLS) > as a transport protocol for Session Traversal Utilities for NAT (STUN). It > also specifies modifications to the STUN URIs and TURN URIs and to the TURN > resolution mechanism to facilitate the resolution of STUN URIs and TURN URIs > into the IP address and port of STUN and TURN servers supporting DTLS as a > transport protocol. > > Working Group Summary > > This is the first document produced by the TRAM working group. No controversy > was experienced. Many different people have provided feedback and guidance. > Some of the harder questions: > > - What cipher suite to specify as mandatory? > - How to ensure that a hostname is available for certificate validation? > > Document Quality > > Two existing implementations are listed in section 5. RTCWEB implementers have > demonstrated interest. > > This draft has continuously been reviewed by many different people throughout > its history. While the TRAM WG is composed primarily of NAT traversal > experts, TLS experts have been solicited and have provided very helpful > feedback, particularly at the IETF 89 meeting. > > Personnel > > Document Shepherd: Simon Perreault > Responsible Area Director: Spencer Dawkins > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Mon Jun 30 22:52:27 2014 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 C5E241A015B for ; Mon, 30 Jun 2014 22:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 v79T27TBK2Sz for ; Mon, 30 Jun 2014 22:52:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68371A014D for ; Mon, 30 Jun 2014 22:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3888; q=dns/txt; s=iport; t=1404193943; x=1405403543; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=209sCJZtWqvBlu2B6v2lvhYbosr+QmaoEjf2djsx3Po=; b=CTsIoKlXsEUMtvd86Q+PDLaxPszB5+tpJv9BbbldtKyDPpUi0wEtA5aC f1NoH5LkIq7Sc2+b/mzyWIccE8u2S+ut1l71bteZYCWQO3DbOio7wwq7P F5CWbZAxSWs/eDVzdTNYcos+Nl+/pflp391icQP9+m+d0JcMm+XlcPYvV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FAE1MslOtJV2Q/2dsb2JhbABagw1SWoJuqDIBAQEBAQEFAQJsAZIHh0QBGXQWdYQDAQEBBAEBASAROgsMBgEIDgMEAQEDAgYdAwIEHwYLFAEICQEEDgUIiCYDEQ2rN5VgDYYlF4ErhDmGfIF2MQ2CcTaBFgWYY4NGjCWGEoNCgjA X-IronPort-AV: E=Sophos;i="5.01,580,1400025600"; d="scan'208";a="57340731" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 01 Jul 2014 05:52:23 +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 s615qN3O022791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 05:52:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 00:52:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] Two new authentication mechanisms Thread-Index: Ac+U8J3s//GQasFmSzCtc7pMvGOoPw== Date: Tue, 1 Jul 2014 05:52:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282E8B26@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.60.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FVHaxipZuEIvTs9Hx-xGvQWWgxo Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Two new authentication mechanisms 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, 01 Jul 2014 05:52:25 -0000 SGkgT2xlZywNCg0KR29vZCBxdWVzdGlvbi4gDQoNCjEpIERvbid0IHdlIHN0aWxsIG5lZWQgcmVh bG0gaW4gdGhlIHRoaXJkLXBhcnR5IGF1dGhvcml6YXRpb24gPw0KUmVwbHk+IE5vDQoyKSBBbSBJ IG1pc3Npbmcgc29tZXRoaW5nID8gSSB3YXMgdW5kZXIgaW1wcmVzc2lvbiB0aGF0IHdlIHN0aWxs IGhhdmUgcmVhbG1zLCB0b2dldGhlciB3aXRoIHRoZSB0b2tlbnMuDQpSZXBseT4gVGhlIGtpZCAo dW5pcXVlIGtleSBpZGVudGlmaWVyKSB1c2VkIGluIHRoZSBkcmFmdCBzb2x2ZXMgdGhlIHByb2Js ZW0gb2YgVFVSTiBzZXJ2ZXIgKHJlc291cmNlIHNlcnZlcikgdG8gaW50ZXJhY3Qgd2l0aCBkaWZm ZXJlbnQgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIChmcm9tIGRpZmZlcmVudCBkb21haW5zKTsgQXQg aGlnaC1sZXZlbCBpdCB3b3JrcyBhcyBmb2xsb3dzLCBraWQgaXMgcmV0dXJuZWQgYnkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIHdoaWNoIGlzIHNpZ25hbGVkIGJ5IHRoZSBjbGllbnQgdG8gdGhl IFRVUk4gc2VydmVyLCBUVVJOIHNlcnZlciB1c2VzIGtpZCB0byBwaWNrIHRoZSBhcHByb3ByaWF0 ZSBrZXlpbmcgbWF0ZXJpYWwuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQotVGlydQ0KDQpGcm9t OiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tXSANClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMDEsIDIwMTQgMToxMyBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkNCkNjOiBTaW1vbiBQZXJyZWF1bHQ7IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb dHJhbV0gVHdvIG5ldyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zDQoNCkkgYWdyZWUgdGhhdCB0 d28gZHJhZnRzIGNhbiBiZSBrZXB0IGluZGVwZW5kZW50bHkuDQpBcyBmb3IgdGhlIE9SSUdJTiBh dHRyaWJ1dGUgaW4gdGhlIHRoaXJkLXBhcnR5IGF1dGhvcml6YXRpb24gZW52aXJvbm1lbnQgLSBk b24ndCB3ZSBzdGlsbCBuZWVkIHJlYWxtIGluIHRoZSB0aGlyZC1wYXJ0eSBhdXRob3JpemF0aW9u ID8gQW0gSSBtaXNzaW5nIHNvbWV0aGluZyA/IEkgd2FzIHVuZGVyIGltcHJlc3Npb24gdGhhdCB3 ZSBzdGlsbCBoYXZlIHJlYWxtcywgdG9nZXRoZXIgd2l0aCB0aGUgdG9rZW5zLg0KVGhhbmtzDQpP bGVnDQoNCk9uIE1vbiwgSnVuIDMwLCAyMDE0IGF0IDEwOjUzIEFNLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbT4gd3JvdGU6DQpJIHN1cHBvcnQgYWRvcHRp b24gb2YgYm90aCBkcmFmdHMuIEkgdGhpbmsgdGhlcmUgaXMgbm8gaW50ZXJhY3Rpb24gcmVxdWly ZWQgYmV0d2VlbiB0aGVzZSB0d28gZHJhZnRzLiBGb3IgZXhhbXBsZSBJZiB0aGlyZCBwYXJ0eSBh dXRob3JpemF0aW9uIGlzIHVzZWQgdGhlbiBPUklHSU4gYXR0cmlidXRlIGNvdWxkIGJlIHVzZWQg YnkgdGhlIFRVUk4gc2VydmVyIGZvciBsb2dnaW5nIHB1cnBvc2UuDQoNCi1UaXJ1DQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNpbW9uIFBlcnJlYXVsdA0KPiBTZW50OiBGcmlkYXks IEp1bmUgMjcsIDIwMTQgNjo1MSBQTQ0KPiBUbzogdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBb dHJhbV0gVHdvIG5ldyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zDQo+DQo+IFRSQU1zdGVycywN Cj4NCj4gV2UgYXJlIHNvbGljaXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGUgcG90ZW50aWFsIGFkb3B0 aW9uIGFzIHdvcmtpbmctZ3JvdXANCj4gZG9jdW1lbnRzIG9mIHRoZXNlIHR3byBkcmFmdHM6DQo+ DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1v cmlnaW4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktdHJhbS10dXJu LXRoaXJkLXBhcnR5LWF1dGh6DQo+DQo+IFRoZXkgd291bGQgYmUgdGFyZ2V0ZWQgYXQgZnVsZmls bGluZyBtaWxlc3RvbmUgNCAoIk5vdiAyMDE0IC0gU2VuZCBuZXcNCj4gYXV0aGVudGljYXRpb24g bWVjaGFuaXNtKHMpIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJk IikuDQo+DQo+IElmIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSBvbmUgb3IgYm90aCBvZiB0aGUgZHJh ZnRzIGFkb3B0ZWQsIG9yIGlmIHlvdSBhcmUgb3Bwb3NlZCwNCj4gcGxlYXNlIGV4cGxhaW4gd2h5 LiBBdXRob3JzLCB3ZSB3aWxsIGFzc3VtZSB5b3UgYXJlIGZvciBhZG9wdGlvbiBvZiB5b3VyIG93 bg0KPiBkcmFmdHMuDQo+DQo+IFBsZWFzZSBjb25zaWRlciB0aGUgaW50ZXJhY3Rpb25zIGJldHdl ZW4gdGhlIHR3byBkcmFmdHMuIElzIHRoZXJlIGFueXRoaW5nDQo+IGludGVyZXN0aW5nIG9yIHBy b2JsZW1hdGljPyBXaGF0IGFib3V0IG92ZXJsYXAgaW4gZnVuY3Rpb24/IElzIHRoZXJlIGFueT8g SWYgc28sDQo+IGlzIGl0IG5lY2Vzc2FyeSBvciBwcm9ibGVtYXRpYz8NCj4NCj4gTGV0J3MgdGFr ZSB0d28gd2Vla3MgdG8gZGlzY3VzcyB0aGlzLg0KPg0KPiBUaGFua3MsDQo+IFNpbW9uICYgR29u emFsbw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiB0cmFtIG1haWxpbmcgbGlzdA0KPiB0cmFtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= From nobody Mon Jun 30 23:22:39 2014 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 9F48C1B279B for ; Mon, 30 Jun 2014 23:22:36 -0700 (PDT) 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 sNbujgdSlSj5 for ; Mon, 30 Jun 2014 23:22:35 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DA51B27BD for ; Mon, 30 Jun 2014 23:22:29 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so7140363wiv.3 for ; Mon, 30 Jun 2014 23:22:28 -0700 (PDT) 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=LhnfyeP1xDtVMrxFW0P/WaT0X/oh0df3LsnV6pHRyCg=; b=O7CF4RD6B9msKP4/5lrS3SeAEaELG7mW7awyIk/cFVD2dJHI54jat/IgmE4AvNEs9y FkYUKT91k20RnsBeon4NMAi0zZOoj1m+cOeho6F4zH809CYCgkhUtftsBSfVzJcKWbi4 DtAMabTA1yvnhulqSB8+YZFQM5zEJPOvW00DFRhILJ9M30UAUV+/UUAJMR1AI8Cbmp2h hmafIkML5cJU91vhDP3DUNX2Befo3BQyTG8OiE6yuIuoB1JQvWa0j7Vp2tSBdu/cpZkv 8Elx4nr2TbrOJ2g9TqcmhK2yrGmSDymGW6P7f4uaU7xVx93UvMY9odsPdyYJOvCV2TOZ umlQ== MIME-Version: 1.0 X-Received: by 10.180.101.39 with SMTP id fd7mr33773971wib.65.1404195748619; Mon, 30 Jun 2014 23:22:28 -0700 (PDT) Received: by 10.194.120.71 with HTTP; Mon, 30 Jun 2014 23:22:28 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A282E8B26@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A282E8B26@xmb-rcd-x10.cisco.com> Date: Mon, 30 Jun 2014 23:22:28 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=f46d041825d2caadc104fd1bcc70 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/h_O2tNPTUztNPJRjH4XMKPylEnE Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Two new authentication mechanisms 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, 01 Jul 2014 06:22:36 -0000 --f46d041825d2caadc104fd1bcc70 Content-Type: text/plain; charset=UTF-8 OK... thanks for the explanation. Kid is a sort of "realm"... That's cool. Regards, Oleg On Mon, Jun 30, 2014 at 10:52 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Oleg, > > Good question. > > 1) Don't we still need realm in the third-party authorization ? > Reply> No > 2) Am I missing something ? I was under impression that we still have > realms, together with the tokens. > Reply> The kid (unique key identifier) used in the draft solves the > problem of TURN server (resource server) to interact with different > authorization servers (from different domains); At high-level it works as > follows, kid is returned by the authorization server which is signaled by > the client to the TURN server, TURN server uses kid to pick the appropriate > keying material. > > Thanks and Regards, > -Tiru > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > Sent: Tuesday, July 01, 2014 1:13 AM > To: Tirumaleswar Reddy (tireddy) > Cc: Simon Perreault; tram@ietf.org > Subject: Re: [tram] Two new authentication mechanisms > > I agree that two drafts can be kept independently. > As for the ORIGIN attribute in the third-party authorization environment - > don't we still need realm in the third-party authorization ? Am I missing > something ? I was under impression that we still have realms, together with > the tokens. > Thanks > Oleg > > On Mon, Jun 30, 2014 at 10:53 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > I support adoption of both drafts. I think there is no interaction > required between these two drafts. For example If third party authorization > is used then ORIGIN attribute could be used by the TURN server for logging > purpose. > > -Tiru > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > > Sent: Friday, June 27, 2014 6:51 PM > > To: tram@ietf.org > > Subject: [tram] Two new authentication mechanisms > > > > TRAMsters, > > > > We are soliciting discussion on the potential adoption as working-group > > documents of these two drafts: > > > > http://tools.ietf.org/html/draft-johnston-tram-stun-origin > > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz > > > > They would be targeted at fulfilling milestone 4 ("Nov 2014 - Send new > > authentication mechanism(s) to IESG for publication as Proposed > Standard"). > > > > If you would like to see one or both of the drafts adopted, or if you > are opposed, > > please explain why. Authors, we will assume you are for adoption of your > own > > drafts. > > > > Please consider the interactions between the two drafts. Is there > anything > > interesting or problematic? What about overlap in function? Is there > any? If so, > > is it necessary or problematic? > > > > Let's take two weeks to discuss this. > > > > Thanks, > > Simon & Gonzalo > > > > _______________________________________________ > > 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 > > --f46d041825d2caadc104fd1bcc70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK... thanks for the explanation.

Kid i= s a sort of "realm"... That's cool.

Re= gards,
Oleg


<= div class=3D"gmail_quote"> On Mon, Jun 30, 2014 at 10:52 PM, Tirumaleswar Reddy (tireddy) <tireddy@ci= sco.com> wrote:
Hi Oleg,

Good question.

1) Don't we still need realm in the third-party authorization ?
Reply> No
2) Am I missing something ? I was under impression that we still have realm= s, together with the tokens.
Reply> The kid (unique key identifier) used in the draft solves the prob= lem of TURN server (resource server) to interact with different authorizati= on servers (from different domains); At high-level it works as follows, kid= is returned by the authorization server which is signaled by the client to= the TURN server, TURN server uses kid to pick the appropriate keying mater= ial.

Thanks and Regards,
-Tiru

From: Oleg Moskalenko [mailto:mom040= 267@gmail.com]
Sent: Tuesday, July 01, 2014 1:13 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] Two new authentication mechanisms

I agree that two drafts can be kept independently.
As for the ORIGIN attribute in the third-party authorization environment - = don't we still need realm in the third-party authorization ? Am I missi= ng something ? I was under impression that we still have realms, together w= ith the tokens.
Thanks
Oleg

On Mon, Jun 30, 2014 at 10:53 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
I support adoption of both drafts. I think there is no interaction required= between these two drafts. For example If third party authorization is used= then ORIGIN attribute could be used by the TURN server for logging purpose= .

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounc= es@ietf.org] On Behalf Of Simon Perreault
> Sent: Friday, June 27, 2014 6:51 PM
> To: tram@ietf.org
> Subject: [tram] Two new authentication mechanisms
>
> TRAMsters,
>
> We are soliciting discussion on the potential adoption as working-grou= p
> documents of these two drafts:
>
> http://tools.ietf.org/html/draft-johnston-tram-stun-orig= in
> http://tools.ietf.org/html/draft-reddy-tram-turn= -third-party-authz
>
> They would be targeted at fulfilling milestone 4 ("Nov 2014 - Sen= d new
> authentication mechanism(s) to IESG for publication as Proposed Standa= rd").
>
> If you would like to see one or both of the drafts adopted, or if you = are opposed,
> please explain why. Authors, we will assume you are for adoption of yo= ur own
> drafts.
>
> Please consider the interactions between the two drafts. Is there anyt= hing
> interesting or problematic? What about overlap in function? Is there a= ny? If so,
> is it necessary or problematic?
>
> Let's take two weeks to discuss this.
>
> Thanks,
> Simon & Gonzalo
>
> _______________________________________________
> 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


--f46d041825d2caadc104fd1bcc70--