From nobody Sun Apr 3 09:29:12 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E365912D12A for ; Sun, 3 Apr 2016 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9PNkSMN2_Ly for ; Sun, 3 Apr 2016 09:29:09 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED512D0FE for ; Sun, 3 Apr 2016 09:29:09 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3F8214237C5; Sun, 3 Apr 2016 16:29:08 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 291D04237C0; Sun, 3 Apr 2016 16:29:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459700948; bh=v0z68L0E52KUBH1XEIbji/NY4xk4kdwMXY2SR4LnncM=; l=5625; h=To:References:From:Date:In-Reply-To:From; b=eoSSE6ZZ2RmJWsuok5txlu57fp9++GQx6k/1cbLz/COXLfnKM3rnthwAhiH5YEelI pWkQSY8BzX3JhcDMt9MuxWq2Ep5QPw5WQfTZ1gS//1IwglS4+ybtPAVdG2GxNpnugt Q7wmzV4nqPgIfZDD/qncnpSIUMfmpiT8LpwBUjJQ= Received: from [172.28.112.97] (bowill.kendall.corp.akamai.com [172.28.112.97]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 21FE01FCA8; Sun, 3 Apr 2016 16:29:08 +0000 (GMT) To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <20160311043903.2754.65997.idtracker@ietfa.amsl.com> <56F0388B.20805@akamai.com> <995693f2812e48efa262c8f1bf23d8c9@XCH-RCD-017.cisco.com> From: Brandon Williams Message-ID: <570144D4.50304@akamai.com> Date: Sun, 3 Apr 2016 12:29:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <995693f2812e48efa262c8f1bf23d8c9@XCH-RCD-017.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 16:29:11 -0000 You're correct that the MTU text in stunbis hasn't yet been changed to reflect what I believe was the previous consensus. I've raised this on the list but haven't seen any responses yet. Marc didn't want to make this change without getting confirmation that the WG had actually agreed. I'll try to touch base with a couple of people this week to see if we can get that closed. --Brandon On 03/22/2016 03:53 AM, Tirumaleswar Reddy (tireddy) wrote: > Hi Brandon, > > Please see inline > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Monday, March 21, 2016 11:38 PM >> To: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt >> >> Hi Tiru, >> >> Thanks for the update. I've got two minor comments. >> >> The new text about fragmentation and ticket length is less specific than the >> old text, but it still repeats guidance from the RFC that I believe we've agreed >> to change in STUNbis. > > I don't see any specific changes in STUNbis yet to handle fragmentation ! > >> How about instead of this: "... >> assume that the path MTU is unknown and MUST ensure that the ticket >> length is restricted to avoid UDP fragmentation ...", we say this: "... >> assume that the path MTU is unknown and use a ticket length in accordance >> with published guidance on STUN UDP fragmentation ...". This wording >> defers all requirements language to the STUN RFC but still calls out the >> possible concern. > > Okay, updated. > >> >> In the paragraph describing the handling of a verified Refresh request, it >> states "The server then updates it's state data with the new client IP address >> and port but does not discard the old 5-tuple from it's state data." However, >> in the next paragraph, the new text states "After receiving any of those >> messages, a TURN server updates its 5-tuple with the new client IP address >> and port." I think what you want in the second paragraph is "After receiving >> any of those messages, a TURN server discards the 5-tuple associated with >> the old MOBILITY-TICKET from its state data." In that paragraph, you can >> probably also say that it discards the old MOBILITY-TICKET at that point >> without waiting for the timeout, although the text about holding onto the old >> MOBILITY-TICKET hasn't appeared yet (it's in the next paragraph). > > NEW: > After receiving any of those messages, a TURN server discards the 5-tuple associated with the old MOBILITY-TICKET and the old MOBILITY-TICKET from its state data. > > -Tiru > >> >> --Brandon >> >> On 03/10/2016 11:48 PM, Tirumaleswar Reddy (tireddy) wrote: >>> This revision adds support for make-before-break and addresses >> comments from Brandon. >>> >>> -Tiru >>> >>>> -----Original Message----- >>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >>>> drafts@ietf.org >>>> Sent: Friday, March 11, 2016 10:09 AM >>>> To: i-d-announce@ietf.org >>>> Cc: tram@ietf.org >>>> Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>>> This draft is a work item of the TURN Revised and Modernized of the IETF. >>>> >>>> Title : Mobility with TURN >>>> Authors : Dan Wing >>>> Prashanth Patil >>>> Tirumaleswar Reddy >>>> Paal-Erik Martinsen >>>> Filename : draft-ietf-tram-turn-mobility-01.txt >>>> Pages : 12 >>>> Date : 2016-03-10 >>>> >>>> Abstract: >>>> It is desirable to minimize traffic disruption caused by changing IP >>>> address during a mobility event. One mechanism to minimize >>>> disruption is to expose a shorter network path to the mobility event >>>> so only the local network elements are aware of the changed IP >>>> address but the remote peer is unaware of the changed IP address. >>>> >>>> This draft provides such an IP address mobility solution using >>>> Traversal Using Relays around NAT (TURN). This is achieved by >>>> allowing a client to retain an allocation on the TURN server when the >>>> IP address of the client changes. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-01 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-mobility-01 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >> tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >> >> -- >> Brandon Williams; Chief Architect >> Cloud Networking; 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 > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Mon Apr 4 00:22:32 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60CE12D0E0 for ; Mon, 4 Apr 2016 00:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2CxBFfz1g_q for ; Mon, 4 Apr 2016 00:22:29 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DDE12D0BB for ; Mon, 4 Apr 2016 00:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6552; q=dns/txt; s=iport; t=1459754549; x=1460964149; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CNQ69dDBUnI6SjhL+DLS+t2ahvxe1eaJ/to2r8zWUX4=; b=VVS3avKw+VUOBba5XWEiIZpKA9VuAd7k7O2d+lmpdaVqn0l8JquGefn/ kJKxi6KH6slZDOil8E0t9AFfqbnmO/c06uEVbdC8GHU0oscinWyruAT6s Oi2fHzZ5E+xOcVu6LVJyYrGjo9y23WcPfSErqLqDMYmQ0iJpcJZn1RMaS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgDdFQJX/4gNJK1dgzdTfQa7IQENg?= =?us-ascii?q?XIXCoVsAoEoOBQBAQEBAQEBZSeEQQEBAQQBAQE3NBcEAgEIEQQBAQEeCQcnCxQ?= =?us-ascii?q?JCAIEARIIE4gMDrwEAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYghEqEJwaFaAWYA?= =?us-ascii?q?QGFcogOgW9Og3+IWoYaiH8BHgEBQoNnbIcMfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,439,1454976000"; d="scan'208";a="257106030" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 07:22:27 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u347MRWs027522 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 07:22:27 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 02:22:26 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 02:22:26 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt Thread-Index: AQHRe0/1XNdwPPuTokCC39MWoUNZe59TqZBwgBDs44CAAI7u8IATw7QAgAClOZA= Date: Mon, 4 Apr 2016 07:22:26 +0000 Message-ID: <6fc370251e8b4b7590b856e0132c098f@XCH-RCD-017.cisco.com> References: <20160311043903.2754.65997.idtracker@ietfa.amsl.com> <56F0388B.20805@akamai.com> <995693f2812e48efa262c8f1bf23d8c9@XCH-RCD-017.cisco.com> <570144D4.50304@akamai.com> In-Reply-To: <570144D4.50304@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.21.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 07:22:31 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Sunday, April 03, 2016 9:59 PM > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt >=20 > You're correct that the MTU text in stunbis hasn't yet been changed to re= flect > what I believe was the previous consensus. I've raised this on the list b= ut > haven't seen any responses yet. Marc didn't want to make this change > without getting confirmation that the WG had actually agreed. I'll try to= touch > base with a couple of people this week to see if we can get that closed. Thanks, I will update the draft to point to stunbis after MTU text is updat= ed in stunbis draft. -Tiru >=20 > --Brandon >=20 > On 03/22/2016 03:53 AM, Tirumaleswar Reddy (tireddy) wrote: > > Hi Brandon, > > > > Please see inline > > > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >> Williams > >> Sent: Monday, March 21, 2016 11:38 PM > >> To: tram@ietf.org > >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt > >> > >> Hi Tiru, > >> > >> Thanks for the update. I've got two minor comments. > >> > >> The new text about fragmentation and ticket length is less specific > >> than the old text, but it still repeats guidance from the RFC that I > >> believe we've agreed to change in STUNbis. > > > > I don't see any specific changes in STUNbis yet to handle fragmentation= ! > > > >> How about instead of this: "... > >> assume that the path MTU is unknown and MUST ensure that the ticket > >> length is restricted to avoid UDP fragmentation ...", we say this: "..= . > >> assume that the path MTU is unknown and use a ticket length in > >> accordance with published guidance on STUN UDP fragmentation ...". > >> This wording defers all requirements language to the STUN RFC but > >> still calls out the possible concern. > > > > Okay, updated. > > > >> > >> In the paragraph describing the handling of a verified Refresh > >> request, it states "The server then updates it's state data with the > >> new client IP address and port but does not discard the old 5-tuple > >> from it's state data." However, in the next paragraph, the new text > >> states "After receiving any of those messages, a TURN server updates > >> its 5-tuple with the new client IP address and port." I think what > >> you want in the second paragraph is "After receiving any of those > >> messages, a TURN server discards the 5-tuple associated with the old > >> MOBILITY-TICKET from its state data." In that paragraph, you can > >> probably also say that it discards the old MOBILITY-TICKET at that > >> point without waiting for the timeout, although the text about holding > onto the old MOBILITY-TICKET hasn't appeared yet (it's in the next > paragraph). > > > > NEW: > > After receiving any of those messages, a TURN server discards the 5-tup= le > associated with the old MOBILITY-TICKET and the old MOBILITY-TICKET from > its state data. > > > > -Tiru > > > >> > >> --Brandon > >> > >> On 03/10/2016 11:48 PM, Tirumaleswar Reddy (tireddy) wrote: > >>> This revision adds support for make-before-break and addresses > >> comments from Brandon. > >>> > >>> -Tiru > >>> > >>>> -----Original Message----- > >>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > >>>> drafts@ietf.org > >>>> Sent: Friday, March 11, 2016 10:09 AM > >>>> To: i-d-announce@ietf.org > >>>> Cc: tram@ietf.org > >>>> Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-01.txt > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>>> This draft is a work item of the TURN Revised and Modernized of the > IETF. > >>>> > >>>> Title : Mobility with TURN > >>>> Authors : Dan Wing > >>>> Prashanth Patil > >>>> Tirumaleswar Reddy > >>>> Paal-Erik Martinsen > >>>> Filename : draft-ietf-tram-turn-mobility-01.txt > >>>> Pages : 12 > >>>> Date : 2016-03-10 > >>>> > >>>> Abstract: > >>>> It is desirable to minimize traffic disruption caused by changi= ng IP > >>>> address during a mobility event. One mechanism to minimize > >>>> disruption is to expose a shorter network path to the mobility = event > >>>> so only the local network elements are aware of the changed IP > >>>> address but the remote peer is unaware of the changed IP addres= s. > >>>> > >>>> This draft provides such an IP address mobility solution using > >>>> Traversal Using Relays around NAT (TURN). This is achieved by > >>>> allowing a client to retain an allocation on the TURN server wh= en the > >>>> IP address of the client changes. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ > >>>> > >>>> There's also a htmlized version available at: > >>>> https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-01 > >>>> > >>>> A diff from the previous version is available at: > >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-mobility-01 > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the time of > >>>> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> tram mailing list > >>>> tram@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tram > >>> > >>> _______________________________________________ > >>> tram mailing list > >>> tram@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tram > >>> > >> > >> -- > >> Brandon Williams; Chief Architect > >> Cloud Networking; 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 > > >=20 > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. From nobody Mon Apr 4 00:31:04 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2834412D14F; Mon, 4 Apr 2016 00:31:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404073100.15696.29634.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 00:31:00 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 04 Apr 2016 07:31:00 -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 of the IETF. Title : Mobility with TURN Authors : Dan Wing Prashanth Patil Tirumaleswar Reddy Paal-Erik Martinsen Filename : draft-ietf-tram-turn-mobility-02.txt Pages : 12 Date : 2016-04-04 Abstract: It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-mobility-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 Apr 4 00:33:52 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5482112D146 for ; Mon, 4 Apr 2016 00:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTyWdBlmd2SI for ; Mon, 4 Apr 2016 00:33:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907DB12D13B for ; Mon, 4 Apr 2016 00:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2292; q=dns/txt; s=iport; t=1459755229; x=1460964829; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=un+4by8sE0Cf1cRlSvsu77UycueexKGHQJrV/DIvnBQ=; b=TpbPb0NDQnZ/4BnbvgM95gf6FpSwmPL/k0L9Qc1Z8zxTqOV3d8K72gCm B8QKRjBKywSCJZlEwsjrmfjm3LXbxmQqsC9U7hElzOooqYm5RasR2Kg2u LkkUtCcJN4FJfTBwpdHlTUj0aDHmoTEpPDwnHkyfTqMF/8xapkscC6N6y w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgARGAJX/5pdJa1dgzdTfQa7IQENg?= =?us-ascii?q?XIXCoVsAoEoOBQBAQEBAQEBZRwLhEEBAQEEAQEBNzQXBAIBCBEEAQEfCQcnCxQ?= =?us-ascii?q?JCAIEEwgTiAwOvAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiCESoQnhW4FmAEBh?= =?us-ascii?q?XKIDoFvToN/iFqPGQEeAQFCg2dshwx+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,439,1454976000"; d="scan'208";a="257109539" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2016 07:33:48 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u347Xmko031091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Apr 2016 07:33:48 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 02:33:47 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 02:33:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-02.txt Thread-Index: AQHRjkP6eF3HMndRnU6U3yJGQHS/4595bAAA Date: Mon, 4 Apr 2016 07:33:47 +0000 Message-ID: <7b8e571cd02d43729f9010f9dc7722b2@XCH-RCD-017.cisco.com> References: <20160404073100.15696.29634.idtracker@ietfa.amsl.com> In-Reply-To: <20160404073100.15696.29634.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.21.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 07:33:51 -0000 This revision addresses comments from Brandon. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, April 04, 2016 1:01 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized of the IETF. >=20 > Title : Mobility with TURN > Authors : Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Paal-Erik Martinsen > Filename : draft-ietf-tram-turn-mobility-02.txt > Pages : 12 > Date : 2016-04-04 >=20 > Abstract: > It is desirable to minimize traffic disruption caused by changing IP > address during a mobility event. One mechanism to minimize > disruption is to expose a shorter network path to the mobility event > so only the local network elements are aware of the changed IP > address but the remote peer is unaware of the changed IP address. >=20 > This draft provides such an IP address mobility solution using > Traversal Using Relays around NAT (TURN). This is achieved by > allowing a client to retain an allocation on the TURN server when the > IP address of the client changes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-mobility-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Apr 5 07:19:54 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3546412D557 for ; Tue, 5 Apr 2016 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmYd85FCcd3t for ; Tue, 5 Apr 2016 07:19:51 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C3A8C12D1A9 for ; Tue, 5 Apr 2016 07:19:51 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 161C7423727; Tue, 5 Apr 2016 14:19:51 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id E4A35423724; Tue, 5 Apr 2016 14:19:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459865990; bh=h8mULCdHQX/u9lBAdOltGSqiXRIhGlafCB8x380oWhA=; l=3253; h=To:References:From:Date:In-Reply-To:From; b=Hrde0AB/MARfRTiHW9XOckMQBt/aJhqO69Jsi8hUqHLyRkYYgWaFvaNb/x8LoIGhi 25eUpisnS26fOKc+Rbli2wYyZe/9NXqOq0lhtUrxpLHLrbQfFDqV2p9Pzh9fXUEdqP +XNH87YjiKXXvYGwI9ojOFb2hsc4JSP9KLeQdwps= Received: from [172.28.112.97] (bowill.kendall.corp.akamai.com [172.28.112.97]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id DD9831FC98; Tue, 5 Apr 2016 14:19:50 +0000 (GMT) To: Marc Petit-Huguenin , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A90B27.9080502@akamai.com> From: Brandon Williams Message-ID: <5703C986.2070006@akamai.com> Date: Tue, 5 Apr 2016 10:19:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A90B27.9080502@akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:19:54 -0000 Hi all, I haven't seen any responses to this question so I'm going to convert it into a proposal. My sense is that the group sees little enough problem with fragmentation, and particularly little enough risk the the PMTU is 576 bytes, that the MUST language about MTU limitations can be removed. I propose that we completely remove the following statement from stunbis. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [RFC5780]. Outside of this or similar applications, the MTU constraint MUST be followed. I think this reflects the outcome of a previous discussion. Are there any objections to this change? --Brandon On 01/27/2016 01:23 PM, Brandon Williams wrote: > On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >>> s 6.1 This section still says "MTU constraint MUST be followed" >>> language. I'm pretty sure that we decided to relax this constraint in >>> Dallas, but I don't see it in the minutes. It seems to be implied by >>> the decision about removing the SCTP requirement. >> >> My recollection was that the relaxation was linked to the introduction >> of the SCTP transport in STUN (which permitted safe fragmentation). >> Now that SCTP is gone, I am not sure that this decision stands alone. >> > > IIRC, in Dallas we discussed MTU constraints in the context of both the > SCTP requirement and the ORIGIN draft. The point was made that both > small MTUs and fragment delivery failure are rare and that the existing > requirements language is unnecessary. This was the foundation for > removing the SCTP language and for removing some size constraint > language from the ORIGIN draft. My understanding of the discussion was > also that the group agreed to relax the existing RFC5389 constraint, at > least for request/response message types. > > This really just applies to the following text: > > If the path MTU is unknown for UDP, messages SHOULD be the smaller of > 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for > IPv6 [RFC2460]. > > The MTU limitation is a SHOULD, and not a MUST, to account for cases > where STUN itself is being used to probe for MTU characteristics > [RFC5780]. Outside of this or similar applications, the MTU > constraint MUST be followed. > > IOW, if you don't know the PMTU, an allocation request MUST be smaller > than 576 bytes for IPv4. My sense of the room in Dallas was that we > agreed this is an unnecessary restriction, at least for the > request/response message types. > > So, what do others think/remember? Should we keep the existing > requirement (in which case I think it will be important to consider this > limitation whenever new attribute types are created)? Am I remembering > correctly that we already decided to loosen the requirement and it just > didn't make it into the notes for the meeting? > > --Brandon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Tue Apr 5 07:49:32 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA612D569 for ; Tue, 5 Apr 2016 07:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQWlx3SNoM5i for ; Tue, 5 Apr 2016 07:49:29 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0C12D583 for ; Tue, 5 Apr 2016 07:49:29 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DF3544E1311; Tue, 5 Apr 2016 14:49:28 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C81224E130B; Tue, 5 Apr 2016 14:49:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459867768; bh=3NDA5rSwb0gW1EM6snnS3nIPT1Bydgro5gqG+wFOOBA=; l=7087; h=To:References:Cc:From:Date:In-Reply-To:From; b=OwaAs3UjTATaFUP2Bl/aXqaPT8ztYe2CG4NjKGzs9WS6wAyDw4/IA8r8OeTgigmJr zx1nNh9Ud49BXiRjQtH6gQ+bUZPzYaf21l5vHUlUcjl/kex57Va7js3izH8hpHxQ0e X21DvfAHZ79bUubXdr/C8IOZnq3JW/QEsjvFNsLc= Received: from [172.28.112.97] (bowill.kendall.corp.akamai.com [172.28.112.97]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B8FBE1FC8D; Tue, 5 Apr 2016 14:49:28 +0000 (GMT) To: Justin Uberti , Martin Thomson References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> From: Brandon Williams Message-ID: <5703D078.7020306@akamai.com> Date: Tue, 5 Apr 2016 10:49:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Marc Petit-Huguenin Subject: Re: [tram] Size of ICE connectivity checks X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:49:31 -0000 Justin, The thread on the list doesn't have too many people involved, but everyone who responded seems generally supportive. Do you intend to publish the draft and try to get some progress in the ice wg? And if so, should we be discussing here whether to relax the ICV length requirements to allow specific STUN usages to support ICV truncation? I had earlier proposed that we continue to say that MESSAGE-INTEGRITY has a 20 byte HMAC by default and MESSAGE-INTEGRITY-SHA256 has a 32 byte HMAC by default, but that in each case, a specific STUN usage is allowed to define an alternative truncated HMAC length. What do you think? Should we make this change now to support a future discussion in ice about connectivity check size? --Brandon On 01/28/2016 08:14 PM, Justin Uberti wrote: > > > On Wed, Jan 27, 2016 at 4:32 PM, Martin Thomson > > wrote: > > I think that this is a fine way to shave this down if we want > something as close to STUN as possible. But none of these changes is > at all compatible. > > The alternative is to look at what we need and to change the > connectivity check entirely so that it is maximally compact. > > For all of these, we need to clearly signal that the compact form is > acceptable, so maybe we can find a way to trim this right down: > > a demux octet (1) > a transaction ID (12-16) > a target ufrag (4) > a source ufrag (4) > an integrity value (8-16) > > So that's 32 bytes, assuming the smallest values mentioned here, and > assuming we round to multiples of 4. > > My proposal ends up with a 32-byte STUN message; the remaining areas for > optimization are: > - unnecessary(?) magic-cookie; 4 bytes > - T + L for USERNAME attributes; 4 bytes, but needed to support > variable-size ufrags > > If you get rid of these things, I think you would end up with: > - 4 bytes for demux + length + meta > - 12 bytes for combined TID + integrity > - 8 bytes for lfrag/rfrag combo > > = 24 bytes, which is slightly better, but maybe not enough to define a > new format. > > As Justin implies below, we might not need the same aggressive > optimization for responses, because the main driver for reducing > packet size is reducing the check interval without driving the data > rate too high. If too many checks are successful, the responses can > be rate limited to reduce the data rate, but in that case you have > consent, so the only concern there is congestion. > > Other possible tweak is to say that the ufrag attributes in SDP > include base64 encoded binary so that you can boost the entropy of the > reduced sized ufrags by a third. > > Of course, you don't want to use SHA1 for M-I for any of this. > > On 28 January 2016 at 05:25, Justin Uberti > wrote: > > ufrag already has a 4-byte lower bound, so we can't really reduce > that > > further. > > > > Here is my concrete proposal: > > > https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5deb8ZXHLJJpadBE/edit#slide=id.gc34db0b92_0_23 > > > > > Basically: > > - truncate M-I > > - allow special case for 8-byte USERNAME > > - remove tiebreaker, fingerprint, priority attributes > > > > Possibly: > > - combine ICE-CONTROLLING and USERNAME > > - put M-I into transaction ID (for REQUEST; RESPONSE would still > need to > > have an attribute) > > > > On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti) > > > wrote: > >> > >> > >> > On 27 Jan 2016, at 14:39, Simon Perreault > wrote: > >> > > >> > Le 2016-01-26 22:41, Marc Petit-Huguenin a écrit : > >> >>> s 14.4/14.5 There has been some discussion in mmusic about > trying to > >> >>>> compress ICE connectivity checks. Justin presented on this. > IIRC, one > >> >>>> of his proposals was to shrink the size of the ICV. It > would be good > >> >>>> to follow up on this and perhaps update stunbis to allow > ICV's that > >> >>>> are shorter. > >> >> Here's the conclusions (from MMUSIC minutes) of the > discussion about > >> >> that in Prague: > >> >> > >> >> "Next steps: We need to discuss more on the approach and get > back. Look > >> >> further into what we can do with ufrag, etc. How much can we > reduce packet > >> >> size safely?" > >> >> > >> >> I do not think that there is consensus enough to take any > action at > >> >> this point. > >> > > >> > I am seizing this opportunity to restart discussion on this > topic. I > >> > think we've discussed many possibilities, and what is needed > at this > >> > moment is an actual concrete text proposal. I don't think it's > >> > necessarily up to the draft editors to come up with such a > proposal, but > >> > rather up to the working group as a whole. > >> > > >> > Discuss. :) > >> > >> I think limiting the size to a reasonable value is fine. A > smaller limit > >> to UFRAG and so on is simple and nice. > >> > >> I do not think putting much effort into saving a few bytes is > worth it at > >> this point in time. Let us save that for later if we want to > tackle ICEv2 > >> with a different connectivity check format. > >> > >> .-. > >> Pål-Erik > >> > >> > > >> > Thanks, > >> > Simon > >> > > >> > _______________________________________________ > >> > tram mailing list > >> > tram@ietf.org > >> > https://www.ietf.org/mailman/listinfo/tram > > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > > From nobody Fri Apr 8 13:05:41 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176F912D0CA for ; Thu, 7 Apr 2016 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fCz3nNw361qj for ; Thu, 7 Apr 2016 09:07:08 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74612D0B8 for ; Thu, 7 Apr 2016 09:07:08 -0700 (PDT) Received: from [IPv6:2602:4b:a2f4:e100:d5c3:46f7:5079:5952] (unknown [IPv6:2602:4b:a2f4:e100:d5c3:46f7:5079:5952]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 90B7E20129; Thu, 7 Apr 2016 18:07:06 +0200 (CEST) To: Brandon Williams , Justin Uberti , Martin Thomson References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> <5703D078.7020306@akamai.com> From: Marc Petit-Huguenin Message-ID: <570685A5.9090602@petit-huguenin.org> Date: Thu, 7 Apr 2016 10:07:01 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <5703D078.7020306@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s2FkI0P73H9vvuddRUBvaTVPkUUhIvomQ" Archived-At: X-Mailman-Approved-At: Fri, 08 Apr 2016 13:05:40 -0700 Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] Size of ICE connectivity checks X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:07:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s2FkI0P73H9vvuddRUBvaTVPkUUhIvomQ Content-Type: multipart/mixed; boundary="PAEQQiDlpKHWlQhv9X4nfwvaEp5ncPnl6" From: Marc Petit-Huguenin To: Brandon Williams , Justin Uberti , Martin Thomson Cc: Simon Perreault , "Pal Martinsen (palmarti)" , "tram@ietf.org" Message-ID: <570685A5.9090602@petit-huguenin.org> Subject: Re: [tram] Size of ICE connectivity checks References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A8C88A.1090305@jive.com> <7ED1D1EC-0911-4CAC-AB8B-7DA501B9FF1E@cisco.com> <5703D078.7020306@akamai.com> In-Reply-To: <5703D078.7020306@akamai.com> --PAEQQiDlpKHWlQhv9X4nfwvaEp5ncPnl6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/05/2016 08:49 AM, Brandon Williams wrote: > Justin, >=20 > The thread on the list doesn't have too many people involved, but > everyone who responded seems generally supportive. Do you intend to > publish the draft and try to get some progress in the ice wg? And if > so, should we be discussing here whether to relax the ICV length > requirements to allow specific STUN usages to support ICV > truncation? >=20 > I had earlier proposed that we continue to say that MESSAGE-INTEGRITY > has a 20 byte HMAC by default and MESSAGE-INTEGRITY-SHA256 has a 32 > byte HMAC by default, but that in each case, a specific STUN usage is > allowed to define an alternative truncated HMAC length. >=20 > What do you think? Should we make this change now to support a future > discussion in ice about connectivity check size? I think that having each usage deciding for itself a smaller size for eit= her MI or MI-2 may be fine, but that stunbis should still provide some gu= idance, e.g. if truncating is done on LSB or MSB, or a minimal size for e= ach MI, or if it needs to be a multiple of a power of 2, etc... Advice f= rom security people would be welcome there. The next major update for stunbis is scheduled for end of May, so it woul= d be great to get a clear consensus before that. Thanks. >=20 > --Brandon >=20 > On 01/28/2016 08:14 PM, Justin Uberti wrote: >>=20 >>=20 >> On Wed, Jan 27, 2016 at 4:32 PM, Martin Thomson=20 >> > >> wrote: >>=20 >> I think that this is a fine way to shave this down if we want=20 >> something as close to STUN as possible. But none of these changes >> is at all compatible. >>=20 >> The alternative is to look at what we need and to change the=20 >> connectivity check entirely so that it is maximally compact. >>=20 >> For all of these, we need to clearly signal that the compact form >> is acceptable, so maybe we can find a way to trim this right down: >>=20 >> a demux octet (1) a transaction ID (12-16) a target ufrag (4) a >> source ufrag (4) an integrity value (8-16) >>=20 >> So that's 32 bytes, assuming the smallest values mentioned here, >> and assuming we round to multiples of 4. >>=20 >> My proposal ends up with a 32-byte STUN message; the remaining >> areas for optimization are: - unnecessary(?) magic-cookie; 4 bytes=20 >> - T + L for USERNAME attributes; 4 bytes, but needed to support=20 >> variable-size ufrags >>=20 >> If you get rid of these things, I think you would end up with: - 4 >> bytes for demux + length + meta - 12 bytes for combined TID + >> integrity - 8 bytes for lfrag/rfrag combo >>=20 >> =3D 24 bytes, which is slightly better, but maybe not enough to >> define a new format. >>=20 >> As Justin implies below, we might not need the same aggressive=20 >> optimization for responses, because the main driver for reducing=20 >> packet size is reducing the check interval without driving the >> data rate too high. If too many checks are successful, the >> responses can be rate limited to reduce the data rate, but in that >> case you have consent, so the only concern there is congestion. >>=20 >> Other possible tweak is to say that the ufrag attributes in SDP=20 >> include base64 encoded binary so that you can boost the entropy of >> the reduced sized ufrags by a third. >>=20 >> Of course, you don't want to use SHA1 for M-I for any of this. >>=20 >> On 28 January 2016 at 05:25, Justin Uberti > > wrote: >>> ufrag already has a 4-byte lower bound, so we can't really >>> reduce >> that >>> further. >>>=20 >>> Here is my concrete proposal: >>>=20 >> https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5de= b8ZXHLJJpadBE/edit#slide=3Did.gc34db0b92_0_23 >> >>=20 >>>=20 >>> Basically: - truncate M-I - allow special case for 8-byte >>> USERNAME - remove tiebreaker, fingerprint, priority attributes >>>=20 >>> Possibly: - combine ICE-CONTROLLING and USERNAME - put M-I into >>> transaction ID (for REQUEST; RESPONSE would still >> need to >>> have an attribute) >>>=20 >>> On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti)=20 >>> > wrote: >>>>=20 >>>>=20 >>>>> On 27 Jan 2016, at 14:39, Simon Perreault >>>>> > > wrote: >>>>>=20 >>>>> Le 2016-01-26 22:41, Marc Petit-Huguenin a =C3=A9crit : >>>>>>> s 14.4/14.5 There has been some discussion in mmusic >>>>>>> about >> trying to >>>>>>>> compress ICE connectivity checks. Justin presented on >>>>>>>> this. >> IIRC, one >>>>>>>> of his proposals was to shrink the size of the ICV. It >> would be good >>>>>>>> to follow up on this and perhaps update stunbis to >>>>>>>> allow >> ICV's that >>>>>>>> are shorter. >>>>>> Here's the conclusions (from MMUSIC minutes) of the >> discussion about >>>>>> that in Prague: >>>>>>=20 >>>>>> "Next steps: We need to discuss more on the approach and >>>>>> get >> back. Look >>>>>> further into what we can do with ufrag, etc. How much can >>>>>> we >> reduce packet >>>>>> size safely?" >>>>>>=20 >>>>>> I do not think that there is consensus enough to take any >> action at >>>>>> this point. >>>>>=20 >>>>> I am seizing this opportunity to restart discussion on this >> topic. I >>>>> think we've discussed many possibilities, and what is needed >> at this >>>>> moment is an actual concrete text proposal. I don't think >>>>> it's necessarily up to the draft editors to come up with such >>>>> a >> proposal, but >>>>> rather up to the working group as a whole. >>>>>=20 >>>>> Discuss. :) >>>>=20 >>>> I think limiting the size to a reasonable value is fine. A >> smaller limit >>>> to UFRAG and so on is simple and nice. >>>>=20 >>>> I do not think putting much effort into saving a few bytes is >> worth it at >>>> this point in time. Let us save that for later if we want to >> tackle ICEv2 >>>> with a different connectivity check format. >>>>=20 >>>> .-. P=C3=A5l-Erik >>>>=20 >>>>>=20 >>>>> Thanks, Simon >>>>>=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --PAEQQiDlpKHWlQhv9X4nfwvaEp5ncPnl6-- --s2FkI0P73H9vvuddRUBvaTVPkUUhIvomQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXBoWmAAoJECnERZXWan7E17UP/j6JCDmk41L7xG/wVSSDCKKr vgrwsof7+BpRDxZKUhNJo5TZ/0ZWWjEvkuk3OsRRZ1b7fOmC8xToYc7nEDhaIkMs sncxjgQ6Q0x1M7dLbCp24s1Vab0GE+f9sR0wffNSVapww2HQhidJbI2wbR05FpXH pizqUbuMyi/PA/LpdC21cHzPjeCDxz2t8Oos2+36bxBtjkeYgMcMaDfxHfy1QSNs Bm5dfEJcaDFePwIR/UQDV3KjIgQFgGEZxyhJDDUh/dIcJzFhrH0OrCdsVK/3Uvd3 nHzRQjIafU+cAQLi22scOqF1dE5XODnN1NLZIaSM2I6dA3pgyoYd0zyCa5APCW/W 8Y1VdUxu++FK8g8MTYyR1UfVY3+lJK1Al0vjiLe1foSjdmg3kWdkwlXAoleHC4Ob NvPsSMjbp46h91t9/0ImXwbbZP1GSj/KG3TqxH5ad25K8xX7a7Xu2ir037a/1LtC a84z+gUoMcf7EHdAkGQqI7DaKjFuxGNqgasY0zK8UZAdUfKBhIEJ2T5SLMod0GiH j3uAE4bjg0aCnkbBNyBGnGFBsRMrrYGJOZJUblR9qNZzC/GV4nSWZ/zOeN9TJ/8C P1qRBE0WFpGjKYt6PI6nu8CZzjgh+tI2XWrsmkYCIjYETmjiqYTGJ7Iq6lIOKIkr kgoInNwzv9ufuiJLeHt7 =W6jO -----END PGP SIGNATURE----- --s2FkI0P73H9vvuddRUBvaTVPkUUhIvomQ-- From nobody Fri Apr 15 05:59:10 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6112D59F for ; Fri, 15 Apr 2016 05:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkMroKWuQOky for ; Fri, 15 Apr 2016 05:59:08 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1290E12B01F for ; Fri, 15 Apr 2016 05:59:08 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e128so56652873pfe.3 for ; Fri, 15 Apr 2016 05:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=kQVqiXoMpLBi0QBn+dK1CU+3BBJKuqKrtkLBAqHuyCM=; b=PzY89BT7zSmu2Xl20p1Woc5eFZk0P2lAbKQYJdEKf6/VBwqU5gpuK9ua5jtVmIMMY/ prlWU5xeJKwSVA+juVGMpUezDFm08XYSYfPYt6regxY6VEqbigjKt6JbPjdlmIh67Vde gG+iUcqv+RVn9Sv4V8G5QOMqws4kBAKx0yPAN6hoylRxQMx5vcZ/NQKEp0XMkWnab2Y9 ITMqzItR93ri0Hzx40uEPBJEIAd9tY01bR0s4+aEckeRUNfu0bxKvAYKJjRUcW/Av7lH xbc0nLUVqCKZbLXQpJIKRwmQoqJN27kuTpIBhHixzN99cyU+rkRT3BwkIPPf+Xts9Xv9 ebpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=kQVqiXoMpLBi0QBn+dK1CU+3BBJKuqKrtkLBAqHuyCM=; b=OLfSy8M4Y5Rcc903y2p/UES8wXwsgSyoQt2Zxt/ER64DeS07g+sAkawffcns44xaBT CTeUr6TbB1yAXANBPI5w6U4UztS8KbNqwVyjWUTk5ecaKkKXk8tA9zqqdjOh/C5lXl16 T5FSnj0I3JacW40hYFSZTVL+89j4hhJzttykdtik1QvzKKAUmZrLNuSYmupLU8mfzsdt G8EmIGU0NbKdzLPYF8TySZQcKQbMcBkTmCzR+3YCW6gTM2+fClxQercpLhKoXtjHIWfF DmxpwisY72E3SAfk+atpCRS+xraC9Rv8Am90ESQVyn44MXiqDhI8WTdBJ6Uhl7ekQ25m 1y1A== X-Gm-Message-State: AOPr4FWLLKISsJKNH+P8yd/St0VcS9RC+4NvUefdS8qoHb46T5rRx3J99TyW3nYRqBuP0VlyJ2esXVrp+jRRUHGRpdlum9VskyVehQFr0FUloUKRRkKfe7E= X-Received: by 10.98.19.2 with SMTP id b2mr29255217pfj.93.1460725147647; Fri, 15 Apr 2016 05:59:07 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:5c7c:2cf3:5c1e:6df2]) by smtp.gmail.com with ESMTPSA id wi5sm38054520pab.8.2016.04.15.05.59.06 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 05:59:07 -0700 (PDT) To: tram@ietf.org From: Simon Perreault Message-ID: <5710E599.50400@jive.com> Date: Fri, 15 Apr 2016 08:59:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] WGLC draft-ietf-tram-turn-mobility-02 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 12:59:09 -0000 TRAMsters, This email initiates a two-week working-group last call on this draft: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ Please read it now. Substantial comments should be addressed to the group. Nits should be sent directly to the authors. Thanks, Simon & Gonzalo From nobody Fri Apr 15 13:25:28 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBCF12D7E4; Fri, 15 Apr 2016 13:25:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 13:25:25 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 15 Apr 2016 20:25:25 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tram-stun-path-data-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few questions that could potentially be further clarified in the document: 1) How often should the request be retransmitted to get a qualified loss measure? 2) What's the frequency of the retransmissions/pacing or wating between retransmissions? 3) How big is the overhead when retransmitting several times? Thanks! From nobody Fri Apr 15 22:29:24 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08A712B014; Fri, 15 Apr 2016 22:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.498 X-Spam-Level: X-Spam-Status: No, score=-15.498 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz68ESYxn7ze; Fri, 15 Apr 2016 22:29:16 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D0A12D575; Fri, 15 Apr 2016 22:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2570; q=dns/txt; s=iport; t=1460784555; x=1461994155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tD9k/zN5Suvt6yyzPpvpNVd4wr8KMMNZlri1nOtlNtw=; b=VhJ7+JsoyWdrpKQRFdxLN7H1mxXc+Kd/xePvungIhLxLoFy51aDJ1KE+ XLKa7XU3xLhIjvb1yeVPjutDYfbQskTPCQ8x8DCj50NplZP466vUds7AA BHlbJXUBDhVbaT2+7zCip1aU/ZQd6vzUd1OzrQYkYuVpxRBvPVWzchi1H 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AgDEzBFX/5ldJa1egzhTfQa1aYIfg?= =?us-ascii?q?g8BDYFxIoVsAhyBGDgUAQEBAQEBAWUnhEEBAQEDASMRRQUHBAIBCA4DBAEBAwI?= =?us-ascii?q?jAwICAjAUAQUDCAIEAQ0FCIgZCA6wCpF7AQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR8hSWES4QPEQGDHoJWBYd0kBoBhXeID4FuhE6IXI8qAR4BAUKCAR2BSmwBiBY?= =?us-ascii?q?2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,490,1454976000"; d="scan'208";a="260664433" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2016 05:29:13 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3G5TDPH023329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Apr 2016 05:29:14 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 16 Apr 2016 00:29:13 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Sat, 16 Apr 2016 00:29:13 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIFllcyBvbiBkcmFmdC1pZXRmLXRyYW0tc3R1?= =?utf-8?Q?n-path-data-03:_(with_COMMENT)?= Thread-Index: AQHRl1TzJIcpWiyxZUmigkEGWSYnmp+MCDMw Date: Sat, 16 Apr 2016 05:29:13 +0000 Message-ID: References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> In-Reply-To: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.77.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , "sperreault@jive.com" , "tram@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 05:29:18 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kIFtt YWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldF0NCj4gU2VudDogU2F0dXJkYXksIEFwcmlsIDE2LCAy MDE2IDE6NTUgQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRmLXRyYW0tc3R1bi1w YXRoLWRhdGFAaWV0Zi5vcmc7IFNpbW9uIFBlcnJlYXVsdDsgdHJhbS0NCj4gY2hhaXJzQGlldGYu b3JnOyBzcGVycmVhdWx0QGppdmUuY29tOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IE1pcmph IEvDvGhsZXdpbmQncyBZZXMgb24gZHJhZnQtaWV0Zi10cmFtLXN0dW4tcGF0aC1kYXRhLTAzOiAo d2l0aA0KPiBDT01NRU5UKQ0KPiANCj4gTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUg Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi10cmFtLXN0dW4tcGF0 aC1kYXRhLTAzOiBZZXMNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRy b2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tc3R1bi1wYXRoLWRhdGEvDQo+IA0KPiANCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQSBm ZXcgcXVlc3Rpb25zIHRoYXQgY291bGQgcG90ZW50aWFsbHkgYmUgZnVydGhlciBjbGFyaWZpZWQg aW4gdGhlDQo+IGRvY3VtZW50Og0KPiANCj4gMSkgSG93IG9mdGVuIHNob3VsZCB0aGUgcmVxdWVz dCBiZSByZXRyYW5zbWl0dGVkIHRvIGdldCBhIHF1YWxpZmllZCBsb3NzDQo+IG1lYXN1cmUgPw0K PiAyKSBXaGF0J3MgdGhlIGZyZXF1ZW5jeSBvZiB0aGUgcmV0cmFuc21pc3Npb25zL3BhY2luZyBv ciB3YXRpbmcgYmV0d2Vlbg0KPiByZXRyYW5zbWlzc2lvbnMgPw0KDQpBIFNUVU4gY2xpZW50IHJl dHJhbnNtaXRzIGEgU1RVTiByZXF1ZXN0IHN0YXJ0aW5nIHdpdGggYW4gaW50ZXJ2YWwgb2YgUlRP LCBkb3VibGluZyBhZnRlciBlYWNoIHJldHJhbnNtaXNzaW9uLiBSZXRyYW5zbWlzc2lvbnMgY29u dGludWUgdW50aWwgYSByZXNwb25zZSBpcyByZWNlaXZlZCwgb3IgdW50aWwgYSB0b3RhbCBvZiBS YyByZXF1ZXN0cyBoYXZlIGJlZW4gc2VudC4gSXQgaXMgZGlzY3Vzc2VkIGluIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1Mzg5IGluIGRldGFpbC4gDQoNCj4gMykgSG93IGJpZyBpcyB0 aGUgb3ZlcmhlYWQgd2hlbiByZXRyYW5zbWl0dGluZyBzZXZlcmFsIHRpbWVzID8NCg0KVGhlIG92 ZXJoZWFkIGludHJvZHVjZWQgYnkgdGhlIG5ldyBQQVRILUNIQVJBQ1RFUklTVElDIGF0dHJpYnV0 ZSBpcyBqdXN0IDQgYnl0ZXMuDQoNCi1UaXJ1DQoNCj4gDQo+IFRoYW5rcyENCj4gDQoNCg== From nobody Sat Apr 16 03:38:40 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A36512D0E6 for ; Sat, 16 Apr 2016 03:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 DwAt8hGcgBYu for ; Sat, 16 Apr 2016 03:38:31 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E15E12D96B for ; Sat, 16 Apr 2016 03:38:30 -0700 (PDT) Received: (qmail 11964 invoked from network); 16 Apr 2016 12:38:27 +0200 Received: from p5dec2073.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.115) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Apr 2016 12:38:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sat, 16 Apr 2016 12:38:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , "sperreault@jive.com" , "tram-chairs@ietf.org" , The IESG , "tram@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 10:38:33 -0000 Hi, see below. >>=20 >> A few questions that could potentially be further clarified in the >> document: >>=20 >> 1) How often should the request be retransmitted to get a qualified = loss >> measure ? >> 2) What's the frequency of the retransmissions/pacing or wating = between >> retransmissions ? >=20 > A STUN client retransmits a STUN request starting with an interval of = RTO, doubling after each retransmission. Retransmissions continue until = a response is received, or until a total of Rc requests have been sent. = It is discussed in https://tools.ietf.org/html/rfc5389 in detail.=20 Okay, it wasn=E2=80=99t clear to me if you would send more = retransmissions just to measure loss. If you don=E2=80=99t, how much = retransmission do you usually see and is this sufficient to get a = reliable loss measure (see question one)? >=20 >> 3) How big is the overhead when retransmitting several times ? >=20 > The overhead introduced by the new PATH-CHARACTERISTIC attribute is = just 4 bytes. Okay, again, wasn=E2=80=99t clear to me if you would need more request = than usually or not. Mirja >=20 > -Tiru >=20 >>=20 >> Thanks! >>=20 >=20 From nobody Sat Apr 16 06:20:20 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC68712D9F0; Sat, 16 Apr 2016 06:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCtz7FHjt2uU; Sat, 16 Apr 2016 06:20:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B9412D9D7; Sat, 16 Apr 2016 06:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1460812813; x=1462022413; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LDnDVWySYh6ejD6ldw26fJNElw1+0Wuwsx/3azzlKbY=; b=AUPqLcYc0NpBUCpXD+eV1arn+rqIuYZ9n70AAsJ89d1FBp/VIoeLiK08 uIGJZmy33O+gPM3C7YmIYw7CUhY4yDIJVjtI75sdoA00EZtNI93HVIjzK xvLTNwO7Qrw0/j7bFhyEVllWqktCezeMQI330n114m6AsTmyI29NQk4av 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgBcOxJX/5tdJa1cgzhTfQa1aYIfg?= =?us-ascii?q?g8BDYFxHoVwAhyBETgUAQEBAQEBAWUnhEEBAQEDASMRRQUHBAIBCBEEAQEDAiM?= =?us-ascii?q?DAgICMBQBBQMIAgQOBQiIGQgOqyqRaAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEf?= =?us-ascii?q?IUlhEuHP4JWBZgOAYV3iA+PGI8qAR4BAUKCAR2BSmyITX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,492,1454976000"; d="scan'208";a="92186326" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2016 13:20:12 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3GDKCC6026592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Apr 2016 13:20:12 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 16 Apr 2016 08:20:11 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Sat, 16 Apr 2016 08:20:11 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIFllcyBvbiBkcmFmdC1pZXRmLXRyYW0tc3R1?= =?utf-8?Q?n-path-data-03:_(with_COMMENT)?= Thread-Index: AQHRl1TzJIcpWiyxZUmigkEGWSYnmp+MCDMwgAC1KwD//84vEA== Date: Sat, 16 Apr 2016 13:20:11 +0000 Message-ID: <403566031bb74465bbd0d0da1acf1b7c@XCH-RCD-017.cisco.com> References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.77.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , "sperreault@jive.com" , "tram-chairs@ietf.org" , The IESG , "tram@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 13:20:15 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kIChJ RVRGKSBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IFNlbnQ6IFNhdHVyZGF5LCBBcHJp bCAxNiwgMjAxNiA0OjA4IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ IENjOiBUaGUgSUVTRzsgZHJhZnQtaWV0Zi10cmFtLXN0dW4tcGF0aC1kYXRhQGlldGYub3JnOyBz cGVycmVhdWx0QGppdmUuY29tOw0KPiB0cmFtQGlldGYub3JnOyB0cmFtLWNoYWlyc0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogTWlyamEgS8O8aGxld2luZCdzIFllcyBvbiBkcmFmdC1pZXRmLXRy YW0tc3R1bi1wYXRoLWRhdGEtMDM6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBIaSwNCj4gDQo+ IHNlZSBiZWxvdy4NCj4gDQo+ID4+DQo+ID4+IEEgZmV3IHF1ZXN0aW9ucyB0aGF0IGNvdWxkIHBv dGVudGlhbGx5IGJlIGZ1cnRoZXIgY2xhcmlmaWVkIGluIHRoZQ0KPiA+PiBkb2N1bWVudDoNCj4g Pj4NCj4gPj4gMSkgSG93IG9mdGVuIHNob3VsZCB0aGUgcmVxdWVzdCBiZSByZXRyYW5zbWl0dGVk IHRvIGdldCBhIHF1YWxpZmllZA0KPiA+PiBsb3NzIG1lYXN1cmUgPw0KPiA+PiAyKSBXaGF0J3Mg dGhlIGZyZXF1ZW5jeSBvZiB0aGUgcmV0cmFuc21pc3Npb25zL3BhY2luZyBvciB3YXRpbmcNCj4g Pj4gYmV0d2VlbiByZXRyYW5zbWlzc2lvbnMgPw0KPiA+DQo+ID4gQSBTVFVOIGNsaWVudCByZXRy YW5zbWl0cyBhIFNUVU4gcmVxdWVzdCBzdGFydGluZyB3aXRoIGFuIGludGVydmFsIG9mIFJUTywN Cj4gZG91YmxpbmcgYWZ0ZXIgZWFjaCByZXRyYW5zbWlzc2lvbi4gUmV0cmFuc21pc3Npb25zIGNv bnRpbnVlIHVudGlsIGENCj4gcmVzcG9uc2UgaXMgcmVjZWl2ZWQsIG9yIHVudGlsIGEgdG90YWwg b2YgUmMgcmVxdWVzdHMgaGF2ZSBiZWVuIHNlbnQuIEl0IGlzDQo+IGRpc2N1c3NlZCBpbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM4OSBpbiBkZXRhaWwuDQo+IA0KPiBPa2F5LCBp dCB3YXNu4oCZdCBjbGVhciB0byBtZSBpZiB5b3Ugd291bGQgc2VuZCBtb3JlIHJldHJhbnNtaXNz aW9ucyBqdXN0IHRvDQo+IG1lYXN1cmUgbG9zcy4gDQoNCklmIHRoZXJlIGlzIHJlc3BvbnNlIHRo ZW4gdGhlcmUgaXMgbm8gbmVlZCB0byByZXRyYW5zbWl0IHRoZSBTVFVOIHJlcXVlc3QuDQoNCj4g SWYgeW91IGRvbuKAmXQsIGhvdyBtdWNoIHJldHJhbnNtaXNzaW9uIGRvIHlvdSB1c3VhbGx5IHNl ZSBhbmQNCj4gaXMgdGhpcyBzdWZmaWNpZW50IHRvIGdldCBhIHJlbGlhYmxlIGxvc3MgbWVhc3Vy ZSAoc2VlIHF1ZXN0aW9uIG9uZSkgPw0KDQpJZiB0aGVyZSBpcyBubyByZXNwb25zZSB0aGVuIHRo ZSByZXF1ZXN0IGlzIHJldHJhbnNtaXR0ZWQsIHRoZSByYXRlIG9mIHJldHJhbnNtaXNzaW9ucyBh bmQgbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucyBhcmUgZGVwZW5kZW50IG9uIHRoZSBwcm90b2Nv bCB1c2luZyBTVFVOIChlLmcuIElDRSBjYWxjdWxhdGVzIHJldHJhbnNtaXNzaW9uIHRpbWVyIChS VE8pIGRpZmZlcmVudGx5IGZvciBtZWRpYSBhbmQgbm9uLW1lZGlhIHN0cmVhbXMpLiBJdCdzIHVw IHRvIHRoZSBhcHBsaWNhdGlvbiBpZiBpdCB3YW50cyB0byB0cnkganVzdCBvbmUgdHJhbnNhY3Rp b24gb3IgTk5OIG51bWJlciBvZiB0cmFuc2FjdGlvbnMgdG8gbWVhc3VyZSB0aGUgcGF0aCBjaGFy YWN0ZXJpc3RpY3MuDQoNCiAtVGlydQ0KDQo+IA0KPiA+DQo+ID4+IDMpIEhvdyBiaWcgaXMgdGhl IG92ZXJoZWFkIHdoZW4gcmV0cmFuc21pdHRpbmcgc2V2ZXJhbCB0aW1lcyA/DQo+ID4NCj4gPiBU aGUgb3ZlcmhlYWQgaW50cm9kdWNlZCBieSB0aGUgbmV3IFBBVEgtQ0hBUkFDVEVSSVNUSUMgYXR0 cmlidXRlIGlzDQo+IGp1c3QgNCBieXRlcy4NCj4gDQo+IE9rYXksIGFnYWluLCB3YXNu4oCZdCBj bGVhciB0byBtZSBpZiB5b3Ugd291bGQgbmVlZCBtb3JlIHJlcXVlc3QgdGhhbiB1c3VhbGx5DQo+ IG9yIG5vdC4NCj4gDQo+IE1pcmphDQo+IA0KPiANCj4gDQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ ID4+DQo+ID4+IFRoYW5rcyENCj4gPj4NCj4gPg0KDQo= From nobody Sun Apr 17 07:06:07 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AD12D6AB for ; Sun, 17 Apr 2016 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6APXTHc_dEeh for ; Sun, 17 Apr 2016 07:06:04 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9000712D686 for ; Sun, 17 Apr 2016 07:06:03 -0700 (PDT) Received: (qmail 28025 invoked from network); 17 Apr 2016 16:06:01 +0200 Received: from p5494e707.dip0.t-ipconnect.de (HELO ?192.168.75.37?) (84.148.231.7) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Apr 2016 16:06:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <403566031bb74465bbd0d0da1acf1b7c@XCH-RCD-017.cisco.com> Date: Sun, 17 Apr 2016 16:06:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67B76B8A-3141-4C5B-8902-A6C745863D4B@kuehlewind.net> References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> <403566031bb74465bbd0d0da1acf1b7c@XCH-RCD-017.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , "sperreault@jive.com" , "tram@ietf.org" , The IESG , "tram-chairs@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 14:06:05 -0000 Hi, see below. > Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) = : >=20 >> -----Original Message----- >> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >> Sent: Saturday, April 16, 2016 4:08 PM >> To: Tirumaleswar Reddy (tireddy) >> Cc: The IESG; draft-ietf-tram-stun-path-data@ietf.org; = sperreault@jive.com; >> tram@ietf.org; tram-chairs@ietf.org >> Subject: Re: Mirja K=C3=BChlewind's Yes on = draft-ietf-tram-stun-path-data-03: >> (with COMMENT) >>=20 >> Hi, >>=20 >> see below. >>=20 >>>>=20 >>>> A few questions that could potentially be further clarified in the >>>> document: >>>>=20 >>>> 1) How often should the request be retransmitted to get a qualified >>>> loss measure ? >>>> 2) What's the frequency of the retransmissions/pacing or wating >>>> between retransmissions ? >>>=20 >>> A STUN client retransmits a STUN request starting with an interval = of RTO, >> doubling after each retransmission. Retransmissions continue until a >> response is received, or until a total of Rc requests have been sent. = It is >> discussed in https://tools.ietf.org/html/rfc5389 in detail. >>=20 >> Okay, it wasn=E2=80=99t clear to me if you would send more = retransmissions just to >> measure loss.=20 >=20 > If there is response then there is no need to retransmit the STUN = request. >=20 >> If you don=E2=80=99t, how much retransmission do you usually see and >> is this sufficient to get a reliable loss measure (see question one) = ? >=20 > If there is no response then the request is retransmitted, the rate of = retransmissions and number of retransmissions are dependent on the = protocol using STUN (e.g. ICE calculates retransmission timer (RTO) = differently for media and non-media streams). It's up to the application = if it wants to try just one transaction or NNN number of transactions to = measure the path characteristics. Would it be possible to give some recommendation in this doc what an = application needs to do to get an appropriate measure? Mirja >=20 > -Tiru >=20 >>=20 >>>=20 >>>> 3) How big is the overhead when retransmitting several times ? >>>=20 >>> The overhead introduced by the new PATH-CHARACTERISTIC attribute is >> just 4 bytes. >>=20 >> Okay, again, wasn=E2=80=99t clear to me if you would need more = request than usually >> or not. >>=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> -Tiru >>>=20 >>>>=20 >>>> Thanks! >>>>=20 >>>=20 >=20 From nobody Sun Apr 17 07:15:34 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448E612D63D for ; Sun, 17 Apr 2016 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vvnatCvU6vSI for ; Sun, 17 Apr 2016 07:15:30 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7010512D5A4 for ; Sun, 17 Apr 2016 07:15:30 -0700 (PDT) Received: (qmail 28220 invoked from network); 17 Apr 2016 16:15:28 +0200 Received: from p5494e707.dip0.t-ipconnect.de (HELO ?192.168.75.37?) (84.148.231.7) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Apr 2016 16:15:28 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <67B76B8A-3141-4C5B-8902-A6C745863D4B@kuehlewind.net> Date: Sun, 17 Apr 2016 16:15:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57144431-794F-447D-ADF2-6B61608D2B58@kuehlewind.net> References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> <403566031bb74465bbd0d0da1acf1b7c@XCH-RCD-017.cisco.com> <67B76B8A-3141-4C5B-8902-A6C745863D4B@kuehlewind.net> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , "sperreault@jive.com" , "tram@ietf.org" , The IESG , "tram-chairs@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 14:15:32 -0000 Hi again, one more point: When I was reading the doc, I was assuming that you aim = to measure something like the path loss rate, as you talk in the whole = doc always about 'the path characteristics like round-trip time (RTT) = and packet loss=E2=80=98. However, after the discussion with you, I = believe what you actually do with this extension is to get the ability = to detect signal packet losses (rather than something like an actual = meaningful rate). If that=E2=80=99s the case, that should probably be = more clarified in the whole doc. Mirja =20 > Am 17.04.2016 um 16:06 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi, >=20 > see below. >=20 >=20 >> Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) = : >>=20 >>> -----Original Message----- >>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >>> Sent: Saturday, April 16, 2016 4:08 PM >>> To: Tirumaleswar Reddy (tireddy) >>> Cc: The IESG; draft-ietf-tram-stun-path-data@ietf.org; = sperreault@jive.com; >>> tram@ietf.org; tram-chairs@ietf.org >>> Subject: Re: Mirja K=C3=BChlewind's Yes on = draft-ietf-tram-stun-path-data-03: >>> (with COMMENT) >>>=20 >>> Hi, >>>=20 >>> see below. >>>=20 >>>>>=20 >>>>> A few questions that could potentially be further clarified in the >>>>> document: >>>>>=20 >>>>> 1) How often should the request be retransmitted to get a = qualified >>>>> loss measure ? >>>>> 2) What's the frequency of the retransmissions/pacing or wating >>>>> between retransmissions ? >>>>=20 >>>> A STUN client retransmits a STUN request starting with an interval = of RTO, >>> doubling after each retransmission. Retransmissions continue until a >>> response is received, or until a total of Rc requests have been = sent. It is >>> discussed in https://tools.ietf.org/html/rfc5389 in detail. >>>=20 >>> Okay, it wasn=E2=80=99t clear to me if you would send more = retransmissions just to >>> measure loss.=20 >>=20 >> If there is response then there is no need to retransmit the STUN = request. >>=20 >>> If you don=E2=80=99t, how much retransmission do you usually see and >>> is this sufficient to get a reliable loss measure (see question one) = ? >>=20 >> If there is no response then the request is retransmitted, the rate = of retransmissions and number of retransmissions are dependent on the = protocol using STUN (e.g. ICE calculates retransmission timer (RTO) = differently for media and non-media streams). It's up to the application = if it wants to try just one transaction or NNN number of transactions to = measure the path characteristics. >=20 > Would it be possible to give some recommendation in this doc what an = application needs to do to get an appropriate measure? >=20 > Mirja >=20 >=20 >>=20 >> -Tiru >>=20 >>>=20 >>>>=20 >>>>> 3) How big is the overhead when retransmitting several times ? >>>>=20 >>>> The overhead introduced by the new PATH-CHARACTERISTIC attribute is >>> just 4 bytes. >>>=20 >>> Okay, again, wasn=E2=80=99t clear to me if you would need more = request than usually >>> or not. >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>>>=20 >>>> -Tiru >>>>=20 >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>=20 >>=20 >=20 From nobody Sun Apr 17 07:37:35 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B635512DE7E for ; Sun, 17 Apr 2016 07:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io 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 N8P6mQ2SXlJX for ; Sun, 17 Apr 2016 07:37:25 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8209812DE65 for ; Sun, 17 Apr 2016 07:37:21 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id j11so191291911lfb.1 for ; Sun, 17 Apr 2016 07:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gLKyaKFnN+pt+Ki8TrUcjI9yBTtgQs5Z5n5g1hfYxbA=; b=fgt5LazWOM37+4flxkx4BCdl5bK3mgzpm9gypTacUsETL+A7VQX6qylcf9Zhl19J8I wmjwQWzOIHAz9EA3SF0cqyZqyh+/pXiGz7pIOtsu5ipgTKXYXRRIv8HcEps0J0ZlN09c RW4NS3830S0o3xoCXbY+EjusgH3n/mz6G0DME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gLKyaKFnN+pt+Ki8TrUcjI9yBTtgQs5Z5n5g1hfYxbA=; b=ef7yd5QyFQ7hJkoIcCInYrsxtvQD81zre+A8riM0j0oks2g6JmjLuk/R2rebifzZAc oELIKHuos6J84jKbSzxf7JnG2YM9wvaRA5qAgSB5zOPIuWPEJFCPPFyOaD35WSSOREVC /KGp6hUAy+mecaEIofpl6QseVsT1DHX+GHiJRZVRIzyg2suNI48vnEjbdsVTs5WizMpk 6jRwGA0GKREpJWWnASdVJhuaCcEZ7XkZHljHdQ3S7gB8xKg9w1D6BvbXKzuZGSknQ/cj ZZimi3Lb8t84lCzeqig7Bon+5/EgaeLVmbxulJpLWVZuAjeuQ5nyZ+LdjgKqeJjwjl2e SH5g== X-Gm-Message-State: AOPr4FWlt5Q2jEdEL2zRAoWSTlQGpHG4Q4ghBvYWMRQrz/R0YnAwvs3uX+fVlfWlcqJKj9CqvAIYiPaa/dUq1g== X-Received: by 10.112.198.6 with SMTP id iy6mr3760431lbc.43.1460903839527; Sun, 17 Apr 2016 07:37:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.77.34 with HTTP; Sun, 17 Apr 2016 07:37:00 -0700 (PDT) In-Reply-To: <57144431-794F-447D-ADF2-6B61608D2B58@kuehlewind.net> References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> <403566031bb74465bbd0d0da1acf1b7c@XCH-RCD-017.cisco.com> <67B76B8A-3141-4C5B-8902-A6C745863D4B@kuehlewind.net> <57144431-794F-447D-ADF2-6B61608D2B58@kuehlewind.net> From: Varun Singh Date: Sun, 17 Apr 2016 17:37:00 +0300 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=001a11c2b75a680c570530af2ed3 Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , "sperreault@jive.com" , The IESG , "draft-ietf-tram-stun-path-data@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 14:37:27 -0000 --001a11c2b75a680c570530af2ed3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, I agree, the metric being measured is fractional loss, and not the loss rate. This should be fixed. To your other comment: > Would it be possible to give some recommendation in this doc what an application needs to do to get an appropriate measure? Would the following proposal work? According to rfc5389, the path characteristic is measured when the first STUN transaction is complete for each ICE candidate pair during connectivity establishment. If more measurements are needed, this STUN extension MAY be applied to the STUN consent checks defined in [rfc7675]. On Sun, Apr 17, 2016 at 5:15 PM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi again, > > one more point: When I was reading the doc, I was assuming that you aim t= o > measure something like the path loss rate, as you talk in the whole doc > always about 'the path characteristics like round-trip time (RTT) and > packet loss=E2=80=98. However, after the discussion with you, I believe w= hat you > actually do with this extension is to get the ability to detect signal > packet losses (rather than something like an actual meaningful rate). If > that=E2=80=99s the case, that should probably be more clarified in the wh= ole doc. > > Mirja > > > > Am 17.04.2016 um 16:06 schrieb Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net>: > > > > Hi, > > > > see below. > > > > > >> Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com>: > >> > >>> -----Original Message----- > >>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] > >>> Sent: Saturday, April 16, 2016 4:08 PM > >>> To: Tirumaleswar Reddy (tireddy) > >>> Cc: The IESG; draft-ietf-tram-stun-path-data@ietf.org; > sperreault@jive.com; > >>> tram@ietf.org; tram-chairs@ietf.org > >>> Subject: Re: Mirja K=C3=BChlewind's Yes on > draft-ietf-tram-stun-path-data-03: > >>> (with COMMENT) > >>> > >>> Hi, > >>> > >>> see below. > >>> > >>>>> > >>>>> A few questions that could potentially be further clarified in the > >>>>> document: > >>>>> > >>>>> 1) How often should the request be retransmitted to get a qualified > >>>>> loss measure ? > >>>>> 2) What's the frequency of the retransmissions/pacing or wating > >>>>> between retransmissions ? > >>>> > >>>> A STUN client retransmits a STUN request starting with an interval o= f > RTO, > >>> doubling after each retransmission. Retransmissions continue until a > >>> response is received, or until a total of Rc requests have been sent. > It is > >>> discussed in https://tools.ietf.org/html/rfc5389 in detail. > >>> > >>> Okay, it wasn=E2=80=99t clear to me if you would send more retransmis= sions > just to > >>> measure loss. > >> > >> If there is response then there is no need to retransmit the STUN > request. > >> > >>> If you don=E2=80=99t, how much retransmission do you usually see and > >>> is this sufficient to get a reliable loss measure (see question one) = ? > >> > >> If there is no response then the request is retransmitted, the rate of > retransmissions and number of retransmissions are dependent on the protoc= ol > using STUN (e.g. ICE calculates retransmission timer (RTO) differently fo= r > media and non-media streams). It's up to the application if it wants to t= ry > just one transaction or NNN number of transactions to measure the path > characteristics. > > > > Would it be possible to give some recommendation in this doc what an > application needs to do to get an appropriate measure? > > > > Mirja > > > > > >> > >> -Tiru > >> > >>> > >>>> > >>>>> 3) How big is the overhead when retransmitting several times ? > >>>> > >>>> The overhead introduced by the new PATH-CHARACTERISTIC attribute is > >>> just 4 bytes. > >>> > >>> Okay, again, wasn=E2=80=99t clear to me if you would need more reques= t than > usually > >>> or not. > >>> > >>> Mirja > >>> > >>> > >>> > >>>> > >>>> -Tiru > >>>> > >>>>> > >>>>> Thanks! > >>>>> > >>>> > >> > > > > --=20 Founder, CEO, callstats.io http://www.callstats.io Analytics and Optimizations for WebRTC. We are hiring: www.callstats.io/jobs/ --001a11c2b75a680c570530af2ed3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,

