From nobody Thu Oct 2 00:08: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 0F8FB1A0119; Thu, 2 Oct 2014 00:08:41 -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 YN4dlg9Q2Z3u; Thu, 2 Oct 2014 00:08:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7598C1A0113; Thu, 2 Oct 2014 00:08:39 -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.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 00:08:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VJi7rcTkB7KQbUG17J4sM24zsPE Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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: Thu, 02 Oct 2014 07:08:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-05.txt Pages : 20 Date : 2014-10-02 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensure that access to a STUN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-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 Thu Oct 2 00:18: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 8928B1A0125; Thu, 2 Oct 2014 00:18: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 6C9Ql_oHjugn; Thu, 2 Oct 2014 00:18:02 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8861A00FE; Thu, 2 Oct 2014 00:18:02 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so2345835wgg.3 for ; Thu, 02 Oct 2014 00:18:01 -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=Jm1VA/WZJK2nLYAVcj6NT0KkYFP5aiKXrxp30cdR/r4=; b=WKBEaudgUuOlYzwsUpzsi7LKqLFsx0pdP2cP9ObU9slux9/0noGB8SVlZ6KyLbloal YsrP/Gzzgt9BhjVLA5Rif6Gnzv+tJEPuojZc8vJTDhXnxYK6rjEBSp6TiNH/FJcDQLhf 6ZGNDgvjn3LVyzhJm5W+TlLlP2/Io85TiRdMPkOhrxNfF2rHCq4T6VY/9VQrORiCS0jY 4jU5J9SLI2qQqOEtlPnBAFebWCaK4w46ucDWHIq9E4D5BAGK+UaxIQnn7P3WWywBF4o6 5t3Hikqn5zc7yrzH4TdS6i+Ax7qMIKTnPUMV4kGMnT84yrxswrGJHNjNjhSpo8hW7kmE fBew== MIME-Version: 1.0 X-Received: by 10.180.8.229 with SMTP id u5mr1702706wia.76.1412234280980; Thu, 02 Oct 2014 00:18:00 -0700 (PDT) Received: by 10.194.67.167 with HTTP; Thu, 2 Oct 2014 00:18:00 -0700 (PDT) In-Reply-To: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> References: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> Date: Thu, 2 Oct 2014 00:18:00 -0700 Message-ID: From: Oleg Moskalenko To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=f46d044289eaa8554905046b6a41 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SyfFcdxkIZ_81o4yh5s_1ytjvhE Cc: "tram@ietf.org" , i-d-announce@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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: Thu, 02 Oct 2014 07:18:03 -0000 --f46d044289eaa8554905046b6a41 Content-Type: text/plain; charset=UTF-8 I agree with the changes. Thanks Oleg --f46d044289eaa8554905046b6a41 Content-Type: text/html; charset=UTF-8
I agree with the changes.

Thanks
Oleg

--f46d044289eaa8554905046b6a41-- From nobody Fri Oct 3 05:54:48 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 8538B1A06FD for ; Fri, 3 Oct 2014 05:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.786] 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 r5JS0tcstbNJ for ; Fri, 3 Oct 2014 05:54:45 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id F1CB11A066B for ; Fri, 3 Oct 2014 05:54:42 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id BC4001EB842C; Fri, 3 Oct 2014 14:54:41 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 14:54:41 +0200 From: "Hutton, Andrew" To: "Gonzalo Salgueiro (gsalguei)" , "tram-chairs@tools.ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-alpn-05.txt Thread-Index: AQHP2YVYvLByrEmnmk61IjhuTNzqkpwTrFKAgAASpYCAABItAIAKjg/g Date: Fri, 3 Oct 2014 12:54:40 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5B6095@MCHP04MSX.global-ad.net> References: <20140926122802.30401.32452.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: [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/eZ-cTKVqevpwyQTrhNPqnKuZ4hA Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-alpn-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: Fri, 03 Oct 2014 12:54:46 -0000 Just read the draft and it looks good to me. Andy > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo > Salgueiro (gsalguei) > Sent: 26 September 2014 15:43 > To: tram-chairs@tools.ietf.org > Cc: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-alpn-05.txt >=20 > This version now addresses all open issues and the authors believe is > now ready to be WGLC'ed. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 >=20 > On Sep 26, 2014, at 9:38 AM, Martin Thomson > wrote: >=20 > > On 26 September 2014 13:31, Prashanth Patil (praspati) > > wrote: > >> Published new revision that only defines ALPN labels to identify > >> 'stun.turn' & 'stun.nat-discovery'. > > > > > > LGTM > > > > _______________________________________________ > > 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 Oct 6 12:10:53 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 3955C1A88A7; Mon, 6 Oct 2014 12:10:48 -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 1Cpvo-MYCRLc; Mon, 6 Oct 2014 12:10:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B941A889F; Mon, 6 Oct 2014 12:10:46 -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.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006191046.32144.27788.idtracker@ietfa.amsl.com> Date: Mon, 06 Oct 2014 12:10:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HmOyGRanSJbfSmhjKzy155VXcoE Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-alpn-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:10:48 -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 : Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages Authors : Prashanth Patil Tirumaleswar Reddy Gonzalo Salgueiro Marc Petit-Huguenin Filename : draft-ietf-tram-alpn-06.txt Pages : 5 Date : 2014-10-06 Abstract: Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-alpn-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-alpn-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 7 11:48:29 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 A3A2C1A8745; Tue, 7 Oct 2014 11:48:23 -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 O3SUUTgrOFbY; Tue, 7 Oct 2014 11:48:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 091F81A03AB; Tue, 7 Oct 2014 11:48:22 -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.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141007184822.18585.49773.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 11:48:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6c-jYCkgDcKcqN79w12oWaqw6CI Cc: tram@ietf.org Subject: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) 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: Tue, 07 Oct 2014 18:48:23 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages' 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-10-21. 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 Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 13 02:42: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 4BCEC1A8912 for ; Mon, 13 Oct 2014 02:41:58 -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 KN7eFFcu0Ooi for ; Mon, 13 Oct 2014 02:41:57 -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 210C71A890F for ; Mon, 13 Oct 2014 02:41:56 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so6901603wiv.3 for ; Mon, 13 Oct 2014 02:41:55 -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=viwu4x9uL/N/p1iAZL/cOJOQPukE9J4MoPLCNBPYhGM=; b=kFjErKttwzI1HyV1CncxwfRkQCgz+gqSpzLDyj/lo1k9RsGyls8qpctIztcGTw+p+h ROO0oP3YWzUim/a894n3SOyGa9UXp/720brnpU4XqIjWBRh7J5jAFm+IJrQ4RCdCABSm DZN0o6IsEGhL3g74SNK8wOBKBBWT11I8oB9vRVppWfa2ml2Oxj5puJbJgxmylr5ns3ju SHRoen4MP6gWICG7UfptQkDU//fLkvNUHsG5Ng8g9mdbARN3Khk2MMNDetWATNeLXsQo MLV8l2oAay974gX0ikAbsQ+GJacasBnTWVjsZs7lrWpSIT3xjYKHyR63TwQg/nVfqWHZ tX8Q== MIME-Version: 1.0 X-Received: by 10.180.75.73 with SMTP id a9mr19371098wiw.76.1413193315645; Mon, 13 Oct 2014 02:41:55 -0700 (PDT) Received: by 10.194.5.194 with HTTP; Mon, 13 Oct 2014 02:41:55 -0700 (PDT) In-Reply-To: References: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 02:41:55 -0700 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=f46d0438eba593fdb405054ab506 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dqkKG5q1s8cCA9KMt3qNazYyrbM Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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, 13 Oct 2014 09:41:58 -0000 --f46d0438eba593fdb405054ab506 Content-Type: text/plain; charset=UTF-8 The third-party authorization option has been implemented in Coturn: https://code.google.com/p/coturn/ Oleg On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko wrote: > I agree with the changes. > > Thanks > Oleg > > --f46d0438eba593fdb405054ab506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The third-party authorization option has been impleme= nted in Coturn:

https:= //code.google.com/p/coturn/

Oleg


On Thu, Oct 2, 2014 at 12:1= 8 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
I agree with the changes.<= br>
Thanks
Oleg<= br>

--f46d0438eba593fdb405054ab506-- From nobody Mon Oct 13 03:14: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 27A191A8967 for ; Mon, 13 Oct 2014 03:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 1f7iVJrCbM10 for ; Mon, 13 Oct 2014 03:14:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C561A8973 for ; Mon, 13 Oct 2014 03:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6322; q=dns/txt; s=iport; t=1413195241; x=1414404841; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+Ek99DLHMbz+FoB4N8RYsLPlVGjP/24PIRfVqphJJvQ=; b=hMwRzpuMrzVUmObsXHxzrRKLLzhAgjKxvHdYd3nY7PMu1WthTBtD2sbU 1U0RHNSRRUjT4Msu+anI2ZVIAz2seGKtdOXTPePkUSANAxJqayjQ6jc3N 3Jc+D52VJneNeE9OHT/9DopUoIurox5oINaoUqU2W37tz4bdXLRkNXIcS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADylO1StJV2b/2dsb2JhbABbgkhGU1gEgwLIGodRAhuBABYBfYQCAQEBBCMKXAIBCA4DBAEBCx0DAgICHxEUCQgCBAESCIgiAxGvCY19DYZpAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSOE4IBLQoBgnc2gR4FhRUCikiCGoRChH+RToZUg3dsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,709,1406592000"; d="scan'208,217";a="362798774" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 13 Oct 2014 10:14:00 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9DADxOS013177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 10:13:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 05:13:58 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-05.txt Thread-Index: AQHP3g+/hQAQZlYCUkmLhlW2HC7rnZwcubAAgBFx24D//7T3MA== Date: Mon, 13 Oct 2014 10:13:58 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2833A171@xmb-rcd-x10.cisco.com> References: <20141002070839.18899.72936.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: [173.39.66.189] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2833A171xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XTVKijiY95-9E1ogaKiv7earPfg Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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, 13 Oct 2014 10:14:02 -0000 --_000_913383AAA69FF945B8F946018B75898A2833A171xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXdlc29tZS4NCg0KLVRpcnUNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE9sZWcgTW9za2FsZW5rbw0KU2VudDogTW9uZGF5LCBPY3RvYmVy IDEzLCAyMDE0IDM6MTIgUE0NClRvOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1d IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTA1LnR4 dA0KDQpUaGUgdGhpcmQtcGFydHkgYXV0aG9yaXphdGlvbiBvcHRpb24gaGFzIGJlZW4gaW1wbGVt ZW50ZWQgaW4gQ290dXJuOg0KDQpodHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL2NvdHVybi8NCk9s ZWcNCg0KT24gVGh1LCBPY3QgMiwgMjAxNCBhdCAxMjoxOCBBTSwgT2xlZyBNb3NrYWxlbmtvIDxt b20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpJ IGFncmVlIHdpdGggdGhlIGNoYW5nZXMuDQpUaGFua3MNCk9sZWcNCg0K --_000_913383AAA69FF945B8F946018B75898A2833A171xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF3ZXNvbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5PbGVnIE1vc2thbGVua288YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IDM6MTIgUE08YnI+DQo8Yj5U bzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wNS50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIHRoaXJkLXBhcnR5IGF1dGhvcml6YXRp b24gb3B0aW9uIGhhcyBiZWVuIGltcGxlbWVudGVkIGluIENvdHVybjo8YnI+DQo8YnI+DQo8YSBo cmVmPSJodHRwczovL2NvZGUuZ29vZ2xlLmNvbS9wL2NvdHVybi8iPmh0dHBzOi8vY29kZS5nb29n bGUuY29tL3AvY290dXJuLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbGVnPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9jdCAyLCAyMDE0IGF0IDEy OjE4IEFNLCBPbGVnIE1vc2thbGVua28gJmx0OzxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9tMDQwMjY3QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgYWdyZWUgd2l0aCB0aGUgY2hhbmdlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5UaGFua3M8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+T2xlZzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2833A171xmbrcdx10ciscoc_-- From nobody Mon Oct 13 10:25:41 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 3CB8B1A1B0C for ; Mon, 13 Oct 2014 10:25:32 -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 hYSun0iOV4zO for ; Mon, 13 Oct 2014 10:25:31 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9DE1A1B15 for ; Mon, 13 Oct 2014 10:25:24 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so8023746wid.6 for ; Mon, 13 Oct 2014 10:25:23 -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=d08aiaUnkGmwSVwal/5uzqYlyyU+MxhVZ+x1ZPxsrt8=; b=PmbEHmJVAAjwtVsZ+g66ExPndUqgUCkPdc8puMVghZ5Eb3XlSKehmFZVEBRsnbF5m9 3b1WVcsidh0oHZWpwzzUfrkfi/rgjEAy4ICC0PdBj1DPFLIIpp0imUhOnpPBrJcwh8ST TO44B9dSdUT9o3oLY21Y/Ghue3chueLluJ5GCe4TOKoMx8fXIA/OA5NXaDvSRPtgzct7 29pdmgHMRAZaHmsvkqtdYKCUOCGKTCIKHEkMuUdGor+kviA49+UAY7VhxsSR0rdQQNoK vnVjWpvFJdbaLWS3IG0VbIi8NFKxEbYCi+2v66CYfx5I0pjQxsN1ZZa8RMNdd/5CJ0Fd EB1Q== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr22142704wjv.45.1413221123124; Mon, 13 Oct 2014 10:25:23 -0700 (PDT) Received: by 10.194.5.194 with HTTP; Mon, 13 Oct 2014 10:25:23 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2833A171@xmb-rcd-x10.cisco.com> References: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2833A171@xmb-rcd-x10.cisco.com> Date: Mon, 13 Oct 2014 10:25:23 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b5d2fde08754b0505512f8b Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0yfOjseG1aE1g3t_m5sqmGxiXH4 Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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, 13 Oct 2014 17:25:32 -0000 --047d7b5d2fde08754b0505512f8b Content-Type: text/plain; charset=UTF-8 As IANA has not assigned the attribute numbers, yet, we are using the unassigned values 0x8031 and 0x0031. On Mon, Oct 13, 2014 at 3:13 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Awesome. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenko > *Sent:* Monday, October 13, 2014 3:12 PM > *To:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: > draft-ietf-tram-turn-third-party-authz-05.txt > > > > The third-party authorization option has been implemented in Coturn: > > https://code.google.com/p/coturn/ > > Oleg > > > > On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko > wrote: > > I agree with the changes. > > Thanks > Oleg > > > --047d7b5d2fde08754b0505512f8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As IANA has not assigned the attribute numbers, yet, we ar= e using the unassigned values 0x8031 and 0x0031.


On Mon, Oct 13, 2014 at 3:13 A= M, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Awesome.

=C2=A0

-Tiru

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Monday, October 13, 2014 3:12 PM
To: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-aut= hz-05.txt

=C2=A0

The third-party autho= rization option has been implemented in Coturn:

https://cod= e.google.com/p/coturn/

Oleg

=C2=A0

On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko <= ;mom040267@gmail.c= om> wrote:

I agree with the chan= ges.

Thanks
Oleg

=C2=A0


--047d7b5d2fde08754b0505512f8b-- From nobody Tue Oct 14 07:19:46 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 5B8BF1A8862 for ; Tue, 14 Oct 2014 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEwbuOJKKbBt for ; Tue, 14 Oct 2014 07:19:32 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930BE1A87B2 for ; Tue, 14 Oct 2014 07:19:32 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so8199241lbi.39 for ; Tue, 14 Oct 2014 07:19:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9sq0JR4+Dzmdbw8tJHoNg+J+wUKLyWaAsTp0Pdw5G3Y=; b=G29uzNinOWIXjOIxWFYJ5sOFd8BtGSXJCqMR8DY9Rsgot7BcjoDVUtLLgX0wboSGfn VM7LaCzdxyMHE/x2FYmHPKaxi/U57teCTVhtOAxouibYf9lyAFPZFxfAu/PoFtbvA7DC mbGrn2vbwcSIHBhblAZJ9KMCMI5Y1SJbUOrJHFxo9/V5Ef2Ndr55MXBAGeoPYa1wEy6R 1jMZ/3OC2eRKf1Dha5nabPqIjJfnZWChCsFyHkLkDcagVsDgvtJuQyIel5sc+S2SMzDu kTxc0qctoTOVLjB/tzY5zXvl1nsQArXOxnoTPJOKC29HhVNchGJ931nXupiJrOrR7qTD Tchw== X-Gm-Message-State: ALoCoQmXMEN7HnS3F2xJk1sYp9cLfHlYCjYVgmARpaY73HNcGX8iRul1nN9vCBYSxi8eAfiwHNmz MIME-Version: 1.0 X-Received: by 10.112.12.35 with SMTP id v3mr100393lbb.80.1413296370720; Tue, 14 Oct 2014 07:19:30 -0700 (PDT) Received: by 10.25.137.9 with HTTP; Tue, 14 Oct 2014 07:19:30 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2833A171@xmb-rcd-x10.cisco.com> References: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2833A171@xmb-rcd-x10.cisco.com> Date: Tue, 14 Oct 2014 10:19:30 -0400 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c39fd223bc95050562b442 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/X6BaMO4IgAyLIwiw8_L8DeU4gRE Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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: Tue, 14 Oct 2014 14:19:36 -0000 --001a11c39fd223bc95050562b442 Content-Type: text/plain; charset=UTF-8 +1! Simon On Mon, Oct 13, 2014 at 6:13 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Awesome. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg Moskalenko > *Sent:* Monday, October 13, 2014 3:12 PM > *To:* tram@ietf.org > *Subject:* Re: [tram] I-D Action: > draft-ietf-tram-turn-third-party-authz-05.txt > > > > The third-party authorization option has been implemented in Coturn: > > https://code.google.com/p/coturn/ > > Oleg > > > > On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko > wrote: > > I agree with the changes. > > Thanks > Oleg > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a11c39fd223bc95050562b442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1!

Simon

On Mon, Oct 13, 2014 at 6:13 AM, Ti= rumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Awesome.

=C2=A0

-Tiru

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Monday, October 13, 2014 3:12 PM
To: tram@ietf.org=
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-aut= hz-05.txt

=C2=A0

The third-party autho= rization option has been implemented in Coturn:

https://cod= e.google.com/p/coturn/

Oleg

=C2=A0

On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko <= ;mom040267@gmail.c= om> wrote:

I agree with the chan= ges.

Thanks
Oleg

=C2=A0


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


--001a11c39fd223bc95050562b442-- From nobody Tue Oct 14 07:22:17 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 A48E01A8789 for ; Tue, 14 Oct 2014 07:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 SLPF4DI7QaP1 for ; Tue, 14 Oct 2014 07:22:09 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id DBD571A888F for ; Tue, 14 Oct 2014 07:22:08 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2E37693C2A2; Tue, 14 Oct 2014 14:21:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_0B120623-9B00-49B6-820C-FB8981FB8B82" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 14 Oct 2014 16:22:06 +0200 Message-Id: References: <20141002070839.18899.72936.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2833A171@xmb-rcd-x10.cisco.com> To: Simon Perreault X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PqFR9DauC3PNPVoezYn8WlHNPvs Cc: Oleg Moskalenko , Olle E Johansson , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-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: Tue, 14 Oct 2014 14:22:11 -0000 --Apple-Mail=_0B120623-9B00-49B6-820C-FB8981FB8B82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Oct 2014, at 16:19, Simon Perreault wrote: > +1! >=20 Great work Oleg! +pi ! /O > Simon >=20 > On Mon, Oct 13, 2014 at 6:13 AM, Tirumaleswar Reddy (tireddy) = wrote: > Awesome. >=20 > =20 >=20 > -Tiru >=20 > =20 >=20 > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Monday, October 13, 2014 3:12 PM > To: tram@ietf.org > Subject: Re: [tram] I-D Action: = draft-ietf-tram-turn-third-party-authz-05.txt >=20 > =20 >=20 > The third-party authorization option has been implemented in Coturn: >=20 > https://code.google.com/p/coturn/ >=20 > Oleg >=20 > =20 >=20 > On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko = wrote: >=20 > I agree with the changes. >=20 > Thanks > Oleg >=20 > =20 >=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=_0B120623-9B00-49B6-820C-FB8981FB8B82 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 14 Oct 2014, at 16:19, Simon Perreault <sperreault@jive.com> wrote:

+1!

Great work Oleg! +pi !

/O
Simon

On Mon, Oct 13, 2014 at 6:13 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Awesome.

 

-Tiru

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Monday, October 13, 2014 3:12 PM
To: tram@ietf.org
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-05.txt

 

The third-party authorization option has been implemented in Coturn:

https://code.google.com/p/coturn/

Oleg

 

On Thu, Oct 2, 2014 at 12:18 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

I agree with the changes.

Thanks
Oleg

 


_______________________________________________
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=_0B120623-9B00-49B6-820C-FB8981FB8B82-- From nobody Wed Oct 15 00:02:22 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 CBBE01A039A for ; Wed, 15 Oct 2014 00:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSqmSP8XA9sv for ; Wed, 15 Oct 2014 00:02:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7923C1A0396 for ; Wed, 15 Oct 2014 00:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5313; q=dns/txt; s=iport; t=1413356537; x=1414566137; h=from:to:cc:subject:date:message-id:mime-version; bh=nr2A3VZI0aQHMPXzjLhLCgqd29ty8ZbWy1yh+ZkwRcs=; b=l1Lo6JiV7C/dg/23CBWW2c8vv2S84L7WKeVaRV0KTo5ieZWHDcrVC6tO fPmZnBKV//Nc/qlawTE7Z1x7Z8A+RU+tcs1zxlZ5vOO56x39GEY/4RhtU uhwcBGJvU16/LtCNVXkRJ71SG1FBvR5krxy4XhEAZAN8VVJz/KO+yn9J+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALQbPlStJA2L/2dsb2JhbABbgkhGU1zKGIFwh0uBGRYBfYQDAQEDAXkFDQEIOz0nBAENBYg2CA3HYAEBAQEBBQEBAQEBAQEBGpBOhFIFkX2ERIcRgTA8kC6DfoI0gUNsAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,722,1406592000"; d="scan'208,217";a="363176803" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2014 07:01:59 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9F71xq0020928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 07:01:59 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 02:01:58 -0500 From: "Prashanth Patil (praspati)" To: "agl@imperialviolet.org" , Simon Perreault Thread-Topic: Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard Thread-Index: AQHP6EXoL8DGcuGOKEOg4TL90oqJoA== Date: Wed, 15 Oct 2014 07:01:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [173.39.66.144] Content-Type: multipart/alternative; boundary="_000_D06419B651618praspaticiscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HhWXbVhtEgyZHbxbBAcTsZsn_z8 Cc: "tram@ietf.org" Subject: Re: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 07:02:20 -0000 --_000_D06419B651618praspaticiscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, The concerning use cases described in the draft were to indicate that the n= ew ALPN identifiers could also be considered for WebRTC firewall traversal = (as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firew= all-considerations-03#section-4.2). End to end identifier negotiation is still the goal of this draft i.e. to n= egotiate the use of stun and its usages. We'll remove these use cases and stick to end to end negotiation. -Prashanth > On Thu, Oct 9, 2014 at 15:41, Adam Langley wrote= : >> Is your concern specific to TRAM's proposed use of ALPN, or does it appl= y to >> ALPN in general? > In general I think the IETF should be promoting the end-to-end > principle. My concern is specifically about TRAM implicitly endorsing > the idea that the network should be applying policy like that. > (There's also a fair amount of irony in that fact that the second > example suggests ALPN be used to get around the fact that networks > often discriminate based on TCP port numbers, and the first example is > suggesting that networks do exactly the same thing to ALPN > identifiers.) > Cheers > AGL --_000_D06419B651618praspaticiscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2AC1D3DDC1EC9D4C87F9B305DE50E583@emea.cisco.com> Content-Transfer-Encoding: quoted-printable 
Hi Adam,
The concerning use cases described in the draft we=
re to indicate that the new ALPN identifiers could also be considered for W=
ebRTC firewall traversal (as pointed out in http=
://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#s=
ection-4.2).
End to end identifier negotiation is still the goal of this draft i.e. to =
negotiate the use of stun and its usages.

We'll remove these use cases and stick to end to end ne=
gotiation.

-Prashanth

> On T=
hu, Oct 9, 2014 at 15:41, Adam Langley <agl@imperialviolet.org> wrote:

&=
gt;> Is your concern specific to TRAM's proposed use of ALPN, or does it=
 apply to
>> ALPN in general?

> In general I think the IETF should be promoting the end-to-end
> principle. My concern is specifically about TRAM implicitly endorsing
> the idea that the network should be applying policy like that.

> (There's also a fair amount of irony in that fact that the second
> example suggests ALPN be used to get around the fact that networks
> often discriminate based on TCP port numbers, and the first example is
> suggesting that networks do exactly the same thing to ALPN
> identifiers.)

> Cheers

> AGL


--_000_D06419B651618praspaticiscocom_-- From nobody Fri Oct 24 05:51: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 5FAEF1A8F37 for ; Fri, 24 Oct 2014 05:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3DCAg3wV-LM for ; Fri, 24 Oct 2014 05:51:00 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B041A8AB5 for ; Fri, 24 Oct 2014 05:51:00 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so2530041lbi.11 for ; Fri, 24 Oct 2014 05:50:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ruTlyqp/aV6U7/rybZG59Trp5QlxYl5tMrBCq4GoIow=; b=KkyvduQ25RSYFiRKhgt277hg8/HMLW7HPA1ooxld4PmpGJNKvOcT+6Ci7+Vr6H082p 281kWxSfaiQivnSFyAVSB/KVF0bJ9IPAIwIWY6csSKcVVj0UOBK9i8eFb2RhbKMi7C9O 5NcPw8u8j/BycSM3qhYGV/0B8TlMOvCXbas04Lc/bJVhJ7eHvPSjnMCb9+EqkNUHWI9m 8Ne/XyitGwpRO8m/HitbB1ObWf+JJuL6Hoh4HlV1OI1DaoaPPla/sG/5ETd+IdFIlgKw /P4Sr+U7+xS0mK3KMSKeiRkR996RsT35JIAVCSKH7KcCxbltDIVvMryQ2kgW5Vw66Fgh q48A== X-Gm-Message-State: ALoCoQnBvsk37SOKcholEPpSVJbdg4eFZexn7YWpUmNBKw3pCGgHTQhO2UM52z8eBBwSHkpJFWcr MIME-Version: 1.0 X-Received: by 10.112.225.225 with SMTP id rn1mr2680217lbc.98.1414155058297; Fri, 24 Oct 2014 05:50:58 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Fri, 24 Oct 2014 05:50:58 -0700 (PDT) Date: Fri, 24 Oct 2014 06:50:58 -0600 Message-ID: From: Simon Perreault To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a1134dc20e8565d05062aa139 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4wWbLb9mj6CMRhHhD07haBxhwPw Subject: [tram] STUN-bis adoption call 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, 24 Oct 2014 12:51:03 -0000 --001a1134dc20e8565d05062aa139 Content-Type: text/plain; charset=UTF-8 TRAMsters, This email starts a two-week adoption call for draft-salgueiro-tram-stunbis-02 to fulfill the STUN-bis milestone that we have. Let's focus the discussion on the high-level direction this draft is going. If you agree or disagree with it, please explain why. The authors have provided a list of the top issues to help focus this discussion. Please also see Appendix B in the draft. 1. STUN hash algorithm agility (currently only SHA-1 is allowed) with a new message-integrity attribute (following 16.3). 2. Integrate RFC 5769 (stun vectors) as examples 3. Integrate RFC 7350 (dtls) and RFC 7064 (URI) 4. Clarify text on RTP caching in section 7.2.1.. 5. Clarify terminology, text and guidance for STUN fragmentation. 6. Fix bug on retransmission RTO in section 7.2. 7. Address existing errata (2010, 2972, 3737). 8. Fix bug on retransmission RTO in section 7.2. 9. Clarify whether it's valid to share nonces across TURN allocations. Clarify nonce behavior for both invalid and expired nonces. Right now only expired nonces are described. Define a new "invalid nonce" error code (presumably 438) Please send your comments before November 7, 2014. Thanks, Simon & Gonzalo --001a1134dc20e8565d05062aa139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TRAMsters,

This = email starts a two-week adoption call for=C2=A0= draft-salgueiro-tram-stunbis-02=C2=A0to fulfill the STUN-bis milestone = that we have.

Let= 's focus the discussion on the high-level direction this draft is going= . If you agree or disagree with it, please explain why. The authors have pr= ovided a list of the top issues to help focus this discussion. Please also = see Appendix B in the draft.

=C2=A0 =C2=A01.=C2=A0 =C2=A0STUN hash algorithm agility (curren= tly only SHA-1 is allowed) with a new message-integrity attribute (followin= g 16.3).

=C2=A0 =C2=A02.=C2=A0 =C2=A0Integrate RFC 5769 (stun vector= s) as examples

=C2=A0 =C2=A03.=C2=A0 =C2=A0Integrate RFC 7350 (dtls)= and RFC 7064 (URI)

=C2=A0 =C2=A04.=C2=A0 =C2=A0Clarify text on RTP = caching in section 7.2.1..

=C2=A0 =C2=A05.=C2=A0 =C2=A0Clarify termi= nology, text and guidance for STUN fragmentation.

=C2=A0 =C2=A06.=C2= =A0 =C2=A0Fix bug on retransmission RTO in section 7.2.

=C2=A0 =C2= =A07.=C2=A0 =C2=A0Address existing errata (2010, 2972, 3737).

=C2=A0= =C2=A08.=C2=A0 =C2=A0Fix bug on retransmission RTO in section 7.2.

= =C2=A0 =C2=A09.=C2=A0 Clarify whether it's valid to share nonces across= TURN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 allocations.=C2=A0 Clarify nonce behav= ior for both invalid and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 expired nonces.=C2= =A0 Right now only expired nonces are described.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Define a new "invalid nonce" error code (presumably 438)

Please send yo= ur comments before November 7, 2014.

Thanks,
Simon & Gonzalo
--001a1134dc20e8565d05062aa139-- From nobody Fri Oct 24 07:22: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 9BF9A1A0161 for ; Fri, 24 Oct 2014 07:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7tuLmNicIv5 for ; Fri, 24 Oct 2014 07:21:58 -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 A3D4A1A0158 for ; Fri, 24 Oct 2014 07:21:58 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B2736475DD for ; Fri, 24 Oct 2014 14:21:57 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A4449475D8 for ; Fri, 24 Oct 2014 14:21:57 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 6071A2036 for ; Fri, 24 Oct 2014 14:21:57 +0000 (GMT) Message-ID: <544A6085.70707@akamai.com> Date: Fri, 24 Oct 2014 10:21:57 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/S0YYrCUOBc7etXZhsMpMNbP0trg Subject: Re: [tram] STUN-bis adoption call 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, 24 Oct 2014 14:22:01 -0000 I'm not completely certain what you mean by "high-level direction". You could be referring to the general degree of coverage, or you could mean the general approach taken for each item. I'll respond to both. In terms of the degree of coverage, I think this is a good list, though I could easily be missing something because there are really only two items that I've been particularly concerned about and they are both covered (hash agility and framentation). If you would like the adoption call to focus on coverage with an assumption that we'll fix content later, then I support adoption. In terms of the approach taken for the two items I'm most focused on, I've got concerns (see below). If you would like the adoption call to focus on high-level agreement with the proposed approach, then I think the document needs some more work before I would support adoption. Regarding fragmentation (item 5) ... I don't see any substantive changes. I don't see anything about this in appendix B.2, so I don't think I'm missing anything. Regarding hash agility (item 1) ... I've got a few concerns about the currently proposed approach. First, There was a discussion about hash agility on the list with reference to third party auth, and the currently proposed approach doesn't reflect the content of that discussion. In particular, I would not describe this proposal as "agile". It has the same shortcomings as the 5389 approach in that regard, locking us into a specific alternate algorithm rather than defining the mechanisms necessary for moving to new agorithms in the future. Next, it describes using an HMAC-SHA256 key size for long term credentials that falls outside of the recommendation from the relevant HMAC spec, which strongly discourages key lengths shorter than the algorithm's output length. This problem already exists in rfc5389 for SHA1, but I hope we can either come up with a way to correct it or provide an explanation of why STUN does not follow the guidance. Finally, there has been some discussion on the list about concerns regarding the use of MD5 for generation and storage of keys and a hope that we could move away from that mechanism. I'm not particularly concerns about that myself, since we would be using the third party auth mechanism. That said, I was expecting to see some reference to these concerns in the context of hash agility. Perhaps that item just hasn't been addressed yet and will be in a future revision. --Brandon On 10/24/2014 08:50 AM, Simon Perreault wrote: > TRAMsters, > > This email starts a two-week adoption call for > draft-salgueiro-tram-stunbis-02 > to > fulfill the STUN-bis milestone that we have. > > Let's focus the discussion on the high-level direction this draft is > going. If you agree or disagree with it, please explain why. The authors > have provided a list of the top issues to help focus this discussion. > Please also see Appendix B in the draft. > > 1. STUN hash algorithm agility (currently only SHA-1 is allowed) > with a new message-integrity attribute (following 16.3). > > 2. Integrate RFC 5769 (stun vectors) as examples > > 3. Integrate RFC 7350 (dtls) and RFC 7064 (URI) > > 4. Clarify text on RTP caching in section 7.2.1.. > > 5. Clarify terminology, text and guidance for STUN fragmentation. > > 6. Fix bug on retransmission RTO in section 7.2. > > 7. Address existing errata (2010, 2972, 3737). > > 8. Fix bug on retransmission RTO in section 7.2. > > 9. Clarify whether it's valid to share nonces across TURN > allocations. Clarify nonce behavior for both invalid and > expired nonces. Right now only expired nonces are described. > Define a new "invalid nonce" error code (presumably 438) > > Please send your comments before November 7, 2014. > > Thanks, > Simon & Gonzalo -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Oct 24 14:08:40 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 C676F1A1A97 for ; Fri, 24 Oct 2014 14:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE2Z16bAZ2VJ for ; Fri, 24 Oct 2014 14:08:30 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FB01A9174 for ; Fri, 24 Oct 2014 14:08:26 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id gf13so3683869lab.29 for ; Fri, 24 Oct 2014 14:08:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=V/igbTJUrSHxUlrpV6D0kzBR6Q57GtzmfDv0lzM769I=; b=X6a3wQDf9dVhuGAj5t8X1/0LAYWUcfR6CVnxpLGJPtmE8izE1W8B5tLfi64ttUlbWb vFwa7Mu3fM36nxj9x4JsUA55ibeRPnodMGTt9VYm/O3RdjKBTybT9WkHMjTBg0GXOvgG 4VKp3UOJC/awiomxPlJhn7NobhBixU6TGN57QgVcaAbyCmrybt69V4TpxZUR9+Eoae/p cQIY3qztixhJpghx1z2RYfy3cEdcaquotK+4KEVkc9FDwqh1ry6XZiiJvgb33GWRQ4cv b2whhS5pKsWo37Zn01X2xx6SNhrax405xBiUJ0SoJWGHpJ2nAEclQy65B3r+sFZ/QZF/ eTsw== X-Gm-Message-State: ALoCoQkFi52FfWPPSFOD0cU/yplI+Hti8+pyUXAfXW6XbHc75kF+pEkexlrEjzIGo7Wsgp3P85ND MIME-Version: 1.0 X-Received: by 10.112.180.198 with SMTP id dq6mr6876514lbc.56.1414184904860; Fri, 24 Oct 2014 14:08:24 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Fri, 24 Oct 2014 14:08:24 -0700 (PDT) Date: Fri, 24 Oct 2014 17:08:24 -0400 Message-ID: From: Simon Perreault To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a11c26b42e6c30b05063194ba Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-i3vRJ1WcBSi_UKO16x6Fq05soc Subject: [tram] TRAM agenda requests 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, 24 Oct 2014 21:08:37 -0000 --001a11c26b42e6c30b05063194ba Content-Type: text/plain; charset=UTF-8 TRAMsters, We have an agenda to build! If you want to present, please send us a request. We have a two-hour slot. If we manage to adopt a STUN-bis draft before the meeting, and there's one candidate in adoption call right now, then we can talk about new milestones during the meeting! (hint! hint!) Thanks, Simon & Gonzalo --001a11c26b42e6c30b05063194ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TRAMsters,

We have an agenda to build! = If you want to present, please send us a request. We have a two-hour slot.<= /div>