I agree, the metric being mea= sured is fractional loss, and not the loss rate. This should be fixed.=C2= =A0

To your other comment:
>=C2=A0Would it be possible to give some recommendat= ion in this doc what an application needs to do to get an appropriate measu= re?

Would the following proposal work?=C2=A0<= /span>

According to rfc5389,=C2=A0the path characteristic is measured when the first ST= UN transaction is complete=C2=A0for= each ICE candidate pair during connectivity establishment. If more measurements are needed, this STUN extensi= on MAY be applied to the STUN consent checks defined in [rfc7675].


On Sun, Apr 17, 2016 at 5:15 PM, = Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi again,

one more point: When I was reading the doc, I was assuming that you aim to = measure something like the path loss rate, as you talk in the whole doc alw= ays about 'the path characteristics like round-trip time (RTT) and pack= et loss=E2=80=98. However, after the discussion with you, I believe what yo= u actually do with this extension is to get the ability to detect signal pa= cket losses (rather than something like an actual meaningful rate). If that= =E2=80=99s the case, that should probably be more clarified in the whole do= c.

Mirja


> Am 17.04.2016 um 16:06 schrieb Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>:<= br> >
> Hi,
>
> see below.
>
>
>> Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) <tireddy@cisco.com&= gt;:
>>
>>> -----Original Message-----
>>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
>>> Sent: Saturday, April 16, 2016 4:08 PM
>>> To: Tirumaleswar Reddy (tireddy)
>>> Cc: The IESG; draft-ietf-tram-stun-path-data@ietf.org; <= a href=3D"mailto:sperreault@jive.com" target=3D"_blank">sperreault@jive.com= ;
>>> tram@ietf.o= rg; tram-chai= rs@ietf.org
>>> Subject: Re: Mirja K=C3=BChlewind's Yes on draft-ietf-tram= -stun-path-data-03:
>>> (with COMMENT)
>>>
>>> Hi,
>>>
>>> see below.
>>>
>>>>>
>>>>> A few questions that could potentially be further clar= ified in the
>>>>> document:
>>>>>
>>>>> 1) How often should the request be retransmitted to ge= t a qualified
>>>>> loss measure ?
>>>>> 2) What's the frequency of the retransmissions/pac= ing or wating
>>>>> between retransmissions ?
>>>>
>>>> A STUN client retransmits a STUN request starting with an = interval of RTO,
>>> doubling after each retransmission. Retransmissions continue u= ntil a
>>> response is received, or until a total of Rc requests have bee= n sent. It is
>>> discussed in https://tools.ietf.org/html/rfc5389= in detail.
>>>
>>> Okay, it wasn=E2=80=99t clear to me if you would send more ret= ransmissions just to
>>> measure loss.
>>
>> If there is response then there is no need to retransmit the STUN = request.
>>
>>> If you don=E2=80=99t, how much retransmission do you usually s= ee and
>>> is this sufficient to get a reliable loss measure (see questio= n one) ?
>>
>> If there is no response then the request is retransmitted, the rat= e of retransmissions and number of retransmissions are dependent on the pro= tocol using STUN (e.g. ICE calculates retransmission timer (RTO) differentl= y for media and non-media streams). It's up to the application if it wa= nts to try just one transaction or NNN number of transactions to measure th= e path characteristics.
>
> Would it be possible to give some recommendation in this doc what an a= pplication needs to do to get an appropriate measure?
>
> Mirja
>
>
>>
>> -Tiru
>>
>>>
>>>>
>>>>> 3) How big is the overhead when retransmitting several= times ?
>>>>
>>>> The overhead introduced by the new PATH-CHARACTERISTIC att= ribute is
>>> just 4 bytes.
>>>
>>> Okay, again, wasn=E2=80=99t clear to me if you would need more= request than usually
>>> or not.
>>>
>>> Mirja
>>>
>>>
>>>
>>>>
>>>> -Tiru
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>
>>
>