If we manage to adopt a STUN-bis draft before the = meeting, and there's one candidate in adoption call right now, then we = can talk about new milestones during the meeting! (hint! hint!)
<= br>
Thanks,
Simon & Gonzalo
--001a11c26b42e6c30b05063194ba-- From nobody Fri Oct 24 20:10:36 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 4595D1A1AFC for ; Fri, 24 Oct 2014 20:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQRPwt8V-EpV for ; Fri, 24 Oct 2014 20:10:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284DE1A1AE2 for ; Fri, 24 Oct 2014 20:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5667; q=dns/txt; s=iport; t=1414206617; x=1415416217; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EnFRtkWnScDJ5ldRTPsQUst6pNywzmwzjG0U7SlMMh8=; b=jOnTd8xfo2zMnqbU5jb26IAIl/D0aImW8so9lqxd7M+1IoaXa9UKXaQA VeL84tHXNcIme3OGCXJvMm4vmIDzbvZpXKwFEASIE6oF3ri7J9Ov/MiPo LnStcQn50U9VJ/RpJuADX/+uVMWxrkmCjhLsbaQTdwES+EJJi6k5amd+b Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACgUS1StJA2K/2dsb2JhbABcgw5UWATNKgqHTQKBCBYBfYQCAQEBAwEBAQEaHTQQBwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIiDAJDcoFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF492EQEHGDgGgyeBHgWSBYRGiEM8gw2NMoQAggACHIFabAEBgQUIFyKBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,784,1406592000"; d="scan'208";a="363189493" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 25 Oct 2014 03:10:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9P3AG3c028365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Oct 2014 03:10:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 22:10:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] STUN-bis adoption call Thread-Index: AQHP74kujxIWxKPPY0GL4Xv+jnj0F5w/oHuAgAB+lIA= Date: Sat, 25 Oct 2014 03:10:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com> References: <544A6085.70707@akamai.com> In-Reply-To: <544A6085.70707@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.57] 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/3U8cBV09AaEplbvRNr4_4ISYmQ4 Subject: Re: [tram] STUN-bis adoption call 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, 25 Oct 2014 03:10:35 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, October 24, 2014 7:52 PM > To: tram@ietf.org > Subject: Re: [tram] STUN-bis adoption call >=20 > I'm not completely certain what you mean by "high-level direction". You > could be referring to the general degree of coverage, or you could mean t= he > general approach taken for each item. I'll respond to both. >=20 > In terms of the degree of coverage, I think this is a good list, though I= could > easily be missing something because there are really only two items that = I've > been particularly concerned about and they are both covered (hash agility > and framentation). If you would like the adoption call to focus on covera= ge > with an assumption that we'll fix content later, then I support adoption. >=20 > In terms of the approach taken for the two items I'm most focused on, I'v= e > got concerns (see below). If you would like the adoption call to focus on= high- > level agreement with the proposed approach, then I think the document > needs some more work before I would support adoption. >=20 > Regarding fragmentation (item 5) ... I don't see any substantive changes.= I > don't see anything about this in appendix B.2, so I don't think I'm missi= ng > anything. There were discussions about fragmentation support in the list sometime bac= k but without any conclusions.=20 Please provide more details. >=20 > Regarding hash agility (item 1) ... I've got a few concerns about the cur= rently > proposed approach. >=20 > First, There was a discussion about hash agility on the list with referen= ce to > third party auth, and the currently proposed approach doesn't reflect the > content of that discussion. In particular, I would not describe this prop= osal as > "agile". It has the same shortcomings as the 5389 approach in that regard= , > locking us into a specific alternate algorithm rather than defining the > mechanisms necessary for moving to new agorithms in the future. +1 >=20 > Next, it describes using an HMAC-SHA256 key size for long term credential= s > that falls outside of the recommendation from the relevant HMAC spec, > which strongly discourages key lengths shorter than the algorithm's outpu= t > length. This problem already exists in rfc5389 for SHA1, but I hope we ca= n > either come up with a way to correct it or provide an explanation of why > STUN does not follow the guidance. Yup, http://tools.ietf.org/html/rfc4868#section-2.1.1 discusses the above p= oint and section 14.5 needs to be fixed HMAC-SHA-256+ are secret key algorithms. While no fixed key length is specified in [HMAC], this specification requires that when used as an integrity/authentication algorithm, a fixed key length equal to the output length of the hash functions MUST be supported, and key lengths other than the output length of the associated hash function MUST NOT be supported. >=20 > Finally, there has been some discussion on the list about concerns regard= ing > the use of MD5 for generation and storage of keys and a hope that we coul= d > move away from that mechanism. I'm not particularly concerns about that > myself, since we would be using the third party auth mechanism.=20 But when TURN server is deployed in Enterprise network then it may have to = support both first and third party mechanisms.=20 The problem with MD5 is documented in https://tools.ietf.org/html/rfc7376#s= ection-4. Cheers, -Tiru > That said, I > was expecting to see some reference to these concerns in the context of h= ash > agility. Perhaps that item just hasn't been addressed yet and will be in = a > future revision. >=20 > --Brandon >=20 > On 10/24/2014 08:50 AM, Simon Perreault wrote: > > TRAMsters, > > > > This email starts a two-week adoption call for > > draft-salgueiro-tram-stunbis-02 > > to > > fulfill the STUN-bis milestone that we have. > > > > Let's focus the discussion on the high-level direction this draft is > > going. If you agree or disagree with it, please explain why. The > > authors have provided a list of the top issues to help focus this discu= ssion. > > Please also see Appendix B in the draft. > > > > 1. STUN hash algorithm agility (currently only SHA-1 is allowed) > > with a new message-integrity attribute (following 16.3). > > > > 2. Integrate RFC 5769 (stun vectors) as examples > > > > 3. Integrate RFC 7350 (dtls) and RFC 7064 (URI) > > > > 4. Clarify text on RTP caching in section 7.2.1.. > > > > 5. Clarify terminology, text and guidance for STUN fragmentation. > > > > 6. Fix bug on retransmission RTO in section 7.2. > > > > 7. Address existing errata (2010, 2972, 3737). > > > > 8. Fix bug on retransmission RTO in section 7.2. > > > > 9. Clarify whether it's valid to share nonces across TURN > > allocations. Clarify nonce behavior for both invalid and > > expired nonces. Right now only expired nonces are described. > > Define a new "invalid nonce" error code (presumably 438) > > > > Please send your comments before November 7, 2014. > > > > Thanks, > > Simon & Gonzalo >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sun Oct 26 20:16:40 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 7E79C1A6F9C for ; Sun, 26 Oct 2014 20:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_42=0.6] 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 vmh04Ca1HQgg for ; Sun, 26 Oct 2014 20:16:35 -0700 (PDT) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 839421A6F91 for ; Sun, 26 Oct 2014 20:16:33 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.77]) by app1 (Coremail) with SMTP id Z0GX06BLmQJAqE1UVgNsAA==.19989S4; Mon, 27 Oct 2014 10:05:05 +0800 (CST) From: "Aijun Wang" To: Date: Mon, 27 Oct 2014 11:16:10 +0800 Message-ID: <00d901cff194$64471e70$2cd55b50$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/xirTp2SNdPv19SgaGJ04kzZMpsQAB7yPQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06BLmQJAqE1UVgNsAA==.19989S4 X-Coremail-Antispam: 1U3129KBjvJXoW7ZFWkJryDXFW3Zr4UWF17KFg_yoW8tFW5pa yUW3yaqw1vvr97GFWDuw4xZ3Wrur9YgrZrAF15Jr18ua98A3Wxt343tF4YvrWDXrZ5G34a qF1Fvr15Aa4FqFJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/o62J_8V2x_LmZ-xyIXwELRRLXIw Cc: "'Liubing \(Leo\)'" Subject: [tram] FW: New Version Notification for draft-wang-tram-turnlite-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 03:16:36 -0000 Hi, All TRAMsters We have submitted one new draft that describes the lightweight TURN(we = refer it as TURNLite later) architecture and the corresponding new STUN = message introduced in this draft. With the TURNLite solution, CP/SP can = easily offload the complex and troublesome deployment of TURN servers to = the service provider, the service provider can easily integrate the data = relay function of TURNLite server into their current distributed = deployed CGN devices.=20 This can be a win-win solution, and meets all the communication = scenarios that the current TURN solution intends to solve, but in a more = simple manner. =20 We are also eager to find other cooperators that are interested in this = topic. Any comments are valuable. Mr. Liubing has apply the timeslot to present this draft in the coming = IETF meeting in Holununu. Best Regards. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 27, 2014 10:07 AM To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu Subject: New Version Notification for draft-wang-tram-turnlite-01.txt A new version of I-D, draft-wang-tram-turnlite-01.txt has been = successfully submitted by Bing Liu and posted to the IETF repository. Name: draft-wang-tram-turnlite Revision: 01 Title: A Lightweight TURN Architecture and Specification (TURNLite) Document date: 2014-10-27 Group: Individual Submission Pages: 15 URL: = http://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-01.txt Status: = https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ Htmlized: http://tools.ietf.org/html/draft-wang-tram-turnlite-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wang-tram-turnlite-01 Abstract: This document proposes a lightweight TURN architecture which simplifies the application provider side complexity of implementing TURN server by transfering the data relay processing to the ISP infrastructure (e.g. CGN). To achieve this goal, a new "Couple" operation using STUN message format is also defined. = =20 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 Oct 26 21:44: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 E05BB1A8749 for ; Sun, 26 Oct 2014 21:44:45 -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 BfUY3KMzOQzA for ; Sun, 26 Oct 2014 21:44:44 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39AE1A6FB4 for ; Sun, 26 Oct 2014 21:44:43 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so5199569lab.13 for ; Sun, 26 Oct 2014 21:44:42 -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=UhcfxP2C0pD1n0OOVjBHZRygOKpfVZze9jzcUordDjI=; b=cuJyCmQ3XIUPt0zdXVJCMhYfqKV/bEwgF7mE5X/w+ksANCHAJYEmSIB6F+NfQblLZV QpaR4SnDuBrZVb92wCKX42IeRBYEtdAKPuaxSqJAcJUvsDCUy/1rVV5nag0dFRd2MKdU MA82U5cR3eL1yb6+6+huqe2GeUNe3j4aiLbdQr+OloBWDD/g0Yzz1iJq6tbthx0fzknD 0LbUi4LmSq8IF28Ndbu61yqzNx4N4Zc68TAOlW7e8tHyBEMN6DwPU5a4zMGuDPnPAH9a 56LsKGsyJcQw6eBxLJxFpCsPyDxr0lnDTch62g5D/zwDAH3HSQUT0Cy1Uo8TzYOrGx5t pqgw== MIME-Version: 1.0 X-Received: by 10.112.42.114 with SMTP id n18mr20805289lbl.44.1414385081936; Sun, 26 Oct 2014 21:44:41 -0700 (PDT) Received: by 10.152.106.237 with HTTP; Sun, 26 Oct 2014 21:44:41 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Oct 2014 23:44:41 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Prashanth Patil (praspati)" Content-Type: multipart/alternative; boundary=001a1133b3d46270e30506603032 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/p1m_X39KrEmctokgzLlaK56GVWI Cc: "agl@imperialviolet.org" , Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 04:44:46 -0000 --001a1133b3d46270e30506603032 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, October 15, 2014, Prashanth Patil (praspati) < praspati@cisco.com> wrote: > Hi Adam, > The concerning use cases described in the draft were to indicate that the= new ALPN identifiers could also be considered for WebRTC firewall traversa= l (as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-fir= ewall-considerations-03#section-4.2). > End to end identifier negotiation is still the goal of this draft i.e. to= negotiate the use of stun and its usages. > > We'll remove these use cases and stick to end to end negotiation. > > Just so I'm clear, should I be expecting a -07? Thanks, Spencer > -Prashanth > > > On Thu, Oct 9, 2014 at 15:41, Adam Langley > wrote: > > >> Is your concern specific to TRAM's proposed use of ALPN, or does it ap= ply to > >> ALPN in general? > > > In general I think the IETF should be promoting the end-to-end > > principle. My concern is specifically about TRAM implicitly endorsing > > the idea that the network should be applying policy like that. > > > (There's also a fair amount of irony in that fact that the second > > example suggests ALPN be used to get around the fact that networks > > often discriminate based on TCP port numbers, and the first example is > > suggesting that networks do exactly the same thing to ALPN > > identifiers.) > > > Cheers > > > AGL > > > > --001a1133b3d46270e30506603032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, October 15, 2014, Prashanth Patil (praspati) <praspati@cisco.com> wrote:
Hi Adam,<=
/div>
The concerning use ca=
ses described in the draft were to indicate that the new ALPN identifiers c=
ould also be considered for WebRTC firewall traversal (as pointed out in http://tools.ietf.org/html/draft=
-hutton-rtcweb-nat-firewall-considerations-03#section-4.2).
End to end identifier negotiatio=
n is still the goal of this draft i.e. to negotiate the use of stun and its=
 usages.

We'll remove these=
 use cases and stick to end to end negotiation.

=
Just so I'm clear, should I be expecting a -07?

Thanks,

Spencer
=C2=A0
-Prashanth

> On Thu, Oct 9, 2014 at 15:41, Adam Langley <agl@imperialviolet.org> wrote:

>> Is your concern specific to TRAM's proposed use of ALPN=
, or does it apply to
>> ALPN in general?

> In general I think the IETF should be promoting the end-to-end
> principle. My concern is specifically about TRAM implicitly endorsing
> the idea that the network should be applying policy like that.

> (There's also a fair amount of irony in that fact that the second
> example suggests ALPN be used to get around the fact that networks
> often discriminate based on TCP port numbers, and the first example is
> suggesting that networks do exactly the same thing to ALPN
> identifiers.)

> Cheers

> AGL


--001a1133b3d46270e30506603032-- From nobody Sun Oct 26 21:53:22 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 033F01A6FBB for ; Sun, 26 Oct 2014 21:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucAfDyhGVB3q for ; Sun, 26 Oct 2014 21:53:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B581A6FB4 for ; Sun, 26 Oct 2014 21:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1941; q=dns/txt; s=iport; t=1414385599; x=1415595199; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Nms3Y3giO5l1VtBfm1vguQGS+Ru0eeM0Lj9enClPQOk=; b=lUaDjGKlfZ3Jbg1hgjqYb2xjvFIJJRXruSsMMjrAvJbj6XsFYThF3rjG mTUtY7BKvSeoQPT2SVSU97GDEsw7XnfYfjMqtPWiwjsKc5UE50VKNdJ1w y/cLktwkToF/ZBQa+hmdZjt0mMmYkAFo/GOHVSwBkgBj4DAkLcZZWKb5Z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAALPTVStJV2P/2dsb2JhbABcgw5UWATMeQyHSwKBDhYBfYQCAQEBAwEBAQE3NAsFCwIBCBgeBQshBgslAgQOBYgsAwkJDcIADYY4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF45OggczB4MtgR4FkgeESIUBghGBMTyNZIJdhACCNIFEbAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,792,1406592000"; d="scan'208";a="366654001" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 27 Oct 2014 04:53:18 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9R4rICZ016152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 04:53:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 23:53:18 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Spencer Dawkins at IETF Thread-Topic: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard Thread-Index: AQHP8aC+iIej4QXyZE6aq7tE5EYmtpxDtGiA Date: Mon, 27 Oct 2014 04:53:17 +0000 Message-ID: <27E0796F-3117-4715-91C6-904B2E9620E5@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.231.165] 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/2_Z_FSYtHEKoSVXoENjP56sqn5U Cc: "Prashanth Patil \(praspati\)" , "agl@imperialviolet.org" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 04:53:21 -0000 Hi Spencer -=20 Do you want that -07 prior to IESG review? We assumed we should wait to ma= ke all changes after IESG review. We're flexible and can do it either way.= Just let us know. Cheers, Gonzalo > On Oct 27, 2014, at 12:44 AM, Spencer Dawkins at IETF wrote: >=20 >=20 >=20 > On Wednesday, October 15, 2014, Prashanth Patil (praspati) wrote: > Hi Adam, > The concerning use cases described in the draft were to indicate that the= new ALPN identifiers could also be considered for WebRTC firewall traversa= l (as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-fir= ewall-considerations-03#section-4.2). > End to end identifier negotiation is still the goal of this draft i.e. to= negotiate the use of stun and its usages. >=20 > We'll remove these use cases and stick to end to end negotiation. >=20 > Just so I'm clear, should I be expecting a -07? >=20 > Thanks, >=20 > Spencer > =20 > -Prashanth >=20 > > On Thu, Oct 9, 2014 at 15:41, Adam Langley wro= te: >=20 > >> Is your concern specific to TRAM's proposed use of ALPN, or does it ap= ply to > >> ALPN in general? >=20 > > In general I think the IETF should be promoting the end-to-end > > principle. My concern is specifically about TRAM implicitly endorsing > > the idea that the network should be applying policy like that. >=20 > > (There's also a fair amount of irony in that fact that the second > > example suggests ALPN be used to get around the fact that networks > > often discriminate based on TCP port numbers, and the first example is > > suggesting that networks do exactly the same thing to ALPN > > identifiers.) >=20 > > Cheers >=20 > > AGL >=20 >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Oct 27 05:01:59 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 EF54C1A9130 for ; Mon, 27 Oct 2014 05:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKgQqmWc5q_r for ; Mon, 27 Oct 2014 05:01:56 -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 3B4361A9136 for ; Mon, 27 Oct 2014 05:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2628; q=dns/txt; s=iport; t=1414411317; x=1415620917; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lD3NFfrHIs8xD4b01ZjSq4dOeKM37yviWw/voTgXmIU=; b=YEtgM5Op93PRzs8RCGp5YzBHzj2cbmS4MVrjdVI7o3m+cKCnKLXMg9R0 aAqnOjv4H6powOJAunMXHpDAMPtKXZ+9ZS54LdsODicPJbOi0zQTjKTR8 cX17yp0mDs4/61UCSFjC4yZqBVbINXeUOjd9v9UNbAwrcgJlVeI9RlkqF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAI0zTlStJA2J/2dsb2JhbABcgw5UWASDAso7h0sCG3sWAXILhAIBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBiDgNtRaUOQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLI8rOAaCcTaBHgWSB4RIiEM8gw2RNIN4bAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,795,1406592000"; d="scan'208";a="366736085" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 27 Oct 2014 12:01:56 +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 s9RC1tia015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Oct 2014 12:01:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 07:01:55 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-patil-tram-turn-serv-selection-00.txt Thread-Index: AQHP8d2U/VGnHz+5B0+2xcrz4yYRxJxD14GA Date: Mon, 27 Oct 2014 12:01:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com> References: <20141027120016.1947.18448.idtracker@ietfa.amsl.com> In-Reply-To: <20141027120016.1947.18448.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.66.221] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/J7NuNlkwP5hXsGeQzpNjvd3J1ZY Subject: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-selection-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, 27 Oct 2014 12:01:58 -0000 V2UndmUgcHVibGlzaGVkIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgVFVSTiBzZWxlY3Rpb24gY3Jp dGVyaWEsIGFzIGd1aWRlbGluZXMsIHRoYXQgY2FuIGJlIHVzZWQgYnkgYSBjbGllbnQgdG8gcGVy Zm9ybSBhbiBpbmZvcm1lZCBUVVJOIHNlcnZlciBzZWxlY3Rpb24gZGVjaXNpb24gd2hlbiBhIGNs aWVudCBkaXNjb3ZlcnMgbXVsdGlwbGUgVFVSTiBzZXJ2ZXJzLiAgQ29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpDaGVlcnMsDQotVGlydQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNywgMjAxNCA1OjMw IFBNDQpUbzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7IEdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSk7IFByYXNoYW50aCBQYXRpbCAo cHJhc3BhdGkpOyBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpOyBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXBhdGlsLXRyYW0tdHVybi1zZXJ2LXNlbGVjdGlvbi0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcGF0aWwtdHJhbS10 dXJuLXNlcnYtc2VsZWN0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJVHJhdmVyc2FsIFVzaW5n IFJlbGF5cyBhcm91bmQgTkFUIChUVVJOKSBTZXJ2ZXIgU2VsZWN0aW9uDQpEb2N1bWVudCBkYXRl OgkyMDE0LTEwLTI2DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk3DQpV Ukw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt cGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhdGlsLXRyYW0tdHVybi1zZXJ2 LXNlbGVjdGlvbi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAg IEEgVFVSTiBjbGllbnQgbWF5IGRpc2NvdmVyIG11bHRpcGxlIFRVUk4gc2VydmVycy4gIEluIHN1 Y2ggYSBjYXNlLA0KICAgdGhlcmUgYXJlIG5vIGd1aWRlbGluZXMgdGhhdCBhIGNsaWVudCBjYW4g Zm9sbG93IHRvIGNob29zZSBvciBwcmVmZXINCiAgIGEgcGFydGljdWxhciBUVVJOIHNlcnZlciBh bW9uZyB0aG9zZSBkaXNjb3ZlcmVkLiAgVGhpcyBkb2N1bWVudA0KICAgZGV0YWlscyBzZWxlY3Rp b24gY3JpdGVyaWEsIGFzIGd1aWRlbGluZXMsIHRoYXQgY2FuIGJlIHVzZWQgYnkgYQ0KICAgY2xp ZW50IHRvIHBlcmZvcm0gYW4gaW5mb3JtZWQgVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIGRlY2lzaW9u Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Oct 27 06:48:15 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 924AC1A86EF for ; Mon, 27 Oct 2014 06:47:59 -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 HhMn5Wzt6rIG for ; Mon, 27 Oct 2014 06:47:58 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082681AC425 for ; Mon, 27 Oct 2014 06:47:57 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id va2so3376630obc.14 for ; Mon, 27 Oct 2014 06:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QnR4QR3mv36vtp49Z9Z7tz0aVxmETL4j9eGyfJYrFjQ=; b=sdvHLu9mvv/7S11V2hw3na3pIJS3JAOunQfLx0cAj0WxDifLR71IPX6klm/IVI8dSc 90IzJsgJsZk3amtJ4e6d9W55tcft+AMKfDUGKlHWnGNqXJGINDNJGvEVfEZDyamIKjaE SxES7N73O8uGJUjyTiUDiUIdd6acKxX6Sep5uNepBIfrCpCnMvOueEDVKiJrexec+jUx z905ys80Yr2RkvO3LZcDS8mIFfEWCIirwBY6y8ccG/SoBWqgjf0LICbjygJe+Qixhv60 5B2hWbyJGCDA1tguaIZrbLMw9+PP4qocj5uPZGOBhOIOAiW+a+efgZodJF6eS2ztpjCh 4lJQ== X-Received: by 10.182.20.15 with SMTP id j15mr2151079obe.52.1414417677452; Mon, 27 Oct 2014 06:47:57 -0700 (PDT) Received: from ?IPv6:2605:6000:9004:ce00:1554:d705:2681:ed08? ([2605:6000:9004:ce00:1554:d705:2681:ed08]) by mx.google.com with ESMTPSA id k9sm4951217oev.8.2014.10.27.06.47.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 06:47:56 -0700 (PDT) Message-ID: <544E4D06.4090204@gmail.com> Date: Mon, 27 Oct 2014 08:47:50 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" References: <27E0796F-3117-4715-91C6-904B2E9620E5@cisco.com> In-Reply-To: <27E0796F-3117-4715-91C6-904B2E9620E5@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BpdzYGRCU9lvDAIj3bVKLekeH_M Cc: "Prashanth Patil \(praspati\)" , "agl@imperialviolet.org" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:48:00 -0000 On 10/26/2014 11:53 PM, Gonzalo Salgueiro (gsalguei) wrote: > Hi Spencer - > > Do you want that -07 prior to IESG review? We assumed we should wait to make all changes after IESG review. We're flexible and can do it either way. Just let us know. Ah - I'm glad we had this conversation! My preference would be to have the IESG review a clean version of drafts that receive Last Call or review comments. That makes it easier for everyone to compare what the Last Call and review comments were to what the working group thinks the draft says as a result. So, yes, please respin the draft. And I'm sorry I didn't ask sooner. Spencer > Cheers, > > Gonzalo > > >> On Oct 27, 2014, at 12:44 AM, Spencer Dawkins at IETF wrote: >> >> >> >> On Wednesday, October 15, 2014, Prashanth Patil (praspati) wrote: >> Hi Adam, >> The concerning use cases described in the draft were to indicate that the new ALPN identifiers could also be considered for WebRTC firewall traversal (as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2). >> End to end identifier negotiation is still the goal of this draft i.e. to negotiate the use of stun and its usages. >> >> We'll remove these use cases and stick to end to end negotiation. >> >> Just so I'm clear, should I be expecting a -07? From nobody Mon Oct 27 06:59: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 DD2E21ACC80 for ; Mon, 27 Oct 2014 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nkfdUiURHPx for ; Mon, 27 Oct 2014 06:58:55 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB681A872B for ; Mon, 27 Oct 2014 06:58:55 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ge10so674507lab.22 for ; Mon, 27 Oct 2014 06:58:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=npC2SPLm5rrk+bZw99Ru1JZIKL7sQtuhGBG+Icst4VY=; b=O2QZMT0kapcKkEvmmq4tLooOnb9ZBB894IZYPb0UBe/nGoilYbdSYJ5z507TDU6Gzp CA+qOFsVF42goTrVyQ/c1QaylbPB7TXo35rNiZ0rZpVvPo95/X50t5xyhpZguYe0WIBD gWFPXsga/AvxRmAX7lZ/jYNfNwn8AtkccF8h0+0cGgoV+M2xUNSI8ZWIk7j8Sp30DsY2 Dmg6ZTEg+Egw9553TpAaW4xsIwHX0DjkZQoC50Zxr8dh8033ioKoGl7WR7Qm8FJMwTPF SRZoObk2lAdf9fHdFzZo8gHkI1HB2KSHuf5oOQ4p84taAGgj/ojpTGlBLO5Z/5onz31q bVjQ== X-Gm-Message-State: ALoCoQmMUlozjc7puhPE4m1+wl6eQygXBDFNelpbf5SOGvpDryg5dHRIlAvCfKCuCxLpM5Pz7IVV MIME-Version: 1.0 X-Received: by 10.112.54.162 with SMTP id k2mr23790735lbp.63.1414418333247; Mon, 27 Oct 2014 06:58:53 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Mon, 27 Oct 2014 06:58:53 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com> References: <20141027120016.1947.18448.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com> Date: Mon, 27 Oct 2014 09:58:53 -0400 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c3eeee514220050667eef4 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NRmDWUyAz529LR_IM0KCsCFcs_g Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-selection-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, 27 Oct 2014 13:58:58 -0000 --001a11c3eeee514220050667eef4 Content-Type: text/plain; charset=UTF-8 Interesting! Quick procedural question: The intended status says Informational, but the text uses RFC2119 keywords. Is this an oversight? Simon On Mon, Oct 27, 2014 at 8:01 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > We've published a draft that describes TURN selection criteria, as > guidelines, that can be used by a client to perform an informed TURN server > selection decision when a client discovers multiple TURN servers. Comments > and suggestions are welcome. > > Cheers, > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 27, 2014 5:30 PM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Gonzalo > Salgueiro (gsalguei); Prashanth Patil (praspati); Gonzalo Salgueiro > (gsalguei); Tirumaleswar Reddy (tireddy) > Subject: New Version Notification for > draft-patil-tram-turn-serv-selection-00.txt > > > A new version of I-D, draft-patil-tram-turn-serv-selection-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-patil-tram-turn-serv-selection > Revision: 00 > Title: Traversal Using Relays around NAT (TURN) Server Selection > Document date: 2014-10-26 > Group: Individual Submission > Pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-selection-00.txt > Status: > https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-selection/ > Htmlized: > http://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-00 > > > Abstract: > A TURN client may discover multiple TURN servers. In such a case, > there are no guidelines that a client can follow to choose or prefer > a particular TURN server among those discovered. This document > details selection criteria, as guidelines, that can be used by a > client to perform an informed TURN server selection decision. > > > > > 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 > --001a11c3eeee514220050667eef4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting!

Quick procedural question:= The intended status says Informational, but the text uses RFC2119 keywords= . Is this an oversight?

Simon

On Mon, Oct 27, 2014 at 8:= 01 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrot= e:
We've published a draft that descr= ibes TURN selection criteria, as guidelines, that can be used by a client t= o perform an informed TURN server selection decision when a client discover= s multiple TURN servers.=C2=A0 Comments and suggestions are welcome.

Cheers,
-Tiru

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, October 27, 2014 5:30 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Gonzalo Salgu= eiro (gsalguei); Prashanth Patil (praspati); Gonzalo Salgueiro (gsalguei); = Tirumaleswar Reddy (tireddy)
Subject: New Version Notification for draft-patil-tram-turn-serv-selection-= 00.txt


A new version of I-D, draft-patil-tram-turn-serv-selection-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-patil-tram-turn-serv-se= lection
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Traversal Using Relays around NAT = (TURN) Server Selection
Document date:=C2=A0 2014-10-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-select= ion-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://= datatracker.ietf.org/doc/draft-patil-tram-turn-serv-selection/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf= .org/html/draft-patil-tram-turn-serv-selection-00


Abstract:
=C2=A0 =C2=A0A TURN client may discover multiple TURN servers.=C2=A0 In suc= h a case,
=C2=A0 =C2=A0there are no guidelines that a client can follow to choose or = prefer
=C2=A0 =C2=A0a particular TURN server among those discovered.=C2=A0 This do= cument
=C2=A0 =C2=A0details selection criteria, as guidelines, that can be used by= a
=C2=A0 =C2=A0client to perform an informed TURN server selection decision.<= br>



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

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

--001a11c3eeee514220050667eef4-- From nobody Mon Oct 27 07:09: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 7E16F1ACD3A for ; Mon, 27 Oct 2014 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltvo6ZdNphgf for ; Mon, 27 Oct 2014 07:08:54 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2BF1ACD36 for ; Mon, 27 Oct 2014 07:08:34 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id e131so719216oig.30 for ; Mon, 27 Oct 2014 07:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=z87Ly62G1oFJqil9qA2RGycu+fwEdur5eWiGaspoZcc=; b=ohnDkf4SCrJnu2yPr21Nho2sa238mlryOYrCZ246Hmnslr4eU2mXMjIZlAbCfAFjqP +4gcdR+pD7qF7t43XnefyFEAULzQtgC0+m3zb1W1F94hkNAq2DxodRs8F0QZ5kgCv994 3LFQ80nBhcIuASKeAPkC+igM/M6+E5aFwPEFQL5b6kEX1wPL8HxpElpD5eYTEiK4iz5e eRObha1rSs56iPk8QtbQOD/TUA3iNJ42jZE6H1aCe8pLHISrZg6UT309vAL3B1/PIP+s dKP3HEln/49MRT+B9mK3AwJnuSTeqRmokihssNWGb0tvHNk8wKmLo2m9irwx+s3s5D2J 6D5A== X-Received: by 10.182.176.40 with SMTP id cf8mr20557124obc.22.1414418914209; Mon, 27 Oct 2014 07:08:34 -0700 (PDT) Received: from ?IPv6:2605:6000:9004:ce00:1554:d705:2681:ed08? ([2605:6000:9004:ce00:1554:d705:2681:ed08]) by mx.google.com with ESMTPSA id e73sm5103880oih.3.2014.10.27.07.08.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 07:08:32 -0700 (PDT) Message-ID: <544E51DC.1010908@gmail.com> Date: Mon, 27 Oct 2014 09:08:28 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "agl@imperialviolet.org" , Simon Perreault References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070007020005050401010009" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/GX4MY7B_SC9Uw6KwwdkrDPswoZM Cc: "tram@ietf.org" Subject: Re: [tram] Last Call: (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:08:55 -0000 This is a multi-part message in MIME format. --------------070007020005050401010009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/15/2014 02:01 AM, Prashanth Patil (praspati) wrote: > Hi Adam, > The concerning use cases described in the draft were to indicate that > the new ALPN identifiers could also be considered for WebRTC firewall > traversal (as pointed out in > http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2). > End to end identifier negotiation is still the goal of this draft i.e. > to negotiate the use of stun and its usages. > We'll remove these use cases and stick to end to end negotiation. Sorry for chiming in late. I saw this exchange when it happened, but I'm still thinking about it. I understood Adam's point to be "the draft says you can use ALPN labels to do something we don't think people should do", and Prashanth's response to be "we'll make sure the draft doesn't say that". That might be the right action. What finally sunk in for me, was that changing the draft so that it doesn't include those use cases, doesn't prevent anyone from doing what Adam doesn't think should be done, does it? Would it be better to point out this concern in the draft, and perhaps explain why this is discouraged? That's not a suggestion that you should do that. It's an honest question. Thanks, Spencer, as your more alert AD ... > -Prashanth > >On Thu, Oct 9, 2014 at 15:41, Adam Langley wrote: > >> Is your concern specific to TRAM's proposed use of ALPN, or does it apply to > >> ALPN in general? > > > In general I think the IETF should be promoting the end-to-end > > principle. My concern is specifically about TRAM implicitly endorsing > > the idea that the network should be applying policy like that. > > > (There's also a fair amount of irony in that fact that the second > > example suggests ALPN be used to get around the fact that networks > > often discriminate based on TCP port numbers, and the first example is > > suggesting that networks do exactly the same thing to ALPN > > identifiers.) > > > Cheers > > > AGL > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --------------070007020005050401010009 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 10/15/2014 02:01 AM, Prashanth Patil (praspati) wrote:
Hi Adam,
The concerning use cases described in the draft were to indicate that the new ALPN identifiers could also be considered for WebRTC firewall traversal (as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.2).
End to end identifier negotiation is still the goal of this draft i.e. to negotiate the use of stun and its usages.


We'll remove these use cases and stick to end to end negotiation.

Sorry for chiming in late. I saw this exchange when it happened, but I'm still thinking about it.

I understood Adam's point to be "the draft says you can use ALPN labels to do something we don't think people should do", and Prashanth's response to be "we'll make sure the draft doesn't say that".

That might be the right action.

What finally sunk in for me, was that changing the draft so that it doesn't include those use cases, doesn't prevent anyone from doing what Adam doesn't think should be done, does it?

Would it be better to point out this concern in the draft, and perhaps explain why this is discouraged?

That's not a suggestion that you should do that. It's an honest question.

Thanks,

Spencer, as your more alert AD ... 

-Prashanth


> On Thu, Oct 9, 2014 at 15:41, Adam Langley <agl@imperialviolet.org> wrote:


>> Is your concern specific to TRAM's proposed use of ALPN, or does it apply to
>> ALPN in general?

> In general I think the IETF should be promoting the end-to-end
> principle. My concern is specifically about TRAM implicitly endorsing
> the idea that the network should be applying policy like that.

> (There's also a fair amount of irony in that fact that the second
> example suggests ALPN be used to get around the fact that networks
> often discriminate based on TCP port numbers, and the first example is
> suggesting that networks do exactly the same thing to ALPN
> identifiers.)

> Cheers

> AGL

      

      

      

      

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


    

    

  


--------------070007020005050401010009--


From nobody Mon Oct 27 07:20:43 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 C28621ACD40 for ; Mon, 27 Oct 2014 07:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-PdCD84wFFh for ; Mon, 27 Oct 2014 07:19:53 -0700 (PDT)
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8D71A8750 for ; Mon, 27 Oct 2014 07:19:38 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ge10so715250lab.22 for ; Mon, 27 Oct 2014 07:19:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YcV98GwgoBRv8uGsd8V/epl9hMhfNG13EdBogIsm19w=; b=TiYa+t68Rb1aHH9uyckPiYh7h/K3h0qvj7llvqOhqk6fo8iAl0q4hItmEc89yYJZvN YYXa1WZCyeZTsC7/6aJibVhV8xVpewx51a5cNmpyOsUOFJH75oXW9kbmoD99QpshS8Ws DMY9XUJeJ2Lc3dBFacMk3USkzZkANQN7g5nh12Mys+XaoGDAe5lj+GsWDQusGDnS7v51 syZ4qcCDDL9pdAH4g5sRZYQk7p9J1/1OgbyrkJ8j5oD8eZoVY7XMyHFVKv0ztoexoJDm 705M6OiRopOgVEcOo9LfWNqY5BsGsd+j/PSH+RmMdWmH1nXrpGu/k3QP+uGwY2xI5s+k 74OQ==
X-Gm-Message-State: ALoCoQlLz7IG/gVKyOISeDGWwww8jrFofvFQ4sk/llv2TBmZfHX+RiYhVIOVZUfuZKtMf0pVNzLN
MIME-Version: 1.0
X-Received: by 10.112.38.67 with SMTP id e3mr24437252lbk.6.1414419576460; Mon, 27 Oct 2014 07:19:36 -0700 (PDT)
Received: by 10.25.167.20 with HTTP; Mon, 27 Oct 2014 07:19:36 -0700 (PDT)
In-Reply-To: <544E51DC.1010908@gmail.com>
References:  <544E51DC.1010908@gmail.com>
Date: Mon, 27 Oct 2014 10:19:36 -0400
Message-ID: 
From: Simon Perreault 
To: Spencer Dawkins 
Content-Type: multipart/alternative; boundary=001a113461586b2ea30506683864
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XWUu6DADqo5ce9xprS0OkTdsHJs
Cc: "Prashanth Patil \(praspati\)" , "agl@imperialviolet.org" , "tram@ietf.org" 
Subject: Re: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:19:56 -0000

--001a113461586b2ea30506683864
Content-Type: text/plain; charset=UTF-8

On Mon, Oct 27, 2014 at 10:08 AM, Spencer Dawkins <
spencerdawkins.ietf@gmail.com> wrote:

> What finally sunk in for me, was that changing the draft so that it
> doesn't include those use cases, doesn't prevent anyone from doing what
> Adam doesn't think should be done, does it?
>
> Would it be better to point out this concern in the draft, and perhaps
> explain why this is discouraged?
>
> That's not a suggestion that you should do that. It's an honest question.
>

My take on this is that any ALPN code would have the same consideration. So
if it's something we want to say (I don't have an opinion either way), then
it needs to be said about ALPN in general, not in this STUN/TURN-specific
ALPN usage.

Simon

--001a113461586b2ea30506683864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Mon, Oct 27, 2014 at 10:08 AM, Spencer Dawkins <spencerdawk=
ins.ietf@gmail.com> wrote:
=

What finally sunk in for me, was =
that changing the draft so that it
    doesn't include those use cases, doesn't prevent anyone from do=
ing
    what Adam doesn't think should be done, does it? 

    

    Would it be better to point out this concern in the draft, and
    perhaps explain why this is discouraged?

    

    That's not a suggestion that you should do that. It's an honest
    question.

My take on this is that any ALPN =
code would have the same consideration. So if it's something we want to=
 say (I don't have an opinion either way), then it needs to be said abo=
ut ALPN in general, not in this STUN/TURN-specific ALPN usage.

Simon


--001a113461586b2ea30506683864--


From nobody Mon Oct 27 07:20: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 AAF511A8A0F for ; Mon, 27 Oct 2014 07:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc3W6naq6dEF for ; Mon, 27 Oct 2014 07:20:00 -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 51C5C1A8759 for ; Mon, 27 Oct 2014 07:19:41 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 760DD47547 for ; Mon, 27 Oct 2014 14:19:40 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 646AC4753A for ; Mon, 27 Oct 2014 14:19:40 +0000 (GMT)
Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 12D222035 for ; Mon, 27 Oct 2014 14:19:40 +0000 (GMT)
Message-ID: <544E547C.20903@akamai.com>
Date: Mon, 27 Oct 2014 10:19:40 -0400
From: Brandon Williams 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "tram@ietf.org" 
References:  <544A6085.70707@akamai.com> <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/EtuHlhNsqxzJGV1bpOX71xNKwS0
Subject: Re: [tram] STUN-bis adoption call
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, 27 Oct 2014 14:20:01 -0000

On 10/24/2014 11:10 PM, Tirumaleswar Reddy (tireddy) wrote:
>> Regarding fragmentation (item 5) ... I don't see any substantive changes. I
>> >don't see anything about this in appendix B.2, so I don't think I'm missing
>> >anything.
> There were discussions about fragmentation support in the list sometime back but without any conclusions.
> Please provide more details.
>

My primary point is that improved guidance on fragmentation and message 
sizes is one of the things on the list of open items and it doesn't 
appear that any changes have been made yet. I mostly wanted to confirm 
that there isn't something about this already in the document that I'm 
not seeing.

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


From nobody Mon Oct 27 07:23: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 91B471ACD1C for ; Mon, 27 Oct 2014 07:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OlpVQHEMFSL for ; Mon, 27 Oct 2014 07:21:59 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8141A00A3 for ; Mon, 27 Oct 2014 07:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10857; q=dns/txt; s=iport; t=1414419719; x=1415629319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=moOScV4UgClpEedByYKE//FwNe17JGiCgWXdKKstAkQ=; b=Fd++p2YWH54DCpIglkncLkH+Ibn0icGLBz84fLrG+fc2o1Z5TAg5LxJ4 aWjoNzHqotdR5h47Hn/Oddj7w8HCJ28R75HK1eRy0Nv+od6fRmPZ1eGbO s/jQaprgDQyDZoq5Vk2rzEri82exw0u8a0wxDvHvA6CLO6huuWLYJXpWC Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAOdTTlStJA2G/2dsb2JhbABcgkhGVFgEzTIBC4dLAoEaFgF9hAIBAQEDAQEBAWsLBQsCAQgRAwECJAQHIQYLFAkIAgQBDQUJiCMDCQkNxFINhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjj4QgikRB4RLBY9pgh6ESIUBghGBMTyNZIJdhACCNIFEbAGBR4EDAQEB
X-IronPort-AV: E=Sophos;i="5.04,796,1406592000";  d="scan'208,217";a="363665130"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 27 Oct 2014 14:21:58 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9RELwxr024747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 14:21:58 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 09:21:58 -0500
From: "Prashanth Patil (praspati)" 
To: Spencer Dawkins , "agl@imperialviolet.org" , Simon Perreault 
Thread-Topic: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
Thread-Index: AQHP8e966bhsJ/XP+EuLC8ncvRqiO5xErtwA
Date: Mon, 27 Oct 2014 14:21:57 +0000
Message-ID: 
References:  <544E51DC.1010908@gmail.com>
In-Reply-To: <544E51DC.1010908@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [10.65.36.132]
Content-Type: multipart/alternative; boundary="_000_D07452A3558E7praspaticiscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/86YD6NIIIQbXZ_kON8hseBsR3Yo
Cc: "tram@ietf.org" 
Subject: Re: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 14:22:02 -0000

--_000_D07452A3558E7praspaticiscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Spencer,
Yes, a middle box could still use ALPN identifiers to make policy decisions=
. But that=92s true with any ALPN identifier and not specific to identifier=
s defined in this draft.

-Prashanth

From: Spencer Dawkins >
Date: Monday, October 27, 2014 7:38 PM
To: Prashanth Patil >, "agl@i=
mperialviolet.org" >, Simon Perreault >
Cc: "tram@ietf.org" >
Subject: Re: [tram] Last Call:  (Application L=
ayer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for=
 NAT (STUN) Usages) to Proposed Standard

On 10/15/2014 02:01 AM, Prashanth Patil (praspati) wrote:

Hi Adam,
The concerning use cases described in the draft were to indicate that the n=
ew ALPN identifiers could also be considered for WebRTC firewall traversal =
(as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firew=
all-considerations-03#section-4.2).
End to end identifier negotiation is still the goal of this draft i.e. to n=
egotiate the use of stun and its usages.
We'll remove these use cases and stick to end to end negotiation.

Sorry for chiming in late. I saw this exchange when it happened, but I'm st=
ill thinking about it.

I understood Adam's point to be "the draft says you can use ALPN labels to =
do something we don't think people should do", and Prashanth's response to =
be "we'll make sure the draft doesn't say that".

That might be the right action.

What finally sunk in for me, was that changing the draft so that it doesn't=
 include those use cases, doesn't prevent anyone from doing what Adam doesn=
't think should be done, does it?

Would it be better to point out this concern in the draft, and perhaps expl=
ain why this is discouraged?

That's not a suggestion that you should do that. It's an honest question.

Thanks,

Spencer, as your more alert AD ...


-Prashanth
> On Thu, Oct 9, 2014 at 15:41, Adam Langley  wrote:

>> Is your concern specific to TRAM's proposed use of ALPN, or does it appl=
y to
>> ALPN in general?

> In general I think the IETF should be promoting the end-to-end
> principle. My concern is specifically about TRAM implicitly endorsing
> the idea that the network should be applying policy like that.

> (There's also a fair amount of irony in that fact that the second
> example suggests ALPN be used to get around the fact that networks
> often discriminate based on TCP port numbers, and the first example is
> suggesting that networks do exactly the same thing to ALPN
> identifiers.)

> Cheers

> AGL



_______________________________________________
tram mailing list
tram@ietf.orghttps://www.ietf.org/mailman/listinfo/tr=
am


--_000_D07452A3558E7praspaticiscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <08099EFD68E7B44BB2D3204E605A850C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Spencer,


Yes, a middle box could still use ALPN identifiers to make policy deci=
sions. But that=92s true with any ALPN identifier and not specific to ident=
ifiers defined in this draft.







-Prashanth









From: Spencer Dawkins <spencerdawkins.ietf@gmail.com=
>

Date: Monday, October 27, 2014 7:38=
 PM

To: Prashanth Patil <praspati@cisco.com>, "agl@imperialviolet.org" <agl@imperialviolet.org>,
 Simon Perreault <sperreault@jive=
.com>

Cc: "tram@ietf.org" <tram@i=
etf.org>

Subject: Re: [tram] Last Call: <=
draft-ietf-tram-alpn-06.txt> (Application Layer Protocol Negotiation (AL=
PN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Propos=
ed Standard













On 10/15/2014 02:01 AM, Prashanth Patil (pra=
spati) wrote:






Hi Adam,
The concerning use cases described in the draft we=
re to indicate that the new ALPN identifiers could also be considered for W=
ebRTC firewall traversal (as pointed out in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-fir=
ewall-considerations-03#section-4.2).
End to end identifier negotiation is still the go=
al of this draft i.e. to negotiate the use of stun and its usages.
We'll remove these use cases and stick to end to end negotiation.




Sorry for chiming in late. I saw this exchange when it happened, but I'm st=
ill thinking about it.



I understood Adam's point to be "the draft says you can use ALPN label=
s to do something we don't think people should do", and Prashanth's re=
sponse to be "we'll make sure the draft doesn't say that".



That might be the right action. 



What finally sunk in for me, was that changing the draft so that it doesn't=
 include those use cases, doesn't prevent anyone from doing what Adam doesn=
't think should be done, does it?




Would it be better to point out this concern in the draft, and perhaps expl=
ain why this is discouraged?



That's not a suggestion that you should do that. It's an honest question.


Thanks,



Spencer, as your more alert AD ... 






-Prashanth
> On Thu, Oct 9, 2014 at 15:41, Adam Langley <agl@imperialviolet.or=
g> wrote:
>> Is your concern specific to TRAM's proposed=
 use of ALPN, or does it apply to
>> ALPN in general?

> In general I think the IETF should be promoting the end-to-end
> principle. My concern is specifically about TRAM implicitly endorsing
> the idea that the network should be applying policy like that.

> (There's also a fair amount of irony in that fact that the second
> example suggests ALPN be used to get around the fact that networks
> often discriminate based on TCP port numbers, and the first example is
> suggesting that networks do exactly the same thing to ALPN
> identifiers.)

> Cheers

> AGL








 


_______________________________________________
tram mailing list
tram@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/tram













--_000_D07452A3558E7praspaticiscocom_--


From nobody Mon Oct 27 11:49:43 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 81F331A0070 for ; Mon, 27 Oct 2014 11:49:21 -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 qk4TZKpRLNW7 for ; Mon, 27 Oct 2014 11:49:18 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD9D1A6F8F for ; Mon, 27 Oct 2014 11:48:47 -0700 (PDT)
Received: by mail-oi0-f41.google.com with SMTP id e131so1196478oig.28 for ; Mon, 27 Oct 2014 11:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=QPzTjc1VGuKelNwupNQ23avFD64ndaolzpo6+zrSBME=; b=ja06tp2WdDxnadinS//0M/ahqGACumjj46OMu2MRYl/9d0Xtrlgdl8kic+Z16rByF8 5cG+LcAWp1h8uR6PCaP4tJNHzXZe0n5BY7rL9cA8thcV4Qb72cQrkLcaqWHKK2zshsSc +ybXi1eCWfP+jSQpKJ6IUzvNV+Cz9H0hYhs2d8Yb7w4QPopBgjML7ROPPufUoSP0iMu/ NwysO3k2E4Ij/5XEUISpq4ATeDGqoC41znlx0/okXLHiwnK0vSjZvcC8RwE/RvZ9v5wq L4vpLQGZ273ssrogEty7Nuhjym8NHHcwTs2UNO/kZ91I8qagd8t4pie0Sf1qOjwO3g6L dbAQ==
X-Received: by 10.182.149.162 with SMTP id ub2mr2068865obb.86.1414435726762; Mon, 27 Oct 2014 11:48:46 -0700 (PDT)
Received: from ?IPv6:2605:6000:9004:ce00:2db3:51d5:f380:7d16? ([2605:6000:9004:ce00:2db3:51d5:f380:7d16]) by mx.google.com with ESMTPSA id bu5sm5390978obd.2.2014.10.27.11.48.44 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 11:48:45 -0700 (PDT)
Message-ID: <544E938B.1030802@gmail.com>
Date: Mon, 27 Oct 2014 13:48:43 -0500
From: Spencer Dawkins 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Stephen Farrell 
References: 
In-Reply-To: 
X-Forwarded-Message-Id: 
Content-Type: multipart/alternative; boundary="------------000303030608000700080509"
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_tx3W31dbx1E3zWSGZO601zIE9A
Cc: Adam Langley , Martin Stiemerling , Kathleen Moriarty , "tram@ietf.org" , tls-chairs@tools.ietf.org
Subject: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 18:49:21 -0000

This is a multi-part message in MIME format.
--------------000303030608000700080509
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Stephen, the responsible AD for TLS WG,

I could be all wrong about this, but what I think is going on is ...

As part of IETF Last Call for draft-ietf-tram-alpn-06.txt, we got a 
thought-provoking comment from Adam Langley, objecting to an observation 
in the draft that STUN ALPN labels could be used by middleboxes to 
enforce policy, because doing so runs head on into chartered work in TLS 
to encrypt as much of the TLS handshake as possible.

In subsequent exchanges, Adam and the TRAM folk agreed that this is true 
for any ALPN label, not just for STUN ALPN labels.

The TRAM folk aren't comfortable adding discussions about this broader 
issue in a TRAM document. The most recent proposal was to remove the 
text that points out this possibility.

I'm thinking that removing the text that says it's possible to use STUN 
ALPN labels may not be the best response to Adam's comment (even in "The 
Wizard of Oz", the man behind the curtain saying, "pay no attention to 
the man behind the curtain" didn't change the fact that there's still a 
man behind the curtain).

Would a document about ALPN label abuse, regardless of the specific 
label, be appropriate for the TLS working group, if the TLS working 
group thought this question mattered enough to work on it?

I've slipped draft-ietf-tram-alpn from this week's telechat to 11/25, so 
we have time to talk about this question without bouncing a Discuss 
around, and people can talk at IETF 91 if that's helpful.

Thanks for any guidance you can provide.

Spencer, as shepherding AD for draft-ietf-tram-alpn

-------- Forwarded Message --------
Subject: 	Last Call:  (Application Layer 
Protocol Negotiation (ALPN) labels for Session Traversal Utilities for 
NAT (STUN) Usages) to Proposed Standard
Date: 	Wed, 8 Oct 2014 10:24:08 -0700
From: 	Adam Langley 
To: 	ietf@ietf.org



In the introduction of this document[1], the first example appears to
endorse the idea that a firewall would inspect a TLS handshake and
quash the communication if it saw an ALPN identifier that it didn't
like.

If I'm not misunderstanding this example, then it's contradictory to
the work that the TLS WG is chartered to do[2]:

"Develop a mode that encrypts as much of the handshake as is possible
to reduce the amount of observable data to both passive and active
attackers."

It would be disappointing if an RFC explicitly endorsed middleware
that tries to parse high-level protocols and interferes with the
network based on the result. There might not be much that we can do
about it, but we don't have to condone it.


Cheers

AGL


[1] https://tools.ietf.org/html/draft-ietf-tram-alpn-06#section-1
[2] https://datatracker.ietf.org/doc/charter-ietf-tls/

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org




--------------000303030608000700080509
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Hi, Stephen, the responsible AD for TLS WG,

    

    I could be all wrong about this, but what I think is going on is ...

    

    As part of IETF Last Call for draft-ietf-tram-alpn-06.txt, we got a
    thought-provoking comment from Adam Langley, objecting to an
    observation in the draft that STUN ALPN labels could be used by
    middleboxes to enforce policy, because doing so runs head on into
    chartered work in TLS to encrypt as much of the TLS handshake as
    possible.

    

    

      In subsequent exchanges, Adam and the TRAM folk agreed that this
      is true for any ALPN label, not just for STUN ALPN labels. 

      

      The TRAM folk aren't comfortable adding discussions about this
      broader issue in a TRAM document. The most recent proposal was to
      remove the text that points out this possibility.

      

      I'm thinking that removing the text that says it's possible to use
      STUN ALPN labels may not be the best response to Adam's comment
      (even in "The Wizard of Oz", the man behind the curtain saying,
      "pay no attention to the man behind the curtain" didn't change the
      fact that there's still a man behind the curtain).

       

      Would a document about ALPN label abuse, regardless of the
      specific label, be appropriate for the TLS working group, if the
      TLS working group thought this question mattered enough to work on
      it?

      

      I've slipped draft-ietf-tram-alpn from this week's telechat to
      11/25, so we have time to talk about this question without
      bouncing a Discuss around, and people can talk at IETF 91 if
      that's helpful.

      

      Thanks for any guidance you can provide.

      

      Spencer, as shepherding AD for draft-ietf-tram-alpn

      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            Last Call: <draft-ietf-tram-alpn-06.txt>
              (Application Layer Protocol Negotiation (ALPN) labels for
              Session Traversal Utilities for NAT (STUN) Usages) to
              Proposed Standard
          

          

            Date: 
            Wed, 8 Oct 2014 10:24:08 -0700
          

          

            From: 
            Adam Langley <agl@imperialviolet.org>
          

          

            To: 
            ietf@ietf.org
          

        
      

      

      

      
In the introduction of this document[1], the first example appears to
endorse the idea that a firewall would inspect a TLS handshake and
quash the communication if it saw an ALPN identifier that it didn't
like.

If I'm not misunderstanding this example, then it's contradictory to
the work that the TLS WG is chartered to do[2]:

"Develop a mode that encrypts as much of the handshake as is possible
to reduce the amount of observable data to both passive and active
attackers."

It would be disappointing if an RFC explicitly endorsed middleware
that tries to parse high-level protocols and interferes with the
network based on the result. There might not be much that we can do
about it, but we don't have to condone it.


Cheers

AGL


[1] https://tools.ietf.org/html/draft-ietf-tram-alpn-06#section-1
[2] https://datatracker.ietf.org/doc/charter-ietf-tls/

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org



      

    

    

  


--------------000303030608000700080509--


From nobody Mon Oct 27 13:37:16 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 AF1E11AD4A0; Mon, 27 Oct 2014 13:36:56 -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 wv4mCrCiA1tu; Mon, 27 Oct 2014 13:36:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CF91AD49D; Mon, 27 Oct 2014 13:36:54 -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.7.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141027203654.26735.33855.idtracker@ietfa.amsl.com>
Date: Mon, 27 Oct 2014 13:36:54 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ziE9DqdktSDS12WnYjjBM4OCCpY
Cc: tram@ietf.org
Subject: [tram] I-D Action: draft-ietf-tram-stun-origin-02.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, 27 Oct 2014 20:36:57 -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           : An Origin Attribute for the STUN Protocol
        Authors         : Alan Johnston
                          Justin Uberti
                          John Yoakum
                          Kundan Singh
	Filename        : draft-ietf-tram-stun-origin-02.txt
	Pages           : 13
	Date            : 2014-10-27

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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tram-stun-origin-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-origin-02


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 Mon Oct 27 14:57:22 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 B49811A0171 for ; Mon, 27 Oct 2014 14:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7rDW6wa1tDr for ; Mon, 27 Oct 2014 14:57:11 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F1C1A0181 for ; Mon, 27 Oct 2014 14:56:26 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id g10so6441296pdj.38 for ; Mon, 27 Oct 2014 14:56:26 -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=uXn7TzuAXx7BIXCqDgMsGFc3yVH2dXFttkn0pTVyrAw=; b=RSnziZMV5tXrE0dP5UxvBfZ1XdF3Esj1OhLLg/t0p3R1qZWUPBcH1vCCz9V84rgpJz eQBs6gg5PFuTO5JjTnTJYMADVg41eRFsr1seZ5IKuvcZyEVmodIp3J/aekAFpwW3Ixi/ vN7tbZCYixt9Cuh3kgM15PaCSdxa6NgE3XviWuntyvNWycyjrcRgvtnm8qTDosQm2rop I/ysJTZgrn6eiKjmxWz4qs2mRbmdFR1bUS4HsC19M2JbQI/eFi2em06S2rhbH3FMNJEQ yhirByRHeqSwMWHBYuxHNUjRlgYiWw/nBA1H7S6quWL7IvrQ/yOy6wI/Txqbh1uvfCKE p4Xw==
X-Received: by 10.70.4.164 with SMTP id l4mr6279066pdl.137.1414446986168; Mon, 27 Oct 2014 14:56:26 -0700 (PDT)
Received: from ?IPv6:2001:4998:effd:600:dc6a:5c44:8609:db55? ([2001:4998:effd:600:dc6a:5c44:8609:db55]) by mx.google.com with ESMTPSA id d9sm11768437pdm.5.2014.10.27.14.56.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:56:25 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Oleg Moskalenko 
In-Reply-To: <00d901cff194$64471e70$2cd55b50$@org.cn>
Date: Mon, 27 Oct 2014 14:56:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D6FC0A2-D36B-48A3-8EE7-E156B538C329@gmail.com>
References: <00d901cff194$64471e70$2cd55b50$@org.cn>
To: Aijun Wang 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sjzNTlZfvrDgvQyCZn7vwm6-vYg
Cc: tram@ietf.org, "Liubing \(Leo\)" 
Subject: Re: [tram] FW: New Version Notification for draft-wang-tram-turnlite-01.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 21:57:12 -0000

On Oct 26, 2014, at 8:16 PM, Aijun Wang  =
wrote:

> Hi, All TRAMsters
>=20
> We have submitted one new draft that describes the lightweight TURN(we =
refer it as TURNLite later) architecture and the corresponding new STUN =
message introduced in this draft. With the TURNLite solution, CP/SP can =
easily offload the complex and troublesome deployment of TURN servers to =
the service provider, the service provider can easily integrate the data =
relay function of TURNLite server into their current distributed =
deployed CGN devices.=20
> This can be a win-win solution, and meets all the communication =
scenarios that the current TURN solution intends to solve, but in a more =
simple manner.  =20

Actually, not all the communication scenarios of the =93full=94 TURN can =
be achieved by the TURNLite.

The "full=94 TURN allows pretty high degree of the network hosts =
privacy. If a host is using TLS/DTLS protocol for the TURN =
communications, then the network infrustructure devices are not able to =
determine the hosts=92s peer address. The peer information is stored =
(ephemerally) at the TURN server and it may not be retrieved by the =
outside parties if the TURN server is properly secured.

With the TURNLite, the communication between the parties is fully =
controlled by the host=92s network infrastructure. That may be a =
desirable quality in some limited circumstances (like in a strict =
corporate environment), but I am not sure about the general case.

>=20
> We are also eager to find other cooperators that are interested in =
this topic. Any comments are valuable.
>=20
> Mr. Liubing has apply the timeslot to present this draft in the coming =
IETF meeting in Holununu.
>=20
> Best Regards.
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
> Sent: Monday, October 27, 2014 10:07 AM
> To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu
> Subject: New Version Notification for draft-wang-tram-turnlite-01.txt
>=20
>=20
> A new version of I-D, draft-wang-tram-turnlite-01.txt has been =
successfully submitted by Bing Liu and posted to the IETF repository.
>=20
> Name:		draft-wang-tram-turnlite
> Revision:	01
> Title:		A Lightweight TURN Architecture and =
Specification (TURNLite)
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		15
> URL:            =
http://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-01.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/
> Htmlized:       http://tools.ietf.org/html/draft-wang-tram-turnlite-01
> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-wang-tram-turnlite-01
>=20
> Abstract:
>   This document proposes a lightweight TURN architecture which
>   simplifies the application provider side complexity of implementing
>   TURN server by transfering the data relay processing to the ISP
>   infrastructure (e.g.  CGN).  To achieve this goal, a new "Couple"
>   operation using STUN message format is also defined.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20
>=20
>=20
>=20
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram


From nobody Mon Oct 27 17:16: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 1A89B1A8791 for ; Mon, 27 Oct 2014 17:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9f9IxtTOgdW for ; Mon, 27 Oct 2014 17:16:09 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2699E1A879A for ; Mon, 27 Oct 2014 17:16:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DF9EBDD0; Tue, 28 Oct 2014 00:16:08 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ5MW1mGYNR2; Tue, 28 Oct 2014 00:16:06 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.46.26.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A330CBE1D; Tue, 28 Oct 2014 00:16:06 +0000 (GMT)
Message-ID: <544EE046.5080101@cs.tcd.ie>
Date: Tue, 28 Oct 2014 00:16:06 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Spencer Dawkins 
References:  <544E938B.1030802@gmail.com>
In-Reply-To: <544E938B.1030802@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3CShOAqGqg9Vnin3OEQ5hHIoras
Cc: Adam Langley , Martin Stiemerling , Kathleen Moriarty , "tram@ietf.org" , tls-chairs@tools.ietf.org
Subject: Re: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 00:16:12 -0000

Hiya,

Brief response sorry. Yes, TLS1.3 aims to encrypt ALPN labels
as a deliberate specific goal. NPN (the pre-standards ALPN)
which is in use and is functionally the same, already does
this for TLS1.2, so even current deployments cannot assume
that such labels are clear as some may prefer to deploy with
NPN until TLS1.3.

Not sure we're in a position to write ALPN guidance as you'd
like right now, but were it just a paragraph like the above,
then we could. I'd ask Adam L. to write that though others
could be as good.

S.

On 27/10/14 18:48, Spencer Dawkins wrote:
> Hi, Stephen, the responsible AD for TLS WG,
> 
> I could be all wrong about this, but what I think is going on is ...
> 
> As part of IETF Last Call for draft-ietf-tram-alpn-06.txt, we got a
> thought-provoking comment from Adam Langley, objecting to an observation
> in the draft that STUN ALPN labels could be used by middleboxes to
> enforce policy, because doing so runs head on into chartered work in TLS
> to encrypt as much of the TLS handshake as possible.
> 
> In subsequent exchanges, Adam and the TRAM folk agreed that this is true
> for any ALPN label, not just for STUN ALPN labels.
> 
> The TRAM folk aren't comfortable adding discussions about this broader
> issue in a TRAM document. The most recent proposal was to remove the
> text that points out this possibility.
> 
> I'm thinking that removing the text that says it's possible to use STUN
> ALPN labels may not be the best response to Adam's comment (even in "The
> Wizard of Oz", the man behind the curtain saying, "pay no attention to
> the man behind the curtain" didn't change the fact that there's still a
> man behind the curtain).
> 
> Would a document about ALPN label abuse, regardless of the specific
> label, be appropriate for the TLS working group, if the TLS working
> group thought this question mattered enough to work on it?
> 
> I've slipped draft-ietf-tram-alpn from this week's telechat to 11/25, so
> we have time to talk about this question without bouncing a Discuss
> around, and people can talk at IETF 91 if that's helpful.
> 
> Thanks for any guidance you can provide.
> 
> Spencer, as shepherding AD for draft-ietf-tram-alpn
> 
> -------- Forwarded Message --------
> Subject:     Last Call:  (Application Layer
> Protocol Negotiation (ALPN) labels for Session Traversal Utilities for
> NAT (STUN) Usages) to Proposed Standard
> Date:     Wed, 8 Oct 2014 10:24:08 -0700
> From:     Adam Langley 
> To:     ietf@ietf.org
> 
> 
> 
> In the introduction of this document[1], the first example appears to
> endorse the idea that a firewall would inspect a TLS handshake and
> quash the communication if it saw an ALPN identifier that it didn't
> like.
> 
> If I'm not misunderstanding this example, then it's contradictory to
> the work that the TLS WG is chartered to do[2]:
> 
> "Develop a mode that encrypts as much of the handshake as is possible
> to reduce the amount of observable data to both passive and active
> attackers."
> 
> It would be disappointing if an RFC explicitly endorsed middleware
> that tries to parse high-level protocols and interferes with the
> network based on the result. There might not be much that we can do
> about it, but we don't have to condone it.
> 
> 
> Cheers
> 
> AGL
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-tram-alpn-06#section-1
> [2] https://datatracker.ietf.org/doc/charter-ietf-tls/
> 


From nobody Mon Oct 27 17:37:54 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 F0FAF1A0395 for ; Mon, 27 Oct 2014 17:37:52 -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 RZFJxk9vVS1z for ; Mon, 27 Oct 2014 17:37:51 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C3F1A0360 for ; Mon, 27 Oct 2014 17:37:51 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id f15so3134024lbj.37 for ; Mon, 27 Oct 2014 17:37: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 :cc:content-type; bh=LiiKfrpOm518uHts0/O1YjvQUa3um//z/0IxYBrQK8o=; b=Chaic7UiRz1/w4RtGNJwKWaFcxzL7zjd9JMwHenzM379JOkNrc1/0PkBrYeygtNlES MhfUpsGR2AvVapyXcfH+VG969AR+542w89/mW0HbL6CnuHaICW5v1KAncrzRGosVXiEp YgB6GxBBmLnOaA9UxGGMm10B9eh7INDSejMyzh3SupDIAjlzDqKHEsAmuIb08VNeVajd LvojlQkOj437aQ7nNIOFBnjOAFzfmntfje/UmH23GXdKMzHw6X0XdSeucaj7gQ99XFw2 mh2S1VR3pn0SvcNbh6qcD/Ts3v5PyxthNGkjdQpQUOAtEE6HJ4Y77azhkf+kdoSVa6+X 2KKQ==
MIME-Version: 1.0
X-Received: by 10.152.216.200 with SMTP id os8mr13390330lac.85.1414456669856;  Mon, 27 Oct 2014 17:37:49 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 17:37:49 -0700 (PDT)
In-Reply-To: <544EE046.5080101@cs.tcd.ie>
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>
Date: Mon, 27 Oct 2014 17:37:49 -0700
Message-ID: 
From: Martin Thomson 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/poeT2DlM63wKWGgJJ7Yx5EYHCvE
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Kathleen Moriarty , Spencer Dawkins , Adam Langley 
Subject: Re: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 00:37:53 -0000

On 27 October 2014 17:16, Stephen Farrell  wrote:
> Not sure we're in a position to write ALPN guidance as you'd
> like right now, but were it just a paragraph like the above,
> then we could. I'd ask Adam L. to write that though others
> could be as good.


I think that my review strongly suggested removal of that text.  I
generally concur with agl on this point.  There are potentially even
cases where the intermediary won't see the initial round of the
handshake, so there is no chance of even seeing what *might* be
negotiated (not that you should be basing any decision on this marking
anyway).

Basically, this hook might be in the clear, or it might not.  Don't
expect to hang anything heavy on it.


From nobody Mon Oct 27 18:54: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 566B81A026E for ; Mon, 27 Oct 2014 18:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.989
X-Spam-Level: 
X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_42=0.6] 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 YFypop-phqCR for ; Mon, 27 Oct 2014 18:54:49 -0700 (PDT)
Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id E207E1A0233 for ; Mon, 27 Oct 2014 18:54:48 -0700 (PDT)
Received: from ctbriwangaij (unknown [219.142.69.77]) by app1 (Coremail) with SMTP id Z0GX06CriACH5k5U8RFtAA==.60810S4; Tue, 28 Oct 2014 08:43:04 +0800 (CST)
From: "Aijun Wang" 
To: "'Oleg Moskalenko'" 
References: <00d901cff194$64471e70$2cd55b50$@org.cn> <0D6FC0A2-D36B-48A3-8EE7-E156B538C329@gmail.com>
In-Reply-To: <0D6FC0A2-D36B-48A3-8EE7-E156B538C329@gmail.com>
Date: Tue, 28 Oct 2014 09:54:25 +0800
Message-ID: <007901cff252$22a9ff00$67fdfd00$@org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac/yJxSVrpHJ/VszTquxCZ70R7n6+wAJiqkA
Content-Language: zh-cn
X-CM-TRANSID: Z0GX06CriACH5k5U8RFtAA==.60810S4
X-Coremail-Antispam: 1U3129KBjvJXoW3AF48GrWfAFWDKw45ZF15CFg_yoW7Xr1kpa y5Gayaka4kJr17C34UZa1xuFyrurZ3GrZrJFn8Gr1Uu3sIkF1Igr47tr15uFyDWrZ5Gr1a qF1j9F13uw15ArJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BDMQm06737Wa0Qm5IOji6Ot6DeQ
Cc: tram@ietf.org, "'Liubing \(Leo\)'" 
Subject: Re: [tram] FW: New Version Notification for draft-wang-tram-turnlite-01.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 01:54:51 -0000

Hi, Oleg:

Thanks for your comments. Below is my consideration for your concern points.

> -----Original Message-----
> From: Oleg Moskalenko [mailto:mom040267@gmail.com]
> Sent: Tuesday, October 28, 2014 5:56 AM
> To: Aijun Wang
> Cc: tram@ietf.org; Liubing (Leo)
> Subject: Re: [tram] FW: New Version Notification for
> draft-wang-tram-turnlite-01.txt
> 
> 
> On Oct 26, 2014, at 8:16 PM, Aijun Wang  wrote:
> 
> > Hi, All TRAMsters
> >
> > We have submitted one new draft that describes the lightweight TURN(we
> refer it as TURNLite later) architecture and the corresponding new STUN
> message introduced in this draft. With the TURNLite solution, CP/SP can
easily
> offload the complex and troublesome deployment of TURN servers to the
> service provider, the service provider can easily integrate the data relay
> function of TURNLite server into their current distributed deployed CGN
> devices.
> > This can be a win-win solution, and meets all the communication
scenarios
> that the current TURN solution intends to solve, but in a more simple
manner.
> 
> Actually, not all the communication scenarios of the "full" TURN can be
> achieved by the TURNLite.
> 
> The "full" TURN allows pretty high degree of the network hosts privacy. If
a
> host is using TLS/DTLS protocol for the TURN communications, then the
> network infrustructure devices are not able to determine the hosts's peer
> address. The peer information is stored (ephemerally) at the TURN server
and
> it may not be retrieved by the outside parties if the TURN server is
properly
> secured.
> 
> With the TURNLite, the communication between the parties is fully
controlled
> by the host's network infrastructure. That may be a desirable quality in
some
> limited circumstances (like in a strict corporate environment), but I am
not sure
> about the general case.

Actually, under the TURNLite solution, the communication between the parties
is fully controlled by the Application provider, not the service provider.
The service provider will only relay the packets under the instruction from
the Application provider, via the newly defined "Couple" message. The
"Couple" information is stored in also ephemerally in the CGN devices and
can be withdrawn at the requirement of the Application provider.

Considering the host privacy information, I think the most important thing
is that the service provider should not know the communication contents, not
the peer's address. If one would even want the service provider be blind to
the peer address, they can accomplish this by deploying their own "Full"
TURN server, just as you mentioned that "in some limited circumstances(like
in a strict corporate environment)", for example, the security department of
one corporation). For general host-to-host communication, the hide of peer
address is not one important factor.  

TURNLite solution supports also the TLS/DTLS protocol, the communication key
is exchanged directly between the peers. The service provider can't parse
the application layer contents between the two hosts, it just only relay the
TCP/UDP data, as that they do within the CGN devices.

Aijun

> 
> >
> > We are also eager to find other cooperators that are interested in this
topic.
> Any comments are valuable.
> >
> > Mr. Liubing has apply the timeslot to present this draft in the coming
IETF
> meeting in Holununu.
> >
> > Best Regards.
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Monday, October 27, 2014 10:07 AM
> > To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu
> > Subject: New Version Notification for draft-wang-tram-turnlite-01.txt
> >
> >
> > A new version of I-D, draft-wang-tram-turnlite-01.txt has been
successfully
> submitted by Bing Liu and posted to the IETF repository.
> >
> > Name:		draft-wang-tram-turnlite
> > Revision:	01
> > Title:		A Lightweight TURN Architecture and Specification
(TURNLite)
> > Document date:	2014-10-27
> > Group:		Individual Submission
> > Pages:		15
> > URL:
> http://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-01.txt
> > Status:
https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/
> > Htmlized:       http://tools.ietf.org/html/draft-wang-tram-turnlite-01
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-wang-tram-turnlite-01
> >
> > Abstract:
> >   This document proposes a lightweight TURN architecture which
> >   simplifies the application provider side complexity of implementing
> >   TURN server by transfering the data relay processing to the ISP
> >   infrastructure (e.g.  CGN).  To achieve this goal, a new "Couple"
> >   operation using STUN message format is also defined.
> >
> >
> >
> >
> > 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 Tue Oct 28 02:47: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 343F01A1AD9 for ; Tue, 28 Oct 2014 02:46:36 -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 aspu_PlYMIvH for ; Tue, 28 Oct 2014 02:46:34 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0271A1AB7 for ; Tue, 28 Oct 2014 02:46:34 -0700 (PDT)
Received: by mail-ob0-f177.google.com with SMTP id m8so202460obr.8 for ; Tue, 28 Oct 2014 02:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xqwftas3cOr0mQA5ABD0v3q5xKq05LpfQ2ynrJGbDBU=; b=L0PFfCSHDQoaLwc+3qRV9RXPOp4EGF2TlHMjSVKUjZxkQhtHEN7Oo73poYqjzxEHIM SqUHWY7a8/fc265CO1wkANIgl24mUbhwb40TAUsYHWliKjEtgGyWvhKJ9yWEv9XO55kn 39z/93MCBnRvp6yf1lKWfqImiuUysO8IYCQZKE41zWTYneqEghauDYY3ZCszZFFmYILx AnOjF37q+raMSz+CNJsNGswXQX+wQBBGBByOXhDeYCT9t1+qhIJe0DH9vvPYyomURXaR fixFvcwvrWosA2ImMwNViacTTVEvCHQ4uFYWisjSfAaFWS9CxcZXELnGDZEZzgfdU+Gu SEsA==
X-Received: by 10.202.75.202 with SMTP id y193mr1873056oia.56.1414489593082; Tue, 28 Oct 2014 02:46:33 -0700 (PDT)
Received: from ?IPv6:2605:6000:9004:ce00:88c:24f6:be8f:8d9? ([2605:6000:9004:ce00:88c:24f6:be8f:8d9]) by mx.google.com with ESMTPSA id w6sm436125obz.20.2014.10.28.02.46.30 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 02:46:31 -0700 (PDT)
Message-ID: <544F65F4.5080305@gmail.com>
Date: Tue, 28 Oct 2014 04:46:28 -0500
From: Spencer Dawkins 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Martin Thomson ,  Stephen Farrell 
References: 	<544E938B.1030802@gmail.com>	<544EE046.5080101@cs.tcd.ie> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pWiUKV0e_LutnMantL9H85IX0bQ
Cc: Adam Langley , Martin Stiemerling , Kathleen Moriarty , "tram@ietf.org" , tls chair 
Subject: Re: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 09:46:36 -0000

On 10/27/2014 07:37 PM, Martin Thomson wrote:
> On 27 October 2014 17:16, Stephen Farrell  wrote:
>> Not sure we're in a position to write ALPN guidance as you'd
>> like right now, but were it just a paragraph like the above,
>> then we could. I'd ask Adam L. to write that though others
>> could be as good.
>
> I think that my review strongly suggested removal of that text.  I
> generally concur with agl on this point.  There are potentially even
> cases where the intermediary won't see the initial round of the
> handshake, so there is no chance of even seeing what *might* be
> negotiated (not that you should be basing any decision on this marking
> anyway).
>
> Basically, this hook might be in the clear, or it might not.  Don't
> expect to hang anything heavy on it.

So, you guys are the experts on this. Please feel free to clue me in.

What I was getting from Adam's Last Call comment was that this was a 
futures thing in the TLS working group, and that when the TLS working 
group delivers and what they deliver gets deployed, middleboxes won't be 
able to make policy decisions on based on ALPN labels because they'll be 
encrypted, so remove the text about making policy decisions based on 
ALPN labels because that will stop working.

What I was asking, was whether there was any reason to point out that 
until the TLS working group delivers, this is a possibility.

The current text included this possibility as a feature, and I 
understood Adam to be objecting to that characterization.

What I'm getting from this exchange is that it's not necessary to point 
out this possibility in the TRAM document as bug, either, because the 
bug applies to all ALPN labels, not just this one.

So, delete the existing text and don't add anything.

Am I tracking the conversation?

Thanks,

Spencer


From nobody Tue Oct 28 07:25:38 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 74F4D1A897F for ; Tue, 28 Oct 2014 07:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4DXSWZtZc6g for ; Tue, 28 Oct 2014 07:25:32 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD171A896B for ; Tue, 28 Oct 2014 07:25:09 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id 10so708405lbg.15 for ; Tue, 28 Oct 2014 07:25:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z4TAl80ZlUXC14q62rLGRIEfJqwNeNNltukzelQGmz4=; b=MtDNSEPAps6NFh8+zLSLlYyganrnI4kc/xZDxBazpBzsOqP2NESY3O1qfy2/bMRRwC V233j68Cw/3lwz/IqIDlt1GX9yyC6cV10qs8XEGq2e/mSfc9q1JNiPGqFiOUsNWgRKtF sO0/lS6duAAGGZVvT/FGIYeF30vSKp3zFE3qfJM+7FoLZ6GgW+g5HTnUoGHc+jhZV1XJ Ke+MSp2s4/z0/rFdIdOqeDsMBs6//idPIwqDZE8iT5qoj+5odnNA7Xq3gZHILuN1ktNV +ywMXS4FnOB5SG2zYhMfZST3vnFxmEcJLGqLVo9a+vI1p/lfXKNqIvLtR7kabNcoTQlm ceng==
X-Gm-Message-State: ALoCoQmwPh30bfEzX7frhSK3Cv7Ld6fBErRUQZx/XG1a3f4ee6+BLyn7xzMihgL/nyVGS0VAonuv
MIME-Version: 1.0
X-Received: by 10.112.87.162 with SMTP id az2mr4343546lbb.15.1414506307973; Tue, 28 Oct 2014 07:25:07 -0700 (PDT)
Received: by 10.25.167.20 with HTTP; Tue, 28 Oct 2014 07:25:07 -0700 (PDT)
In-Reply-To: <544F65F4.5080305@gmail.com>
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>  <544F65F4.5080305@gmail.com>
Date: Tue, 28 Oct 2014 10:25:07 -0400
Message-ID: 
From: Simon Perreault 
To: Spencer Dawkins 
Content-Type: multipart/alternative; boundary=001a11347e0a050b3b05067c6a64
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7IY1R-BeVnIyExNCTalsw67RAy4
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Kathleen Moriarty , Adam Langley , Martin Thomson , Stephen Farrell 
Subject: Re: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 14:25:34 -0000

--001a11347e0a050b3b05067c6a64
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 28, 2014 at 5:46 AM, Spencer Dawkins <
spencerdawkins.ietf@gmail.com> wrote:

> What I was getting from Adam's Last Call comment was that this was a
> futures thing in the TLS working group, and that when the TLS working group
> delivers and what they deliver gets deployed, middleboxes won't be able to
> make policy decisions on based on ALPN labels because they'll be encrypted,
> so remove the text about making policy decisions based on ALPN labels
> because that will stop working.
>
> What I was asking, was whether there was any reason to point out that
> until the TLS working group delivers, this is a possibility.
>
> The current text included this possibility as a feature, and I understood
> Adam to be objecting to that characterization.
>
> What I'm getting from this exchange is that it's not necessary to point
> out this possibility in the TRAM document as bug, either, because the bug
> applies to all ALPN labels, not just this one.
>
> So, delete the existing text and don't add anything.
>
> Am I tracking the conversation?
>

Re-reading the draft again, if we delete those use cases, we are left
with... nothing. I don't see any use case for ALPN in STUN/TURN that does
not involve middleboxes. I don't see the point of STUN usage negotiation
since all usages speak the same protocol (STUN) and will be "negotiated"
implicitly later on, when a usage-specific message is emitted. So... why
are we doing this again?

Simon

--001a11347e0a050b3b05067c6a64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Tue, Oct 28, 2014 at 5:46 AM, Spencer Dawkins <spencerdawki=
ns.ietf@gmail.com> wrote:
<=
div id=3D":5r9" class=3D"a3s" style=3D"overflow:hidden">What I was getting =
from Adam's Last Call comment was that this was a futures thing in the =
TLS working group, and that when the TLS working group delivers and what th=
ey deliver gets deployed, middleboxes won't be able to make policy deci=
sions on based on ALPN labels because they'll be encrypted, so remove t=
he text about making policy decisions based on ALPN labels because that wil=
l stop working.



What I was asking, was whether there was any reason to point out that until=
 the TLS working group delivers, this is a possibility.



The current text included this possibility as a feature, and I understood A=
dam to be objecting to that characterization.



What I'm getting from this exchange is that it's not necessary to p=
oint out this possibility in the TRAM document as bug, either, because the =
bug applies to all ALPN labels, not just this one.



So, delete the existing text and don't add anything.



Am I tracking the conversation?

Re-reading the =
draft again, if we delete those use cases, we are left with... nothing. I d=
on't see any use case for ALPN in STUN/TURN that does not involve middl=
eboxes. I don't see the point of STUN usage negotiation since all usage=
s speak the same protocol (STUN) and will be "negotiated" implici=
tly later on, when a usage-specific message is emitted. So... why are we do=
ing this again?

Simon


--001a11347e0a050b3b05067c6a64--


From nobody Tue Oct 28 07:40:20 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 D0CF41A89AA for ; Tue, 28 Oct 2014 07:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsTzI1BtUUQO for ; Tue, 28 Oct 2014 07:40:16 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2691A8980 for ; Tue, 28 Oct 2014 07:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14024; q=dns/txt; s=iport; t=1414507216; x=1415716816; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7Aafe0Aw8NgXGjUDT8TzWO4mDiHpK+ZpB1Yo2mwP1eE=; b=RnpT5vqodOEYfjhtWuGtbD/A4NGBHT9dfYhyR/kE46Deso2vGzIfZjDa vE1fgEvlLkulV1v2X4eyjYBd4Rx55LW58BFdTvGoGq8bINq7QJ/kmKYN6 UF/M06/PMwQoWSbetAZE+1xExk5S69jdLKNNYYM1Ghm4jRKnu8TxJ/KVe Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai4GABeqT1StJA2F/2dsb2JhbABcgkhGVFgEgwLJSIFmAQuHSwIbgQAWAX2EAgEBAQQBAQEgCkEJAgwEAgEIDgMEAQELHQMCAgIlCxQIAQgCBA4FCAGIOA20TpUgAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXLQQGAQYDgm42gR4Fj2mCHoRIiEM8gw2KFYcfgjSBRGwBgUeBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,802,1406592000";  d="scan'208,217";a="367403247"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 28 Oct 2014 14:40:15 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9SEeFnH013604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 14:40:15 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 09:40:15 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: Simon Perreault 
Thread-Topic: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-selection-00.txt
Thread-Index: AQHP8d2U/VGnHz+5B0+2xcrz4yYRxJxD14GAgAB03oCAAUnOEA==
Date: Tue, 28 Oct 2014 14:40:14 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A28351037@xmb-rcd-x10.cisco.com>
References: <20141027120016.1947.18448.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.69.106]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A28351037xmbrcdx10ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sm9TkjIzkXFPpIWBpYAnaxZOIhI
Cc: "tram@ietf.org" 
Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-selection-00.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Oct 2014 14:40:19 -0000

--_000_913383AAA69FF945B8F946018B75898A28351037xmbrcdx10ciscoc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NClNlbnQ6
IE1vbmRheSwgT2N0b2JlciAyNywgMjAxNCA3OjI5IFBNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5
ICh0aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5l
dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2Vs
ZWN0aW9uLTAwLnR4dA0KDQpJbnRlcmVzdGluZyENCg0KUXVpY2sgcHJvY2VkdXJhbCBxdWVzdGlv
bjogVGhlIGludGVuZGVkIHN0YXR1cyBzYXlzIEluZm9ybWF0aW9uYWwsIGJ1dCB0aGUgdGV4dCB1
c2VzIFJGQzIxMTkga2V5d29yZHMuIElzIHRoaXMgYW4gb3ZlcnNpZ2h0Pw0KDQpbVFJdIFllcywg
d2lsbCBmaXggaW4gbmV4dCB1cGRhdGUuDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCi1UaXJ1DQoN
ClNpbW9uDQoNCk9uIE1vbiwgT2N0IDI3LCAyMDE0IGF0IDg6MDEgQU0sIFRpcnVtYWxlc3dhciBS
ZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNv
bT4+IHdyb3RlOg0KV2UndmUgcHVibGlzaGVkIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgVFVSTiBz
ZWxlY3Rpb24gY3JpdGVyaWEsIGFzIGd1aWRlbGluZXMsIHRoYXQgY2FuIGJlIHVzZWQgYnkgYSBj
bGllbnQgdG8gcGVyZm9ybSBhbiBpbmZvcm1lZCBUVVJOIHNlcnZlciBzZWxlY3Rpb24gZGVjaXNp
b24gd2hlbiBhIGNsaWVudCBkaXNjb3ZlcnMgbXVsdGlwbGUgVFVSTiBzZXJ2ZXJzLiAgQ29tbWVu
dHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpDaGVlcnMsDQotVGlydQ0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h
aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0KU2VudDogTW9uZGF5LCBP
Y3RvYmVyIDI3LCAyMDE0IDU6MzAgUE0NClRvOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsg
VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgR29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVp
KTsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3Vl
aSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v
dGlmaWNhdGlvbiBmb3IgZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwLnR4
dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1z
ZWxlY3Rpb24tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVt
YWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6
ICAgICAgICAgICBkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24NClJldmlzaW9u
OiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIFRyYXZlcnNhbCBVc2luZyBSZWxheXMgYXJvdW5k
IE5BVCAoVFVSTikgU2VydmVyIFNlbGVjdGlvbg0KRG9jdW1lbnQgZGF0ZTogIDIwMTQtMTAtMjYN
Ckdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA3
DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh
ZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAg
IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhdGlsLXRyYW0tdHVybi1z
ZXJ2LXNlbGVjdGlvbi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24tMDANCg0KDQpBYnN0cmFjdDoN
CiAgIEEgVFVSTiBjbGllbnQgbWF5IGRpc2NvdmVyIG11bHRpcGxlIFRVUk4gc2VydmVycy4gIElu
IHN1Y2ggYSBjYXNlLA0KICAgdGhlcmUgYXJlIG5vIGd1aWRlbGluZXMgdGhhdCBhIGNsaWVudCBj
YW4gZm9sbG93IHRvIGNob29zZSBvciBwcmVmZXINCiAgIGEgcGFydGljdWxhciBUVVJOIHNlcnZl
ciBhbW9uZyB0aG9zZSBkaXNjb3ZlcmVkLiAgVGhpcyBkb2N1bWVudA0KICAgZGV0YWlscyBzZWxl
Y3Rpb24gY3JpdGVyaWEsIGFzIGd1aWRlbGluZXMsIHRoYXQgY2FuIGJlIHVzZWQgYnkgYQ0KICAg
Y2xpZW50IHRvIHBlcmZvcm0gYW4gaW5mb3JtZWQgVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIGRlY2lz
aW9uLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p
bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz
aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xz
LmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGll
dGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby90cmFtDQoNCg==

--_000_913383AAA69FF945B8F946018B75898A28351037xmbrcdx10ciscoc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u
IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC
YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu
LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNpbW9uIFBlcnJlYXVsdCBb
bWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBP
Y3RvYmVyIDI3LCAyMDE0IDc6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRk
eSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1w
YXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24tMDAudHh0PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkludGVyZXN0aW5nITxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UXVpY2sgcHJvY2VkdXJhbCBxdWVz
dGlvbjogVGhlIGludGVuZGVkIHN0YXR1cyBzYXlzIEluZm9ybWF0aW9uYWwsIGJ1dCB0aGUgdGV4
dCB1c2VzIFJGQzIxMTkga2V5d29yZHMuIElzIHRoaXMgYW4gb3ZlcnNpZ2h0PzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFll
cywgd2lsbCBmaXggaW4gbmV4dCB1cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYW5kIFJlZ2FyZHMs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1vbjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAy
NywgMjAxNCBhdCA4OjAxIEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBo
cmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNp
c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+V2UndmUgcHVibGlzaGVkIGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgVFVSTiBzZWxlY3Rpb24g
Y3JpdGVyaWEsIGFzIGd1aWRlbGluZXMsIHRoYXQgY2FuIGJlIHVzZWQgYnkgYSBjbGllbnQgdG8g
cGVyZm9ybSBhbiBpbmZvcm1lZCBUVVJOIHNlcnZlciBzZWxlY3Rpb24gZGVjaXNpb24gd2hlbiBh
IGNsaWVudCBkaXNjb3ZlcnMgbXVsdGlwbGUgVFVSTiBzZXJ2ZXJzLiZuYnNwOyBDb21tZW50cyBh
bmQgc3VnZ2VzdGlvbnMgYXJlDQogd2VsY29tZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KLVRp
cnU8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhy
ZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRm
Lm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XTxicj4NClNlbnQ6IE1vbmRheSwgT2N0b2Jl
ciAyNywgMjAxNCA1OjMwIFBNPGJyPg0KVG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBU
aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkp
OyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgR29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVp
KTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9u
IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2VsZWN0aW9uLTAw
LnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wYXRpbC10
cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24tMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5
IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy
ZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDtkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb248YnI+DQpSZXZp
c2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRpdGxlOiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVHJhdmVyc2FsIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFU
IChUVVJOKSBTZXJ2ZXIgU2VsZWN0aW9uPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNC0x
MC0yNjxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZp
ZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyA3PGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBhdGls
LXRyYW0tdHVybi1zZXJ2LXNlbGVjdGlvbi0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6
Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBhdGlsLXRyYW0tdHVybi1zZXJ2
LXNlbGVjdGlvbi0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtc2Vs
ZWN0aW9uLzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo
cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vy
di1zZWxlY3Rpb24tMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1zZWxlY3Rpb24tMDA8L2E+PGJyPg0KPGJyPg0K
PGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO0EgVFVSTiBjbGllbnQgbWF5IGRpc2Nv
dmVyIG11bHRpcGxlIFRVUk4gc2VydmVycy4mbmJzcDsgSW4gc3VjaCBhIGNhc2UsPGJyPg0KJm5i
c3A7ICZuYnNwO3RoZXJlIGFyZSBubyBndWlkZWxpbmVzIHRoYXQgYSBjbGllbnQgY2FuIGZvbGxv
dyB0byBjaG9vc2Ugb3IgcHJlZmVyPGJyPg0KJm5ic3A7ICZuYnNwO2EgcGFydGljdWxhciBUVVJO
IHNlcnZlciBhbW9uZyB0aG9zZSBkaXNjb3ZlcmVkLiZuYnNwOyBUaGlzIGRvY3VtZW50PGJyPg0K
Jm5ic3A7ICZuYnNwO2RldGFpbHMgc2VsZWN0aW9uIGNyaXRlcmlhLCBhcyBndWlkZWxpbmVzLCB0
aGF0IGNhbiBiZSB1c2VkIGJ5IGE8YnI+DQombmJzcDsgJm5ic3A7Y2xpZW50IHRvIHBlcmZvcm0g
YW4gaW5mb3JtZWQgVFVSTiBzZXJ2ZXIgc2VsZWN0aW9uIGRlY2lzaW9uLjxicj4NCjxicj4NCjxi
cj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg
bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl
cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRo
ZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9
Im1haWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_913383AAA69FF945B8F946018B75898A28351037xmbrcdx10ciscoc_--


From nobody Tue Oct 28 17:25:45 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 0D9991A1BB3 for ; Tue, 28 Oct 2014 17:25:44 -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 xVJ9BYWpZgoX for ; Tue, 28 Oct 2014 17:25:42 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F1A1A1BAD for ; Tue, 28 Oct 2014 17:25:42 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id z12so1621836lbi.11 for ; Tue, 28 Oct 2014 17:25:40 -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=tYWaPm07aVMbqKLDdcmcgHq7E3h2Wdf/70XVAQhj9kk=; b=wWTze7xxtmjvFXxUu1Qv+sQawFFc7TZM9gjjFL7TUsE9dLPHguj7CUZH907rkb2aMJ 0qJcB1xD6kcmbzspR+Jv5v0gWA//2e1BG5GFDC+q0+kzZNmjewn2Ky71Ls7fXEnQdw71 cwmjN19MXm28sd0iJk0134iEjwzc8+FWoaVdkhKsZZTekPr0wpYbWSzz7Dw4Iyu0SoDg 3S5P8GRWhQXAeqEREcw8NPGo58mwk745gBUWz+bbE6HpA1XEpjBcJW2jad6vX7k9Eni4 ON8y9VpgZ7VdB2Ii3j7OJOTAc2EX5iQE7kCgSsj7JwEPA6dchn9tvm+2WtQgnSmYgMqW GmLA==
MIME-Version: 1.0
X-Received: by 10.152.120.133 with SMTP id lc5mr7695604lab.62.1414542340407; Tue, 28 Oct 2014 17:25:40 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Tue, 28 Oct 2014 17:25:40 -0700 (PDT)
In-Reply-To: 
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>  <544F65F4.5080305@gmail.com> 
Date: Tue, 28 Oct 2014 17:25:40 -0700
Message-ID: 
From: Martin Thomson 
To: Simon Perreault 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2kGzRO1AkoZDBf6wW4yutnz57oU
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Kathleen Moriarty , Spencer Dawkins , Adam Langley , Stephen Farrell 
Subject: Re: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 00:25:44 -0000

On 28 October 2014 07:25, Simon Perreault  wrote:
> Re-reading the draft again, if we delete those use cases, we are left
> with... nothing. I don't see any use case for ALPN in STUN/TURN that does
> not involve middleboxes. I don't see the point of STUN usage negotiation
> since all usages speak the same protocol (STUN) and will be "negotiated"
> implicitly later on, when a usage-specific message is emitted. So... why are
> we doing this again?

What ALPN does is provide an unambiguous identification of the
intended protocol.  That allows for use of multiple protocols (TURN v2
perhaps!) on the same port.  The uses for HTTP and WebRTC do this
already.  Maybe it's not important for TURN.

If you are concerned about this, perhaps the working group might be
consulted.  I'll confess, I always sort of assumed that you knew what
you were doing here, so I didn't think much on the issue.


From nobody Tue Oct 28 19:08:17 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 41F1F1A3BA3 for ; Tue, 28 Oct 2014 19:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAubD1rFw8ol for ; Tue, 28 Oct 2014 19:08:13 -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 380291A3B9E for ; Tue, 28 Oct 2014 19:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2044; q=dns/txt; s=iport; t=1414548493; x=1415758093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sViHENUxUu2I9ybSptTY0WtxsWwEbU2fjXqM+2vCMZE=; b=MXekxOUMhHyc7j9OgHBbJiaD/JPoo3hQ0G0GGXAbFDKOM37n5Y9EVhsF bIKHJ6vBoKZf7LiXa0ZLllShJ2mczZ173zQ3pPjHf72SH1escY+v24cf6 jZPKvPZToeEALY0DFNggMODAipfLdPdff3JB2cDM8RfmHhbJsGpz+K7mk U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAJ9KUFStJV2R/2dsb2JhbABcgw5UWATOPAqHTQKBHhYBAQEBAX2EAgEBAQMBAQEBNzQLBQsCAQgYHgULIQYLJQIEDgWILAMJCQ2+VQ2GOAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjk+CBzMHgy2BHgWSC4lMghGPVYZhgjSBRGyBSIEDAQEB
X-IronPort-AV: E=Sophos; i="5.04,807,1406592000"; d="scan'208,223"; a="91229859"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP; 29 Oct 2014 02:08:12 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9T28Ce4014205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 02:08:12 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 21:08:12 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: Martin Thomson 
Thread-Topic: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
Thread-Index: AQHP8x0wG4sgGUnN9EK1WgJnrhBlxg==
Date: Wed, 29 Oct 2014 02:08:11 +0000
Message-ID: 
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>  <544F65F4.5080305@gmail.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.231.239]
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/XR6VHtWnGWZt1u-efmIzYxYqMlM
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Simon Perreault , Kathleen Moriarty , Spencer Dawkins , Adam Langley , Stephen Farrell 
Subject: Re: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 02:08:16 -0000

>From the authors' perspective I think we have what we need to produce the n=
ext version of the document that satisfies the recently raised concerns reg=
arding the sample use cases.  We will trim this purely informational text a=
s it is not in line with forward-looking end-to-end security best practices=
 as we have no desire to propagate misconceptions or unsound approaches, no=
 matter if it is non-normative text or not. I think we also all agree that =
this document is nothing more than the registration of a new label and not =
the place to expound on those more generally applicable best practices for =
ALPN. We're confident that the text removal will result in no loss of infor=
mation with respect to what we are standardizing in this draft.

Does this sound like a reasonable way forward?


Cheers,

Gonzalo



> On Oct 28, 2014, at 8:25 PM, Martin Thomson  wr=
ote:
>=20
> On 28 October 2014 07:25, Simon Perreault  wrote:
>> Re-reading the draft again, if we delete those use cases, we are left
>> with... nothing. I don't see any use case for ALPN in STUN/TURN that doe=
s
>> not involve middleboxes. I don't see the point of STUN usage negotiation
>> since all usages speak the same protocol (STUN) and will be "negotiated"
>> implicitly later on, when a usage-specific message is emitted. So... why=
 are
>> we doing this again?
>=20
> What ALPN does is provide an unambiguous identification of the
> intended protocol.  That allows for use of multiple protocols (TURN v2
> perhaps!) on the same port.  The uses for HTTP and WebRTC do this
> already.  Maybe it's not important for TURN.
>=20
> If you are concerned about this, perhaps the working group might be
> consulted.  I'll confess, I always sort of assumed that you knew what
> you were doing here, so I didn't think much on the issue.
>=20
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram


From nobody Tue Oct 28 23:21: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 3A87A1A03B3 for ; Tue, 28 Oct 2014 23:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNl4hu13CN6a for ; Tue, 28 Oct 2014 23:21:41 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC2E1A036E for ; Tue, 28 Oct 2014 23:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1429; q=dns/txt; s=iport; t=1414563701; x=1415773301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gzKskgFcPRxQAtOwEsUdQffjLfhzzB7LK0iTwjhABiY=; b=VJml/QcOfuk1l6HZ1VOAfq7gGs0HSq7vshzykgNGst1Qe+zrdbrkNKOv UsqXmgFTqzSiV/smW8OA6T7nC407ZS2+tcI72d/R/rkH9HyTPaBj1+gNw ZZqI2p5A8Nlk/jQa5FLUDOc645VApzAcKl+AJWFA6rHqKObz14TV/Usr0 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAKOGUFStJA2J/2dsb2JhbABcgw5UWATORAqHTQKBFhYBAQEBAX2EAgEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FiDgJDcR6AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQVjMHgy2BHgWSC4tdgTGDSZE+g3hsgUiBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,808,1406592000"; d="scan'208";a="367642895"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 29 Oct 2014 06:21:41 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9T6Le82031641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 06:21:41 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 01:21:40 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: Brandon Williams 
Thread-Topic: [tram] STUN-bis adoption call
Thread-Index: AQHP74kufYDRCH373E+puywBXxVRcZw/oHuAgADWqACAA9+zAIACnxuA
Date: Wed, 29 Oct 2014 06:21:39 +0000
Message-ID: 
References:  <544A6085.70707@akamai.com> <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com> <544E547C.20903@akamai.com>
In-Reply-To: <544E547C.20903@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.231.239]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8EDA812B63D4FF43B971A87820AB0367@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/TxFJb9KwE0jblKQRFIiNNtIYM8o
Cc: "tram@ietf.org" 
Subject: Re: [tram] STUN-bis adoption call
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, 29 Oct 2014 06:21:43 -0000