--
=
Founder, CEO, callst= ats.io
http://= www.callstats.io
Analytics and Optimizations for WebRTC.

We a= re hiring: www.= callstats.io/jobs/
--001a11c2b75a680c570530af2ed3-- From nobody Mon Apr 18 13:45:16 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A712DEC1; Mon, 18 Apr 2016 13:45:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160418204513.11071.23097.idtracker@ietfa.amsl.com> Date: Mon, 18 Apr 2016 13:45:13 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-07.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 18 Apr 2016 20:45:14 -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 of the IETF. Title : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-07.txt Pages : 15 Date : 2016-04-18 Abstract: Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 18 13:46:41 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8818512E785 for ; Mon, 18 Apr 2016 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0cRFeklCJ3a for ; Mon, 18 Apr 2016 13:46:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183A012E784 for ; Mon, 18 Apr 2016 13:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2164; q=dns/txt; s=iport; t=1461012398; x=1462221998; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hHZWKuxCxu5Itu/E2P4FUxu1gwVFOOIU9dJD9e1ex5k=; b=UDwO/eoB2tMhmTHT0S1VkC+lqnAdpEyLQG+4XTtz5M4Qw4BXjYM1BRXo +9gsQ5bpM0qOVRMLHiiuxWGRA4VLNZrlxlO4U5gVqrQMpiAlch2F1vJoy MUPmtKZJEiuovV5lxaxzvkjXBAig6ZMrxMjcApVfhW53gU5SgOvFeRC+z w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AgDqRhVX/49dJa1dgzhTfQa6JAENg?= =?us-ascii?q?XEXDYVqAoE6OBQBAQEBAQEBZRwLhEIBAQQBAQFrGwIBCEYnCyUCBBOIKQ68WQE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBARmGIYRLhBkOFoVYBY4LigMBhXeIFoFnToQAiFyPKgEeA?= =?us-ascii?q?QFCg2hsh30/fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="261148143" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2016 20:46:37 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3IKkaAH023517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Apr 2016 20:46:37 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 16:46:35 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 16:46:36 -0400 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-07.txt Thread-Index: AQHRmbNme/lht7QuiUaEwNLakWusWg== Date: Mon, 18 Apr 2016 20:46:36 +0000 Message-ID: References: <20160418204513.11071.23097.idtracker@ietfa.amsl.com> In-Reply-To: <20160418204513.11071.23097.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.87.40] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1138C25315E7FD4889F2EE23F19666DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-07.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 20:46:40 -0000 We=B9ve submitted a revised TRAM auto discovery draft that reflect changes to the security considerations section based on Brandon=B9s feedback. -Prashanth On 4/18/16, 1:45 PM, "tram on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the TURN Revised and Modernized of the IETF. > > Title : TURN Server Auto Discovery > Authors : Prashanth Patil > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-tram-turn-server-discovery-07.txt > Pages : 15 > Date : 2016-04-18 > >Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control of > the application or TURN service provider, and not the enterprise, > ISP, or the network in which the client is located. Enterprises and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes three such mechanisms for > TURN server discovery. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-server-discovery-= 07 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Tue Apr 19 06:13:12 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 078E612D9C9; Tue, 19 Apr 2016 06:13:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419131308.31482.35784.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 06:13:08 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Stephen Farrell's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 13:13:09 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-tram-stun-path-data-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like, but am a little surprised by, the MUST NOT at the end of section 6. Thanks though! From nobody Tue Apr 19 12:20:11 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3D512E2D8; Tue, 19 Apr 2016 12:20:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419192007.31617.47250.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 12:20:07 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Kathleen Moriarty's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 19:20:07 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tram-stun-path-data-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The draft looks good, I would just add in the security section that the information could be observed passively if not encrypted (especially since that is an option) and used for reconnaissance and later attacks. From nobody Tue Apr 19 13:18:23 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CD312D5AD; Tue, 19 Apr 2016 13:18:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419201822.31508.3712.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 13:18:22 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Alissa Cooper's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 20:18:22 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tram-stun-path-data-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = General = I find the name the name PATH-CHARACTERISTIC a bit general for this, since it specifies a single specific characteristic while one could imagine other characteristics one might want to specify in the future. Would suggest naming this something more specific. = Section 1 = I think it will be important for future ICE specs to document expected usage of this feature, and those won't necessarily be limited to continuous nomination. I don't think there is anything to be done in this draft, but just noting here that close coordination between TRAM and ICE will be necessary to make sure this happens going forward. = Section 3.3 = Section 3.1 defines ReTransCnt as "Number of times request is re-transmitted with the same transaction ID to the server," but then the examples in 3.3 all show the client populating this field with 1 in its first request. If the number is supposed to be about *re-transmits* (not transmits, but re-transmits), I would have expected it to be 0 in the first request, then 1 upon an actual re-transmit. Why do these start at 1? It may be that simply re-wording the use of "re-transmits" in 3.1 would fix this. Also, in the first two examples, why do the ReTransCnt values keep incrementing after a successful response? For example, in the normal case, why does the client re-transmit its request with ReTransCnt equal to 2 when it received a successful response? From nobody Tue Apr 19 15:30:21 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC2C12E42E; Tue, 19 Apr 2016 15:30:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419223017.31528.61658.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 15:30:17 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Ben Campbell's Yes on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 22:30:18 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tram-stun-path-data-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comments. In addition: - Is there any expected interaction between this and the ongoing 5245bis work? - 3, last paragraph: "distinguish STUN responses from the re-transmitted requests." I think you mean to distinguish the response to one request from a response to a retransmitted request. But it sounds like you mean to distinguish the response from the request itself. -4 : resends of the same request: you’ve used the term retransmission so far. I assume this means the same—any reason not to be consistent? From nobody Wed Apr 20 00:34:44 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A155F12D761; Wed, 20 Apr 2016 00:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC1zdxNl_fBm; Wed, 20 Apr 2016 00:34:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D7112D72C; Wed, 20 Apr 2016 00:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13774; q=dns/txt; s=iport; t=1461137676; x=1462347276; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WTK4TFtTCJPj059CMtFX6aIlIGsUklSp3Wf32Og7hoQ=; b=iKQl7jA8Bz3PlPUm/G06un2e85/SdSrknzl20xjRRX5xEiOX6GjsP01g zJ7dq8c79w6/SpnQC+rLWBsnGI++NaR0TFY4YTsAGmklE2GAEWvb7ORPo JmgxfB9mKXW5Xgae9T0rrfr1nWLM4Jm7XGuvTwop1sAHEvjjQS/PCuXu2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgA0MBdX/5xdJa1egmtNgVAGtHGCY?= =?us-ascii?q?4IPAQ2BcYYOAhyBJTgUAQEBAQEBAWUnhEIBAQQjVhACAQg/AwICAjAUEQIEDgW?= =?us-ascii?q?IKawmkUUBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdYJWhBkOgxgrgisFjVOFS?= =?us-ascii?q?4RwAY4SjxCPKwEeAQFCggQaFYE1bIdWP34BAQE?= X-IronPort-AV: E=Sophos; i="5.24,508,1454976000"; d="scan'208,217"; a="99259130" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 07:34:35 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3K7YY7v015894 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 07:34:35 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 03:34:34 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 03:34:34 -0400 From: "Pal Martinsen (palmarti)" To: Alissa Cooper Thread-Topic: Alissa Cooper's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) Thread-Index: AQHRmnigODG6UZSeYUWHurET+HGvfZ+SvGkA Date: Wed, 20 Apr 2016 07:34:34 +0000 Message-ID: References: <20160419201822.31508.3712.idtracker@ietfa.amsl.com> In-Reply-To: <20160419201822.31508.3712.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.109.124] Content-Type: multipart/alternative; boundary="_000_C34E3B26DEA84B6694B8098EDFD032AFciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , Simon Perreault , "tram@ietf.org" , The IESG , "tram-chairs@ietf.org" Subject: Re: [tram] Alissa Cooper's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:34:38 -0000 --_000_C34E3B26DEA84B6694B8098EDFD032AFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAxOSBBcHIgMjAxNiwgYXQgMjI6MTgsIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3 LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5pbj4+IHdyb3RlOg0KDQoNCj0gR2VuZXJhbCA9DQoN CkkgZmluZCB0aGUgbmFtZSB0aGUgbmFtZSBQQVRILUNIQVJBQ1RFUklTVElDIGEgYml0IGdlbmVy YWwgZm9yIHRoaXMsDQpzaW5jZSBpdCBzcGVjaWZpZXMgYSBzaW5nbGUgc3BlY2lmaWMgY2hhcmFj dGVyaXN0aWMgd2hpbGUgb25lIGNvdWxkDQppbWFnaW5lIG90aGVyIGNoYXJhY3RlcmlzdGljcyBv bmUgbWlnaHQgd2FudCB0byBzcGVjaWZ5IGluIHRoZSBmdXR1cmUuDQpXb3VsZCBzdWdnZXN0IG5h bWluZyB0aGlzIHNvbWV0aGluZyBtb3JlIHNwZWNpZmljLg0KDQpJIGFncmVlLg0KDQpIb3cgYWJv dXQ7IFRSQU5TQUNUSU9OX1RSQU5TTUlUX0NPVU5URVIsIHdpdGggdGhlIGZpZWxkcyBqdXN0IGNh bGxlZCByZXEgYW5kIHJlc3AuDQoNCkJ5IGV4cGxpY2l0bHkgY2FsbGluZyBpdCB0cmFuc21pdCBh bmQgbm90IHJldHJhbnNtaXQgd2UgYWxzbyBnZXQgcmlkIG9mIHRoZSBwcm9ibGVtcyByZWdhcmRp bmcgd2hhdCB2YWx1ZSBkbyB0aGUgZmlyc3QgcmV0cmFuc21pdCBoYXZlLiBBbmQgcmVzcG9uc2Vz IHJlYWxseSBoYXZlIG5vIHJldHJhbnNtaXRzLiBTbGlnaHQgcmV3b3JkaW5nIGluIHRoZSBkb2N1 bWVudCBpcyBuZWVkZWQgdG8gcmVwaHJhc2UgZnJvbSByZXRyYW5zbWl0IHRvIGp1c3QgdXNpbmcg dHJhbnNtaXQgd2l0aCB0aGUgc2FtZSB0cmFuc2FjdGlvbiBJRC4NCg0KRmlndXJlIDEgYW5kIEZp Z3VyZSAyIGFyZSBpZGVudGljYWwuIFdvdWxkIGl0IGJlIGJldHRlciB0byBoYXZlIG9uZSBzZWN0 aW9uIGRlc2NyaWJpbmcgdGhlIGF0dHJpYnV0ZSBhbmQgdGhlbiB0aGUgdHdvIHNlY3Rpb25zIGNh biBkZXNjcmliZSB1c2FnZSB3aXRoIHJlcXVlc3QgYW5kIHJlc3BvbnNlPw0KDQoNCkluIGhpbmRz aWdodCBJIGFsc28gZmluZCB0aGUgbmFtaW5nIGEgYml0IHRvIGdlbmVyaWMuIEl0IGNhbGN1bGF0 ZXMgZnJhY3Rpb25hbCBsb3NzIGFuZCBSVFQuDQpJIHRoaW5rIGEgYmV0dGVyIG5hbWUgd291bGQg YmU7IOKAnERpc2NvdmVyeSBvZiBmcmFjdGlvbmFsIGxvc3MgYW5kIFJUVCB1c2luZyBTVFVO4oCd DQoNClRoZSBkcmFmdCBhbHNvIHRhbGtzIGFib3V0IGxvc3MuIEkgYW0gbWlzc2luZyBhIGRpc2N1 c3Npb24gb2YgaG93IHRvIGhhbmRsZSBjcm9zc2luZyByZXFzIGFuZCByZXNwcy4gU29tZXRpbWVz IGEgY2xpZW50IHdvdWxkIGhhdmUgc2VudCBhIHJldHJhbnNtaXQgYmVmb3JlIHJlY2VpdmluZyB0 aGUgb3JpZ2luYWwgcmVzcG9uc2UuIEEgc2VjdGlvbiBvbiBob3cgdG8gY2FsY3VsYXRlIFJUVCAo VGhpcyBpcyBub3cgc2ltcGxlIGJlY2F1c2Ugb2YgdGhlIGNvdW50ZXIpLCBhbmQgbG9zcyAoV2Ug bmVlZCB0byB3YWl0IHRvIHNlZSBpZiB3ZSBhY3R1YWxseSBnZXQgYSByZXNwb25zZSBmcm9tIHRo ZSBzZWNvbmQgcmV0cmFuc21pdD8pIGluIHRoYXQgc2NlbmFyaW8gd2lsbCBiZSB1c2VmdWwgZm9y IGltcGxlbWVudGVycy4NCg0KDQo9IFNlY3Rpb24gMSA9DQoNCkkgdGhpbmsgaXQgd2lsbCBiZSBp bXBvcnRhbnQgZm9yIGZ1dHVyZSBJQ0Ugc3BlY3MgdG8gZG9jdW1lbnQgZXhwZWN0ZWQNCnVzYWdl IG9mIHRoaXMgZmVhdHVyZSwgYW5kIHRob3NlIHdvbid0IG5lY2Vzc2FyaWx5IGJlIGxpbWl0ZWQg dG8NCmNvbnRpbnVvdXMgbm9taW5hdGlvbi4gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGlu ZyB0byBiZSBkb25lIGluIHRoaXMNCmRyYWZ0LCBidXQganVzdCBub3RpbmcgaGVyZSB0aGF0IGNs b3NlIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIFRSQU0gYW5kIElDRQ0Kd2lsbCBiZSBuZWNlc3Nhcnkg dG8gbWFrZSBzdXJlIHRoaXMgaGFwcGVucyBnb2luZyBmb3J3YXJkLg0KDQoNCklNSE8gdGhlcmUg c2hvdWxkIGJlIG5vIOKAnHVwd2FyZHPigJ0gZGVwZW5kZW5jaWVzLiBUUkFNIHNob3VsZCBidWls ZCBnZW5lcmljIGJ1aWxkaW5nIGJsb2NrcywgaG93ZXZlciBzb21ldGltZXMgdGhleSBhcmUgdGFp bG9yZWQgZm9yIHNvbWUgdXNlLiBJbiB0aGlzIGNhc2UgSSB0aGluayBpdCB3b3VsZCBiZSBzdWZm aWNpZW50IHRvIGRlc2NyaWJlIHRoYXQgSUNFIGNhbiB1c2UgdGhpcyB0byBkbyDigJxzbWFydGVy IHRoaW5nc+KAnSh0bSkuICBJIHdvdWxkIHByZWZlciBpZiB3ZSBsb3NzIHRoZSByZWZlcmVuY2Vz IHRvIHNwZWNpZmljIElDRSBkcmFmdHMgdGhhdCBtYXkgb3IgbWF5IG5vdCBnbyBmb3J3YXJkLg0K DQpGb3IgbWUgdGhpcyBkcmFmdCBpcyB1c2VmdWwgZHVlIHRvIHRoZSBuZXcgbWV0cmljcyBpdCBw cm92aWRlcy4gKFRoYXQgaXMgd2h5IEthdGhsZWVucyBjb21tZW50IG9uIHRoZSBzZWN1cml0eSBz ZWN0aW9uIGlzIGltcG9ydGFudC4pDQoNCj0gU2VjdGlvbiAzLjMgPQ0KDQpTZWN0aW9uIDMuMSBk ZWZpbmVzIFJlVHJhbnNDbnQgYXMgIk51bWJlciBvZiB0aW1lcyByZXF1ZXN0IGlzDQpyZS10cmFu c21pdHRlZCB3aXRoIHRoZSBzYW1lIHRyYW5zYWN0aW9uIElEIHRvIHRoZSBzZXJ2ZXIsIiBidXQg dGhlbiB0aGUNCmV4YW1wbGVzIGluIDMuMyBhbGwgc2hvdyB0aGUgY2xpZW50IHBvcHVsYXRpbmcg dGhpcyBmaWVsZCB3aXRoIDEgaW4gaXRzDQpmaXJzdCByZXF1ZXN0LiBJZiB0aGUgbnVtYmVyIGlz IHN1cHBvc2VkIHRvIGJlIGFib3V0ICpyZS10cmFuc21pdHMqIChub3QNCnRyYW5zbWl0cywgYnV0 IHJlLXRyYW5zbWl0cyksIEkgd291bGQgaGF2ZSBleHBlY3RlZCBpdCB0byBiZSAwIGluIHRoZQ0K Zmlyc3QgcmVxdWVzdCwgdGhlbiAxIHVwb24gYW4gYWN0dWFsIHJlLXRyYW5zbWl0LiBXaHkgZG8g dGhlc2Ugc3RhcnQgYXQNCjE/IEl0IG1heSBiZSB0aGF0IHNpbXBseSByZS13b3JkaW5nIHRoZSB1 c2Ugb2YgInJlLXRyYW5zbWl0cyIgaW4gMy4xDQp3b3VsZCBmaXggdGhpcy4NCg0KUmVuYW1pbmcg b2YgYXR0cmlidXRlIGFuZCBmaWVsZHMgYW5kIHJld29yZGluZyB0byBjb25zaXN0ZW50bHkgdGFs ayBhYm91dCB0cmFuc21pdHMgd2l0aCBzYW1lIHRyYW5zYWN0aW9uIElEIHdvdWxkIGZpeCB0aGlz Lg0KDQoNCkFsc28sIGluIHRoZSBmaXJzdCB0d28gZXhhbXBsZXMsIHdoeSBkbyB0aGUgUmVUcmFu c0NudCB2YWx1ZXMga2VlcA0KaW5jcmVtZW50aW5nIGFmdGVyIGEgc3VjY2Vzc2Z1bCByZXNwb25z ZT8gRm9yIGV4YW1wbGUsIGluIHRoZSBub3JtYWwNCmNhc2UsIHdoeSBkb2VzIHRoZSBjbGllbnQg cmUtdHJhbnNtaXQgaXRzIHJlcXVlc3Qgd2l0aCBSZVRyYW5zQ250IGVxdWFsDQp0byAyIHdoZW4g aXQgcmVjZWl2ZWQgYSBzdWNjZXNzZnVsIHJlc3BvbnNlPw0KDQpJIHRoaW5rIGl0IGlzIGEgYnVn LiBCdXQgaWYgdGhlIGNsaWVudHMgd2FudCB0byBzZW5kIG1vcmUgcGFja2V0cyB0byBnZXQgYSBi ZXR0ZXIgbWVhc3VyZW1lbnRzIG9mIHRoZSBmcmFjdGlvbmFsIGxvc3MgaXQgbWlnaHQgZW5kIHVw IHdpdGggYSByZXRyYW5zbWl0IGluc3RlYWQgb2YgY3JlYXRpbmcgYSBuZXcgdHJhbnNhY3Rpb24u IFRoaXMgbWlnaHQgc2ltcGxpZnkgdGhlIGNsaWVudCBhIGJpdCBhcyBpdCBjYW4gZWFzaWx5IGNv bGxlY3QgbWV0cmljcyBieSBsb29raW5nIGF0IHRoZSBuZXcgYXR0cmlidXRlLiBUaGlzIG1heSBi cmVhayBzb21ldGhpbmcgaW4gdGhlIFNUVU4gc3BlYyBzbyB0aGlzIG5lZWRzIHRvIGJlIGludmVz dGlnYXRlZCBhbmQgYmV0dGVyIGRlc2NyaWJlZC4NCg0KRGlzY2xhaW1lci4uIEkgYW0gb25lIG9m IHRoZSBjby1hdXRob3JzLiBJIGFtIHNvcnJ5IGZvciBub3QgY2F0Y2hpbmcgc29tZSBvZiB0aGVz ZSBuZXcgaXNzdWVzIGVhcmxpZXIuIEkganVzdCBzdGFydGVkIHRvIGltcGxlbWVudCB0aGlzIHRo aW5ncyBiZWNhbWUgYSBiaXQgY2xlYXJlciB3aGVuIHRoZSBkcmFmdCBuZWVkcyB0byBiZSB0cmFu c2Zvcm1lZCBpbnRvIGFjdHVhbCBydW5uaW5nIGNvZGUuDQoNCi4tLg0KUMOlbC1FcmlrDQo= --_000_C34E3B26DEA84B6694B8098EDFD032AFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <408461322FFA23429BC3AEC97808561A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxOSBB cHIgMjAxNiwgYXQgMjI6MTgsIEFsaXNzYSBDb29wZXIgJmx0OzxhIGhyZWY9Im1haWx0bzphbGlz c2FAY29vcGVydy5pbiIgY2xhc3M9IiI+YWxpc3NhQGNvb3BlcncuaW48L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCj0gR2VuZXJhbCA9PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBmaW5k IHRoZSBuYW1lIHRoZSBuYW1lIFBBVEgtQ0hBUkFDVEVSSVNUSUMgYSBiaXQgZ2VuZXJhbCBmb3Ig dGhpcyw8YnIgY2xhc3M9IiI+DQpzaW5jZSBpdCBzcGVjaWZpZXMgYSBzaW5nbGUgc3BlY2lmaWMg Y2hhcmFjdGVyaXN0aWMgd2hpbGUgb25lIGNvdWxkPGJyIGNsYXNzPSIiPg0KaW1hZ2luZSBvdGhl ciBjaGFyYWN0ZXJpc3RpY3Mgb25lIG1pZ2h0IHdhbnQgdG8gc3BlY2lmeSBpbiB0aGUgZnV0dXJl LjxiciBjbGFzcz0iIj4NCldvdWxkIHN1Z2dlc3QgbmFtaW5nIHRoaXMgc29tZXRoaW5nIG1vcmUg c3BlY2lmaWMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+SSBhZ3JlZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PkhvdyBhYm91dDsgVFJBTlNBQ1RJT05fVFJBTlNNSVRfQ09VTlRFUiwgd2l0aCB0 aGUgZmllbGRzIGp1c3QgY2FsbGVkIHJlcSBhbmQgcmVzcC48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMy4zMzMzcHg7IHdpZG93czogMTsiIGNsYXNzPSIiPjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkJ5IGV4cGxpY2l0bHkgY2FsbGluZyBpdCB0cmFuc21p dCBhbmQgbm90IHJldHJhbnNtaXQgd2UgYWxzbyBnZXQgcmlkIG9mIHRoZSBwcm9ibGVtcyByZWdh cmRpbmcgd2hhdCB2YWx1ZSBkbyB0aGUgZmlyc3QgcmV0cmFuc21pdCBoYXZlLiBBbmQgcmVzcG9u c2VzIHJlYWxseSBoYXZlIG5vIHJldHJhbnNtaXRzLiBTbGlnaHQgcmV3b3JkaW5nIGluIHRoZSBk b2N1bWVudCBpcyBuZWVkZWQgdG8gcmVwaHJhc2UgZnJvbSByZXRyYW5zbWl0IHRvDQoganVzdCB1 c2luZyB0cmFuc21pdCB3aXRoIHRoZSBzYW1lIHRyYW5zYWN0aW9uIElELiZuYnNwOzwvZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkZpZ3VyZSAxIGFuZCBGaWd1cmUgMiBhcmUgaWRlbnRpY2FsLiBXb3VsZCBpdCBiZSBiZXR0ZXIg dG8gaGF2ZSBvbmUgc2VjdGlvbiBkZXNjcmliaW5nIHRoZSBhdHRyaWJ1dGUgYW5kIHRoZW4gdGhl IHR3byBzZWN0aW9ucyBjYW4gZGVzY3JpYmUgdXNhZ2Ugd2l0aCByZXF1ZXN0IGFuZCByZXNwb25z ZT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PkluIGhpbmRzaWdodCBJIGFs c28gZmluZCB0aGUgbmFtaW5nIGEgYml0IHRvIGdlbmVyaWMuIEl0IGNhbGN1bGF0ZXMgZnJhY3Rp b25hbCBsb3NzIGFuZCBSVFQuJm5ic3A7PC9kaXY+DQo8ZGl2PkkgdGhpbmsgYSBiZXR0ZXIgbmFt ZSB3b3VsZCBiZTsg4oCcRGlzY292ZXJ5IG9mIGZyYWN0aW9uYWwgbG9zcyBhbmQgUlRUIHVzaW5n IFNUVU7igJ08L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBkcmFm dCBhbHNvIHRhbGtzIGFib3V0IGxvc3MuIEkgYW0gbWlzc2luZyBhIGRpc2N1c3Npb24gb2YgaG93 IHRvIGhhbmRsZSBjcm9zc2luZyByZXFzIGFuZCByZXNwcy4gU29tZXRpbWVzIGEgY2xpZW50IHdv dWxkIGhhdmUgc2VudCBhIHJldHJhbnNtaXQgYmVmb3JlIHJlY2VpdmluZyB0aGUgb3JpZ2luYWwg cmVzcG9uc2UuIEEgc2VjdGlvbiBvbiBob3cgdG8gY2FsY3VsYXRlIFJUVCAoVGhpcyBpcyBub3cg c2ltcGxlIGJlY2F1c2Ugb2YNCiB0aGUgY291bnRlciksIGFuZCBsb3NzIChXZSBuZWVkIHRvIHdh aXQgdG8gc2VlIGlmIHdlIGFjdHVhbGx5IGdldCBhIHJlc3BvbnNlIGZyb20gdGhlIHNlY29uZCBy ZXRyYW5zbWl0PykgaW4gdGhhdCBzY2VuYXJpbyB3aWxsIGJlIHVzZWZ1bCBmb3IgaW1wbGVtZW50 ZXJzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPj0gU2VjdGlvbiAxID08YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJIHRoaW5rIGl0IHdpbGwgYmUgaW1wb3J0YW50IGZvciBmdXR1cmUgSUNFIHNw ZWNzIHRvIGRvY3VtZW50IGV4cGVjdGVkPGJyIGNsYXNzPSIiPg0KdXNhZ2Ugb2YgdGhpcyBmZWF0 dXJlLCBhbmQgdGhvc2Ugd29uJ3QgbmVjZXNzYXJpbHkgYmUgbGltaXRlZCB0bzxiciBjbGFzcz0i Ij4NCmNvbnRpbnVvdXMgbm9taW5hdGlvbi4gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0aGlu ZyB0byBiZSBkb25lIGluIHRoaXM8YnIgY2xhc3M9IiI+DQpkcmFmdCwgYnV0IGp1c3Qgbm90aW5n IGhlcmUgdGhhdCBjbG9zZSBjb29yZGluYXRpb24gYmV0d2VlbiBUUkFNIGFuZCBJQ0U8YnIgY2xh c3M9IiI+DQp3aWxsIGJlIG5lY2Vzc2FyeSB0byBtYWtlIHN1cmUgdGhpcyBoYXBwZW5zIGdvaW5n IGZvcndhcmQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PklNSE8gdGhlcmUg c2hvdWxkIGJlIG5vIOKAnHVwd2FyZHPigJ0gZGVwZW5kZW5jaWVzLiBUUkFNIHNob3VsZCBidWls ZCBnZW5lcmljIGJ1aWxkaW5nIGJsb2NrcywgaG93ZXZlciBzb21ldGltZXMgdGhleSBhcmUgdGFp bG9yZWQgZm9yIHNvbWUgdXNlLiBJbiB0aGlzIGNhc2UgSSB0aGluayBpdCB3b3VsZCBiZSBzdWZm aWNpZW50IHRvIGRlc2NyaWJlIHRoYXQgSUNFIGNhbiB1c2UgdGhpcyB0byBkbyDigJxzbWFydGVy IHRoaW5nc+KAnSh0bSkuICZuYnNwO0kgd291bGQNCiBwcmVmZXIgaWYgd2UgbG9zcyB0aGUgcmVm ZXJlbmNlcyB0byBzcGVjaWZpYyBJQ0UgZHJhZnRzIHRoYXQgbWF5IG9yIG1heSBub3QgZ28gZm9y d2FyZC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkZvciBt ZSB0aGlzIGRyYWZ0IGlzIHVzZWZ1bCBkdWUgdG8gdGhlIG5ldyBtZXRyaWNzIGl0IHByb3ZpZGVz LiAoVGhhdCBpcyB3aHkgS2F0aGxlZW5zIGNvbW1lbnQgb24gdGhlIHNlY3VyaXR5IHNlY3Rpb24g aXMgaW1wb3J0YW50Lik8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PSBTZWN0aW9uIDMu MyA9PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbiAzLjEgZGVmaW5lcyBSZVRy YW5zQ250IGFzICZxdW90O051bWJlciBvZiB0aW1lcyByZXF1ZXN0IGlzPGJyIGNsYXNzPSIiPg0K cmUtdHJhbnNtaXR0ZWQgd2l0aCB0aGUgc2FtZSB0cmFuc2FjdGlvbiBJRCB0byB0aGUgc2VydmVy LCZxdW90OyBidXQgdGhlbiB0aGU8YnIgY2xhc3M9IiI+DQpleGFtcGxlcyBpbiAzLjMgYWxsIHNo b3cgdGhlIGNsaWVudCBwb3B1bGF0aW5nIHRoaXMgZmllbGQgd2l0aCAxIGluIGl0czxiciBjbGFz cz0iIj4NCmZpcnN0IHJlcXVlc3QuIElmIHRoZSBudW1iZXIgaXMgc3VwcG9zZWQgdG8gYmUgYWJv dXQgKnJlLXRyYW5zbWl0cyogKG5vdDxiciBjbGFzcz0iIj4NCnRyYW5zbWl0cywgYnV0IHJlLXRy YW5zbWl0cyksIEkgd291bGQgaGF2ZSBleHBlY3RlZCBpdCB0byBiZSAwIGluIHRoZTxiciBjbGFz cz0iIj4NCmZpcnN0IHJlcXVlc3QsIHRoZW4gMSB1cG9uIGFuIGFjdHVhbCByZS10cmFuc21pdC4g V2h5IGRvIHRoZXNlIHN0YXJ0IGF0PGJyIGNsYXNzPSIiPg0KMT8gSXQgbWF5IGJlIHRoYXQgc2lt cGx5IHJlLXdvcmRpbmcgdGhlIHVzZSBvZiAmcXVvdDtyZS10cmFuc21pdHMmcXVvdDsgaW4gMy4x PGJyIGNsYXNzPSIiPg0Kd291bGQgZml4IHRoaXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+UmVuYW1pbmcgb2YgYXR0cmli dXRlIGFuZCBmaWVsZHMgYW5kIHJld29yZGluZyB0byBjb25zaXN0ZW50bHkgdGFsayBhYm91dCB0 cmFuc21pdHMgd2l0aCBzYW1lIHRyYW5zYWN0aW9uIElEIHdvdWxkIGZpeCB0aGlzLiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ QWxzbywgaW4gdGhlIGZpcnN0IHR3byBleGFtcGxlcywgd2h5IGRvIHRoZSBSZVRyYW5zQ250IHZh bHVlcyBrZWVwPGJyIGNsYXNzPSIiPg0KaW5jcmVtZW50aW5nIGFmdGVyIGEgc3VjY2Vzc2Z1bCBy ZXNwb25zZT8gRm9yIGV4YW1wbGUsIGluIHRoZSBub3JtYWw8YnIgY2xhc3M9IiI+DQpjYXNlLCB3 aHkgZG9lcyB0aGUgY2xpZW50IHJlLXRyYW5zbWl0IGl0cyByZXF1ZXN0IHdpdGggUmVUcmFuc0Nu dCBlcXVhbDxiciBjbGFzcz0iIj4NCnRvIDIgd2hlbiBpdCByZWNlaXZlZCBhIHN1Y2Nlc3NmdWwg cmVzcG9uc2U/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+SSB0aGluayBpdCBpcyBhIGJ1Zy4gQnV0IGlmIHRoZSBjbGllbnRz IHdhbnQgdG8gc2VuZCBtb3JlIHBhY2tldHMgdG8gZ2V0IGEgYmV0dGVyIG1lYXN1cmVtZW50cyBv ZiB0aGUgZnJhY3Rpb25hbCBsb3NzIGl0IG1pZ2h0IGVuZCB1cCB3aXRoIGEgcmV0cmFuc21pdCBp bnN0ZWFkIG9mIGNyZWF0aW5nIGEgbmV3IHRyYW5zYWN0aW9uLiBUaGlzIG1pZ2h0IHNpbXBsaWZ5 IHRoZSBjbGllbnQgYSBiaXQgYXMgaXQgY2FuIGVhc2lseSBjb2xsZWN0DQogbWV0cmljcyBieSBs b29raW5nIGF0IHRoZSBuZXcgYXR0cmlidXRlLiBUaGlzIG1heSBicmVhayBzb21ldGhpbmcgaW4g dGhlIFNUVU4gc3BlYyBzbyB0aGlzIG5lZWRzIHRvIGJlIGludmVzdGlnYXRlZCBhbmQgYmV0dGVy IGRlc2NyaWJlZC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkRpc2Ns YWltZXIuLiBJIGFtIG9uZSBvZiB0aGUgY28tYXV0aG9ycy4gSSBhbSBzb3JyeSBmb3Igbm90IGNh dGNoaW5nIHNvbWUgb2YgdGhlc2UgbmV3IGlzc3VlcyBlYXJsaWVyLiBJIGp1c3Qgc3RhcnRlZCB0 byBpbXBsZW1lbnQgdGhpcyB0aGluZ3MgYmVjYW1lIGEgYml0IGNsZWFyZXIgd2hlbiB0aGUgZHJh ZnQgbmVlZHMgdG8gYmUgdHJhbnNmb3JtZWQgaW50byBhY3R1YWwgcnVubmluZyBjb2RlLjwvZGl2 Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi4tLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5Qw6VsLUVyaWs8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C34E3B26DEA84B6694B8098EDFD032AFciscocom_-- From nobody Wed Apr 20 01:57:15 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B64B312E989; Wed, 20 Apr 2016 01:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420085710.32392.13358.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 01:57:10 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, lionel.morand@orange.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 08:57:11 -0000 Benoit Claise has entered the following ballot position for draft-ietf-tram-stun-path-data-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't think this is appropriate to include a URL as affiliation (see callstats.io on the first page). Below is Lionel Morand's OPS DIR review: I think the draft is ready for publication as it is, even if some clarifications would help the reader for a correct use of the proposed solution. The comments listed below should not block the publication process but it would be nice if authors could address them if a new version of the draft is required. Main comments: - The whole solution is introduced as an improvement of the ICE prioritization formula. With the PATH-CHARACTERISTIC attribute, it is understood that there are additional criteria for selecting the most suitable candidate. But finally, it is not clearly said how the loss and RTT info modify/impact/improve the formula recommended in the RFC 5245. If it is left outside the document, please indicate it in the text. - Moreover, the case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field. Other comments: - In section 1. Introduction: The ICE [RFC5245] mechanism uses a prioritization formula to order the candidate pairs and perform connectivity checks, in which the most preferred address pairs are tested first and when a sufficiently good pair is discovered, that pair is used for communications and further connectivity tests are stopped. It is maybe too obvious and not essential for people involved in this work but could help the reader to know that ICE is a technique for NAT traversal and not a general purpose solution. - In section 3. Path characteristics determination mechanism This document defines a new comprehension-optional STUN attribute PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN Type TBD- CA. This type is in the comprehension-optional range, which means that STUN agents can safely ignore the attribute if they do not understand it. It is said in another section but could be good to clarify that "safely ignore" means that when the new attribute is not supported by the server, the client naturally fallbacks to existing STUN/ICE procedures. Instead of having a format for the request (section 3.1) and the response (section 3.2) that are the same, it would be clearer to have a section describing the format of the attribute (section 3.1) and addition clarifying the use in the request (section 3.2) and the response (section 3.3). - In section 3.1. The PATH-CHARACTERISTIC attribute in request The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte Value. I don't know what is the current IETF policy but I would prefer "32-bit value" instead of "4-byte value". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved, should be 0 | ReTransCnt | RespTransCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PATH-CHARACTERISTIC attribute in request Why are the two first octects marked as "reserved"? I'm assuming that these bits are present for alignment with a fixed size of STUN attributes but it should be clarified. And if they are "should" should be replaced by "must". I think it would be easier to left "reserved" in the figure and describe its contents in the description given below the figure. - In section 3.2. . The PATH-CHARACTERISTIC attribute in response When a server receives a STUN request that includes a PATH- CHARACTERISTIC attribute, it processes the request as per the STUN protocol [RFC5389] plus the specific rules mentioned here. It is maybe obvious or already described in RFC 5389, but I assume that the server must include the new attribute in the response if not received in the request. o If the server is stateless or does not want to remember the transaction ID then it would populate value 0 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in the response. If the server is stateful then it populates RespTransCnt with the number of responses it has sent for the STUN request. Is there any recommendation between "stateless vs stateful" for an optimal support of this new attribute? If it is, we could find something like "SHOULD be stateful but MAYBE stateless"... - In section 3.3. Example Operation It should be clarified that the server is stateful in this example. Otherwise, the RespTransCnt field in PATH-CHARACTERISTIC attribute in the response is of no use. Could be "stateful server" instead of "server" in the description of the example. Moreover, as commented earlier, The case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field. - In section 4. Use cases o When an endpoint has multiple interfaces (for example 3G, 4G, WiFi, VPN, etc.), an ICE agent can choose the interfaces for application data according to the path characteristics. After STUN responses to STUN checks are received, the ICE agent using regular nomination can sort the ICE candidate pairs according to the path characteristics (loss and RTT) discovered using STUN. The controlling agent can then assign the highest priority to candidate pair which best fulfills the desired path characteristics. However, it should be noted that the path capacity or throughput is not determined by these STUN checks. If an endpoint needs to pick paths based on capacity, it would have to send application data on those paths. This text illustrates the main comment given above. It is said: the ICE agent using regular nomination can sort the ICE candidate pairs according to the path characteristics (loss and RTT) discovered using STUN. But there is no clue on how the agent will do. From nobody Wed Apr 20 03:11:38 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9F12E864 for ; Wed, 20 Apr 2016 03:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 MOdCtPhR5YIy for ; Wed, 20 Apr 2016 03:11:30 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5318012E959 for ; Wed, 20 Apr 2016 03:11:29 -0700 (PDT) Received: (qmail 9636 invoked from network); 20 Apr 2016 12:11:26 +0200 Received: from p5dec2d8e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.142) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Apr 2016 12:11:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 20 Apr 2016 12:11:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46F020A7-F877-4255-A6CA-51DAEA0D2259@kuehlewind.net> References: <20160415202525.17436.53287.idtracker@ietfa.amsl.com> <403566031bb74465bbd0d0da1acf1b7c@XCH-RCD-017.cisco.com> <67B76B8A-3141-4C5B-8902-A6C745863D4B@kuehlewind.net> <57144431-794F-447D-ADF2-6B61608D2B58@kuehlewind.net> To: Varun Singh X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , "sperreault@jive.com" , The IESG , "draft-ietf-tram-stun-path-data@ietf.org" Subject: Re: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tram-?= =?utf-8?q?stun-path-data-03=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 10:11:32 -0000 Hi Varun, Thanks. That=E2=80=99s helpful. If the following statement is true, = I=E2=80=99d also would like to see something added like this: =E2=80=9ENo additional messages should be sent for measurement purposes = only.=E2=80=9C Thanks, Mirja > Am 17.04.2016 um 16:37 schrieb Varun Singh : >=20 > Hi Mirja, >=20 > I agree, the metric being measured is fractional loss, and not the = loss rate. This should be fixed.=20 >=20 > To your other comment: > > Would it be possible to give some recommendation in this doc what an = application needs to do to get an appropriate measure? >=20 > Would the following proposal work?=20 >=20 > According to rfc5389, the path characteristic is measured when the = first STUN transaction is complete for each ICE candidate pair during = connectivity establishment. If more measurements are needed, this STUN = extension MAY be applied to the STUN consent checks defined in = [rfc7675]. >=20 >=20 > On Sun, Apr 17, 2016 at 5:15 PM, Mirja Kuehlewind (IETF) = wrote: > Hi again, >=20 > one more point: When I was reading the doc, I was assuming that you = aim to measure something like the path loss rate, as you talk in the = whole doc always about 'the path characteristics like round-trip time = (RTT) and packet loss=E2=80=98. However, after the discussion with you, = I believe what you actually do with this extension is to get the ability = to detect signal packet losses (rather than something like an actual = meaningful rate). If that=E2=80=99s the case, that should probably be = more clarified in the whole doc. >=20 > Mirja >=20 >=20 > > Am 17.04.2016 um 16:06 schrieb Mirja Kuehlewind (IETF) = : > > > > Hi, > > > > see below. > > > > > >> Am 16.04.2016 um 15:20 schrieb Tirumaleswar Reddy (tireddy) = : > >> > >>> -----Original Message----- > >>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] > >>> Sent: Saturday, April 16, 2016 4:08 PM > >>> To: Tirumaleswar Reddy (tireddy) > >>> Cc: The IESG; draft-ietf-tram-stun-path-data@ietf.org; = sperreault@jive.com; > >>> tram@ietf.org; tram-chairs@ietf.org > >>> Subject: Re: Mirja K=C3=BChlewind's Yes on = draft-ietf-tram-stun-path-data-03: > >>> (with COMMENT) > >>> > >>> Hi, > >>> > >>> see below. > >>> > >>>>> > >>>>> A few questions that could potentially be further clarified in = the > >>>>> document: > >>>>> > >>>>> 1) How often should the request be retransmitted to get a = qualified > >>>>> loss measure ? > >>>>> 2) What's the frequency of the retransmissions/pacing or wating > >>>>> between retransmissions ? > >>>> > >>>> A STUN client retransmits a STUN request starting with an = interval of RTO, > >>> doubling after each retransmission. Retransmissions continue until = a > >>> response is received, or until a total of Rc requests have been = sent. It is > >>> discussed in https://tools.ietf.org/html/rfc5389 in detail. > >>> > >>> Okay, it wasn=E2=80=99t clear to me if you would send more = retransmissions just to > >>> measure loss. > >> > >> If there is response then there is no need to retransmit the STUN = request. > >> > >>> If you don=E2=80=99t, how much retransmission do you usually see = and > >>> is this sufficient to get a reliable loss measure (see question = one) ? > >> > >> If there is no response then the request is retransmitted, the rate = of retransmissions and number of retransmissions are dependent on the = protocol using STUN (e.g. ICE calculates retransmission timer (RTO) = differently for media and non-media streams). It's up to the application = if it wants to try just one transaction or NNN number of transactions to = measure the path characteristics. > > > > Would it be possible to give some recommendation in this doc what an = application needs to do to get an appropriate measure? > > > > Mirja > > > > > >> > >> -Tiru > >> > >>> > >>>> > >>>>> 3) How big is the overhead when retransmitting several times ? > >>>> > >>>> The overhead introduced by the new PATH-CHARACTERISTIC attribute = is > >>> just 4 bytes. > >>> > >>> Okay, again, wasn=E2=80=99t clear to me if you would need more = request than usually > >>> or not. > >>> > >>> Mirja > >>> > >>> > >>> > >>>> > >>>> -Tiru > >>>> > >>>>> > >>>>> Thanks! > >>>>> > >>>> > >> > > >=20 >=20 >=20 >=20 > --=20 > Founder, CEO, callstats.io > http://www.callstats.io > Analytics and Optimizations for WebRTC. >=20 > We are hiring: www.callstats.io/jobs/ From nobody Wed Apr 20 04:12:09 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E76B12EEA2; Wed, 20 Apr 2016 04:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCQ8PM7QYZPq; Wed, 20 Apr 2016 04:12:04 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4779012EEA1; Wed, 20 Apr 2016 04:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1738; q=dns/txt; s=iport; t=1461150724; x=1462360324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pC0+S0qiUAAiM+L1QeOmv7V7bky2Io1VNDOFg4CRzXo=; b=nIhLLSbh/cfY/teocadtcSxrS+ufgsnstw3C/G1yphkCk0TL22w6Ly0S kCUMJSKHKghp8ZQADXciqJL7QCjNaIT8fVF2VGqA6QB4nQVxDgAbev7AV y7Da36b59YNoJWo6otB0EM6o2oO+T7HCeG7JN1AU+deXl2inBR3SADzAq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAgBcYxdX/4UNJK1egzhTfQa5ZQENg?= =?us-ascii?q?XEXC4VsAoE+OBQBAQEBAQEBZSeEQQEBAQQBAQE3NAsMBAIBCBEEAQEfCQcnCxQ?= =?us-ascii?q?JCAIEAQ0FCIghDr4FAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYRLhA8RAVCFJ?= =?us-ascii?q?AWHdJAbAYV6iBKBbYRNiF2PLAEeAQFCgjOBNWwBhxI2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208";a="263039633" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2016 11:12:03 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3KBC3lc005368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 11:12:03 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 06:12:02 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 06:12:02 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Kathleen Moriarty , The IESG Thread-Topic: [tram] Kathleen Moriarty's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) Thread-Index: AQHRmnCHK+VGQpbLE0+mb0MS5+SEVJ+StU6g Date: Wed, 20 Apr 2016 11:12:02 +0000 Message-ID: <021354164dad4266aeeca33ab6406168@XCH-RCD-017.cisco.com> References: <20160419192007.31617.47250.idtracker@ietfa.amsl.com> In-Reply-To: <20160419192007.31617.47250.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.21.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , "sperreault@jive.com" , "tram@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Kathleen Moriarty's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 11:12:05 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Wednesday, April 20, 2016 12:50 AM > To: The IESG > Cc: draft-ietf-tram-stun-path-data@ietf.org; sperreault@jive.com; > tram@ietf.org; tram-chairs@ietf.org > Subject: [tram] Kathleen Moriarty's No Objection on draft-ietf-tram-stun- > path-data-03: (with COMMENT) >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tram-stun-path-data-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The draft looks good, I would just add in the security section that the > information could be observed passively if not encrypted (especially sinc= e > that is an option) and used for reconnaissance and later attacks. STUN can over (D)TLS but ICE does not encrypt STUN messages and STUN messag= es are integrity-protected. Please clarify what kind of attacks are possibl= e ? -Tiru >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Apr 20 15:58:46 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2712E833; Wed, 20 Apr 2016 15:58:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420225843.780.83631.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 15:58:43 -0700 Archived-At: Cc: draft-ietf-tram-stun-path-data@ietf.org, sperreault@jive.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 22:58:43 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-tram-stun-path-data-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The RespTransCnt mechanism seems to be a bit fragile and error prone possibly leading to wrong conclusions on the client (please see my example below). If you agree with my assessment, it is probably useful to evaluate whether the added complexity of this RespTransCnt mechanism is worth it for the potentially unreliable results it produces. Consider the following two cases (copy paste with a monospace font for better readability) Case 1: Upstream loss of first "re"transmission | Upstream loss | | Client Server | +-+-+-+-+-+-+-+-+-+ | 1 x | | | | 2 2,1 | | 2,1 | Case 2: Downstream loss of response to first "re"transmission with re-ordering | Downstream loss | | Client Server | +-+-+-+-+-+-+-+-+-+ | 1 1,2 | | x | | 2 2,1 | | 2,1 | How does the client differentiate between these two cases? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5: IANA Considerations Shouldn't the range for this option be in the 0x8000-0xBFFF range instead of the 0x8000-0xFFFF range as currently stated by the draft? Section 6: I think this requirement is backwards and needs to be reworded. "Unauthenticated STUN message MUST NOT include the PATH-CHARACTERISTIC attribute in order to prevent on-path attacker from influencing decision-making." Suggest rewording to. "The PATH-CHARACTERISTIC attribute MUST NOT be included in unauthenticated STUN messages in order to prevent an on-path attacker from influencing decision-making." I also agree with Alissa about the vagueness of the attribute name. From nobody Thu Apr 21 00:16:09 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF6012DF24; Thu, 21 Apr 2016 00:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3P0rPm06GyD; Thu, 21 Apr 2016 00:16:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F5012DF1C; Thu, 21 Apr 2016 00:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5162; q=dns/txt; s=iport; t=1461222966; x=1462432566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=W9ct+8PncwvR4MD746rCejXrTHc5OQZUw2y2jbswlHM=; b=fP97q9X6tZLiL4OToHbjtc7sJedtXTrBQY2GxvWDbQ4SkowljWCE2K8N iESWb2vRTXP2JvbF2ck5T9cb4epSUnurXeFcbjfkwRg+5bXCDDVQwi8yS 8ak1TL9f55l1oc6kL7rMBazr5VwYCvJNh/NQJdfB7sHrK6rpT3xnZc+Iz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQBQBvfRhX/49dJa1egzhTfQa5doFyF?= =?us-ascii?q?wuFbAIcgSY5EwEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQgYAgIfBwICAiU?= =?us-ascii?q?LFRACBA4FiCIIDq1fkRIBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyFJYF1CIJOh?= =?us-ascii?q?A8RAQYWgwIrgisFh3SFX4o8AYV6gnWFJIFmhE2IXY8sASICPoIzgTVsAYcSNn4?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="99721624" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 07:16:05 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3L7G5NM004357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 07:16:05 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 03:16:04 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 03:16:04 -0400 From: "Pal Martinsen (palmarti)" To: Suresh Krishnan Thread-Topic: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) Thread-Index: AQHRm1gzKpoD+dVfgUKAqJDVRvrrjJ+UR7cA Date: Thu, 21 Apr 2016 07:16:04 +0000 Message-ID: <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> References: <20160420225843.780.83631.idtracker@ietfa.amsl.com> In-Reply-To: <20160420225843.780.83631.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.97.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , Simon Perreault , "tram-chairs@ietf.org" , The IESG , tram mailing list Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:16:08 -0000 DQo+IE9uIDIxIEFwciAyMDE2LCBhdCAwMDo1OCwgU3VyZXNoIEtyaXNobmFuIDxzdXJlc2gua3Jp c2huYW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IFN1cmVzaCBLcmlzaG5hbiBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi10cmFt LXN0dW4tcGF0aC1kYXRhLTAzOiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4g UGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1 c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXN0dW4tcGF0aC1kYXRh Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gDQo+IFRoZSBSZXNwVHJhbnNDbnQgbWVjaGFuaXNtIHNlZW1zIHRvIGJlIGEgYml0IGZy YWdpbGUgYW5kIGVycm9yIHByb25lDQo+IHBvc3NpYmx5IGxlYWRpbmcgdG8gd3JvbmcgY29uY2x1 c2lvbnMgb24gdGhlIGNsaWVudCAocGxlYXNlIHNlZSBteQ0KPiBleGFtcGxlIGJlbG93KS4gSWYg eW91IGFncmVlIHdpdGggbXkgYXNzZXNzbWVudCwgaXQgaXMgcHJvYmFibHkgdXNlZnVsIHRvDQo+ IGV2YWx1YXRlIHdoZXRoZXIgdGhlIGFkZGVkIGNvbXBsZXhpdHkgb2YgdGhpcyBSZXNwVHJhbnND bnQgbWVjaGFuaXNtIGlzDQo+IHdvcnRoIGl0IGZvciB0aGUgcG90ZW50aWFsbHkgdW5yZWxpYWJs ZSByZXN1bHRzIGl0IHByb2R1Y2VzLiANCj4gDQo+IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgdHdv IGNhc2VzIChjb3B5IHBhc3RlIHdpdGggYSBtb25vc3BhY2UgZm9udCBmb3INCj4gYmV0dGVyIHJl YWRhYmlsaXR5KQ0KPiANCj4gQ2FzZSAxOiBVcHN0cmVhbSBsb3NzIG9mIGZpcnN0ICJyZSJ0cmFu c21pc3Npb24NCj4gDQo+IHwgIFVwc3RyZWFtIGxvc3MgIHwNCj4gfCAgQ2xpZW50ICBTZXJ2ZXIg fA0KPiArLSstKy0rLSstKy0rLSstKy0rDQo+IHwgIDEgICAgICAgICB4ICAgIHwNCj4gfCAgICAg ICAgICAgICAgICAgfA0KPiB8ICAyICAgICAgICAgMiwxICB8DQo+IHwgICAgMiwxICAgICAgICAg IHwNCj4gDQo+IENhc2UgMjogRG93bnN0cmVhbSBsb3NzIG9mIHJlc3BvbnNlIHRvIGZpcnN0ICJy ZSJ0cmFuc21pc3Npb24gd2l0aA0KPiByZS1vcmRlcmluZw0KPiANCj4gfCBEb3duc3RyZWFtIGxv c3MgfA0KPiB8ICBDbGllbnQgIFNlcnZlciB8DQo+ICstKy0rLSstKy0rLSstKy0rLSsNCj4gfCAg MSAgICAgICAgIDEsMiAgfA0KPiB8ICAgIHggICAgICAgICAgICB8DQo+IHwgIDIgICAgICAgICAy LDEgIHwNCj4gfCAgICAyLDEgICAgICAgICAgfA0KPiANCj4gSG93IGRvZXMgdGhlIGNsaWVudCBk aWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlc2UgdHdvIGNhc2VzPw0KPiANClNvIHRoZSBwcm9ibGVt IGlzIHRoYXQgdGhlIGZpcnN0IHJldHJhbnNtaXQgKHNlY29uZCB0cmFuc21pdCkgb2YgdGhlIFNU VU4gcmVxdWVzdCBhcnJpdmVzIGJlZm9yZSB0aGUgaW5pdGlhbCB0cmFuc21pdCBhbmQgdGhlIHJl c3BvbnNlIHRvIHRoZSBpbml0aWFsIHJlcXVlc3QgaXMgbG9zdCBkb3duc3RyZWFtLiANCg0KVGhp cyBtZWFucyBub3QgYWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHVwc3RyZWFtIHJlb3JkZXJp bmcgYW5kIGRvd25zdHJlYW0gbG9zcy4gSSBkbyBub3QgdGhpbmsgYWRkaW5nIGNvbXBsZXhpdHkg dG8gc29sdmUgdGhpcyBpcyB3b3J0aCBpdC4gSWYgSUNFIGlzIHVzaW5nIHRoaXMsIGl0IGlzIHN0 aWxsIHZhbHVhYmxlIGluZm9ybWF0aW9uLiBBbmQgb25jZSAocylSVFAgc3RhcnRzIGZsb3dpbmcg dGhlIHJlb3JkZXJpbmcgd2lsbCBxdWlja2x5IGJlIGRpc2NvdmVyZWQgYnkgb3V0IG9mIG9yZXIg cGFja2V0cy4gDQoNClRoZSBkcmFmdCBuZWVkcyB0byBjbGVhcmx5IHNwZWxsIG91dCB0aGlzIGxp bWl0YXRpb24uDQoNCk15IG1haW4gd29ycnkgbm93IGlzIHRoZSBSVFQgY2FsY3VsYXRpb24uIEFt IEkgcmlnaHQgaWYgSSBhc3N1bWUgdGhhdCB0aGUgcGFja2V0cyB1c3VhbGx5IGFyZSBkZWxheWVk IHdoZW4gcmVvcmRlciwgYW5kIG5vdCBtYWdpY2FsbHkgcHV0IGluIGZyb250IG9mIHRoZSBxdWV1 ZT8gSWYgdGhhdCBpcyB0aGUgY2FzZSB0aGUgUlRUIG1lYXN1cmVtZW50IHNob3VsZCBzdGlsbCBi ZSBvaw0KDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IFNlY3Rpb24gNTogSUFOQSBDb25zaWRlcmF0aW9ucw0KPiANCj4gU2hvdWxkbid0IHRo ZSByYW5nZSBmb3IgdGhpcyBvcHRpb24gYmUgaW4gdGhlIDB4ODAwMC0weEJGRkYgcmFuZ2UgaW5z dGVhZA0KPiBvZiB0aGUgMHg4MDAwLTB4RkZGRiByYW5nZSBhcyBjdXJyZW50bHkgc3RhdGVkIGJ5 IHRoZSBkcmFmdD8NCg0KWWVzLiBXZSB3YW50IGl0IHRvIGJlIHBhcnQgb2YgdGhlIElFVEYgUmV2 aWV3IGNvbXByZWhlbnNpb24tb3B0aW9uYWwgcmFuZ2UuDQoNCj4gDQo+IFNlY3Rpb24gNjoNCj4g DQo+IEkgdGhpbmsgdGhpcyByZXF1aXJlbWVudCBpcyBiYWNrd2FyZHMgYW5kIG5lZWRzIHRvIGJl IHJld29yZGVkLg0KPiANCj4gIlVuYXV0aGVudGljYXRlZCBTVFVOIG1lc3NhZ2UgTVVTVCBOT1Qg aW5jbHVkZSB0aGUgUEFUSC1DSEFSQUNURVJJU1RJQw0KPiBhdHRyaWJ1dGUgaW4gb3JkZXIgdG8g cHJldmVudCBvbi1wYXRoIGF0dGFja2VyIGZyb20gaW5mbHVlbmNpbmcNCj4gZGVjaXNpb24tbWFr aW5nLiINCj4gDQo+IFN1Z2dlc3QgcmV3b3JkaW5nIHRvLg0KPiANCj4gIlRoZSBQQVRILUNIQVJB Q1RFUklTVElDIGF0dHJpYnV0ZSBNVVNUIE5PVCBiZSBpbmNsdWRlZCBpbg0KPiB1bmF1dGhlbnRp Y2F0ZWQgU1RVTiBtZXNzYWdlcyBpbiBvcmRlciB0byBwcmV2ZW50IGFuIG9uLXBhdGggYXR0YWNr ZXINCj4gZnJvbSBpbmZsdWVuY2luZyBkZWNpc2lvbi1tYWtpbmcu4oCdDQo+IA0KDQorMQ0KPiBJ IGFsc28gYWdyZWUgd2l0aCBBbGlzc2EgYWJvdXQgdGhlIHZhZ3VlbmVzcyBvZiB0aGUgYXR0cmli dXRlIG5hbWUuDQo+IA0KPiANCisxDQoNCi4tLg0KUMOlbC1FcmlrDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+ IHRyYW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmFtDQoNCg== From nobody Thu Apr 21 04:05:14 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EAC12D8F6; Thu, 21 Apr 2016 04:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWayupNBo-bx; Thu, 21 Apr 2016 04:05:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9FA12DA7D; Thu, 21 Apr 2016 04:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6274; q=dns/txt; s=iport; t=1461236712; x=1462446312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mT1yaLdJaTgBDwCujbKUh7rVWA3jfONwbdSbDsJlTVg=; b=hsTYM34tHbOG0zF0GW8vzt9DdsJHknDXppAuJjdI0Kwcrwomdb2l1b6M SjYhUy5iCyLiEp7F5vy8tPpEZXQ4NDLRrh6vLkTmfvICanjndRaIOfIt7 wpQ0A12pkmuS1Dj7yIyj/yGEtRa0bkJAt82x0K5zeGBh5IVkHWL1k8v1E g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgDAshhX/40NJK1egzhTfQa5aQENg?= =?us-ascii?q?XIXC4VsAhyBEDgUAQEBAQEBAWUnhEEBAQEDAQEBASAROgsFBwQCAQgRBAEBAQI?= =?us-ascii?q?CHwcCAgIlCxUICAIEAQ0FCIgaCA6uCZEXAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR8hSWES4QPEQEGLoJqglYFh3SFX4o8AYV6gnWFHYFthE2IXY8sAR4BAUKCM4E?= =?us-ascii?q?1bAGHEjZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="94294643" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 11:05:10 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3LB5AlI012566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 11:05:10 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 06:05:10 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 06:05:09 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Pal Martinsen (palmarti)" , Suresh Krishnan Thread-Topic: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) Thread-Index: AQHRm1gzFkDN9JmIfUuyYa8kEYCcCJ+UWHUA///p5DA= Date: Thu, 21 Apr 2016 11:05:09 +0000 Message-ID: <31bcaa55d07642a899e47ad29045cc85@XCH-RCD-017.cisco.com> References: <20160420225843.780.83631.idtracker@ietfa.amsl.com> <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> In-Reply-To: <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.21.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tram-stun-path-data@ietf.org" , Simon Perreault , "tram-chairs@ietf.org" , The IESG , tram mailing list Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 11:05:13 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSkNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIxLCAyMDE2IDEyOjQ2IFBNDQo+IFRvOiBT dXJlc2ggS3Jpc2huYW4NCj4gQ2M6IFRoZSBJRVNHOyBkcmFmdC1pZXRmLXRyYW0tc3R1bi1wYXRo LWRhdGFAaWV0Zi5vcmc7IFNpbW9uIFBlcnJlYXVsdDsgdHJhbQ0KPiBtYWlsaW5nIGxpc3Q7IHRy YW0tY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gU3VyZXNoIEtyaXNobmFu J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRyYW0tc3R1bi1wYXRoLQ0KPiBkYXRhLTAzOiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gDQo+ID4gT24gMjEgQXByIDIwMTYsIGF0IDAw OjU4LCBTdXJlc2ggS3Jpc2huYW4NCj4gPHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+IHdy b3RlOg0KPiA+DQo+ID4gU3VyZXNoIEtyaXNobmFuIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtdHJhbS1zdHVuLXBhdGgtZGF0YS0w MzogRGlzY3Vzcw0KPiA+DQo+ID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4gZW1haWwgYWRkcmVzc2VzIGlu Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+ID4gdGhp cyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPg0KPiA+DQo+ID4gUGxlYXNl IHJlZmVyIHRvDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sDQo+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBh bG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuLXBh dGgtZGF0YS8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoN Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBUaGUgUmVzcFRyYW5zQ250IG1lY2hhbmlzbSBz ZWVtcyB0byBiZSBhIGJpdCBmcmFnaWxlIGFuZCBlcnJvciBwcm9uZQ0KPiA+IHBvc3NpYmx5IGxl YWRpbmcgdG8gd3JvbmcgY29uY2x1c2lvbnMgb24gdGhlIGNsaWVudCAocGxlYXNlIHNlZSBteQ0K PiA+IGV4YW1wbGUgYmVsb3cpLiBJZiB5b3UgYWdyZWUgd2l0aCBteSBhc3Nlc3NtZW50LCBpdCBp cyBwcm9iYWJseSB1c2VmdWwNCj4gPiB0byBldmFsdWF0ZSB3aGV0aGVyIHRoZSBhZGRlZCBjb21w bGV4aXR5IG9mIHRoaXMgUmVzcFRyYW5zQ250DQo+ID4gbWVjaGFuaXNtIGlzIHdvcnRoIGl0IGZv ciB0aGUgcG90ZW50aWFsbHkgdW5yZWxpYWJsZSByZXN1bHRzIGl0IHByb2R1Y2VzLg0KPiA+DQo+ ID4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZyB0d28gY2FzZXMgKGNvcHkgcGFzdGUgd2l0aCBhIG1v bm9zcGFjZSBmb250IGZvcg0KPiA+IGJldHRlciByZWFkYWJpbGl0eSkNCj4gPg0KPiA+IENhc2Ug MTogVXBzdHJlYW0gbG9zcyBvZiBmaXJzdCAicmUidHJhbnNtaXNzaW9uDQo+ID4NCj4gPiB8ICBV cHN0cmVhbSBsb3NzICB8DQo+ID4gfCAgQ2xpZW50ICBTZXJ2ZXIgfA0KPiA+ICstKy0rLSstKy0r LSstKy0rLSsNCj4gPiB8ICAxICAgICAgICAgeCAgICB8DQo+ID4gfCAgICAgICAgICAgICAgICAg fA0KPiA+IHwgIDIgICAgICAgICAyLDEgIHwNCj4gPiB8ICAgIDIsMSAgICAgICAgICB8DQo+ID4N Cj4gPiBDYXNlIDI6IERvd25zdHJlYW0gbG9zcyBvZiByZXNwb25zZSB0byBmaXJzdCAicmUidHJh bnNtaXNzaW9uIHdpdGgNCj4gPiByZS1vcmRlcmluZw0KPiA+DQo+ID4gfCBEb3duc3RyZWFtIGxv c3MgfA0KPiA+IHwgIENsaWVudCAgU2VydmVyIHwNCj4gPiArLSstKy0rLSstKy0rLSstKy0rDQo+ ID4gfCAgMSAgICAgICAgIDEsMiAgfA0KPiA+IHwgICAgeCAgICAgICAgICAgIHwNCj4gPiB8ICAy ICAgICAgICAgMiwxICB8DQo+ID4gfCAgICAyLDEgICAgICAgICAgfA0KPiA+DQo+ID4gSG93IGRv ZXMgdGhlIGNsaWVudCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlc2UgdHdvIGNhc2VzPw0KPiA+ DQo+IFNvIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGZpcnN0IHJldHJhbnNtaXQgKHNlY29uZCB0 cmFuc21pdCkgb2YgdGhlIFNUVU4NCj4gcmVxdWVzdCBhcnJpdmVzIGJlZm9yZSB0aGUgaW5pdGlh bCB0cmFuc21pdCBhbmQgdGhlIHJlc3BvbnNlIHRvIHRoZSBpbml0aWFsDQo+IHJlcXVlc3QgaXMg bG9zdCBkb3duc3RyZWFtLg0KPiANCj4gVGhpcyBtZWFucyBub3QgYWJsZSB0byBkaXN0aW5ndWlz aCBiZXR3ZWVuIHVwc3RyZWFtIHJlb3JkZXJpbmcgYW5kDQo+IGRvd25zdHJlYW0gbG9zcy4gSSBk byBub3QgdGhpbmsgYWRkaW5nIGNvbXBsZXhpdHkgdG8gc29sdmUgdGhpcyBpcyB3b3J0aCBpdC4g DQoNClNUVU4gcmV0cmFuc21pc3Npb25zIGFyZSBwYWNlZCBvdXQgdXNpbmcgUlRPIHZhbHVlIGRp c2N1c3NlZCBpbiBSRkM1Mzg5IGFuZCBkb3VibGVkIGFmdGVyIGVhY2ggcmV0cmFuc21pc3Npb24u IEl0IGxvb2tzIGxpa2UgYSAgY29ybmVyIGNhc2Ugd2hlcmUgdGhlIHJldHJhbnNtaXR0ZWQgcGFj a2V0IHJlYWNoZXMgdGhlIHNlcnZlciBiZWZvcmUgdGhlIHByZXZpb3VzIHBhY2tldC4NCg0KLVRp cnUNCg0KPiBJZiBJQ0UgaXMgdXNpbmcgdGhpcywgaXQgaXMgc3RpbGwgdmFsdWFibGUgaW5mb3Jt YXRpb24uIEFuZCBvbmNlIChzKVJUUCBzdGFydHMgZmxvd2luZw0KPiB0aGUgcmVvcmRlcmluZyB3 aWxsIHF1aWNrbHkgYmUgZGlzY292ZXJlZCBieSBvdXQgb2Ygb3JlciBwYWNrZXRzLg0KPiANCj4g VGhlIGRyYWZ0IG5lZWRzIHRvIGNsZWFybHkgc3BlbGwgb3V0IHRoaXMgbGltaXRhdGlvbi4NCj4g DQo+IE15IG1haW4gd29ycnkgbm93IGlzIHRoZSBSVFQgY2FsY3VsYXRpb24uIEFtIEkgcmlnaHQg aWYgSSBhc3N1bWUgdGhhdCB0aGUNCj4gcGFja2V0cyB1c3VhbGx5IGFyZSBkZWxheWVkIHdoZW4g cmVvcmRlciwgYW5kIG5vdCBtYWdpY2FsbHkgcHV0IGluIGZyb250IG9mDQo+IHRoZSBxdWV1ZT8g SWYgdGhhdCBpcyB0aGUgY2FzZSB0aGUgUlRUIG1lYXN1cmVtZW50IHNob3VsZCBzdGlsbCBiZSBv aw0KPiANCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBDT01NRU5UOg0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPg0KPiA+IFNlY3Rpb24gNTogSUFOQSBDb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4g U2hvdWxkbid0IHRoZSByYW5nZSBmb3IgdGhpcyBvcHRpb24gYmUgaW4gdGhlIDB4ODAwMC0weEJG RkYgcmFuZ2UNCj4gPiBpbnN0ZWFkIG9mIHRoZSAweDgwMDAtMHhGRkZGIHJhbmdlIGFzIGN1cnJl bnRseSBzdGF0ZWQgYnkgdGhlIGRyYWZ0Pw0KPiANCj4gWWVzLiBXZSB3YW50IGl0IHRvIGJlIHBh cnQgb2YgdGhlIElFVEYgUmV2aWV3IGNvbXByZWhlbnNpb24tb3B0aW9uYWwgcmFuZ2UuDQo+IA0K PiA+DQo+ID4gU2VjdGlvbiA2Og0KPiA+DQo+ID4gSSB0aGluayB0aGlzIHJlcXVpcmVtZW50IGlz IGJhY2t3YXJkcyBhbmQgbmVlZHMgdG8gYmUgcmV3b3JkZWQuDQo+ID4NCj4gPiAiVW5hdXRoZW50 aWNhdGVkIFNUVU4gbWVzc2FnZSBNVVNUIE5PVCBpbmNsdWRlIHRoZSBQQVRILQ0KPiBDSEFSQUNU RVJJU1RJQw0KPiA+IGF0dHJpYnV0ZSBpbiBvcmRlciB0byBwcmV2ZW50IG9uLXBhdGggYXR0YWNr ZXIgZnJvbSBpbmZsdWVuY2luZw0KPiA+IGRlY2lzaW9uLW1ha2luZy4iDQo+ID4NCj4gPiBTdWdn ZXN0IHJld29yZGluZyB0by4NCj4gPg0KPiA+ICJUaGUgUEFUSC1DSEFSQUNURVJJU1RJQyBhdHRy aWJ1dGUgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4NCj4gPiB1bmF1dGhlbnRpY2F0ZWQgU1RVTiBt ZXNzYWdlcyBpbiBvcmRlciB0byBwcmV2ZW50IGFuIG9uLXBhdGggYXR0YWNrZXINCj4gPiBmcm9t IGluZmx1ZW5jaW5nIGRlY2lzaW9uLW1ha2luZy7igJ0NCj4gPg0KPiANCj4gKzENCj4gPiBJIGFs c28gYWdyZWUgd2l0aCBBbGlzc2EgYWJvdXQgdGhlIHZhZ3VlbmVzcyBvZiB0aGUgYXR0cmlidXRl IG5hbWUuDQo+ID4NCj4gPg0KPiArMQ0KPiANCj4gLi0uDQo+IFDDpWwtRXJpaw0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdHJhbSBtYWls aW5nIGxpc3QNCj4gPiB0cmFtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtDQoNCg== From nobody Thu Apr 21 07:43:24 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC112D991; Thu, 21 Apr 2016 07:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3xKXGb_Y-p6; Thu, 21 Apr 2016 07:43:18 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5F012E740; Thu, 21 Apr 2016 07:43:16 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t10so91510416ywa.0; Thu, 21 Apr 2016 07:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=47WSEq7E2RDP+PRinmkkvvH30uMCEZS9TUouRWlCfwQ=; b=Y/5bBkiM0uJdK9Ao6zHPM6/oTj9kZpkDEjE0u6oiTqnh19txwvoiSWx3ejAnGRoeh5 UxD8jU9whpYDnIeTOuJBtudwI3ztA3U7r7S6bGANQm2aTjp9mlLkwIGEgxIUA3mZGlyu 21fzk6WzhQs/jxRIZnAlQwWMpNOttHiqxReQLY8vnSTg0p4G5QsQXj+ifGXGhY2AShGM RddfpAdy+Wu88GxS8H4atqEmtuc8+6lKYD496YpHbazrKKKtN0MfzhWUX2MbHwKPI5Z3 4nqYNpPT5Si4XhcW1weMvqPl9vEHnT9rg6JnsFRNPNSW8fFgWYRCQXtZnaKUPF2mXnV7 dV/g== 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; bh=47WSEq7E2RDP+PRinmkkvvH30uMCEZS9TUouRWlCfwQ=; b=cHZruOb0JBaCGr8h6tnfGv2Ho5TyG1JpfPIfWDmBY+94QNW/feG3tTAc3+aV2cD38A hoJ32FrxEhtRfsidrujOxdEn47ybdD4dpshAIuNw11MlVBc5JWk5FhUj/4CkQ2l+dP9E lFpvRORm0QjfatRv9x2KOjhP6ioYz4xXoWkTEHRDMzsCRzrDIgpPJIDEjMjy9m+BtFbs DSsTuToz/CHXDPIp/g93oSc5kkolMzqQ1Uud8f10Bw+LXbDe1mUz5jlKYx0Qe0sHW17x bUy8jYWA8Pu+eBKDpdYdjohu7vmp0CWyUE1kxK0Ti67Zwrmvx4d/G0mKC80jobZdwBny W70g== X-Gm-Message-State: AOPr4FUkhb2ELKJjgqa7RX032uprj79e4IU2mX5CVb8BD4CdZ3YMhj4UYgKveLXIcWPRXgRsdEdwpN6/9lu2gA== MIME-Version: 1.0 X-Received: by 10.129.152.8 with SMTP id p8mr9272616ywg.157.1461249796262; Thu, 21 Apr 2016 07:43:16 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Thu, 21 Apr 2016 07:43:15 -0700 (PDT) In-Reply-To: <20160420085710.32392.13358.idtracker@ietfa.amsl.com> References: <20160420085710.32392.13358.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 09:43:15 -0500 Message-ID: From: Spencer Dawkins at IETF To: Benoit Claise Content-Type: multipart/alternative; boundary=94eb2c0bc49008d9770530ffbbc4 Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , MORAND Lionel IMT/OLN , Simon Perreault , The IESG , draft-ietf-tram-stun-path-data@ietf.org Subject: Re: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 14:43:20 -0000 --94eb2c0bc49008d9770530ffbbc4 Content-Type: text/plain; charset=UTF-8 Hi, Varun, On Wed, Apr 20, 2016 at 3:57 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-tram-stun-path-data-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't think this is appropriate to include a URL as affiliation (see > callstats.io on the first page). > Benoit and I have chatted further about this, and he noted that your affiliation is Varun Singh Nemu Dialogue System Oy in the Authors' Addresses section. At a minimum, the front page affiliation should match what's in the Author's Addresses section. Could you make sure that change happens? Thanks, Spencer --94eb2c0bc49008d9770530ffbbc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Varun,