Brandon -=20

You raise a valid point that bears some clarification.  For the purposes of=
 WG adoption, let's focus on agreeing to the list of items we want to tackl=
e.  Once we have a WG draft, we can iterate on the actual text to ensure we=
 have text that is representative of WG consensus.

Cheers,

Gonzalo



> On Oct 27, 2014, at 10:19 AM, Brandon Williams  wrote:
>=20
> On 10/24/2014 11:10 PM, Tirumaleswar Reddy (tireddy) wrote:
>>> Regarding fragmentation (item 5) ... I don't see any substantive change=
s. I
>>> >don't see anything about this in appendix B.2, so I don't think I'm mi=
ssing
>>> >anything.
>> There were discussions about fragmentation support in the list sometime =
back but without any conclusions.
>> Please provide more details.
>>=20
>=20
> My primary point is that improved guidance on fragmentation and message s=
izes is one of the things on the list of open items and it doesn't appear t=
hat any changes have been made yet. I mostly wanted to confirm that there i=
sn't something about this already in the document that I'm not seeing.
>=20
> --Brandon
>=20
> --=20
> Brandon Williams; Senior Principal Software Engineer
> Emerging Products Engineering; Akamai Technologies Inc.
>=20
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram


From nobody Tue Oct 28 23:37: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 AE2F61A1AF5 for ; Tue, 28 Oct 2014 23:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhSeELnCmOkI for ; Tue, 28 Oct 2014 23:37:05 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A385D1A1A1C for ; Tue, 28 Oct 2014 23:37:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2962; q=dns/txt; s=iport; t=1414564625; x=1415774225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GKFzpCk94Qcst0ng+cETQeq2imSr18nBTewSzwBx7FE=; b=OMjCxXiDh42ZfoGAsYSU4cGOEbqdTpN761gKg5V1OAvNnfEOkXAnkgEA m4ThYpxLJE1gV03AQQ+dPnY1Q4G7AqgftA0kuV0WGW3s3w7Pj3G53hcTX 786peCgp0lEOJMjfhLgPxjl8ByzvU4KHOOo93Huq3fE+JM7qbQQ4vJrXj w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFACmKUFStJV2U/2dsb2JhbABcgw5UWATORAyHSwKBFhYBAQEBAX2EAgEBAQMBAQEBNzQJAgUHBAIBCA4DBAEBAR4JBycLFAkIAgQOBQmILwkNxQABAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFYzBwaDJ4EeBZILhEqHE4ExPIMNkT6CNIFEbAGBR4EDAQEB
X-IronPort-AV: E=Sophos;i="5.04,808,1406592000"; d="scan'208";a="367455249"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 29 Oct 2014 06:37:04 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9T6b4YM021957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 06:37:04 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 01:37:04 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: Simon Perreault 
Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-selection-00.txt
Thread-Index: AQHP80LACmxg4CcK0U2+t3iK6zzbJg==
Date: Wed, 29 Oct 2014 06:37:03 +0000
Message-ID: <75C3DAD3-F797-4732-8BC1-C89D42AA493C@cisco.com>
References: <20141027120016.1947.18448.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.231.239]
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/3nL5Rope3niQ94TGQLNoIUMd5PE
Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" 
Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-selection-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, 29 Oct 2014 06:37:07 -0000