On Wed, Apr 20, 2016 at 3:57 AM, Benoit Claise = <bclaise@cisco.co= m> wrote:
Benoit Claise has entered the f= ollowing ballot position for
draft-ietf-tram-stun-path-data-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-tram-stun-path-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't think this is appropriate to include a URL as affiliation (see<= br> callst= ats.io on the first page).

Benoit a= nd I have chatted further about this, and he noted that your affiliation is= =C2=A0

=C2=A0 =C2=A0Varun Singh
=C2=A0 = =C2=A0Nemu Dialogue System Oy

in the Authors' Addre= sses section. At a minimum, the front page affiliation should match what= 9;s in the Author's Addresses section.
=
Could you make sure that change happen= s?

Tha= nks,

S= pencer
--94eb2c0bc49008d9770530ffbbc4-- From nobody Thu Apr 21 08:37:26 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305BA12EC5E for ; Thu, 21 Apr 2016 08:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=callstats.io 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 BUxMY_oTVJwC for ; Thu, 21 Apr 2016 08:37:22 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDF312EC2C for ; Thu, 21 Apr 2016 08:37:21 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id os9so29188377lbb.2 for ; Thu, 21 Apr 2016 08:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callstats.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WDrJSiLAC7wo1rVAIaLiEf3BSoTCZjCbJCFLkPG81mg=; b=iJLbjcOQjfZVUiOirZt5SlUUAkc0fx8tpTK/u8z+kvczpKmxYtdR3hqajcxSh8NNs6 2P0vK2sK1MLK+iAjVy+WGOM0LDLbK8yxtgzFuz6ItlS4SLOLIyLPzF7pq/M6c13Aj+M2 PlJY8KEXkOrVG8FpMWqNnqmnB282I0BeZnHdE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WDrJSiLAC7wo1rVAIaLiEf3BSoTCZjCbJCFLkPG81mg=; b=Qj3OgBHoIDUoIbEThDbXFRyULHpPdDbg5XQHNO43Cg2NOk3b4WqszwFAo+jNKPdrwk floFv/qskTWKq9Fvi0BDGctL0acoLkGLXUX3r6wEOYZ849gvlQ/E0lhAXQgnWyccIz4Y B2JVS8OOo/d82BE/FQuszXjCX4QSgMKfkSGnrF61LCOOErSM3KvqkavfHedTFAa1aetD lrAV9mQr38jc3YFSeD0cvz54WbJow6/8962X3ZxY9DD78JtwiR45Svhb/l2vCZFfQX4D uvjuTkaCw4pvWAdMCJPiHn7T3sju9fL6sb48OvHb9JhaJtRPUChCjyWlZnFzI+UMpH42 afCw== X-Gm-Message-State: AOPr4FUPekPCn2lK8fQWNqxbGlCKxV2d2yDg6lcfzQVQZuseO6pXxQN/VIjW7xYgbf0w8fw14TJAP29Y4pUf4Q== X-Received: by 10.112.220.6 with SMTP id ps6mr2585442lbc.16.1461253040054; Thu, 21 Apr 2016 08:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.77.34 with HTTP; Thu, 21 Apr 2016 08:37:00 -0700 (PDT) In-Reply-To: References: <20160420085710.32392.13358.idtracker@ietfa.amsl.com> From: Varun Singh Date: Thu, 21 Apr 2016 18:37:00 +0300 Message-ID: To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a1134c6ec6136a00531007c50 Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , MORAND Lionel IMT/OLN , Simon Perreault , The IESG , draft-ietf-tram-stun-path-data@ietf.org Subject: Re: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:37:24 -0000 --001a1134c6ec6136a00531007c50 Content-Type: text/plain; charset=UTF-8 This is easy to fix, will send an updated author block to the editor. On Thu, Apr 21, 2016 at 5:43 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Varun, > > On Wed, Apr 20, 2016 at 3:57 AM, Benoit Claise wrote: > >> Benoit Claise has entered the following ballot position for >> draft-ietf-tram-stun-path-data-03: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I don't think this is appropriate to include a URL as affiliation (see >> callstats.io on the first page). >> > > Benoit and I have chatted further about this, and he noted that your > affiliation is > > Varun Singh > Nemu Dialogue System Oy > > in the Authors' Addresses section. At a minimum, the front page > affiliation should match what's in the Author's Addresses section. > > Could you make sure that change happens? > > Thanks, > > Spencer > -- Founder, CEO, callstats.io http://www.callstats.io Analytics and Optimizations for WebRTC. We are hiring: www.callstats.io/jobs/ --001a1134c6ec6136a00531007c50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is easy to fix, will send an updated author block to = the editor.