> On Oct 27, 2014, at 9:58 AM, Simon Perreault  wrote:
>=20
> Interesting!
>=20
> Quick procedural question: The intended status says Informational, but th=
e text uses RFC2119 keywords. Is this an oversight?

There are many Informational documents that use 2119 language, so they aren=
't be mutually exclusive.   That said, it is meant to be purely as a BCP-st=
yle Informational document.  Whether or not usage of 2119 language is utili=
zed can be determined if we move forward with the document.

Cheers,

Gonzalo


> Simon
>=20
> On Mon, Oct 27, 2014 at 8:01 AM, Tirumaleswar Reddy (tireddy)  wrote:
> We've published a draft that describes TURN selection criteria, as guidel=
ines, that can be used by a client to perform an informed TURN server selec=
tion decision when a client discovers multiple TURN servers.  Comments and =
suggestions are welcome.
>=20
> Cheers,
> -Tiru
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, October 27, 2014 5:30 PM
> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Gonzalo Sal=
gueiro (gsalguei); Prashanth Patil (praspati); Gonzalo Salgueiro (gsalguei)=
; Tirumaleswar Reddy (tireddy)
> Subject: New Version Notification for draft-patil-tram-turn-serv-selectio=
n-00.txt
>=20
>=20
> A new version of I-D, draft-patil-tram-turn-serv-selection-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the I=
ETF repository.
>=20
> Name:           draft-patil-tram-turn-serv-selection
> Revision:       00
> Title:          Traversal Using Relays around NAT (TURN) Server Selection
> Document date:  2014-10-26
> Group:          Individual Submission
> Pages:          7
> URL:            http://www.ietf.org/internet-drafts/draft-patil-tram-turn=
-serv-selection-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-patil-tram-turn-se=
rv-selection/
> Htmlized:       http://tools.ietf.org/html/draft-patil-tram-turn-serv-sel=
ection-00
>=20
>=20
> Abstract:
>    A TURN client may discover multiple TURN servers.  In such a case,
>    there are no guidelines that a client can follow to choose or prefer
>    a particular TURN server among those discovered.  This document
>    details selection criteria, as guidelines, that can be used by a
>    client to perform an informed TURN server selection decision.
>=20
>=20
>=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
> The IETF Secretariat
>=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 Wed Oct 29 06:15:21 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 D501E1A00B0 for ; Wed, 29 Oct 2014 06:15:17 -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 NV_Q7dtm5yxq for ; Wed, 29 Oct 2014 06:15:12 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3DF1A009E for ; Wed, 29 Oct 2014 06:15:12 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id wp18so2335627obc.30 for ; Wed, 29 Oct 2014 06:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=rBALZuYqAyulbt2sM3Pl6FgrHcqnZgso8oyGjAKVZfA=; b=A0u+h/XdLS5Tedd++pme9/XvX1xRGSbWVhuxySyHiL7O4R+tAq3yBsjO0atjbxy4/h V4wkqSfB7BhBEB5FEV/tVhN4YyILYCpxeEXQcR1hkZjPgm9lJqigMk8Pl2583LN751v0 DzXlhaH6NIkU1B7C44NeVPfcLGyzWG6znLijvc3N1hDftGXv6DIUr1VhJIe1gi4VeGnj Swd62luiRIPbmTramilU29MNmKBcdHkwAD3nGN3HixPhA1WcqW6xOQpKdoiRLWYT6WWO z5va/7lfKSayhReDB++lyV8kptreU4ewO2QYuefT+T1V/NOM09dUXsc0mUXRwcJtGjfB yzmw==
X-Received: by 10.182.79.104 with SMTP id i8mr1768737obx.58.1414588511312; Wed, 29 Oct 2014 06:15:11 -0700 (PDT)
Received: from ?IPv6:2605:6000:9004:ce00:68e6:7992:7410:65f4? ([2605:6000:9004:ce00:68e6:7992:7410:65f4]) by mx.google.com with ESMTPSA id w82sm1805750oiw.27.2014.10.29.06.15.07 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 06:15:09 -0700 (PDT)
Message-ID: <5450E850.9080609@gmail.com>
Date: Wed, 29 Oct 2014 08:14:56 -0500
From: Spencer Dawkins 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Gonzalo Salgueiro (gsalguei)" ,  Martin Thomson 
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>  <544F65F4.5080305@gmail.com>   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010800010909000803000808"
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WA09NImdy25r1i6y9eO3TFJ2gdU
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Simon Perreault , Kathleen Moriarty , Adam Langley , Stephen Farrell 
Subject: Re: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:15:18 -0000

This is a multi-part message in MIME format.
--------------010800010909000803000808
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


On 10/28/2014 09:08 PM, Gonzalo Salgueiro (gsalguei) wrote:
>  From the authors' perspective I think we have what we need to produce the next version of the document that satisfies the recently raised concerns regarding the sample use cases.  We will trim this purely informational text as it is not in line with forward-looking end-to-end security best practices as we have no desire to propagate misconceptions or unsound approaches, no matter if it is non-normative text or not. I think we also all agree that this document is nothing more than the registration of a new label and not the place to expound on those more generally applicable best practices for ALPN. We're confident that the text removal will result in no loss of information with respect to what we are standardizing in this draft.
>
> Does this sound like a reasonable way forward?

I'm still listening, if other people have input, but that's where I 
think we are now.

And I agree that a TRAM document is not the right place to talk about 
ALPN labels in a general way - that was why I asked for guidance from 
the TLS folks.

If you know what the draft should say (and not say), please feel free to 
send the revision to be posted to ietf-action@ietf.orgcc: me, requesting 
manual posting, and I'll approve it and leave it on the next telechat 
agenda (where it is currently).

Otherwise, the automated submission tool will start working again on 
2014-11-10.

And thank you all for your help with this.

Spencer

> Cheers,
>
> Gonzalo
>
>
>
>> On Oct 28, 2014, at 8:25 PM, Martin Thomson  wrote:
>>
>> On 28 October 2014 07:25, Simon Perreault  wrote:
>>> Re-reading the draft again, if we delete those use cases, we are left
>>> with... nothing. I don't see any use case for ALPN in STUN/TURN that does
>>> not involve middleboxes. I don't see the point of STUN usage negotiation
>>> since all usages speak the same protocol (STUN) and will be "negotiated"
>>> implicitly later on, when a usage-specific message is emitted. So... why are
>>> we doing this again?
>> What ALPN does is provide an unambiguous identification of the
>> intended protocol.  That allows for use of multiple protocols (TURN v2
>> perhaps!) on the same port.  The uses for HTTP and WebRTC do this
>> already.  Maybe it's not important for TURN.
>>
>> If you are concerned about this, perhaps the working group might be
>> consulted.  I'll confess, I always sort of assumed that you knew what
>> you were doing here, so I didn't think much on the issue.
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram


--------------010800010909000803000808
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 10/28/2014 09:08 PM, Gonzalo
      Salgueiro (gsalguei) wrote:

    

    

      
From the authors' perspective I think we have what we need to produce the next version of the document that satisfies the recently raised concerns regarding the sample use cases.  We will trim this purely informational text as it is not in line with forward-looking end-to-end security best practices as we have no desire to propagate misconceptions or unsound approaches, no matter if it is non-normative text or not. I think we also all agree that this document is nothing more than the registration of a new label and not the place to expound on those more generally applicable best practices for ALPN. We're confident that the text removal will result in no loss of information with respect to what we are standardizing in this draft.

Does this sound like a reasonable way forward?

    

    

    I'm still listening, if other people have input, but that's where I
    think we are now.

    

    And I agree that a TRAM document is not the right place to talk
    about ALPN labels in a general way - that was why I asked for
    guidance from the TLS folks. 

    

    If you know what the draft should say (and not say), please feel
    free to send the revision to be posted to ietf-action@ietf.org
    cc: me, requesting manual posting, and I'll approve it and leave it
    on the next telechat agenda (where it is currently).

    

    Otherwise, the automated submission tool will start working again on
    2014-11-10.

    

    And thank you all for your help with this.

    

    Spencer

    

    

      
Cheers,

Gonzalo





      

        
On Oct 28, 2014, at 8:25 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

On 28 October 2014 07:25, Simon Perreault <sperreault@jive.com> wrote:


        

          
Re-reading the draft again, if we delete those use cases, we are left
with... nothing. I don't see any use case for ALPN in STUN/TURN that does
not involve middleboxes. I don't see the point of STUN usage negotiation
since all usages speak the same protocol (STUN) and will be "negotiated"
implicitly later on, when a usage-specific message is emitted. So... why are
we doing this again?


        

        
What ALPN does is provide an unambiguous identification of the
intended protocol.  That allows for use of multiple protocols (TURN v2
perhaps!) on the same port.  The uses for HTTP and WebRTC do this
already.  Maybe it's not important for TURN.

If you are concerned about this, perhaps the working group might be
consulted.  I'll confess, I always sort of assumed that you knew what
you were doing here, so I didn't think much on the issue.

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


      

      

    

    

  


--------------010800010909000803000808--


From nobody Wed Oct 29 06:30:35 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 365591A00D4 for ; Wed, 29 Oct 2014 06:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJlan-A3JQ13 for ; Wed, 29 Oct 2014 06:30:34 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47421A00C6 for ; Wed, 29 Oct 2014 06:30:33 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id n15so2483833lbi.17 for ; Wed, 29 Oct 2014 06:30:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aUnONQKJYR3sDWim+uuaIfg2wagrxeLFqrP9N/2O3V8=; b=HruL6zbQCu0nKzI9taTntDnibXvStEG+PaWmuBGvOFmLjOGlA7YQcBNsEfPDsD7Xu7 Qxe4E6HmsQQCL8aJUzzZX6Dg3HRogIOsmwxcGUJAGajcZxnzXhQymvzrSpnBdfn/bUfS u9dPM0tNK9TcZ34t5Q+kb1eQODltMgmEvh/u4Jftk0iTyRN+0ipTlRjPec6eJYZ+pXEb oPEEDIXJDU5ZdxkKPbH19t5dH6qV7m4Lxw2t0vtEliNWjzalB2BY/71SaqMzYf/EN1o8 VlAmj5Sms7fDRgCKl64q9E/IuSSOWgzMowO6qKK5ZuFc823W9sjML3bvIdTUg2R5/UlJ yydw==
X-Gm-Message-State: ALoCoQlZESnYvA1fEqewBOaFieHqBDl6fzA91zIeeCOD8DpVvX/5xbh34aicUwXOoSlwHEXwTLpF
MIME-Version: 1.0
X-Received: by 10.152.10.99 with SMTP id h3mr3254185lab.94.1414589430956; Wed, 29 Oct 2014 06:30:30 -0700 (PDT)
Received: by 10.25.167.20 with HTTP; Wed, 29 Oct 2014 06:30:30 -0700 (PDT)
In-Reply-To: 
References:  <544A6085.70707@akamai.com> <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com> <544E547C.20903@akamai.com> 
Date: Wed, 29 Oct 2014 09:30:30 -0400
Message-ID: 
From: Simon Perreault 
To: "Gonzalo Salgueiro (gsalguei)" 
Content-Type: multipart/alternative; boundary=001a1132f26a89198205068fc489
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hCpep1dBknDoKpCeqbJcSbOR8Ao
Cc: "tram@ietf.org" , Brandon Williams 
Subject: Re: [tram] STUN-bis adoption call
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, 29 Oct 2014 13:30:35 -0000

--001a1132f26a89198205068fc489
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 29, 2014 at 2:21 AM, Gonzalo Salgueiro (gsalguei) <
gsalguei@cisco.com> wrote:

> You raise a valid point that bears some clarification.  For the purposes
> of WG adoption, let's focus on agreeing to the list of items we want to
> tackle.  Once we have a WG draft, we can iterate on the actual text to
> ensure we have text that is representative of WG consensus.


Correct. A working group may decide to adopt a draft with conditions, e.g.,
"adopt on condition that such and such issue be resolved in such and such
manner in the next revision".

Simon

--001a1132f26a89198205068fc489
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Oct 29, 2014 at 2:21 AM, Gonzalo Salgueiro (gsalguei) <gsalguei@c=
isco.com> wrote:
You rais=
e a valid point that bears some clarification.=C2=A0 For the purposes of WG=
 adoption, let's focus on agreeing to the list of items we want to tack=
le.=C2=A0 Once we have a WG draft, we can iterate on the actual text to ens=
ure we have text that is representative of WG consensus.
=

Correct. A working group may decide to adopt a draft with conditions, e=
.g., "adopt on condition that such and such issue be resolved in such =
and such manner in the next revision".

Simon


--001a1132f26a89198205068fc489--


From nobody Wed Oct 29 06:35: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 99F771A00C6 for ; Wed, 29 Oct 2014 06:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_mUYynnmNDg for ; Wed, 29 Oct 2014 06:35:04 -0700 (PDT)
Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B891A00B0 for ; Wed, 29 Oct 2014 06:35:03 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id gd6so1327200lab.6 for ; Wed, 29 Oct 2014 06:35:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+eY0sB3Yqiqt8CM4ixRsUhQYeAtU3XGN35sZbIT7Hl4=; b=Oq1TzzUm+zJAPr0yhezXL6YQans1tWR6gOCsxvI2RjHOWgt1wQxobFYdmCBk5jccil oFOGhl8GcNCT6k9mhw8vSfuH4oCkOJR0HaMxFnLu7dlZz5DIdUTn7pyzAgpvaoVRKI7e SKbFS6mYd4llMdOdanRC+A9Ji9dfv8T0mzRXxzDZ7sK+VXxte3uBuMw85BeG3v/PHHMG wbKNReQXVdkA5AP43RV0LJck5TjkuZMOpJzu2N5ZLcjYu0b6+XJrSGpm1XMTr+4iy5/J 8j/QVQat4kdv1qOQBZt8i8zdUnP7azCPV6Jeb5CRi5bqRRm7hKtO3nZGVgVNRZ/O9qEa z+aw==
X-Gm-Message-State: ALoCoQlInwRzRtrp0Gp0IK2u6axaDTyW9rTFlh0EunfCHkSHDBvSelBSh4R7es0qLpwssP5P2sYY
MIME-Version: 1.0
X-Received: by 10.112.87.162 with SMTP id az2mr11295494lbb.15.1414589701897; Wed, 29 Oct 2014 06:35:01 -0700 (PDT)
Received: by 10.25.167.20 with HTTP; Wed, 29 Oct 2014 06:35:01 -0700 (PDT)
In-Reply-To: <75C3DAD3-F797-4732-8BC1-C89D42AA493C@cisco.com>
References: <20141027120016.1947.18448.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com>  <75C3DAD3-F797-4732-8BC1-C89D42AA493C@cisco.com>
Date: Wed, 29 Oct 2014 09:35:01 -0400
Message-ID: 
From: Simon Perreault 
To: "Gonzalo Salgueiro (gsalguei)" 
Content-Type: multipart/alternative; boundary=001a11347e0aaf595805068fd431
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/khQ8ZTSlN1I9gyV2fwjyJkO37C8
Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" 
Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-selection-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, 29 Oct 2014 13:35:06 -0000

--001a11347e0aaf595805068fd431
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 29, 2014 at 2:37 AM, Gonzalo Salgueiro (gsalguei) <
gsalguei@cisco.com> wrote:

> > Quick procedural question: The intended status says Informational, but
> the text uses RFC2119 keywords. Is this an oversight?
>
> There are many Informational documents that use 2119 language, so they
> aren't be mutually exclusive.


Correct.


>  That said, it is meant to be purely as a BCP-style Informational
> document.  Whether or not usage of 2119 language is utilized can be
> determined if we move forward with the document.


Understood. Although with its current content, which is fairly
prescriptive, I think that draft would warrant a Proposed Standard intended
status.

Simon

--001a11347e0aaf595805068fd431
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Oct 29, 2014 at 2:37 AM, Gonzalo Salgueiro (gsalguei) <gsalguei@c=
isco.com> wrote:
> Quick procedural question: The intended status says Informati=
onal, but the text uses RFC2119 keywords. Is this an oversight?



There are many Informational documents that use 2119 language, so th=
ey aren't be mutually exclusive.=C2=A0

=
Correct.
=C2=A0
 =C2=A0That s=
aid, it is meant to be purely as a BCP-style Informational document.=C2=A0 =
Whether or not usage of 2119 language is utilized can be determined if we m=
ove forward with the document.

Understood. Although w=
ith its current content, which is fairly prescriptive, I think that draft w=
ould warrant a Proposed Standard intended status.

Simon


--001a11347e0aaf595805068fd431--


From nobody Wed Oct 29 06:56:37 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 DBB241A0102 for ; Wed, 29 Oct 2014 06:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm7_Vfq6BE9W for ; Wed, 29 Oct 2014 06:56:31 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727491A00C5 for ; Wed, 29 Oct 2014 06:56:31 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id z11so517402lbi.7 for ; Wed, 29 Oct 2014 06:56:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2IY53gTTYkXydYki3LEM2lKY7ScZa6unQniOSubr6No=; b=i8ervG4Q3Jr/53fThb5Mu0Kb5DVvXl1ix4mqw+yThs2j9ZdFOS3ZkMdndKNmhBFwez MDxptFVT8xD1U5Bd6/bIKtBcFRSWIMz32lbPtXnB8Had3XJX20Ut/4HcQ6K+jJX8xw6M b8vT3jdIgeE+hr3YMcIhEd2PQXSu1nyUtTpQqI0VVmhYJqOYj/9E7iHOy5ZqHbSVkmfH zHl3rp0BO6eqLC8N+dapAYRumVk9oJF6nTz4kSArgt/DDSKs60PC+t2dvLfZx4BndUq2 8TjeEwJvVgaxhiheh7Nm0XQhAVKNxCRa11lPVJ5CSVMKWJQbzprSU2u/DX9scNLXjyxY tf6Q==
X-Gm-Message-State: ALoCoQnGVnh0dUIBgPVWty0D60636ZmBxDAF6EUpPx2XkUeZ0mAxQe17DmqOmNEPJcU0+JewHla5
MIME-Version: 1.0
X-Received: by 10.152.22.74 with SMTP id b10mr11607599laf.16.1414590989272; Wed, 29 Oct 2014 06:56:29 -0700 (PDT)
Received: by 10.25.167.20 with HTTP; Wed, 29 Oct 2014 06:56:29 -0700 (PDT)
In-Reply-To: 
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>  <544F65F4.5080305@gmail.com>  
Date: Wed, 29 Oct 2014 09:56:29 -0400
Message-ID: 
From: Simon Perreault 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=089e0158b55c6b248a050690217f
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Df3QAYxVXARyHpwv5o2s_2WLC0g
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Kathleen Moriarty , Spencer Dawkins , Adam Langley , Stephen Farrell 
Subject: Re: [tram] Fwd: Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 13:56:34 -0000

--089e0158b55c6b248a050690217f
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 28, 2014 at 8:25 PM, Martin Thomson 
wrote:

> On 28 October 2014 07:25, Simon Perreault  wrote:
> > Re-reading the draft again, if we delete those use cases, we are left
> > with... nothing. I don't see any use case for ALPN in STUN/TURN that does
> > not involve middleboxes. I don't see the point of STUN usage negotiation
> > since all usages speak the same protocol (STUN) and will be "negotiated"
> > implicitly later on, when a usage-specific message is emitted. So... why
> are
> > we doing this again?
>
> What ALPN does is provide an unambiguous identification of the
> intended protocol.  That allows for use of multiple protocols (TURN v2
> perhaps!) on the same port.  The uses for HTTP and WebRTC do this
> already.  Maybe it's not important for TURN.
>
> If you are concerned about this, perhaps the working group might be
> consulted.


Well, "concerned" is not the right term. I'm sure we're not breaking
anything and, further, we're very probably doing the right thing. I'm just
genuinely curious what immediate use cases there could be for this. The
ones I know are, shall we say, not politically correct: 1) middleboxes, and
2) "run everything on port 443".


> I'll confess, I always sort of assumed that you knew what
> you were doing here, so I didn't think much on the issue.


I'm guilty of this too. "Oh, right, ALPN for STUN/TURN, makes total sense."

Simon

--089e0158b55c6b248a050690217f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Tue, Oct 28, 2014 at 8:25 PM, Martin Thomson <martin.thomson@gma=
il.com> wrote:
On 28 October 2014 07:25, Simon Perreault <sperreault@jive.com> wrote:

> Re-reading the draft again, if we delete those use cases, we are left<=
br>
> with... nothing. I don't see any use case for ALPN in STUN/TURN th=
at does

> not involve middleboxes. I don't see the point of STUN usage negot=
iation

> since all usages speak the same protocol (STUN) and will be "nego=
tiated"

> implicitly later on, when a usage-specific message is emitted. So... w=
hy are

> we doing this again?



What ALPN does is provide an unambiguous identification of the

intended protocol.=C2=A0 That allows for use of multiple protocols (TURN v2=


perhaps!) on the same port.=C2=A0 The uses for HTTP and WebRTC do this

already.=C2=A0 Maybe it's not important for TURN.



If you are concerned about this, perhaps the working group might be

consulted.

Well, "concerned" is n=
ot the right term. I'm sure we're not breaking anything and, furthe=
r, we're very probably doing the right thing. I'm just genuinely cu=
rious what immediate use cases there could be for this. The ones I know are=
, shall we say, not politically correct: 1) middleboxes, and 2) "run e=
verything on port 443".
=C2=A0
I'll confess, I always sort of assumed that you knew what

you were doing here, so I didn't think much on the issue.
<=
/div>
I'm guilty of this too. "=
;Oh, right, ALPN for STUN/TURN, makes total sense."

Simon


--089e0158b55c6b248a050690217f--


From nobody Wed Oct 29 07:11:35 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 8444E1A0117 for ; Wed, 29 Oct 2014 07:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es-RscqJD6j0 for ; Wed, 29 Oct 2014 07:11:20 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B0E1A0125 for ; Wed, 29 Oct 2014 07:11:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=946; q=dns/txt; s=iport; t=1414591872; x=1415801472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9buDvPs5ZDoeCqNxjq/M9DuBmYLB7piiNRxRFi4KyzE=; b=PhJKQUzNeNprwipGt8nJOoq+Jd92M8lwzmZ8iAJlBOZBalrbGySNNuvg S+krYWabi6VYjo3l6DX66zXqCbikY21WjzrAjyiftVQjUkRWZfwd/XUFf UvDVaJzJ01AEt5vwQOayaya1vayT0awlN7MRum1ifmxEruGfkSkNavo8k k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhMFAAT1UFStJV2R/2dsb2JhbABcgw6BLATVZQKBGxYBAQEBAX2EAgEBAQMBOj0CBQsCAQgOCh4QMiUCBA4FiDgJxxoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFYzB4MtgR4BBJILi12WOII0gURsgUiBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="367767881"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 29 Oct 2014 14:11:11 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9TEB9e1017163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 14:11:09 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 09:11:09 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: Simon Perreault 
Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-selection-00.txt
Thread-Index: AQHP80LACmxg4CcK0U2+t3iK6zzbJpxHZ5OAgAAKFwA=
Date: Wed, 29 Oct 2014 14:11:09 +0000
Message-ID: 
References: <20141027120016.1947.18448.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2834FE3F@xmb-rcd-x10.cisco.com>  <75C3DAD3-F797-4732-8BC1-C89D42AA493C@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.231.239]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <101AA4F78C368843A17B8030FC740F48@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7KBSCk8GajGZ-F1pZPO5xgeNkqg
Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" 
Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-selection-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, 29 Oct 2014 14:11:31 -0000

> On Oct 29, 2014, at 9:35 AM, Simon Perreault  wrote:
>=20
>=20
> On Wed, Oct 29, 2014 at 2:37 AM, Gonzalo Salgueiro (gsalguei)  wrote:
> > Quick procedural question: The intended status says Informational, but =
the text uses RFC2119 keywords. Is this an oversight?
>=20
> There are many Informational documents that use 2119 language, so they ar=
en't be mutually exclusive.=20
>=20
> Correct.
> =20
>  That said, it is meant to be purely as a BCP-style Informational documen=
t.  Whether or not usage of 2119 language is utilized can be determined if =
we move forward with the document.
>=20
> Understood. Although with its current content, which is fairly prescripti=
ve, I think that draft would warrant a Proposed Standard intended status.

I'd be fine with that.  At this point I'd be happy to simply hear comments =
on the draft ;-)

Cheers,

-G


>=20
> Simon


From nobody Wed Oct 29 07:59: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 F341D1A00F9 for ; Wed, 29 Oct 2014 07:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv9kJAVp4h8t for ; Wed, 29 Oct 2014 07:59:41 -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 9C66D1A016F for ; Wed, 29 Oct 2014 07:59:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3224; q=dns/txt; s=iport; t=1414594781; x=1415804381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qp0SZ5TrRvXYByp3QqnTBCNli0yQGf4xEjBHzutJSI4=; b=aYO6jtgxAdsl/SgWEl/QbfEC1fR8xAqvcWdA69iU4ma9LdqGNupO1znL K5rm+cQ4CrGms8iK0Xrwsu8t8tzzNeSjTVa3Ib7pIUg047v/FHlU8B6aY ZJ34Sh0kNxcsVw1rnf4Fbn8zM7I4ckXLQcPvjf9utBn4fIY0WJpcYXhRb 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAMv/UFStJV2U/2dsb2JhbABcgw5UWATODwqHTQKBGxYBAQEBAX2EAgEBAQMBAQEBawsFCwIBCBgjCyEGCyUCBA4FiCwDCQkNwFoNhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI5PggczB4MtgR4FkguJTIIRgTGDSYpbgmCEA4I0gURsgQYHO4EDAQEB
X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="367513510"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2014 14:59:35 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9TExZhQ012197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 14:59:35 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 09:59:35 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: Spencer Dawkins 
Thread-Topic: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
Thread-Index: AQHP8x0wG4sgGUnN9EK1WgJnrhBlxpxHYkEAgAAdPAA=
Date: Wed, 29 Oct 2014 14:59:34 +0000
Message-ID: <21FD12B5-D8B9-435B-895E-A55F1DE1507E@cisco.com>
References:  <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie>  <544F65F4.5080305@gmail.com>    <5450E850.9080609@gmail.com>
In-Reply-To: <5450E850.9080609@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.231.239]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <29FCA0ED7C99A54E85E4EB0D06FDF042@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/smQFLIbfFhhBID5CagupWhRqRrE
Cc: "tram@ietf.org" , tls chair , Martin Stiemerling , Simon Perreault , Kathleen Moriarty , Adam Langley , Martin Thomson , Stephen Farrell 
Subject: Re: [tram] Last Call:  (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 14:59:43 -0000

Hi Spencer -=20

I have sent the request for manual publication to ietf-action@ietf.org as r=
equested.

Thanks to all for your feedback.

Cheers,

Gonzalo


> On Oct 29, 2014, at 9:14 AM, Spencer Dawkins  wrote:
>=20
>=20
> On 10/28/2014 09:08 PM, Gonzalo Salgueiro (gsalguei) wrote:
>> From the authors' perspective I think we have what we need to produce th=
e next version of the document that satisfies the recently raised concerns =
regarding the sample use cases.  We will trim this purely informational tex=
t as it is not in line with forward-looking end-to-end security best practi=
ces as we have no desire to propagate misconceptions or unsound approaches,=
 no matter if it is non-normative text or not. I think we also all agree th=
at this document is nothing more than the registration of a new label and n=
ot the place to expound on those more generally applicable best practices f=
or ALPN. We're confident that the text removal will result in no loss of in=
formation with respect to what we are standardizing in this draft.
>>=20
>> Does this sound like a reasonable way forward?
>>=20
>=20
> I'm still listening, if other people have input, but that's where I think=
 we are now.
>=20
> And I agree that a TRAM document is not the right place to talk about ALP=
N labels in a general way - that was why I asked for guidance from the TLS =
folks.=20
>=20
> If you know what the draft should say (and not say), please feel free to =
send the revision to be posted to ietf-action@ietf.org cc: me, requesting m=
anual posting, and I'll approve it and leave it on the next telechat agenda=
 (where it is currently).
>=20
> Otherwise, the automated submission tool will start working again on 2014=
-11-10.
>=20
> And thank you all for your help with this.
>=20
> Spencer
>=20
>> Cheers,
>>=20
>> Gonzalo
>>=20
>>=20
>>=20
>>=20
>>> On Oct 28, 2014, at 8:25 PM, Martin Thomson 
>>>  wrote:
>>>=20
>>> On 28 October 2014 07:25, Simon Perreault=20
>>> 
>>>  wrote:
>>>=20
>>>> Re-reading the draft again, if we delete those use cases, we are left
>>>> with... nothing. I don't see any use case for ALPN in STUN/TURN that d=
oes
>>>> not involve middleboxes. I don't see the point of STUN usage negotiati=
on
>>>> since all usages speak the same protocol (STUN) and will be "negotiate=
d"
>>>> implicitly later on, when a usage-specific message is emitted. So... w=
hy are
>>>> we doing this again?
>>>>=20
>>> What ALPN does is provide an unambiguous identification of the
>>> intended protocol.  That allows for use of multiple protocols (TURN v2
>>> perhaps!) on the same port.  The uses for HTTP and WebRTC do this
>>> already.  Maybe it's not important for TURN.
>>>=20
>>> If you are concerned about this, perhaps the working group might be
>>> consulted.  I'll confess, I always sort of assumed that you knew what
>>> you were doing here, so I didn't think much on the issue.
>>>=20
>>> _______________________________________________
>>> tram mailing list
>>>=20
>>> tram@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tram
>=20


From nobody Wed Oct 29 10:25: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 040F21A6FCB; Wed, 29 Oct 2014 10:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RqS22hW140K; Wed, 29 Oct 2014 10:25:48 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B01731A6FE1; Wed, 29 Oct 2014 10:25:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.1.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141029172548.23393.24174.idtracker@ietfa.amsl.com>
Date: Wed, 29 Oct 2014 10:25:48 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RGek2Gw2OymwUHz9iNheXVZ4t9g
Cc: tram@ietf.org
Subject: [tram] I-D ACTION:draft-ietf-tram-alpn-07.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 17:25:50 -0000

--NextPart

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         : Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages
    Author(s)     : P. Patil, et al
    Filename      : draft-ietf-tram-alpn
    Pages         : 5 
    Date          : 2014-10-29 
    
   Application Layer Protocol Negotiation (ALPN) labels for Session
   Traversal Utilities for NAT (STUN) usages, such as Traversal Using
   Relays around NAT (TURN) and NAT discovery, are defined in this
   document to allow an application layer negotiate STUN usages within
   the Transport Layer Security (TLS) connection.  ALPN protocol
   identifiers defined in this document apply to both TLS and Datagram
   Transport Layer Security (DTLS).

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-tram-alpn-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-tram-alpn";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-10-29102548.I-D@ietf.org>


--NextPart--


From nobody Thu Oct 30 14:54: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 DDFE81A8846 for ; Thu, 30 Oct 2014 14:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV0h-DnCPWVv for ; Thu, 30 Oct 2014 14:54:52 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 990521A8840 for ; Thu, 30 Oct 2014 14:54:52 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A84A92852A for ; Thu, 30 Oct 2014 21:54:51 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 94F3128529 for ; Thu, 30 Oct 2014 21:54:51 +0000 (GMT)
Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 6C801202A for ; Thu, 30 Oct 2014 21:54:51 +0000 (GMT)
Message-ID: <5452B3AB.1080300@akamai.com>
Date: Thu, 30 Oct 2014 17:54:51 -0400
From: Brandon Williams 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "tram@ietf.org" 
References:  <544A6085.70707@akamai.com> <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com> <544E547C.20903@akamai.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KD9mZ4FtuG-riX18za2kYy1kjto
Subject: Re: [tram] STUN-bis adoption call
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, 30 Oct 2014 21:54:55 -0000

Thanks for that clarification on intent.

It allows me to give an unambiguous

+1 on adoption

--Brandon

On 10/29/2014 02:21 AM, Gonzalo Salgueiro (gsalguei) wrote:
> Brandon -
>
> You raise a valid point that bears some clarification.  For the purposes of WG adoption, let's focus on agreeing to the list of items we want to tackle.  Once we have a WG draft, we can iterate on the actual text to ensure we have text that is representative of WG consensus.
>
> Cheers,
>
> Gonzalo
>
>
>
>> On Oct 27, 2014, at 10:19 AM, Brandon Williams  wrote:
>>
>> On 10/24/2014 11:10 PM, Tirumaleswar Reddy (tireddy) wrote:
>>>> Regarding fragmentation (item 5) ... I don't see any substantive changes. I
>>>>> don't see anything about this in appendix B.2, so I don't think I'm missing
>>>>> anything.
>>> There were discussions about fragmentation support in the list sometime back but without any conclusions.
>>> Please provide more details.
>>>
>>
>> My primary point is that improved guidance on fragmentation and message sizes is one of the things on the list of open items and it doesn't appear that any changes have been made yet. I mostly wanted to confirm that there isn't something about this already in the document that I'm not seeing.
>>
>> --Brandon
>>
>> --
>> Brandon Williams; Senior Principal Software Engineer
>> Emerging Products Engineering; Akamai Technologies Inc.
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.


From nobody Fri Oct 31 09:02:43 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 49C8F1ACD28 for ; Fri, 31 Oct 2014 09:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNE-6AjACpa4 for ; Fri, 31 Oct 2014 09:02:41 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF2F1ACD2F for ; Fri, 31 Oct 2014 09:02:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21936; q=dns/txt; s=iport; t=1414771361; x=1415980961; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xp18R+0AJJDwuZPuGUauOXF+AThtk5KwWPkPa83fFcY=; b=fw6tNi80AyKjBCGNlbFtCsc+izq9tFfsx1le5Z2KRtIGzJYeOr11wnpP TY5GTOBYuqApCN+NKLDEFOFTWXgdRmoesfnEgUVvhZf/lEXpSfnL26/A4 BkYQWyGYcKJBF6QOMyboJz6alC7l0wo5HatD/b/KBKJFGK+lxbxFEkeoM E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIFAFWxU1StJV2Q/2dsb2JhbABcgkhGVFgEgwLKFwEJh00CHHoWAQEBAQFyC4QDAQEEAQEBIEsbAgEIPwMCAgIlCxQRAgQTiEENtW2UewEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkHUXC4J3NoEeBZIVi2OBMYNKkU2DeGyBSIEDAQEB
X-IronPort-AV: E=Sophos;i="5.07,295,1413244800";  d="scan'208,217";a="368512344"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2014 16:02:40 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9VG2ent002201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Oct 2014 16:02:40 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 11:02:40 -0500
From: "Pal Martinsen (palmarti)" 
To: "tram@ietf.org" 
Thread-Topic: [tram] STUN-bis adoption call
Thread-Index: AQHP74kuUaa4Xxp9skyMjpEqt5Ta3Jw/oHuAgADWqACAA9+zAIACnxuAgAKXEYCAAS/sAA==
Date: Fri, 31 Oct 2014 16:02:39 +0000
Message-ID: 
References:  <544A6085.70707@akamai.com> <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com> <544E547C.20903@akamai.com>  <5452B3AB.1080300@akamai.com>
In-Reply-To: <5452B3AB.1080300@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.221.156]
Content-Type: multipart/alternative; boundary="_000_C722E37AFA2F41A08A1393B8332B1B0Fciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XmKmKcUBj3tVkr59G8pc43MSIOA
Subject: Re: [tram] STUN-bis adoption call
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, 31 Oct 2014 16:02:43 -0000

--_000_C722E37AFA2F41A08A1393B8332B1B0Fciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzEgdG8gYWRvcHRpb24uDQoNCi4tLg0KUMOlbC1FcmlrDQoNCk9uIDMwIE9jdCAyMDE0LCBhdCAy
Mjo1NCwgQnJhbmRvbiBXaWxsaWFtcyA8YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tPG1haWx0
bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+PiB3cm90ZToNCg0KVGhhbmtzIGZvciB0aGF0
IGNsYXJpZmljYXRpb24gb24gaW50ZW50Lg0KDQpJdCBhbGxvd3MgbWUgdG8gZ2l2ZSBhbiB1bmFt
YmlndW91cw0KDQorMSBvbiBhZG9wdGlvbg0KDQotLUJyYW5kb24NCg0KT24gMTAvMjkvMjAxNCAw
MjoyMSBBTSwgR29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVpKSB3cm90ZToNCkJyYW5kb24gLQ0K
DQpZb3UgcmFpc2UgYSB2YWxpZCBwb2ludCB0aGF0IGJlYXJzIHNvbWUgY2xhcmlmaWNhdGlvbi4g
IEZvciB0aGUgcHVycG9zZXMgb2YgV0cgYWRvcHRpb24sIGxldCdzIGZvY3VzIG9uIGFncmVlaW5n
IHRvIHRoZSBsaXN0IG9mIGl0ZW1zIHdlIHdhbnQgdG8gdGFja2xlLiAgT25jZSB3ZSBoYXZlIGEg
V0cgZHJhZnQsIHdlIGNhbiBpdGVyYXRlIG9uIHRoZSBhY3R1YWwgdGV4dCB0byBlbnN1cmUgd2Ug
aGF2ZSB0ZXh0IHRoYXQgaXMgcmVwcmVzZW50YXRpdmUgb2YgV0cgY29uc2Vuc3VzLg0KDQpDaGVl
cnMsDQoNCkdvbnphbG8NCg0KDQoNCk9uIE9jdCAyNywgMjAxNCwgYXQgMTA6MTkgQU0sIEJyYW5k
b24gV2lsbGlhbXMgPGJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbTxtYWlsdG86YnJhbmRvbi53
aWxsaWFtc0Bha2FtYWkuY29tPj4gd3JvdGU6DQoNCk9uIDEwLzI0LzIwMTQgMTE6MTAgUE0sIFRp
cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3JvdGU6DQpSZWdhcmRpbmcgZnJhZ21lbnRhdGlv
biAoaXRlbSA1KSAuLi4gSSBkb24ndCBzZWUgYW55IHN1YnN0YW50aXZlIGNoYW5nZXMuIEkNCmRv
bid0IHNlZSBhbnl0aGluZyBhYm91dCB0aGlzIGluIGFwcGVuZGl4IEIuMiwgc28gSSBkb24ndCB0
aGluayBJJ20gbWlzc2luZw0KYW55dGhpbmcuDQpUaGVyZSB3ZXJlIGRpc2N1c3Npb25zIGFib3V0
IGZyYWdtZW50YXRpb24gc3VwcG9ydCBpbiB0aGUgbGlzdCBzb21ldGltZSBiYWNrIGJ1dCB3aXRo
b3V0IGFueSBjb25jbHVzaW9ucy4NClBsZWFzZSBwcm92aWRlIG1vcmUgZGV0YWlscy4NCg0KDQpN
eSBwcmltYXJ5IHBvaW50IGlzIHRoYXQgaW1wcm92ZWQgZ3VpZGFuY2Ugb24gZnJhZ21lbnRhdGlv
biBhbmQgbWVzc2FnZSBzaXplcyBpcyBvbmUgb2YgdGhlIHRoaW5ncyBvbiB0aGUgbGlzdCBvZiBv
cGVuIGl0ZW1zIGFuZCBpdCBkb2Vzbid0IGFwcGVhciB0aGF0IGFueSBjaGFuZ2VzIGhhdmUgYmVl
biBtYWRlIHlldC4gSSBtb3N0bHkgd2FudGVkIHRvIGNvbmZpcm0gdGhhdCB0aGVyZSBpc24ndCBz
b21ldGhpbmcgYWJvdXQgdGhpcyBhbHJlYWR5IGluIHRoZSBkb2N1bWVudCB0aGF0IEknbSBub3Qg
c2VlaW5nLg0KDQotLUJyYW5kb24NCg0KLS0NCkJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmlu
Y2lwYWwgU29mdHdhcmUgRW5naW5lZXINCkVtZXJnaW5nIFByb2R1Y3RzIEVuZ2luZWVyaW5nOyBB
a2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0
bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90
cmFtDQoNCg0KLS0NCkJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUg
RW5naW5lZXINCkVtZXJnaW5nIFByb2R1Y3RzIEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9n
aWVzIEluYy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg==

--_000_C722E37AFA2F41A08A1393B8332B1B0Fciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KJiM0MzsxIHRvIGFkb3B0aW9uLg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Li0uPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPlDDpWwtRXJpazwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs
YXNzPSIiPk9uIDMwIE9jdCAyMDE0LCBhdCAyMjo1NCwgQnJhbmRvbiBXaWxsaWFtcyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbSIgY2xhc3M9IiI+YnJhbmRv
bi53aWxsaWFtc0Bha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw
cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0
YW50OyIgY2xhc3M9IiI+VGhhbmtzDQogZm9yIHRoYXQgY2xhcmlmaWNhdGlvbiBvbiBpbnRlbnQu
PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo
YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJy
IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt
YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh
Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs
aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl
LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w
b3J0YW50OyIgY2xhc3M9IiI+SXQNCiBhbGxvd3MgbWUgdG8gZ2l2ZSBhbiB1bmFtYmlndW91czwv
c3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v
cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu
czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBz
dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y
dGFudDsiIGNsYXNzPSIiPiYjNDM7MQ0KIG9uIGFkb3B0aW9uPC9zcGFuPjxiciBzdHlsZT0iZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl
aWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+LS1C
cmFuZG9uPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs
OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi
Pg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv
bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6
IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6
IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu
ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T24NCiAxMC8yOS8yMDE0IDAyOjIxIEFNLCBHb256YWxv
IFNhbGd1ZWlybyAoZ3NhbGd1ZWkpIHdyb3RlOjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5
OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh
cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7
IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJm
b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h
bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp
Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt
c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQpCcmFuZG9uIC08YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQpZb3UgcmFpc2UgYSB2YWxpZCBwb2ludCB0aGF0IGJlYXJzIHNvbWUg
Y2xhcmlmaWNhdGlvbi4gJm5ic3A7Rm9yIHRoZSBwdXJwb3NlcyBvZiBXRyBhZG9wdGlvbiwgbGV0
J3MgZm9jdXMgb24gYWdyZWVpbmcgdG8gdGhlIGxpc3Qgb2YgaXRlbXMgd2Ugd2FudCB0byB0YWNr
bGUuICZuYnNwO09uY2Ugd2UgaGF2ZSBhIFdHIGRyYWZ0LCB3ZSBjYW4gaXRlcmF0ZSBvbiB0aGUg
YWN0dWFsIHRleHQgdG8gZW5zdXJlIHdlIGhhdmUgdGV4dCB0aGF0IGlzIHJlcHJlc2VudGF0aXZl
DQogb2YgV0cgY29uc2Vuc3VzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNoZWVycyw8
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpHb256YWxvPGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgY2xhc3M9IiI+T24gT2N0IDI3LCAyMDE0LCBhdCAxMDoxOSBBTSwgQnJhbmRvbiBXaWxs
aWFtcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbSIgY2xh
c3M9IiI+YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMTAvMjQvMjAxNCAxMToxMCBQTSwgVGlydW1hbGVzd2Fy
IFJlZGR5ICh0aXJlZGR5KSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlJlZ2FyZGlu
ZyBmcmFnbWVudGF0aW9uIChpdGVtIDUpIC4uLiBJIGRvbid0IHNlZSBhbnkgc3Vic3RhbnRpdmUg
Y2hhbmdlcy4gSTxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi
PmRvbid0IHNlZSBhbnl0aGluZyBhYm91dCB0aGlzIGluIGFwcGVuZGl4IEIuMiwgc28gSSBkb24n
dCB0aGluayBJJ20gbWlzc2luZzxiciBjbGFzcz0iIj4NCmFueXRoaW5nLjxiciBjbGFzcz0iIj4N
CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NClRoZXJlIHdlcmUgZGlzY3Vzc2lvbnMgYWJv
dXQgZnJhZ21lbnRhdGlvbiBzdXBwb3J0IGluIHRoZSBsaXN0IHNvbWV0aW1lIGJhY2sgYnV0IHdp
dGhvdXQgYW55IGNvbmNsdXNpb25zLjxiciBjbGFzcz0iIj4NClBsZWFzZSBwcm92aWRlIG1vcmUg
ZGV0YWlscy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIg
Y2xhc3M9IiI+DQpNeSBwcmltYXJ5IHBvaW50IGlzIHRoYXQgaW1wcm92ZWQgZ3VpZGFuY2Ugb24g
ZnJhZ21lbnRhdGlvbiBhbmQgbWVzc2FnZSBzaXplcyBpcyBvbmUgb2YgdGhlIHRoaW5ncyBvbiB0
aGUgbGlzdCBvZiBvcGVuIGl0ZW1zIGFuZCBpdCBkb2Vzbid0IGFwcGVhciB0aGF0IGFueSBjaGFu
Z2VzIGhhdmUgYmVlbiBtYWRlIHlldC4gSSBtb3N0bHkgd2FudGVkIHRvIGNvbmZpcm0gdGhhdCB0
aGVyZSBpc24ndCBzb21ldGhpbmcgYWJvdXQgdGhpcyBhbHJlYWR5DQogaW4gdGhlIGRvY3VtZW50
IHRoYXQgSSdtIG5vdCBzZWVpbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS1CcmFu
ZG9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQpCcmFuZG9u
IFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyPGJyIGNsYXNzPSIi
Pg0KRW1lcmdpbmcgUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5j
LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIg
Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBp
ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RyYW08YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8
L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6
ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h
bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7
IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu
b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh
bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz
cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4tLTxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls
eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12
YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl
dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog
bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l
LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp
ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+
QnJhbmRvbg0KIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyPC9z
cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm
b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp
bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkVtZXJnaW5nDQogUHJvZHVjdHMgRW5naW5lZXJpbmc7
IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg
Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo
dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog
YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi
IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6
ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h
bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl
eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBu
b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz
dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl
OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh
bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz
PSIiPnRyYW0NCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp
bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0
LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg
d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgc3R5bGU9
ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBz
dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiBzdHlsZT0iZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg
dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vdHJhbTwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_C722E37AFA2F41A08A1393B8332B1B0Fciscocom_--


From nobody Fri Oct 31 09:37:45 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 E01091A03E3 for ; Fri, 31 Oct 2014 09:37:40 -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 f8RYOfpDZRjZ for ; Fri, 31 Oct 2014 09:37:39 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AD11A8AA9 for ; Fri, 31 Oct 2014 09:37:38 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id q5so1789594wiv.5 for ; Fri, 31 Oct 2014 09:37:37 -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=Om1OJqwTrf/VuqWzdzEiUdtnDXneeSlvezuSJZjQ4Do=; b=Aof3p+vBzPRIMpFP7l/uGXlH/V6rb/WmLaVKMa2gfN3m+ZstYozuQuxkYrqiVw/AQS qNmMaBelgY+1nrWfRs42z+xy7MUbXwAZlxN+nSdY2hi8Qu2hLIhwfWcMh/TMk5xSa3HJ SKEvZi7R1uGjCCj22P4ad3dvv04gFWO7PFjr68G3igpnRAC4HcvDAxRh7OMOX+QR9UMi QbRXZmiLAv7tjIqmJrdi2svu0bxpNlNCtmD4kXssfj4H4uA9tWMeX09QnAGvpX1Lj0L1 +ULbuD60Pt5Z8F6UGpX/eiyosR7VeGTnslkESIGSkI81gholo43Pzj0094+iNXWJS24S Mf2A==
MIME-Version: 1.0
X-Received: by 10.180.104.198 with SMTP id gg6mr5117121wib.76.1414773457137; Fri, 31 Oct 2014 09:37:37 -0700 (PDT)
Received: by 10.194.5.194 with HTTP; Fri, 31 Oct 2014 09:37:37 -0700 (PDT)
In-Reply-To: 
References:  <544A6085.70707@akamai.com> <913383AAA69FF945B8F946018B75898A2834F0ED@xmb-rcd-x10.cisco.com> <544E547C.20903@akamai.com>  <5452B3AB.1080300@akamai.com> 
Date: Fri, 31 Oct 2014 09:37:37 -0700
Message-ID: 
From: Oleg Moskalenko 
To: "Pal Martinsen (palmarti)" 
Content-Type: multipart/alternative; boundary=f46d04426e1059b8200506ba9d80
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/aISGCIR9L6hdjtrFjXx1SyKr0mE
Cc: "tram@ietf.org" 
Subject: Re: [tram] STUN-bis adoption call
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, 31 Oct 2014 16:37:41 -0000

--f46d04426e1059b8200506ba9d80
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1

On Fri, Oct 31, 2014 at 9:02 AM, Pal Martinsen (palmarti) <
palmarti@cisco.com> wrote:

>  +1 to adoption.
>
>  .-.
> P=C3=A5l-Erik
>
>  On 30 Oct 2014, at 22:54, Brandon Williams 
> wrote:
>
> Thanks for that clarification on intent.
>
> It allows me to give an unambiguous
>
> +1 on adoption
>
> --Brandon
>
> On 10/29/2014 02:21 AM, Gonzalo Salgueiro (gsalguei) wrote:
>
> Brandon -
>
> You raise a valid point that bears some clarification.  For the purposes
> of WG adoption, let's focus on agreeing to the list of items we want to
> tackle.  Once we have a WG draft, we can iterate on the actual text to
> ensure we have text that is representative of WG consensus.
>
> Cheers,
>
> Gonzalo
>
>
>
>
> On Oct 27, 2014, at 10:19 AM, Brandon Williams <
> brandon.williams@akamai.com> wrote:
>
> On 10/24/2014 11:10 PM, Tirumaleswar Reddy (tireddy) wrote:
>
> Regarding fragmentation (item 5) ... I don't see any substantive changes.=
 I
>
> don't see anything about this in appendix B.2, so I don't think I'm missi=
ng
> anything.
>
>  There were discussions about fragmentation support in the list sometime
> back but without any conclusions.
> Please provide more details.
>
>
> My primary point is that improved guidance on fragmentation and message
> sizes is one of the things on the list of open items and it doesn't appea=
r
> that any changes have been made yet. I mostly wanted to confirm that ther=
e
> isn't something about this already in the document that I'm not seeing.
>
> --Brandon
>
> --
> Brandon Williams; Senior Principal Software Engineer
> Emerging Products Engineering; Akamai Technologies Inc.
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
> --
> Brandon Williams; Senior Principal Software Engineer
> Emerging Products Engineering; Akamai Technologies Inc.
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>

--f46d04426e1059b8200506ba9d80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1

On Fri, Oct 31, 2014 at 9:02 AM, Pal Martinsen (palmarti) <pa=
lmarti@cisco.com> wrote:






+1 to adoption.






.-.


P=C3=A5l-Erik









On 30 Oct 2014, at 22:54, Brandon Williams <brandon.williams@akamai.com&g=
t; wrote:




Thanks
 for that clarification on intent.



It
 allows me to give an unambiguous



+1
 on adoption



--Brandon



On
 10/29/2014 02:21 AM, Gonzalo Salgueiro (gsalguei) wrote:



Brandon -



You raise a valid point that bears some clarification.=C2=A0 For the purpos=
es of WG adoption, let's focus on agreeing to the list of items we want=
 to tackle.=C2=A0 Once we have a WG draft, we can iterate on the actual tex=
t to ensure we have text that is representative
 of WG consensus.



Cheers,



Gonzalo









On Oct 27, 2014, at 10:19 AM, Brandon Williams &l=
t;brandon.=
williams@akamai.com> wrote:



On 10/24/2014 11:10 PM, Tirumaleswar Reddy (tireddy) wrote:




Regarding fragmentation (item 5) ... I don't =
see any substantive changes. I


don't see anything about this in appendix B.2=
, so I don't think I'm missing

anything.





There were discussions about fragmentation support in the list sometime bac=
k but without any conclusions.

Please provide more details.







My primary point is that improved guidance on fragmentation and message siz=
es is one of the things on the list of open items and it doesn't appear=
 that any changes have been made yet. I mostly wanted to confirm that there=
 isn't something about this already
 in the document that I'm not seeing.



--Brandon



--

Brandon Williams; Senior Principal Software Engineer

Emerging Products Engineering; Akamai Technologies Inc.



_______________________________________________

tram mailing list

tram@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/tram









--=C2=A0

Brandon
 Williams; Senior Principal Software Engineer

Emerging
 Products Engineering; Akamai Technologies Inc.



________________________=
_______________________

tram
 mailing list

tram@ietf.org

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













_______________________________________________

tram mailing list

tram@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/tram





--f46d04426e1059b8200506ba9d80--