= On Thu, Apr 21, 2016 at 5:43 PM, Spencer Dawkins at IETF = <spen= cerdawkins.ietf@gmail.com> wrote:
Hi, Varun,

On Wed, Apr 20, 2016 at 3:57 AM, Benoit C= laise <bclaise@cisco.com> wrote:
Benoit = Claise has entered the following ballot position for
draft-ietf-tram-stun-path-data-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-tram-stun-path-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't think this is appropriate to include a URL as affiliation (see<= br> callst= ats.io on the first page).

B= enoit and I have chatted further about this, and he noted that your affilia= tion is=C2=A0

=C2=A0 =C2=A0Varun Singh
= =C2=A0 =C2=A0Nemu Dialogue System Oy

in the Authors'= ; Addresses section. At a minimum, the front page affiliation should match = what's in the Author's Addresses section.

Could you make sure that change= happens?

Thanks,

Spencer



--
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for = WebRTC.

We are hiring: www.callstats.io/jobs/
--001a1134c6ec6136a00531007c50-- From nobody Thu Apr 21 08:45:45 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5569612E732; Thu, 21 Apr 2016 08:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls2FbFFQ4vb0; Thu, 21 Apr 2016 08:45:41 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7B512E644; Thu, 21 Apr 2016 08:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8875; q=dns/txt; s=iport; t=1461253541; x=1462463141; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=SR0kBwAbycXesM8YPpqEuJDzvPKHja8Zq2p8TGxGqHw=; b=YLlWFp0ti0uVrmPJHWOcDnXnXjURch9lwhWkL10zVfB4ZOoQUX8UUffq 1hiYv6bf9stXwJ4+/sE/0LlClx/qlEBCoGQmgZO3+5goaVLqZkFKvLRO7 zFrhsiAb9gP+DNVo66pSs4ndo2JQy/SQCSwKn8OGj77gpw0NIagQXBpp3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVBQCf9BhX/xbLJq1ehAt9rhOEDIJeg?= =?us-ascii?q?mOEECKFbAKBfgEBAQEBAWYnhEEBAQEDASMmLwEFCwsYCRYIAwICCQMCAQIBDyU?= =?us-ascii?q?RBgEMBgIBAYgRAwoIDq5PjCANhHABAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES?= =?us-ascii?q?4JBgU4RAYMeglYFgUOGMYVfigsxhXuGI4F2gWZOg3+DBoVXh08Uh0pigjOBNzo?= =?us-ascii?q?wAYdBgTQBAQE?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208,217";a="635290630" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 15:45:38 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3LFjci2001630; Thu, 21 Apr 2016 15:45:38 GMT To: Varun Singh , Spencer Dawkins at IETF References: <20160420085710.32392.13358.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <5718F5A3.8080308@cisco.com> Date: Thu, 21 Apr 2016 17:45:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000308070506040703090304" Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , MORAND Lionel IMT/OLN , Simon Perreault , The IESG , draft-ietf-tram-stun-path-data@ietf.org Subject: Re: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:45:43 -0000 This is a multi-part message in MIME format. --------------000308070506040703090304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Varun, From http://www.callstats.io/about/ callstats.io is a product of /Nemu Dialogue Systems Oy/, a startup based out of Helsinki, Finland I believe you should use your company name and not a product name. Regards, Benoit > This is easy to fix, will send an updated author block to the editor. > > On Thu, Apr 21, 2016 at 5:43 PM, Spencer Dawkins at IETF > > > wrote: > > Hi, Varun, > > On Wed, Apr 20, 2016 at 3:57 AM, Benoit Claise > wrote: > > Benoit Claise has entered the following ballot position for > draft-ietf-tram-stun-path-data-03: No Objection > > When responding, please keep the subject line intact and reply > to all > email addresses included in the To and CC lines. (Feel free to > cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't think this is appropriate to include a URL as > affiliation (see > callstats.io on the first page). > > > Benoit and I have chatted further about this, and he noted that > your affiliation is > > Varun Singh > Nemu Dialogue System Oy > > in the Authors' Addresses section. At a minimum, the front page > affiliation should match what's in the Author's Addresses section. > > Could you make sure that change happens? > > Thanks, > > Spencer > > > > > -- > Founder, CEO, callstats.io > http://www.callstats.io > Analytics and Optimizations for WebRTC. > > We are hiring: www.callstats.io/jobs/ --------------000308070506040703090304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Varun,

From http://www.callstats.io/about/
callstats.io is a product of Nemu Dialogue Systems Oy, a startup based out of Helsinki, Finland
I believe you should use your company name and not a product name.

Regards, Benoit

This is easy to fix, will send an updated author block to the editor.

On Thu, Apr 21, 2016 at 5:43 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Varun,

On Wed, Apr 20, 2016 at 3:57 AM, Benoit Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for
draft-ietf-tram-stun-path-data-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't think this is appropriate to include a URL as affiliation (see
callstats.io on the first page).
Benoit and I have chatted further about this, and he noted that your affiliation is 

   Varun Singh
   Nemu Dialogue System Oy

in the Authors' Addresses section. At a minimum, the front page affiliation should match what's in the Author's Addresses section.

Could you make sure that change happens?

Thanks,

Spencer



--
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/

--------------000308070506040703090304-- From nobody Thu Apr 21 10:32:55 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2556C12DD06 for ; Thu, 21 Apr 2016 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojJPHDAz_lIF for ; Thu, 21 Apr 2016 10:32:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08DF12E258 for ; Thu, 21 Apr 2016 10:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3014; q=dns/txt; s=iport; t=1461259965; x=1462469565; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Yk1TVHjmnrMueMtfph3XW0vo4Nd9ebjvTlB9VJwuxuo=; b=c34KQF6n6jZ+cBOhdYqUzO1/R2q5WmT2E/Z+biReBLOuLq8wkoOZVC9q RCkMynT+NKwEkmv7TaAYQO/TMphNDvpegqWm7JctAVVs2h/EmdK7QKFvL 3McYgOuZLsHThuX65lAyRZJior0RtPtKz4T2rJbUNz8QERcUSEu9hcexj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBmDhlX/5hdJa1egzhTfQa5cgENg?= =?us-ascii?q?XMXC4VsAhyBGDgUAQEBAQEBAWUnhEEBAQEDAQEBASAROhALAgEIGAICJgICAiU?= =?us-ascii?q?LFRACBBOIIggOrxCRGgEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSWBdQiCToQnF?= =?us-ascii?q?oMCK4IrBZgPAYV6iBmBZk6Df4hdjywBHgEBQoNobId4fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="264527169" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 17:32:44 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3LHWiZp004060 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Apr 2016 17:32:44 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 12:32:44 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 12:32:44 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: tram mailing list Thread-Topic: [tram] I-D Action: draft-ietf-tram-stun-pmtud-01.txt Thread-Index: AQHRWG+NPoYfxzc7ckSIS1zBFCt0Ap8Ok7qAgIb214A= Date: Thu, 21 Apr 2016 17:32:44 +0000 Message-ID: <3F653220-1AC9-4230-8413-36D71A055C36@cisco.com> References: <20160126192706.3394.57544.idtracker@ietfa.amsl.com> <3C4D39D8-92FB-4F5D-975F-200C1F24C382@cisco.com> In-Reply-To: <3C4D39D8-92FB-4F5D-975F-200C1F24C382@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.173.48] Content-Type: text/plain; charset="utf-8" Content-ID: <5C5B2C4FA61D4C4A8BFE679E8E58B6DA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-pmtud-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:32:54 -0000 SGkgVFJBTXN0ZXJzLSANCg0KV291bGQgYXBwcmVjaWF0ZSBhbnkgZmVlZGJhY2sgb24gdGhpcyBk cmFmdCBzbyB3ZSBjYW4gZ2V0IGl0IHByb2dyZXNzZWQuDQoNCkNoZWVycywNCg0KR29uemFsbw0K DQoNCg0KPiBPbiBKYW4gMjYsIDIwMTYsIGF0IDI6MzAgUE0sIEdvbnphbG8gU2FsZ3VlaXJvIChn c2FsZ3VlaSkgPGdzYWxndWVpQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBGb2xrcyAtIA0KPiAN Cj4gVGhpcyBpcyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIFBNVFVEIGRyYWZ0LiAgQXV0aG9y cyB3b3VsZCBhcHByZWNpYXRlIGFueSByZXZpZXdzIGFuZCBjb21tZW50cy4NCj4gDQo+IE9uZSBh cmVhIHRoYXQgd2XigJlkIGFwcHJlY2lhdGUgc29tZSBXRyBjb25zaWRlcmF0aW9uIGlzIGhvdyB3 ZSBoYW5kbGUgdGhlIHR3byBwcm9wb3NlZCBQcm9iaW5nIE1lY2hhbmlzbXMgKFNpbXBsZSBhbmQg Q29tcGxldGUpLiAgRG8gd2Ugd2FudCB0byBrZWVwIGJvdGg/IE9yIHBpY2sgb25lPw0KPiANCj4g VGhhbmtzLA0KPiANCj4gR29uemFsbw0KPiANCj4+IE9uIEphbiAyNiwgMjAxNiwgYXQgMTE6Mjcg QU0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4+IA0KPj4gDQo+PiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUVVJO IFJldmlzZWQgYW5kIE1vZGVybml6ZWQgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+IA0K Pj4gICAgICAgVGl0bGUgICAgICAgICAgIDogUGF0aCBNVFUgRGlzY292ZXJ5IFVzaW5nIFNlc3Np b24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KPj4gICAgICAgQXV0aG9ycyAg ICAgICAgIDogTWFyYyBQZXRpdC1IdWd1ZW5pbg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg R29uemFsbyBTYWxndWVpcm8NCj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRyYW0t c3R1bi1wbXR1ZC0wMS50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiAxMQ0KPj4gCURhdGUgICAg ICAgICAgICA6IDIwMTYtMDEtMjYNCj4+IA0KPj4gQWJzdHJhY3Q6DQo+PiAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikN Cj4+ICB1c2FnZSBmb3IgUGF0aCBNVFUgRGlzY292ZXJ5IChQTVRVRCkgYmV0d2VlbiBhIGNsaWVu dCBhbmQgYSBzZXJ2ZXIuDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZC8NCj4+IA0KPj4gVGhlcmUncyBhbHNvIGEg aHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0dW4tcG10dWQtMDENCj4+IA0KPj4gQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS1zdHVuLXBtdHVkLTAxDQo+PiANCj4+ IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+IA0KPj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+IA0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ PiB0cmFtQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHRyYW0gbWFpbGluZyBsaXN0DQo+IHRyYW1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg==