From nobody Sun Oct 1 12:19:48 2017 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 0091F134A4B for ; Sun, 1 Oct 2017 12:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=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 Zl1trSs-k8_u for ; Sun, 1 Oct 2017 12:19:44 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A314F1349C9 for ; Sun, 1 Oct 2017 12:19:43 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v91JHhTE008037; Sun, 1 Oct 2017 20:19:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=CLOfFyJfH4OjNmSg/9QiXsTx4WH1Zi/xujcfd328iUk=; b=d7krDDfeIQBiNxUNuqMl7a5Mty+XuUQQVIhAJpw+0Wo6NfBM+YRg4oUw17g1+xlNNWg1 N7C2w0TkSknEDXsfbRVkk4KsCjtApFcR7AbaC1SPMo0mcGLUXiph5HTCBmW6z/5at0Ez ZinyQWXVFNemuEDalI0j1AGE2JiYMHcVIfzMHLJiYSxZ6/qyE3Qt72ALR5e84r6vAIw7 ABpI8OGhgHd1YbEg8YCZoOhQUON9iuZOIphTvECB5fusuXj8487xoiPn+e3NNXQaPlXX mDZIo8F3PqEklSZG2CCUEy55I4nfh5W5wDiWxmplQMTdaVW8bZjv/P7oqqc1FbaqftX+ 1w== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2da2t5ttp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 01 Oct 2017 20:19:38 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v91JG4HE002074; Sun, 1 Oct 2017 15:19:37 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2da6ku3mfa-1; Sun, 01 Oct 2017 15:19:37 -0400 Received: from [172.28.118.18] (bowill.kendall.corp.akamai.com [172.28.118.18]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id A9CAC20094; Sun, 1 Oct 2017 13:19:36 -0600 (MDT) To: Gonzalo Camarillo , tram@ietf.org References: From: Brandon Williams Message-ID: Date: Sun, 1 Oct 2017 15:19:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710010286 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710010286 Archived-At: Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 19:19:47 -0000 I have a couple final comments re: the version 11 and the changes between version 10 and version 11. Apologies for taking so long for this. I though I had done it already but realize now that I was remembering my response to the stunbis update. 1) idnits calls out a handful of things to check or resolve. a) The doc should use documentation range IPv4 addresses throughout. b) Are there any cases where IPv6 examples should also be provided? c) There are some obsolete and/or outdated references to fix. 2) On page 19, there are two new uses of the word "can": "the TURN client can silently abandon" "the client can silently abandon" These references are about applying address family precedence. Is this text meant to be normative? If so, it should use "MAY" instead of "can". The rest looks as expected I think. --Brandon On 09/15/2017 02:47 PM, Gonzalo Camarillo wrote: > Folks, > > we are starting a Working Group Last Call (WGLC) on the following draft: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > This WGLC will end on October 2nd. Please, send your comments to this > list. Thanks! > > Cheers, > > Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Sun Oct 1 13:07:30 2017 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 261E8134AC0 for ; Sun, 1 Oct 2017 13:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 rcZ8F6uhpDxd for ; Sun, 1 Oct 2017 13:07:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61407134ABB for ; Sun, 1 Oct 2017 13:07:27 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v91K7GjR005081; Sun, 1 Oct 2017 21:07:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : from : to : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=/0YKx5aIWtnMbzX+5LnM0oqGWtwASFCKOE4KPlC1w5Q=; b=m+pT+8chKf89ik7fdTmLMr37VYa7GOXMzrrfFR2gabyLPPlHfueECMgzIQwVSXsWr00r q6xPKZJRKLqLgVurOrF5XsDQFIvZBGVpnU5g9kGR89aCy5/CN1EpEVKg7+W8Zl5N99qZ SGHtjD9u28FWwluHZrUOrkjSyTTgtnveeAqt1x12HmZZDhWSJHV/FPiCKCJoCO+3oQnR qk/NOOkRYloV4HQN2/tFQjJj4t2Fy7j9jyxhxz+U0jH9/n8xfB8FM0rHg9BJTo2Tyo0W e4V/BiZNh43oWjLssKaJ6AwKFEWCrH/ZrOeAYRhzslER4h1skIoLrPOaAZju/KCYMBHK hg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2da2wvtmhq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 01 Oct 2017 21:07:23 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v91K6iZY020418; Sun, 1 Oct 2017 16:07:22 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2da6ktjxbu-1; Sun, 01 Oct 2017 16:07:22 -0400 Received: from [172.28.118.18] (bowill.kendall.corp.akamai.com [172.28.118.18]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 282D61FC7E; Sun, 1 Oct 2017 20:07:22 +0000 (GMT) From: Brandon Williams To: Gonzalo Camarillo , tram@ietf.org References: Message-ID: <457a35de-5eec-ce93-8d81-6484911161b0@akamai.com> Date: Sun, 1 Oct 2017 16:07:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710010299 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-01_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710010299 Archived-At: Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 20:07:29 -0000 One more nit that I just noticed ... 3) Section 15.13. ICMP Attribute contains a field called "Type" in the attribute value. Since attributes are TLV encoded with Type and Length as the first two fields, it might be better to call this field in the attribute value "ICMP Type" instead of just "Type". --Brandon On 10/01/2017 03:19 PM, Brandon Williams wrote: > I have a couple final comments re: the version 11 and the changes > between version 10 and version 11. Apologies for taking so long for > this. I though I had done it already but realize now that I was > remembering my response to the stunbis update. > > 1) idnits calls out a handful of things to check or resolve. > a) The doc should use documentation range IPv4 addresses throughout. > b) Are there any cases where IPv6 examples should also be provided? > c) There are some obsolete and/or outdated references to fix. > > 2) On page 19, there are two new uses of the word "can": > "the TURN client can silently abandon" > "the client can silently abandon" > These references are about applying address family precedence. Is this > text meant to be normative? If so, it should use "MAY" instead of "can". > > The rest looks as expected I think. > > --Brandon > > On 09/15/2017 02:47 PM, Gonzalo Camarillo wrote: >> Folks, >> >> we are starting a Working Group Last Call (WGLC) on the following draft: >> >> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >> >> This WGLC will end on October 2nd. Please, send your comments to this >> list. Thanks! >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Oct 4 02:44:18 2017 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 04377134290 for ; Wed, 4 Oct 2017 02:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 UGbSQ9kIWAcY for ; Wed, 4 Oct 2017 02:44:15 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8804B133011 for ; Wed, 4 Oct 2017 02:44:15 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:943d:2392:4c46:83bb] (unknown [IPv6:2601:648:8301:730f:943d:2392:4c46:83bb]) (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 1A583AE814; Wed, 4 Oct 2017 11:44:12 +0200 (CEST) To: "Asveren, Tolga" , "tram@ietf.org" References: From: Marc Petit-Huguenin Message-ID: <7f486757-7fe4-6d4e-0348-111353df7241@acm.org> Date: Wed, 4 Oct 2017 02:44:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VjATvXlV3lRL2FuxjuJjPpOtAcRtcLRA4" Archived-At: Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 09:44:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VjATvXlV3lRL2FuxjuJjPpOtAcRtcLRA4 Content-Type: multipart/mixed; boundary="eGxp9kgnPPacpjuAJf5xCadoaNtLpHu3K"; protected-headers="v1" From: Marc Petit-Huguenin To: "Asveren, Tolga" , "tram@ietf.org" Message-ID: <7f486757-7fe4-6d4e-0348-111353df7241@acm.org> Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 References: In-Reply-To: --eGxp9kgnPPacpjuAJf5xCadoaNtLpHu3K Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thank you for the review. Gonzalo and I will work on that next week and publish a new version. Thanks. On 09/30/2017 05:31 AM, Asveren, Tolga wrote: > Here are my comments for draft-ietf-tram-stunbis-12 WGLC: > (It could be easier for tracking purposes if authors reply in separate = > threads/bundle relevant ones into separate threads) > i- Please reference latest version of [I-D.ietf-ice-rfc5245bis], and in= dicate=20 > that it should be updated by RFC Editor with the latest version/RFC num= ber (if=20 > present) before publication of this document > ii- > STUN is intended to be used in context of one or more NAT traversal > solutions. These solutions are known as STUN usages. Each usage > describes how STUN is utilized to achieve the NAT traversal solutio= n. > I think there are use cases for non-NAT environments as well, e.g. RFC5= 626=20 > keep-alive for flows without NAT to detect Edge Proxy crash. Maybe addi= ng a=20 > sentence along the following lines could be good: > =E2=80=9CSTUN may also be used for cases where a NAT is not present, e.= g., to detect=20 > crash of an Edge Proxy based on procedures defined in RFC5626 .=E2=80=9D > iii- > Both types of transactions include a transaction ID, which > is a randomly selected 96-bit number. > It may be useful to provide some guidance how this could be made (close= to)=20 > globally unique? > iv- > The server also uses > the transaction ID as a key to identify each transaction uniquely > across all clients. As such, the transaction ID MUST be uniformly > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be > cryptographically random. > There still is the possibility of a clash. What are the implications if= that=20 > happens? A short clarification could be useful. > v- Structurally, it would be better to specify =E2=80=9Cbinding=E2=80=9D= as a =E2=80=9Cmethod=E2=80=9D in its=20 > own/separate section rather than in the sections pertaining to general = message=20 > processing. > vi- > Absent other limits to > the rate of new transactions (such as those specified by ICE for > connectivity checks or when STUN is run over TCP), a client SHOULD > limit itself to ten outstanding transactions to the same server. > What is the justification for this? > vii- > Alternatively, a > client MAY be configured with a set of domains or IP addresses that= > are trusted; if a certificate is received that identifies one of > those domains or IP addresses, the client considers the identity of= > the server to be verified. > Isn=E2=80=99t this already covered by following from RFC6125 (at least = the =E2=80=9Cdomain=E2=80=9D) > 1. The client constructs a list of acceptable reference identifiers > based on the source domain and, optionally, the type of service= > to which the client is connecting. > ... > As previously mentioned, this document specifies that > a URI-ID always contains a "host" component (or its equivalent) > containing a "reg-name". (Matching only the "reg-name" rule fro= m > [_URI_ ] limits verificatio= n to DNS=20 > domain names, thereby > differentiating a URI-ID from a uniformResourceIdentifier entry > that contains an IP address or a mere host name, or that does no= t > contain a "host" component at all.) > It seems only =E2=80=9CIP=E2=80=9D is excluded. > viii- > It checks that the first two > bits are 0, that the magic cookie field has the correct value, that= > the message length is sensible, and that the method value is a > supported method. > What does =E2=80=9Csensible=E2=80=9D mean in this context? > ix- > If the success response contains unknown comprehension-required > attributes, the response is discarded and the transaction is > considered to have failed. > When would such a response be generated? > x- > If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they = do > this. > It may be useful to provide some guidance/recommended values? > xi- > If the part contains an IP address, then this IP address is > used directly to contact the server. A "stuns" URI containing an I= P > address MUST be rejected, unless the domain name is provided by the= > same mechanism that provided the STUN URI, and that domain name can= > be passed to the verification code. > Isn=E2=80=99t this in conflict with the statement > Alternatively, a > client MAY be configured with a set of domains or IP addresses that= > are trusted; if a certificate is received that identifies one of > those domains or IP addresses, the client considers the identity of= > the server to be verified. > xii- Would it be useful to define a DHCP option for STUN Servers simila= r to SIP=20 > in RFC3361? > xiii- > If the request was sent over an unreliable transport, the response > MUST be discarded, as if it was never received. This means that > retransmits, if applicable, will continue. If all the reponses > received are discarded then instead of signalling a timeout after > ending the transaction the layer MUST signal that an attack took > place. > Why signal attack only if all retransmissions are problematic? Shouldn=E2= =80=99t this=20 > happen even if only one is discarded? > xiv- =E2=80=9CBasic Server=E2=80=9D, what does it really refer to? What= are alternatives? Was=20 > the goal here to describe behavior of a =E2=80=9CSTUN Binding Server=E2= =80=9D? If so, shouldn=E2=80=99t=20 > it be renamed as such rather than as =E2=80=9CBasic Server=E2=80=9D? Or= are there procedures=20 > which pertain to =E2=80=9CBasic Servers in general=E2=80=9D (again what= ever a Basic Server is)?=20 > Is defining behavior for a =E2=80=9Cbackward compatible server=E2=80=9D= the real goal here? > xv- > 10. ALTERNATE-SERVER Mechanism > What is raison d=E2=80=99etre for defining such a mechanism? Is there a= n already known=20 > use case? > xvi- > It SHOULD NOT > utilize the short-term or long-term credential mechanism. This is > because the work involved in authenticating the request is more tha= n > the work in simply processing it. It SHOULD NOT utilize the > ALTERNATE-SERVER mechanism for the same reason. > Isn=E2=80=99t backward compatibility the real reason for not using cred= entials and=20 > ALTERTNATE-SERVER? Otherwise there could be reasons other than processi= ng cost=20 > which could make them applicable, e.g. for credentials, not wanting to = serve=20 > illegitimate users, and for ALTERNATE-SERVER getting ready for an upgra= de. > xvii- From idnits: > ** Downref: Normative reference to an Informational RFC: RFC 1321 > ** Downref: Normative reference to an Informational RFC: RFC 2104 > ** Obsolete normative reference: RFC 2460 > ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RF= C 7615, > RFC 7616, RFC 7617) > =3D=3D Outdated reference: A later version (-12) exists of > draft-ietf-ice-rfc5245bis-01 > -- Obsolete informational reference (is this intentional?): RFC 2616= > (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, R= FC 7235) > -- Obsolete informational reference (is this intentional?): RFC 3489= > (Obsoleted by RFC 5389) > -- Obsolete informational reference (is this intentional?): RFC 5226= > Thanks, > Tolga >=20 >=20 >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --eGxp9kgnPPacpjuAJf5xCadoaNtLpHu3K-- --VjATvXlV3lRL2FuxjuJjPpOtAcRtcLRA4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlnUrWsACgkQKcRFldZq fsQ6axAAtVkn+4/x9AY8WPm9DkjQqImCmUg3HLLL01MX8Vw4eDZF8+56XvXFedHA 5eXz7hwtisTVjtB0P+Rtd2BCY0hyGWE7c4x+YyIZOZbNujOF1fKGjVKqDh5VonxU wA8yxqPMPW07+fa7KFR6z5nf1W/nTeDnB2Oq5DX0YYnlu+jfC6zM91CyOHdmOaYv BoHxXXqiijdOcsPZZU1E89PxX3HfCFCRzGg+tqqyv1Np1r7gjFvcULagkb0/c1+F xUp/K8Zs4uHQBczSUqHswO7tUgp7DKxiDHF3s1a0cSEyfY7GDoNiiDH4g3/B9axV O7gPsqdF/HBDk101z/bK7f+BD7TIZAZptc2KJvBsyiHyhFNml4L20RjslLorxYEj RoebEIEsJUbQVSYCgvF801LjYoNaMUcZjJOw7LpvcXyhIt2rRU7sefmiVhsHH+Tl jPncBkwI921KbZ+Psu+61Ca1KUMMPoNSUdzRtdeVJ40ue9xaP7B6xGobulwrYe5r HtJL2etpucuFHve0pWaLl5re89cG+bZGw5VkfPMGkKOEnPf2acPXx+tf3Gg12JXe amXgrEbqZ6mpyJW+HgbvR6xkA/vU+I/TYlYAttXwGZUzg3F9q0eBm5LhDtzCj8Vs bTolNklswuGhOGnnuBhfDGg4GcUfRtRTosoZ+PSEFB+qcZAwzh8= =VQzI -----END PGP SIGNATURE----- --VjATvXlV3lRL2FuxjuJjPpOtAcRtcLRA4-- From nobody Wed Oct 4 02:46:17 2017 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 B11BE1342C2 for ; Wed, 4 Oct 2017 02:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.458 X-Spam-Level: * X-Spam-Status: No, score=1.458 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 HsO4x6x1wt_N for ; Wed, 4 Oct 2017 02:46:14 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08460132F3E for ; Wed, 4 Oct 2017 02:46:14 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:943d:2392:4c46:83bb] (unknown [IPv6:2601:648:8301:730f:943d:2392:4c46:83bb]) (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 1AFD5AE814; Wed, 4 Oct 2017 11:46:11 +0200 (CEST) To: Gonzalo Camarillo , tram@ietf.org References: From: Marc Petit-Huguenin Message-ID: <907d94c8-71fa-b1d7-2f76-797629476a07@acm.org> Date: Wed, 4 Oct 2017 02:46:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m6lUxP2sMXWji1WonqGJB79Pq0ALFnSRt" Archived-At: Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 09:46:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m6lUxP2sMXWji1WonqGJB79Pq0ALFnSRt Content-Type: multipart/mixed; boundary="8HEq42wRTGgG3JOubLUVSrIhDa58orOrJ"; protected-headers="v1" From: Marc Petit-Huguenin To: Gonzalo Camarillo , tram@ietf.org Message-ID: <907d94c8-71fa-b1d7-2f76-797629476a07@acm.org> Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 References: In-Reply-To: --8HEq42wRTGgG3JOubLUVSrIhDa58orOrJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, I completely missed the deadline on that. I'll sent my long overdue revi= ew beginning of next week. Thanks. On 09/15/2017 11:47 AM, Gonzalo Camarillo wrote: > Folks, >=20 > we are starting a Working Group Last Call (WGLC) on the following draft= : >=20 > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > This WGLC will end on October 2nd. Please, send your comments to this > list. Thanks! >=20 > Cheers, >=20 > Gonzalo >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --8HEq42wRTGgG3JOubLUVSrIhDa58orOrJ-- --m6lUxP2sMXWji1WonqGJB79Pq0ALFnSRt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlnUreIACgkQKcRFldZq fsQb/hAAwIa4R0iNfmUgg+hc6xwBnYBS5BpNc/16fFC6RycNBao765ipXBPGv45G 5DORmxSKoq2xs1061iFdCmjHyag2sS15r6mI3/dDdIhgVgX0rKbelkNePXvDKxKG NLcSqiU4MojyH9XmUgi7JO3khoIKxABq9kBHsiOoqGNoEj+ydweCr3akQ21BNHgV 2DDNCauIv+S16eD12WPE/0n6bCl7aN/RpXou6YSXLPli/rxX6PWZtb7HUZbXeLpH TXvFLSURRW6FhY317hhcTOH2Dd2TVtnpEK02T6vWCsSGwkCXFxsmnhuMbPXkSqb0 qpDbLc4MJQvNv5JJBY945x1PiTYoWh0Gsq+fGZHv6oU4icuv1U9KM5V/ALlYn01G X3/9r+fPC0Y4e/30ZL9uaiSSb0p2C7yuVJ8V80LIXf5wG69NJ6Gj7UGxS9OSi0LJ OzL9o3I9njobT/z9vhbnXYONERgG/48iv4Xfe8zvLLuPFTW9j20Xs9BM9gHAWvaR wxtboYoGmlxmiQEWkUnCJSkaJcMhChXgCbmGnVtZU3FVvBw30UU9X1GoursqaOJj N/QypgpFzJqY2h5DAIrmyYUnN8iz26WniWdBJFS3euWYNr4SLMht21vmtKrLsfUI d6s0qytnd16AY7M3E9U8nnegmQIyy7uwMAjB/arAVbzcc2AHnNM= =arCp -----END PGP SIGNATURE----- --m6lUxP2sMXWji1WonqGJB79Pq0ALFnSRt-- From nobody Fri Oct 13 12:29:37 2017 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 6B6BE133210 for ; Fri, 13 Oct 2017 12:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no 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 Ss-06--3TOac for ; Fri, 13 Oct 2017 12:29:33 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A63A133039 for ; Fri, 13 Oct 2017 12:29:33 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:bdc3:8fa6:6b6:a9af] (unknown [IPv6:2601:648:8301:730f:bdc3:8fa6:6b6:a9af]) (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 07948AE80A for ; Fri, 13 Oct 2017 21:29:30 +0200 (CEST) To: "tram@ietf.org" From: Marc Petit-Huguenin Message-ID: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> Date: Fri, 13 Oct 2017 12:29:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CPfu3BJrp8SV9LbSPKhpHNC1Fbxhq3V1U" Archived-At: Subject: [tram] Review of dual allocation in TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 13 Oct 2017 19:29:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CPfu3BJrp8SV9LbSPKhpHNC1Fbxhq3V1U Content-Type: multipart/mixed; boundary="UVeT1v4ePBLrF1POt81ALBM9wnsRggATR"; protected-headers="v1" From: Marc Petit-Huguenin To: "tram@ietf.org" Message-ID: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> Subject: Review of dual allocation in TURNbis-11 --UVeT1v4ePBLrF1POt81ALBM9wnsRggATR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I should first apologize the the delay in reviewing this draft. I never = managed to get a sponsorship that spans the whole lifetime of a draft (or= a Working Group for that matter), and that why it is so difficult for me= to work on IETF stuff in a sustained and consistent manner. Anyway, I was working on a review for turnbis-11 that was specifically fo= cusing on the synchronization with stunbis, but I kept be distracted by i= ssues related to the dual allocation feature. So I decided instead to se= nd a separate email for that, to make things less confusing. My main comment about the dual allocation approach is about the choice of= adding a new attribute for that. STUN supports sending multiple attribu= tes of the same type, and has a default processing rule for them ("Any at= tribute type MAY appear more than once in a STUN message. Unless specifi= ed otherwise, the order of appearance is significant: only the first occ= urrence needs to be processed by a receiver, and any duplicates MAY be ig= nored by a receiver.") So a TURNbis client that wants to do a dual allocating adds two REQUESTED= -ADDRESS-FAMILY (RAF), one for IPv4 and one for IPv6. An RFC 5766 server= will just use the first one and ignore the second. The TURNbis client r= eceives only one XOR-RELAYED-ADDRESS (XRA), for the first RAF it sent. The client can choose the order, so it receives immediately a XRA from th= e family it is most interested in, and can try a second allocation for th= e other if the server is implementing RFC 5766. I think that this makes for simpler rules to implement and simpler text. Now some more specific comments about the text: - Title and abstract The draft should obsolete both RFC 5766 and RFC 6156, and that fact shoul= d be repeated in the abstract. The authors of RFC 6156 should be acknowl= edged either in the Acknowledgment or Contributors section. - Section 5. The first item in the bullet list should say "the relayed transport addre= ss or addresses;" In the the fourth item, there is one time-to-expiry per relayed transport= address. Same for the list of permissions in the fifth item. "Both the relayed transport address and the 5-tuple MUST be unique across= all allocations, so either one can be used to uniquely identify the allo= cation." With the dual allocation, the 5-tuple no longer uniquely identify an allo= cation. - Section 6.2=20 I would suggest to make ADDRESS-ERROR-CODE more generic by renaming it as= WARNING-CODE and use the same format than for ERROR-CODE. Then allocate= a new error code for that specific warning. I would suggest to request = the 0x8009 codepoint for that attribute. Also I think we needs two different warnings, one that states that dual a= llocation is not available in a TURNbis server, but both protocols are av= ailable, and another that says that dual allocation failed because one of= the two protocols is not available. This is to let the client know that= it is useless to try another allocation for the missing protocol. What is the policy when reserving the next port with the EVEN-PORT attrib= ute in a dual allocation, but one of them fails to find a pair of subsequ= ent ports available? It is not said that the Allocate successful response must contain two XRA= s after a successful dual allocation. I would also suggest to add some text that says that when a TURNbis serve= r sends an Allocate success response, it must always send the XRAs in the= same order than the RAFs were sent. So in case the server sends back by= mistake two XRAs, the first one matches the one requested by the client.= The bullet list at the end needs also to be fixed for dual allocation. - Section 6.3 Here's too, the text needs to be updated for the dual allocation case. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --UVeT1v4ePBLrF1POt81ALBM9wnsRggATR-- --CPfu3BJrp8SV9LbSPKhpHNC1Fbxhq3V1U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlnhFBQACgkQKcRFldZq fsREXg//dYnvlJXM1bX4eDYYRZ1UkabJCLGZlIWfTB0PPwEQP5d7e6qY6MCxzNx/ HlaCKyNphNDsfOuKp2yYfkLxDkhyk6BrwtykxK87mNeUT9z4euIWVKT4H9tV1O0q 2o1Z+5OBuIMJNNtJQatIXvZfRczHK51uJS+OB395BUPWX8InJVNZwn+PnHs8xLCb iYVCs+A+Nf20zlB41yL8brmDNo2SMIJabONKeasriKiT2Hfj1S/ol8ArKZf7uzAW nR0MfB1rt9Eth0dgmxVP1/RVvadcD9m99NyUa0KSShrB0gmajtFmn6wcwTJ7vy2b ohoD6JXRaCxYV3AUumVCeE+BHIdNXm30ZW41y1Yhz3sKAGVDv8aI52kuk65omHGH HzyAlZDh85qLBfFVXl7Jzv7Z8jv6KDW+l/WpgIYfGu3K8txKlg2B7kgEH8tlCH35 V/EwdElhzfinX/xFhCpErzdNBYI2JY1APIfsMHiFAiVsOefE0kAGa6jnQyPpim/X UplYcLNZiUBr5di8yN0+fDNkWFiYEOsXqiRb0CmEpx6EVZZt5x48bPgnt6gZczFc 4b1BylK4VisOQEKRa5VnXG/qon2+gMBOe2cD93SQQ6vcYSN2IlEqesG+h+IxqnOW +2H8biicZHIE0Mge84w5Mazv8D0uKnx9OFfoRcS6lijnfrAa6FU= =5Ov3 -----END PGP SIGNATURE----- --CPfu3BJrp8SV9LbSPKhpHNC1Fbxhq3V1U-- From nobody Mon Oct 16 02:19:50 2017 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 2350413449D for ; Mon, 16 Oct 2017 02:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 WiLuZx7DKEOY for ; Mon, 16 Oct 2017 02:19:46 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA1D1344A4 for ; Mon, 16 Oct 2017 02:19:45 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1508145578; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7 i/jnQLVkOHiubIDyVYEJOPXXKP/tm1sYphpvO/WWi U=; b=fs7i3CoAuZTuCZpYbO+un+2ErAvy9t4fwNIvELSfuiaq i60Ct9/2tY+vythUi8NBWBN7l8ogwmhFPKso4WShZj60VqDwmQ f42P8C0kwGcqdVVB0aqS/Iym6gAA8ffzL6rBe3gy3FbJzc22zc sp5HVfx4zJiktwOdsikmafLoVFM= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 29f9_68b1_a5e8f345_eded_47c7_8614_35c5f6f81b3b; Mon, 16 Oct 2017 04:19:38 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 05:19:26 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 16 Oct 2017 05:19:26 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 05:19:25 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 16 Oct 2017 09:19:25 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.022; Mon, 16 Oct 2017 09:19:25 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , Gonzalo Camarillo , "tram@ietf.org" Thread-Topic: [tram] WGLC: draft-ietf-tram-turnbis-11 Thread-Index: AQHTLlM16KjsH3Wyr06kc9dpuhEEUaLPd8kAgBbW9tA= Date: Mon, 16 Oct 2017 09:19:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:zzMZvog29wml4qdcfs6QkpEQklOfxYdJMlYFD/JlCYViLcLx8l3mnbXFyBVx5IpJkqRvZKZfvYpojlNjhLw/zkd4vPW5Ihtt1b64PzL84s70S+7ZhT7B2UZgbxpjbJiN1Vvsd6k0HjLFiSgj+dqidIDUM37Xs/LS7RTanpc8oewjyjGhSYy5ePrp40+f2XMqz4QywTDzIpQGQNpvzb4OdOcHkhz4AbZ2lMgma1qJV74mNrYSwO7eDuEBcz5/MNjjKIUBHT5buzkWpeSmbksowgnPwclKDft0ToZllharMyAJ6poyXjZ7QiHucCtJrBbUqXVsQum6qlDWYx7f6zL3fA==; 5:M5siKOdMi78eGf9JreiQ2qWF4RrJovkl8w7w6aeaH8kF6cN7djwdZm/fIkemQYPNu5jbOruWB2NHExofT9lOMq+3vCwu8C5enTo9GqMvtGpKW0T5YBrUa7wj96+H1JUI8sNZmGNqMf61wYLoH8EKzQ==; 24:iIPz7iTeIfqm4lf8Z/KZh+hWgA3Oh6QytWxWybDYC568MrlqTPDigxU2tU/YkduojweNIIMMf+Kgnqm4gD3RGqgwyTOBtoaaoxnHtJA5/54=; 7:eOwnoK1bnn91o6oystcD0SU7fG51h5ktA10BWxcP4KWQ+zQmAIBy3gnPK44g9SfLZAZerNOhREwFPZhzHww+6P+Y+QhtypFOZGGEvKhYjtuBmF/vMLymNhGT4wf9sAvlw/npJJJ3HY6k8Sw0W/Ptq9ehgRq4Dx0NjuY9keaId2tCurYIcbFwTJJin35chmt5v4pV1QRsaAqhT9+jW3wLxYCULJUjjzoG6mfqXAAuiy0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7878d38e-f9c2-4882-b9fd-08d51476fe89 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(32952001)(24454002)(377454003)(13464003)(189002)(53546010)(189998001)(6246003)(7696004)(99286003)(55016002)(316002)(68736007)(6306002)(9686003)(3660700001)(3280700002)(229853002)(14454004)(110136005)(2950100002)(5660300001)(86362001)(53936002)(66066001)(478600001)(81166006)(72206003)(966005)(76176999)(54356999)(81156014)(97736004)(2900100001)(8676002)(105586002)(106356001)(6436002)(102836003)(6116002)(305945005)(7736002)(2501003)(25786009)(50986999)(3846002)(80792005)(8936002)(101416001)(6506006)(77096006)(2906002)(74316002)(33656002)(230783001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 09:19:24.9846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6136> : inlines <6133> : streams <1767470> : uri <2517352> Archived-At: Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 09:19:48 -0000 Thanks Brandon for the review, Please see inline. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Monday, October 2, 2017 12:50 AM > To: Gonzalo Camarillo ; tram@ietf.org > Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 >=20 > I have a couple final comments re: the version 11 and the changes between > version 10 and version 11. Apologies for taking so long for this. I thoug= h I had > done it already but realize now that I was remembering my response to the > stunbis update. >=20 > 1) idnits calls out a handful of things to check or resolve. > a) The doc should use documentation range IPv4 addresses throughout. Fixed.=20 > b) Are there any cases where IPv6 examples should also be provided? No. > c) There are some obsolete and/or outdated references to fix. Fixed all errors reported by idnits.=20 >=20 > 2) On page 19, there are two new uses of the word "can": > "the TURN client can silently abandon" > "the client can silently abandon" > These references are about applying address family precedence. Is this te= xt > meant to be normative? If so, it should use "MAY" instead of "can". "SHOULD" looks more suitable than "MAY". >=20 > The rest looks as expected I think. -Tiru >=20 > --Brandon >=20 > On 09/15/2017 02:47 PM, Gonzalo Camarillo wrote: > > Folks, > > > > we are starting a Working Group Last Call (WGLC) on the following draft= : > > > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > This WGLC will end on October 2nd. Please, send your comments to this > > list. Thanks! > > > > Cheers, > > > > Gonzalo > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Oct 16 02:29:11 2017 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 9F48313449D for ; Mon, 16 Oct 2017 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 kgDqi9-Jdzx0 for ; Mon, 16 Oct 2017 02:29:08 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90CB132944 for ; Mon, 16 Oct 2017 02:29:07 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1508146146; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=z HGA3BUhABohHL2M6qjy5t8B13BQRLuCnZiE7XUGM7 U=; b=GzJnSe1TEvzmyrgCU1dPd0KgdhwAT5VOfcUH00meH8oA fcwfP5ZlzUl9TfadxOfd49YMEVfu2NG4X4h7du/Y5iboyAkGq/ FGV9Zs0wky/08Yqbwu2b9NWNvQZk9oo2aXcvUdBe6c5T3lBeTD uP6vjV6mCh1rqRrX7m5JI5i2L3Q= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 4d02_4dfb_561802b0_220a_40c0_a84b_35a7dd0ce307; Mon, 16 Oct 2017 04:29:06 -0500 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 03:29:02 -0600 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 16 Oct 2017 03:29:02 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 16 Oct 2017 03:29:01 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 03:29:00 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 16 Oct 2017 09:28:59 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.022; Mon, 16 Oct 2017 09:28:59 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , Gonzalo Camarillo , "tram@ietf.org" Thread-Topic: [tram] WGLC: draft-ietf-tram-turnbis-11 Thread-Index: AQHTLlM16KjsH3Wyr06kc9dpuhEEUaLPd8kAgAANWQCAFt41kA== Date: Mon, 16 Oct 2017 09:28:59 +0000 Message-ID: References: <457a35de-5eec-ce93-8d81-6484911161b0@akamai.com> In-Reply-To: <457a35de-5eec-ce93-8d81-6484911161b0@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:KiwLc+5dN7B1j6lUObIrqfWQK/48nUykaKcjIqdDXrNt2F12hjHA9vOAtd2HxoazHl8y17kYdgSbQuiyPj14Mj/VQf9lzqXd2rIXNcY35VqJ7KalvO6ZxPfozBg2re4X6VQgrmfrUH1inGsQYMYnBUgxY4iexBxpaVYlZWFqq7rRQcFcztGs7cjDPC+WwE8bBV8IzovybRWeVFwLIdgj0fGfQhftZTIg3nHmxBW/9omkEuk7fn1y6xRCfRqP3AUGGe9DwTA1kPVb9WPGoPxhpF26a9b3D1wKo69CBu8osV35l6ErPNzEQ7rIIaddHGIZL7ZcSo9k1wevxvNVMHTJyQ==; 5:Q+jbS+kxKitwQ+nTlkMFK83I4WNEqpVJo+59x06Q33FZooYdXyfsldV1nYRRiyFaCwRhTtMqQ4mxXgdwslMGlTRwYxyzKAq2Mhy3caTnRlAWj9c2xzsYgHq2BqKUHF+b+Z/1a2gvlBL899mORLt9jA==; 24:Z+9QW3L+Gd/b4Cq5d6zs+hwssu3+hBRgDjP7BKgIRNhIFCT/03E0faCUtnegZn8cqWuv7kJm7StWv6t7fGsafDC5QsOHPWiW06lNGBasb4Y=; 7:u1q/AzvzdsspJDYQ3nkG0oxIfjue/xStYmC0BJhSeDyOaYayi5HNWvh4vGSzGgZvNYIGNseO/ZkjsDgEMCFEoJJrlPdMRSHf0B2Hn8nyxcN52jWtu/mpwZXk8AzaaOtgqGajfI9XSow4HJTyyX1blidFX5VcWt9KiRbv1iAlNm4ONdrPxy004ozhTv2HuUohsUXuKCSVYNy629t71ddNL85yIiaxGYEyenj6TOW7dn0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e5fca7c9-d741-4eb6-7b45-08d5147854cb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377454003)(24454002)(13464003)(199003)(32952001)(189002)(14454004)(72206003)(54356999)(76176999)(966005)(7696004)(2950100002)(97736004)(53546010)(2900100001)(25786009)(229853002)(105586002)(6506006)(106356001)(77096006)(50986999)(101416001)(478600001)(3660700001)(3280700002)(86362001)(189998001)(6436002)(2906002)(305945005)(53936002)(7736002)(68736007)(2501003)(230783001)(74316002)(8936002)(81156014)(81166006)(8676002)(102836003)(6116002)(6246003)(3846002)(33656002)(110136005)(80792005)(316002)(6306002)(99286003)(5660300001)(66066001)(9686003)(55016002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 09:28:59.2795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6136> : inlines <6133> : streams <1767471> : uri <2517355> Archived-At: Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 09:29:10 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Monday, October 2, 2017 1:37 AM > To: Gonzalo Camarillo ; tram@ietf.org > Subject: Re: [tram] WGLC: draft-ietf-tram-turnbis-11 >=20 > One more nit that I just noticed ... >=20 > 3) Section 15.13. ICMP Attribute contains a field called "Type" in the at= tribute > value. Since attributes are TLV encoded with Type and Length as the first= two > fields, it might be better to call this field in the attribute value "ICM= P Type" > instead of just "Type". Replaced "Type" with "ICMP Type" and "Code" with "ICMP Code". -Tiru >=20 > --Brandon >=20 > On 10/01/2017 03:19 PM, Brandon Williams wrote: > > I have a couple final comments re: the version 11 and the changes > > between version 10 and version 11. Apologies for taking so long for > > this. I though I had done it already but realize now that I was > > remembering my response to the stunbis update. > > > > 1) idnits calls out a handful of things to check or resolve. > > a) The doc should use documentation range IPv4 addresses throughout. > > b) Are there any cases where IPv6 examples should also be provided? > > c) There are some obsolete and/or outdated references to fix. > > > > 2) On page 19, there are two new uses of the word "can": > > "the TURN client can silently abandon" > > "the client can silently abandon" > > These references are about applying address family precedence. Is this > > text meant to be normative? If so, it should use "MAY" instead of "can"= . > > > > The rest looks as expected I think. > > > > --Brandon > > > > On 09/15/2017 02:47 PM, Gonzalo Camarillo wrote: > >> Folks, > >> > >> we are starting a Working Group Last Call (WGLC) on the following draf= t: > >> > >> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > >> > >> This WGLC will end on October 2nd. Please, send your comments to this > >> list. Thanks! > >> > >> Cheers, > >> > >> Gonzalo > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram > >> > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Oct 16 19:14:30 2017 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 1E5FC133074 for ; Mon, 16 Oct 2017 19:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 HUQxXruOJTNG for ; Mon, 16 Oct 2017 19:14:26 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8068132D53 for ; Mon, 16 Oct 2017 19:14:25 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1508206464; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=X mW+GvWl1Xs7jNIIWiJwz3zE/jVSO7KgPsaFESuA4S Q=; b=fGJvd2zxyEfD6y0hVeWStSTPGGadu8qMJkwhPvkLx1Cc LwYoXsbZUWEXgNXuK95zDvRXUXVDiYbP05MftpAoO2rlD06yjP w0AkOYwrJ5e2wF+KnoKA7VTfmDZ0pYb8fsZoapGSrQ6/gX3qWM d8s6zaeJC5zWVbaMlHZkK7PDb8I= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 29f9_8478_c666617c_d3f2_4615_8b92_eac71898d72e; Mon, 16 Oct 2017 21:14:24 -0500 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 22:14:23 -0400 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 22:14:22 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 16 Oct 2017 22:14:22 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 16 Oct 2017 22:14:21 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 17 Oct 2017 02:14:20 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 02:14:20 +0000 From: "Konda, Tirumaleswar Reddy" To: Marc Petit-Huguenin , "tram@ietf.org" Thread-Topic: [tram] Review of dual allocation in TURNbis-11 Thread-Index: AQHTRFmkTUXySTsG3EGzRBQMWeAaDaLmPU1Q Date: Tue, 17 Oct 2017 02:14:20 +0000 Message-ID: References: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> In-Reply-To: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.172.106.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:t5ilUNaMN/GIR0beN+xnkr4IVatZvNqRG4QEvQ2inkx3ie0x01MZH3uABcUkqNJbGMgcCM9xVWgq/cdDpMiAW4qc90ua65Z4kGXe9y6cYN89HtnRbp8PSUJUccUWgaJNPphk4lAvZE5trYZwgjRIi4Vep08yIlZNpug37yRUUohOBEGv5i/AqEPBw92k1xt9t2DEy7mUSjqsSxxrelbMa+rrGdMNmjgUz+TQUfIordQQCzjmm0KH4M/Jslw2WzDt3lulvvPPw/hzkzi7ddkr0MeL2KR7HWadAMfktpqtDFCtT+zK6N71aRO2Z+uw1/zfZJhYyKOHVTYHzszaC8aiOg==; 5:B63LPJlhAJUPnvvCoDG1O7QksxcBX07CiFK8d29+jbprVtWLxw9oY8AFacMr7T4UtcbUC5HvMdGzHDCBkS/luJlY2h3CUOH8r1vfs5SzDlNr8meSLXVSc5iFwl6dZcdY6VcqudWcNNBMoqlxk0q7xw==; 24:Zn3hDKsHpcEjERQCAXycnRr3CjgkyRiGZDyjXPA6z4a78hiTrC3W91okpqLXMIpTE59ikh9LtfU7cu4SU73B6Nih/oMzEFttOrItCb5KjMQ=; 7:KuyBZhqWT7Gab/QwDX9x7PATeaGTRdNMUj0xVq+bQhJHhavIv920DMBMJsBsBqQTLmYhuesYeibPBeQSCE9bE2p/RlXa4znFIZQRY9OR6qxnHjr8mN7zz+rjNoFyn+PyPKuxzDrR7Lu6lD+v4NTRPVV4LGcDWT1+4uCy3hrfCUPAEa1bU1aFf1F4Qs0b5BxJAoaYhi3K6/ZJfS74USDA3LS87pd3n7P+G9QZAJvVqk4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 432be927-94e7-4f24-d2cf-08d51504c6de x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(158342451672863)(128460861657000)(81160342030619); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(252514010)(189002)(51444003)(52314003)(32952001)(52084003)(13464003)(377454003)(199003)(53546010)(3660700001)(966005)(97736004)(8936002)(316002)(3280700002)(81156014)(66066001)(2950100002)(6306002)(6116002)(3846002)(2906002)(102836003)(86362001)(110136005)(81166006)(2501003)(478600001)(9686003)(72206003)(8676002)(14454004)(6506006)(55016002)(74316002)(6436002)(5660300001)(105586002)(305945005)(99286003)(53936002)(33656002)(45080400002)(76176999)(50986999)(7736002)(2900100001)(77096006)(54356999)(7696004)(106356001)(25786009)(68736007)(6246003)(101416001)(80792005)(189998001)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 02:14:20.2206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6137> : inlines <6133> : streams <1767567> : uri <2517734> Archived-At: Subject: Re: [tram] Review of dual allocation in TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 17 Oct 2017 02:14:28 -0000 VGhhbmtzIE1hcmMgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcsIFBsZWFzZSBzZWUgaW5saW5lDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmMgUGV0aXQtDQo+IEh1Z3VlbmluDQo+ IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDE0LCAyMDE3IDEyOjU5IEFNDQo+IFRvOiB0cmFtQGll dGYub3JnDQo+IFN1YmplY3Q6IFt0cmFtXSBSZXZpZXcgb2YgZHVhbCBhbGxvY2F0aW9uIGluIFRV Uk5iaXMtMTENCj4gDQo+IEkgc2hvdWxkIGZpcnN0IGFwb2xvZ2l6ZSB0aGUgdGhlIGRlbGF5IGlu IHJldmlld2luZyB0aGlzIGRyYWZ0LiAgSSBuZXZlciBtYW5hZ2VkDQo+IHRvIGdldCBhIHNwb25z b3JzaGlwIHRoYXQgc3BhbnMgdGhlIHdob2xlIGxpZmV0aW1lIG9mIGEgZHJhZnQgKG9yIGEgV29y a2luZw0KPiBHcm91cCBmb3IgdGhhdCBtYXR0ZXIpLCBhbmQgdGhhdCB3aHkgaXQgaXMgc28gZGlm ZmljdWx0IGZvciBtZSB0byB3b3JrIG9uIElFVEYNCj4gc3R1ZmYgaW4gYSBzdXN0YWluZWQgYW5k IGNvbnNpc3RlbnQgbWFubmVyLg0KPiANCj4gQW55d2F5LCBJIHdhcyB3b3JraW5nIG9uIGEgcmV2 aWV3IGZvciB0dXJuYmlzLTExIHRoYXQgd2FzIHNwZWNpZmljYWxseQ0KPiBmb2N1c2luZyBvbiB0 aGUgc3luY2hyb25pemF0aW9uIHdpdGggc3R1bmJpcywgYnV0IEkga2VwdCBiZSBkaXN0cmFjdGVk IGJ5DQo+IGlzc3VlcyByZWxhdGVkIHRvIHRoZSBkdWFsIGFsbG9jYXRpb24gZmVhdHVyZS4gIFNv IEkgZGVjaWRlZCBpbnN0ZWFkIHRvIHNlbmQgYQ0KPiBzZXBhcmF0ZSBlbWFpbCBmb3IgdGhhdCwg dG8gbWFrZSB0aGluZ3MgbGVzcyBjb25mdXNpbmcuDQo+IA0KPiBNeSBtYWluIGNvbW1lbnQgYWJv dXQgdGhlIGR1YWwgYWxsb2NhdGlvbiBhcHByb2FjaCBpcyBhYm91dCB0aGUgY2hvaWNlIG9mDQo+ IGFkZGluZyBhIG5ldyBhdHRyaWJ1dGUgZm9yIHRoYXQuICBTVFVOIHN1cHBvcnRzIHNlbmRpbmcg bXVsdGlwbGUgYXR0cmlidXRlcw0KPiBvZiB0aGUgc2FtZSB0eXBlLCBhbmQgaGFzIGEgZGVmYXVs dCBwcm9jZXNzaW5nIHJ1bGUgZm9yIHRoZW0gKCJBbnkgYXR0cmlidXRlDQo+IHR5cGUgTUFZIGFw cGVhciBtb3JlIHRoYW4gb25jZSBpbiBhIFNUVU4gbWVzc2FnZS4gIFVubGVzcyBzcGVjaWZpZWQN Cj4gb3RoZXJ3aXNlLCB0aGUgb3JkZXIgb2YgYXBwZWFyYW5jZSBpcyBzaWduaWZpY2FudDogIG9u bHkgdGhlIGZpcnN0IG9jY3VycmVuY2UNCj4gbmVlZHMgdG8gYmUgcHJvY2Vzc2VkIGJ5IGEgcmVj ZWl2ZXIsIGFuZCBhbnkgZHVwbGljYXRlcyBNQVkgYmUgaWdub3JlZCBieSBhDQo+IHJlY2VpdmVy LiIpDQo+IA0KPiBTbyBhIFRVUk5iaXMgY2xpZW50IHRoYXQgd2FudHMgdG8gZG8gYSBkdWFsIGFs bG9jYXRpbmcgYWRkcyB0d28gUkVRVUVTVEVELQ0KPiBBRERSRVNTLUZBTUlMWSAoUkFGKSwgb25l IGZvciBJUHY0IGFuZCBvbmUgZm9yIElQdjYuICBBbiBSRkMgNTc2NiBzZXJ2ZXINCj4gd2lsbCBq dXN0IHVzZSB0aGUgZmlyc3Qgb25lIGFuZCBpZ25vcmUgdGhlIHNlY29uZC4gIFRoZSBUVVJOYmlz IGNsaWVudCByZWNlaXZlcw0KPiBvbmx5IG9uZSBYT1ItUkVMQVlFRC1BRERSRVNTIChYUkEpLCBm b3IgdGhlIGZpcnN0IFJBRiBpdCBzZW50Lg0KPiANCj4gVGhlIGNsaWVudCBjYW4gY2hvb3NlIHRo ZSBvcmRlciwgc28gaXQgcmVjZWl2ZXMgaW1tZWRpYXRlbHkgYSBYUkEgZnJvbSB0aGUNCj4gZmFt aWx5IGl0IGlzIG1vc3QgaW50ZXJlc3RlZCBpbiwgYW5kIGNhbiB0cnkgYSBzZWNvbmQgYWxsb2Nh dGlvbiBmb3IgdGhlIG90aGVyIGlmDQo+IHRoZSBzZXJ2ZXIgaXMgaW1wbGVtZW50aW5nIFJGQyA1 NzY2DQoNCg0KTm8sIHRoZSBhYm92ZSBjaGFuZ2UgY29udHJhZGljdHMgdGhlIGJlaGF2aW9yIGRl ZmluZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNTYjc2VjdGlvbi0zIA0K PHNuaXA+DQoNCiAgIFRVUk4gc2VydmVycyBhbGxvY2F0ZSBhIHNpbmdsZSByZWxheWVkIHRyYW5z cG9ydCBhZGRyZXNzIHBlcg0KICAgYWxsb2NhdGlvbiByZXF1ZXN0LiAgVGhlcmVmb3JlLCBBbGxv Y2F0ZSByZXF1ZXN0cyBjYW5ub3QgY2FycnkgbW9yZQ0KICAgdGhhbiBvbmUgUkVRVUVTVEVELUFE RFJFU1MtRkFNSUxZIGF0dHJpYnV0ZS4gIENvbnNlcXVlbnRseSwgYSBjbGllbnQNCiAgIHRoYXQg d2lzaGVzIHRvIGFsbG9jYXRlIG1vcmUgdGhhbiBvbmUgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVz cyBhdCBhDQogICBUVVJOIHNlcnZlciAoZS5nLiwgYW4gSVB2NCBhbmQgYW4gSVB2NiBhZGRyZXNz KSBuZWVkcyB0byBwZXJmb3JtDQogICBzZXZlcmFsIGFsbG9jYXRpb24gcmVxdWVzdHMgKG9uZSBh bGxvY2F0aW9uIHJlcXVlc3QgcGVyIHJlbGF5ZWQNCiAgIHRyYW5zcG9ydCBhZGRyZXNzKS4NCjwv c25pcD4NCg0KWW91IG1heSB3YW50IHRvIGdvIHRocm91Z2ggdGhlIGxvbmcgZGlzY3Vzc2lvbiBp biB0aGUgV0cgdG8gcGljayBhIG5ldw0KYXR0cmlidXRlIChBRERJVElPTkFMLUFERFJFU1MtRkFN SUxZKSBmb3IgZHVhbC1zdGFjayBhbGxvY2F0aW9uLg0KDQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhp cyBtYWtlcyBmb3Igc2ltcGxlciBydWxlcyB0byBpbXBsZW1lbnQgYW5kIHNpbXBsZXIgdGV4dC4N Cj4gDQo+IE5vdyBzb21lIG1vcmUgc3BlY2lmaWMgY29tbWVudHMgYWJvdXQgdGhlIHRleHQ6DQo+ IA0KPiAtIFRpdGxlIGFuZCBhYnN0cmFjdA0KPiANCj4gVGhlIGRyYWZ0IHNob3VsZCBvYnNvbGV0 ZSBib3RoIFJGQyA1NzY2IGFuZCBSRkMgNjE1NiwgYW5kIHRoYXQgZmFjdCBzaG91bGQNCj4gYmUg cmVwZWF0ZWQgaW4gdGhlIGFic3RyYWN0LiAgVGhlIGF1dGhvcnMgb2YgUkZDIDYxNTYgc2hvdWxk IGJlDQo+IGFja25vd2xlZGdlZCBlaXRoZXIgaW4gdGhlIEFja25vd2xlZGdtZW50IG9yIENvbnRy aWJ1dG9ycyBzZWN0aW9uLg0KDQpEb25lLiANCg0KPiANCj4gLSBTZWN0aW9uIDUuDQo+IA0KPiBU aGUgZmlyc3QgaXRlbSBpbiB0aGUgYnVsbGV0IGxpc3Qgc2hvdWxkIHNheSAidGhlIHJlbGF5ZWQg dHJhbnNwb3J0IGFkZHJlc3Mgb3INCj4gYWRkcmVzc2VzOyINCg0KVXBkYXRlZCBsaW5lIHRvIHNh eSAiQWxsIFRVUk4gb3BlcmF0aW9ucyByZXZvbHZlIGFyb3VuZCBhbGxvY2F0aW9ucywgYW5kIGFs bCBUVVJOIG1lc3NhZ2VzIGFyZSBhc3NvY2lhdGVkIHdpdGggZWl0aGVyIGEgc2luZ2xlIG9yIGR1 YWwgYWxsb2NhdGlvbi4iDQoNCj4gDQo+IEluIHRoZSB0aGUgZm91cnRoIGl0ZW0sIHRoZXJlIGlz IG9uZSB0aW1lLXRvLWV4cGlyeSBwZXIgcmVsYXllZCB0cmFuc3BvcnQNCj4gYWRkcmVzcy4NCj4g DQo+IFNhbWUgZm9yIHRoZSBsaXN0IG9mIHBlcm1pc3Npb25zIGluIHRoZSBmaWZ0aCBpdGVtLg0K PiANCj4gIkJvdGggdGhlIHJlbGF5ZWQgdHJhbnNwb3J0IGFkZHJlc3MgYW5kIHRoZSA1LXR1cGxl IE1VU1QgYmUgdW5pcXVlIGFjcm9zcw0KPiBhbGwgYWxsb2NhdGlvbnMsIHNvIGVpdGhlciBvbmUg Y2FuIGJlIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgdGhlIGFsbG9jYXRpb24uIg0KPiANCj4g V2l0aCB0aGUgZHVhbCBhbGxvY2F0aW9uLCB0aGUgNS10dXBsZSBubyBsb25nZXIgdW5pcXVlbHkg aWRlbnRpZnkgYW4gYWxsb2NhdGlvbi4NCg0KWWVzLCBmaXhlZC4gDQoNCj4gDQo+IC0gU2VjdGlv biA2LjINCj4gDQo+IEkgd291bGQgc3VnZ2VzdCB0byBtYWtlIEFERFJFU1MtRVJST1ItQ09ERSBt b3JlIGdlbmVyaWMgYnkgcmVuYW1pbmcgaXQNCj4gYXMgV0FSTklORy1DT0RFIGFuZCB1c2UgdGhl IHNhbWUgZm9ybWF0IHRoYW4gZm9yIEVSUk9SLUNPREUuICBUaGVuDQo+IGFsbG9jYXRlIGEgbmV3 IGVycm9yIGNvZGUgZm9yIHRoYXQgc3BlY2lmaWMgd2FybmluZy4gIEkgd291bGQgc3VnZ2VzdCB0 bw0KPiByZXF1ZXN0IHRoZSAweDgwMDkgY29kZXBvaW50IGZvciB0aGF0IGF0dHJpYnV0ZS4NCg0K SSBkb24ndCB1bmRlcnN0YW5kIHRoZSBuZWVkIHRvIGNoYW5nZSBBRERSRVNTLUVSUk9SLUNPREUg IQ0KDQo+IA0KPiBBbHNvIEkgdGhpbmsgd2UgbmVlZHMgdHdvIGRpZmZlcmVudCB3YXJuaW5ncywg b25lIHRoYXQgc3RhdGVzIHRoYXQgZHVhbA0KPiBhbGxvY2F0aW9uIGlzIG5vdCBhdmFpbGFibGUg aW4gYSBUVVJOYmlzIHNlcnZlciwgYnV0IGJvdGggcHJvdG9jb2xzIGFyZQ0KPiBhdmFpbGFibGUs IGFuZCBhbm90aGVyIHRoYXQgc2F5cyB0aGF0IGR1YWwgYWxsb2NhdGlvbiBmYWlsZWQgYmVjYXVz ZSBvbmUgb2YNCj4gdGhlIHR3byBwcm90b2NvbHMgaXMgbm90IGF2YWlsYWJsZS4gIFRoaXMgaXMg dG8gbGV0IHRoZSBjbGllbnQga25vdyB0aGF0IGl0IGlzDQo+IHVzZWxlc3MgdG8gdHJ5IGFub3Ro ZXIgYWxsb2NhdGlvbiBmb3IgdGhlIG1pc3NpbmcgcHJvdG9jb2wuDQoNCkkgZG9uJ3QgZ2V0IHRo ZSByZWFzb24gZm9yIHR3byBkaWZmZXJlbnQgd2FybmluZ3MuIA0KDQo+IA0KPiBXaGF0IGlzIHRo ZSBwb2xpY3kgd2hlbiByZXNlcnZpbmcgdGhlIG5leHQgcG9ydCB3aXRoIHRoZSBFVkVOLVBPUlQN Cj4gYXR0cmlidXRlIGluIGEgZHVhbCBhbGxvY2F0aW9uLCBidXQgb25lIG9mIHRoZW0gZmFpbHMg dG8gZmluZCBhIHBhaXIgb2YNCj4gc3Vic2VxdWVudCBwb3J0cyBhdmFpbGFibGU/DQoNCkl0J3Mg ZGlzY3Vzc2VkIGluIHNlY3Rpb24gNi4xDQoNCjxzbmlwPg0KICAgQ2xpZW50cyBNVVNUIE5PVA0K ICAgaW5jbHVkZSBBRERJVElPTkFMLUFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZSBpbiBhIEFsbG9j YXRlIHJlcXVlc3QNCiAgIHRoYXQgY29udGFpbnMgYW4gRVZFTi1QT1JUIGF0dHJpYnV0ZSB3aXRo IHRoZSBSIGJpdCBzZXQgdG8gMS4NCjwvc25pcD4NCg0KPiANCj4gSXQgaXMgbm90IHNhaWQgdGhh dCB0aGUgQWxsb2NhdGUgc3VjY2Vzc2Z1bCByZXNwb25zZSBtdXN0IGNvbnRhaW4gdHdvIFhSQXMN Cj4gYWZ0ZXIgYSBzdWNjZXNzZnVsIGR1YWwgYWxsb2NhdGlvbi4NCg0KR29vZCBwb2ludCwgVXBk YXRlZCBkcmFmdC4gDQoNCj4gDQo+IEkgd291bGQgYWxzbyBzdWdnZXN0IHRvIGFkZCBzb21lIHRl eHQgdGhhdCBzYXlzIHRoYXQgd2hlbiBhIFRVUk5iaXMgc2VydmVyDQo+IHNlbmRzIGFuIEFsbG9j YXRlIHN1Y2Nlc3MgcmVzcG9uc2UsIGl0IG11c3QgYWx3YXlzIHNlbmQgdGhlIFhSQXMgaW4gdGhl DQo+IHNhbWUgb3JkZXIgdGhhbiB0aGUgUkFGcyB3ZXJlIHNlbnQuICBTbyBpbiBjYXNlIHRoZSBz ZXJ2ZXIgc2VuZHMgYmFjayBieQ0KPiBtaXN0YWtlIHR3byBYUkFzLCB0aGUgZmlyc3Qgb25lIG1h dGNoZXMgdGhlIG9uZSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudC4NCj4gDQo+IFRoZSBidWxsZXQg bGlzdCBhdCB0aGUgZW5kIG5lZWRzIGFsc28gdG8gYmUgZml4ZWQgZm9yIGR1YWwgYWxsb2NhdGlv bi4NCg0KQWdyZWVkLCBmaXhlZC4gDQoNCj4gDQo+IC0gU2VjdGlvbiA2LjMNCj4gDQo+IEhlcmUn cyB0b28sIHRoZSB0ZXh0IG5lZWRzIHRvIGJlIHVwZGF0ZWQgZm9yIHRoZSBkdWFsIGFsbG9jYXRp b24gY2FzZS4NCg0KDQpZdXAsIHVwZGF0ZWQuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IA0K PiAtLQ0KPiBNYXJjIFBldGl0LUh1Z3VlbmluDQo+IEVtYWlsOiBtYXJjQHBldGl0LWh1Z3Vlbmlu Lm9yZw0KPiBCbG9nOiBodHRwczovL21hcmMucGV0aXQtaHVndWVuaW4ub3JnDQo+IFByb2ZpbGU6 IGh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9wZXRpdGh1Zw0KDQo= From nobody Sun Oct 22 09:08:28 2017 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 E3ED0139AA1 for ; Sun, 22 Oct 2017 09:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 KdRjiTV0OTjx for ; Sun, 22 Oct 2017 09:08:24 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5DF133049 for ; Sun, 22 Oct 2017 09:08:24 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:445e:763:74a4:83a9] (unknown [IPv6:2601:648:8301:730f:445e:763:74a4:83a9]) (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 48074AE799; Sun, 22 Oct 2017 18:08:22 +0200 (CEST) To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" References: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> From: Marc Petit-Huguenin Message-ID: Date: Sun, 22 Oct 2017 09:08:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8XkuvCIsk3T16gExbKu6PLBCCjlqlXnvT" Archived-At: Subject: Re: [tram] Review of dual allocation in TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 22 Oct 2017 16:08:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8XkuvCIsk3T16gExbKu6PLBCCjlqlXnvT Content-Type: multipart/mixed; boundary="JELKxaxRUTv4rk7l1IRLPrA716FMieMG2"; protected-headers="v1" From: Marc Petit-Huguenin To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" Message-ID: Subject: Re: [tram] Review of dual allocation in TURNbis-11 References: <65c75449-152c-1ce7-7c81-460ca589d9f0@acm.org> In-Reply-To: --JELKxaxRUTv4rk7l1IRLPrA716FMieMG2 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Inline. On 10/16/2017 07:14 PM, Konda, Tirumaleswar Reddy wrote: > Thanks Marc for the detailed review, Please see inline >=20 >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- >> Huguenin >> Sent: Saturday, October 14, 2017 12:59 AM >> To: tram@ietf.org >> Subject: [tram] Review of dual allocation in TURNbis-11 >> >> I should first apologize the the delay in reviewing this draft. I nev= er managed >> to get a sponsorship that spans the whole lifetime of a draft (or a Wo= rking >> Group for that matter), and that why it is so difficult for me to work= on IETF >> stuff in a sustained and consistent manner. >> >> Anyway, I was working on a review for turnbis-11 that was specifically= >> focusing on the synchronization with stunbis, but I kept be distracted= by >> issues related to the dual allocation feature. So I decided instead t= o send a >> separate email for that, to make things less confusing. >> >> My main comment about the dual allocation approach is about the choice= of >> adding a new attribute for that. STUN supports sending multiple attri= butes >> of the same type, and has a default processing rule for them ("Any att= ribute >> type MAY appear more than once in a STUN message. Unless specified >> otherwise, the order of appearance is significant: only the first occ= urrence >> needs to be processed by a receiver, and any duplicates MAY be ignored= by a >> receiver.") >> >> So a TURNbis client that wants to do a dual allocating adds two REQUES= TED- >> ADDRESS-FAMILY (RAF), one for IPv4 and one for IPv6. An RFC 5766 serv= er >> will just use the first one and ignore the second. The TURNbis client= receives >> only one XOR-RELAYED-ADDRESS (XRA), for the first RAF it sent. >> >> The client can choose the order, so it receives immediately a XRA from= the >> family it is most interested in, and can try a second allocation for t= he other if >> the server is implementing RFC 5766 >=20 >=20 > No, the above change contradicts the behavior defined in https://tools.= ietf.org/html/rfc6156#section-3=20 > >=20 > TURN servers allocate a single relayed transport address per > allocation request. Therefore, Allocate requests cannot carry more > than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client= > that wishes to allocate more than one relayed transport address at a= > TURN server (e.g., an IPv4 and an IPv6 address) needs to perform > several allocation requests (one allocation request per relayed > transport address). > >=20 > You may want to go through the long discussion in the WG to pick a new > attribute (ADDITIONAL-ADDRESS-FAMILY) for dual-stack allocation. I still think it is unnecessarily complicated, but all right. >=20 >> >> I think that this makes for simpler rules to implement and simpler tex= t. >> >> Now some more specific comments about the text: >> >> - Title and abstract >> >> The draft should obsolete both RFC 5766 and RFC 6156, and that fact sh= ould >> be repeated in the abstract. The authors of RFC 6156 should be >> acknowledged either in the Acknowledgment or Contributors section. >=20 > Done.=20 >=20 >> >> - Section 5. >> >> The first item in the bullet list should say "the relayed transport ad= dress or >> addresses;" >=20 > Updated line to say "All TURN operations revolve around allocations, an= d all TURN messages are associated with either a single or dual allocatio= n." >=20 >> >> In the the fourth item, there is one time-to-expiry per relayed transp= ort >> address. >> >> Same for the list of permissions in the fifth item. >> >> "Both the relayed transport address and the 5-tuple MUST be unique acr= oss >> all allocations, so either one can be used to uniquely identify the al= location." >> >> With the dual allocation, the 5-tuple no longer uniquely identify an a= llocation. >=20 > Yes, fixed.=20 >=20 >> >> - Section 6.2 >> >> I would suggest to make ADDRESS-ERROR-CODE more generic by renaming it= >> as WARNING-CODE and use the same format than for ERROR-CODE. Then >> allocate a new error code for that specific warning. I would suggest = to >> request the 0x8009 codepoint for that attribute. >=20 > I don't understand the need to change ADDRESS-ERROR-CODE ! To make it more generic and reusable in future specifications. >=20 >> >> Also I think we needs two different warnings, one that states that dua= l >> allocation is not available in a TURNbis server, but both protocols ar= e >> available, and another that says that dual allocation failed because o= ne of >> the two protocols is not available. This is to let the client know th= at it is >> useless to try another allocation for the missing protocol. >=20 > I don't get the reason for two different warnings.=20 A server may support both IPv6 and IPv4 allocations and not support dual = allocation, in which case the client can do a second allocation for the I= Pv6 relayed address. Alternatively the server may not support IPv6 at all, in which case the s= econd allocation will fail and was unnecessary. Using two different warnings permits to know if the second allocation wil= l succeed or not. >=20 >> >> What is the policy when reserving the next port with the EVEN-PORT >> attribute in a dual allocation, but one of them fails to find a pair o= f >> subsequent ports available? >=20 > It's discussed in section 6.1 >=20 > > Clients MUST NOT > include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request > that contains an EVEN-PORT attribute with the R bit set to 1. > >=20 >> >> It is not said that the Allocate successful response must contain two = XRAs >> after a successful dual allocation. >=20 > Good point, Updated draft.=20 >=20 >> >> I would also suggest to add some text that says that when a TURNbis se= rver >> sends an Allocate success response, it must always send the XRAs in th= e >> same order than the RAFs were sent. So in case the server sends back = by >> mistake two XRAs, the first one matches the one requested by the clien= t. >> >> The bullet list at the end needs also to be fixed for dual allocation.= >=20 > Agreed, fixed.=20 >=20 >> >> - Section 6.3 >> >> Here's too, the text needs to be updated for the dual allocation case.= >=20 >=20 > Yup, updated. >=20 > Cheers, > -Tiru >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --JELKxaxRUTv4rk7l1IRLPrA716FMieMG2-- --8XkuvCIsk3T16gExbKu6PLBCCjlqlXnvT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlnswnAACgkQKcRFldZq fsR1QhAA6QyQtwBrV+vN2dfOk78f9xh2huRo/HwwpaUw85QyAms6MnRmu/QjupSm V1LxqnNJOM8r/RCTIhCB0PRx0V11A4kCmjqBvaFglN35HJZzp/V+8WrIN7W45fEj mojduIm99kboFGJ2HNw0MSMkxf4OcxcpS2/87Ig45ykOWKIieBmLUomxSTTAytpP w8Q38Pgg84K90OylBelvk83zm57WhhWiicQjd4ajZSW684y8AO6YHgOjgBLbjEJ6 axpehVgLXK+t6sq8KZrrsmKZtxAw1R5hW6tkr/5biH5Nskt88zYlJCM+vSAvLtaX e2sm6pAAQCY3OqiTbPBeiFs4wpUrIPPOPrKyY58bA/rN6r8y8IiLnn6pzE3qOYTl /U3AGqcWpNI8BvhfP8+Als8FISPTc3Vy7nPvNTMb/DmBrRy4UY3Xb+8+Iz7bf4Qp ep/AK0yO463q+tZDuPjvNL2SiaZt4K4+Bmca1v0Qt5MBV9hDSD7/YPQ8A9Mho+oe 4bLcL+eLXEMzKwrXm3IRIZyho8K6GBhc/6EeN7LHVGSAjMYYYj0MEsASNP/U0Pyz H525gXqWSojnuDLjAtNaIXEm0HuDsECFN5Hh6YBU2kWbeSYPEle0DuTsGlQhrk/j 7jsRK3uAUa9gvDXcUQ1aMqANFV/7yaBSrSbHRKyaGeD5ha020kQ= =h5Uz -----END PGP SIGNATURE----- --8XkuvCIsk3T16gExbKu6PLBCCjlqlXnvT-- From nobody Sun Oct 22 09:45:53 2017 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 8E35A139E23 for ; Sun, 22 Oct 2017 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 UhmXc0P1tiIe for ; Sun, 22 Oct 2017 09:45:51 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C95139E1F for ; Sun, 22 Oct 2017 09:45:50 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:445e:763:74a4:83a9] (unknown [IPv6:2601:648:8301:730f:445e:763:74a4:83a9]) (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 AC93CAE799 for ; Sun, 22 Oct 2017 18:45:48 +0200 (CEST) To: "tram@ietf.org" From: Marc Petit-Huguenin Message-ID: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> Date: Sun, 22 Oct 2017 09:45:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S5Dp1KaAkOjfLKvSheTtbC90lNdDEH49e" Archived-At: Subject: [tram] Review of TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 22 Oct 2017 16:45:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S5Dp1KaAkOjfLKvSheTtbC90lNdDEH49e Content-Type: multipart/mixed; boundary="bFguwb30qrsft8vEqIK1GqgwOtvcEQOUe"; protected-headers="v1" From: Marc Petit-Huguenin To: "tram@ietf.org" Message-ID: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> Subject: Review of TURNbis-11 --bFguwb30qrsft8vEqIK1GqgwOtvcEQOUe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable This is the second part of my review of TURNbis-11, i.e. everything but t= he dual allocation part. - Section 2.1, last paragraph: May be a reference to RFC 5764 and RFC 7983 can be useful here. Same in = section 4, second paragraph and following. Same at the beginning of sect= ion 11. Again in section 11.6 (if multiplexed, the message in the reserv= ed range is not necessarily discarded). - Section 2.2, first paragraph: I think that an informative reference to RFC 7635 may be useful there, as= alternative to the STUN authentication mechanism. - Section 2.9: The whole 2.9 section and subsections looks normative and so should be mo= ved after section 3, perhaps on their own top level section. - Section 4, 4th paragraph: I would replace "For each allocation..." by "For each Allocate request...= ", because of the dual allocation feature. - Section 4, 12th paragraph: Should make clear clear that UDP covers also DTLS. - Section 6.1, 2nd paragraph: If the port is multiplexed with other protocols (RTP, WebRtc, etc..) then= it has to reuse an existing socket. The document should explain this. - Section 6.2, 3th paragraph: Is it time to recommend DTLS instead of UDP? In that case we need to mak= e DTLS mandatory in section 4 paragraph 11 (and I support that change). - Section 6.4, second bullet: Replace "...SRV procedures)." with "...DNS resolution procedures)." - Sections 14, 15 and 16: These are no longer new methods and attributes. See also the next commen= t. - Section 19: Here you need to update the existing methods, attributes and error code s= o the IANA registries point to the RFC-to-be, then you request allocation= for the new attributes. See section 17 of STUNbis on a way to do that (= that was done following a discussion with the IANA representative at an I= ETF meeting).=20 Note that ICMP should be comprehension-mandatory, not optional, as we do = not want an old client to reject a Data indication with an ICMP attribute= =2E Also, I do not know what this SendErr method is. Nits ---- Section 1:=20 s/connection to the Internet ./connection to the Internet./ Section 2.4, first paragraph: The text switches between the words "mechanisms" and "way". Choose one. Section 6.2, item 8: s/ADDITIONAL- ADDRESS-FAMILY/ADDITIONAL-ADDRESS-FAMILY/ Section 12.1, "Preferred Behavior" s/Label Field[RFC3697]/Label Field [RFC3697]/ Section 21: s/ADDRESS-ERRR-CODE/ADDRESS-ERR-CODE/ Section 22: s/orginal/original/ --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --bFguwb30qrsft8vEqIK1GqgwOtvcEQOUe-- --S5Dp1KaAkOjfLKvSheTtbC90lNdDEH49e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlnsyzoACgkQKcRFldZq fsS60RAAvOGxWZEfNr/pTuHGDom3hi/VwMZlxXB99Itcfv1tRaUbXlrQ4JlDcEK4 MAQComgb0FxUT4QSyhysbc5N3ZK9lpIVc6L/LTkWznS/6hAHOxniSlv5duD0BHvK QVS1Jw3qJnAap+I/8PTCewYWT8oRdnpz41dulZgD1mXQFwCpQ8f3Efdhzskl/+NV tLS78EA1oAJmtubKTQNZ4QO8Aph6ICYA1EpK1SbdMXPLh+8trbyvC8Y1fowhngvK 0v5p8GO+OFzleVBHQnoiDD9Arriyfpxih7gGK4aw52gEV273KxMi8JTF48Pb6vWt GmRO3QngQg5IiMzRIw90i9cL4x9rCcyybCjGYNyWaGVClFBMuqsftEsF52gUedIF aKz+e5qNn/3vACVq1oWvTM9dsebC0NPrn3v3rUTVINmwG/Kxn4D1lT9ZdcKIa/GO 6Jmrp4ahPxd8hGwdApnL/MHUWZztSDiK+4zDfuiRGt0hyxuEYhMiaFKdaAtk9FLf 55xOn/rT+SzzxSudsndt42OM1sVeU4NuK898oGchrI+ZTch5NdQGi2oJHTWuAR6m xDvbrZsSBAmdCiTcKotHASEzuFUWXGSoppjNA9c6GdGZQDqFVVxDPkPjK8I2jnzl rIzh9VJAUnpPaFtSgftZX8Ix7nLEq0kpa2+otZdBCg7aVaLPP3g= =5DtF -----END PGP SIGNATURE----- --S5Dp1KaAkOjfLKvSheTtbC90lNdDEH49e-- From nobody Sun Oct 22 09:48:23 2017 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 00894139E6B for ; Sun, 22 Oct 2017 09:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 ezV-X-v5xqOV for ; Sun, 22 Oct 2017 09:48:20 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B346139E6A for ; Sun, 22 Oct 2017 09:48:20 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:445e:763:74a4:83a9] (unknown [IPv6:2601:648:8301:730f:445e:763:74a4:83a9]) (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 D34A1AE799 for ; Sun, 22 Oct 2017 18:48:18 +0200 (CEST) From: Marc Petit-Huguenin To: "tram@ietf.org" References: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> Message-ID: Date: Sun, 22 Oct 2017 09:48:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6aoTmQ6QOG9A0sFDTc6qUk4TeJcOBWMoe" Archived-At: Subject: Re: [tram] Review of TURNbis-11 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 22 Oct 2017 16:48:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6aoTmQ6QOG9A0sFDTc6qUk4TeJcOBWMoe Content-Type: multipart/mixed; boundary="T27tWbSihOsw8vHDm1FOlBoCFaxu3fTwx"; protected-headers="v1" From: Marc Petit-Huguenin To: "tram@ietf.org" Message-ID: Subject: Re: [tram] Review of TURNbis-11 References: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> In-Reply-To: <325ddd79-ef98-c8ce-de50-1ef3878cd433@acm.org> --T27tWbSihOsw8vHDm1FOlBoCFaxu3fTwx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/22/2017 09:45 AM, Marc Petit-Huguenin wrote: > This is the second part of my review of TURNbis-11, i.e. everything but= the dual allocation part. >=20 > - Section 2.1, last paragraph: >=20 > May be a reference to RFC 5764 and RFC 7983 can be useful here. Same i= n section 4, second paragraph and following. Same at the beginning of se= ction 11. Again in section 11.6 (if multiplexed, the message in the rese= rved range is not necessarily discarded). >=20 > - Section 2.2, first paragraph: >=20 > I think that an informative reference to RFC 7635 may be useful there, = as alternative to the STUN authentication mechanism. >=20 > - Section 2.9: >=20 > The whole 2.9 section and subsections looks normative and so should be = moved after section 3, perhaps on their own top level section. >=20 > - Section 4, 4th paragraph: >=20 > I would replace "For each allocation..." by "For each Allocate request.= =2E.", because of the dual allocation feature. >=20 > - Section 4, 12th paragraph: >=20 > Should make clear clear that UDP covers also DTLS. >=20 > - Section 6.1, 2nd paragraph: >=20 > If the port is multiplexed with other protocols (RTP, WebRtc, etc..) th= en it has to reuse an existing socket. The document should explain this.= >=20 > - Section 6.2, 3th paragraph: >=20 > Is it time to recommend DTLS instead of UDP? In that case we need to m= ake DTLS mandatory in section 4 paragraph 11 (and I support that change).= >=20 > - Section 6.4, second bullet: >=20 > Replace "...SRV procedures)." with "...DNS resolution procedures)." >=20 > - Sections 14, 15 and 16: >=20 > These are no longer new methods and attributes. See also the next comm= ent. >=20 > - Section 19: >=20 > Here you need to update the existing methods, attributes and error code= so the IANA registries point to the RFC-to-be, then you request allocati= on for the new attributes. See section 17 of STUNbis on a way to do that= (that was done following a discussion with the IANA representative at an= IETF meeting).=20 >=20 > Note that ICMP should be comprehension-mandatory, not optional, as we d= o not want an old client to reject a Data indication with an ICMP attribu= te. Correction: we *do* want an old client to reject a Data indication with a= n ICMP attribute. >=20 > Also, I do not know what this SendErr method is. >=20 >=20 > Nits > ---- >=20 > Section 1:=20 >=20 > s/connection to the Internet ./connection to the Internet./ >=20 > Section 2.4, first paragraph: >=20 > The text switches between the words "mechanisms" and "way". Choose one= =2E >=20 > Section 6.2, item 8: >=20 > s/ADDITIONAL- ADDRESS-FAMILY/ADDITIONAL-ADDRESS-FAMILY/ >=20 > Section 12.1, "Preferred Behavior" >=20 > s/Label Field[RFC3697]/Label Field [RFC3697]/ >=20 > Section 21: >=20 > s/ADDRESS-ERRR-CODE/ADDRESS-ERR-CODE/ >=20 > Section 22: >=20 > s/orginal/original/ >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --T27tWbSihOsw8vHDm1FOlBoCFaxu3fTwx-- --6aoTmQ6QOG9A0sFDTc6qUk4TeJcOBWMoe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlnsy9EACgkQKcRFldZq fsSsmxAA32IElh8hX99mPZxD5+krYqZmX+pXWTmxwL/fFWzOiZfIYjG0yOWkdD4c MfwLOkI2lMaMeqDu8DalUTzGid7YllkDc6i0bwiBFX9yairphvu5IiAER6CZe1Pf uvGuT7OZMqrdf1sn43MhtZfetejE16IDa9dH2nUWmvqVGS920/eZ0vDJjUzZxLeK 6LJn7l+fpzliXVXFDoqXIUNK5oOJTo8M0/9TaWX4c1kKzZ4IES0EYd18LBcIPUlq E1ug8JSC84iU0LWWzO9S35doK+ilwTj7Vxc30SMm4lc6uX0jY602m8zbvGSCbNeX fRfUaib1NN3IKjrWAOL5gtNgS63XIGdnq2luj4Jb5Xht/ThvNMUN9VYG8xbGOoGt 0L3vFXgPorgsYjXQfNnt0p0x8cPtz20UPuaN44bmwvt/i+7YYMUaGvnfgGWydW9C 8rYJnbYIOU1hOnPwm3NEoyaMR+lJmgfD7D63YiNXU46LZr+Z8n1u9vVid7GtjZXh MpQy6x0vzei7J85JOuLOg/W4fhI/aPyHD8uoNOvQRvi5R7svq3DTpSpSaxIA+jCn PLohD12dSeCqriywwGx5j3+zN5oaFaZssuLdt3YYXpepue1xj0dt5o3j1xPuIouC XUd/sRDzEWiEZh4ZsJlOq/BHlqjMQMbGxYsIMx8gBKoISiQJcT8= =9hx2 -----END PGP SIGNATURE----- --6aoTmQ6QOG9A0sFDTc6qUk4TeJcOBWMoe-- From nobody Sun Oct 22 23:44:30 2017 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 54B9113E045; Sun, 22 Oct 2017 23:44:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150874106330.24567.10025213746592540332@ietfa.amsl.com> Date: Sun, 22 Oct 2017 23:44:23 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 06:44:23 -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 WG of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-12.txt Pages : 83 Date : 2017-10-22 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes [RFC5766] and [RFC6156]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-12 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 Sun Oct 22 23:48:36 2017 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 DB21C13E00F for ; Sun, 22 Oct 2017 23:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 dtLouIJAgeVT for ; Sun, 22 Oct 2017 23:48:33 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC39138349 for ; Sun, 22 Oct 2017 23:48:32 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1508741312; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=V 0fl2uamUaOxO5lvaKN6Z3EkAD3IMjs98Fco2XeRSP U=; b=CnO6D3KMr81wyScr82f6zawtKcxq+YKO8shx7yPxrQ8V ZdPiP0YA130K1de5DyLIR7pqTXxxVNYPj3vpil8JaVXW3BEZOC yaYmVur4oUZgFAP8HKbvHRaU/f2qDTgmmK1NlHHSV84NfdfF5a n9tqrqt4yroCMVXijFSckysc7Ac= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 263f_a179_2c176fd0_1d1d_4b3b_ad34_4b6cc5ba4106; Mon, 23 Oct 2017 01:48:31 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 23 Oct 2017 00:48:30 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 23 Oct 2017 00:48:30 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 23 Oct 2017 00:48:29 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 23 Oct 2017 00:48:29 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 06:48:28 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0156.007; Mon, 23 Oct 2017 06:48:28 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt Thread-Index: AQHTS8p5n4macCipKkK5ItbjZD/9kqLw/jXw Date: Mon, 23 Oct 2017 06:48:28 +0000 Message-ID: References: <150874106330.24567.10025213746592540332@ietfa.amsl.com> In-Reply-To: <150874106330.24567.10025213746592540332@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:hkHXk1+O/tucRj7pB3LvhakzrlsV57I8N+jOMxt0/Q6u10HTLdK5Rk0pb6j/g9bVwxBM2itO5OtIU+n4QuKs6Pj8t2fxVj5M608AZ+9NAmmKbCQcf35xHkW4zE+tpXPU69EuoD2NioSJ0sern0MbWQnKCs3xQqHKA8bErnZ8iVHF168pDGZflCLjd4ycJJiThd6rrZe4wLQ4ssTTkauBGUbsjeWmb7As63NQvAiMgegWWxW6T66BRdI/vH2Ft5sFc/x88RVkNnjmTas+OiVZfVmt6vVL1O3dOeiC3w4Cc1i5rJUBr58gEiXCw7zAF9CnFayuuUFc23fM40mv/7ToVA==; 5:pvJujifRVr93wjnVoAI560uPlDOvPp/eIxNJ+JDA8pLOC1q/01tIHf7ZbPuW/kPdW+uIBZrELA5s88CcaI8DbAD+U+58xwhsb6loPX4sIBlhuG7QqDugpZGwU/OuKbOyKQOLXb6bOXaqweZK2D0rJw==; 24:2o74k1UazNaLaiQBU7vT27YXgRtb3aamfxhS2E40L194/uAnqx9pVoNRLD19F16nFMkEuFB01tKfpET0w09qDGZMldu+aa86++QhM4FUQFk=; 7:TGEpxMCwhJPRSk1CrAJ1P4ThoZtcliU359/UAMzwKW8pnJX6x1kflWSc1CMMuG1BsZHaGoZVTZL42d6xn2LYwzYzbNRF32vebLeuf9voGhVnVp/AvxLwudiqRpk/JuOfFPZ1/nXcgYMWcjploUBn4oxjUtxP7BBoG8abhDyh1mCWMjVYHS9jRzN5X56vtvnmGLmCgyI1ikugHA9i/c6JZD9ZxUp/O5Cy5NvNT+77PRM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d9c8b917-0a2d-4797-2950-08d519e21162 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(32952001)(377424004)(13464003)(189002)(199003)(72206003)(86362001)(2501003)(305945005)(74316002)(7736002)(966005)(7696004)(2950100002)(6916009)(5660300001)(316002)(50986999)(230783001)(54356999)(76176999)(101416001)(66066001)(33656002)(53546010)(14454004)(102836003)(6116002)(2900100001)(3846002)(81166006)(81156014)(1730700003)(68736007)(8676002)(8936002)(2351001)(4001150100001)(80792005)(105586002)(106356001)(99286003)(55016002)(2906002)(53936002)(25786009)(189998001)(6306002)(3280700002)(97736004)(5640700003)(229853002)(6506006)(9686003)(6246003)(3660700001)(77096006)(6436002)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d9c8b917-0a2d-4797-2950-08d519e21162 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 06:48:28.4899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6141> : inlines <6136> : streams <1768160> : uri <2520955> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 23 Oct 2017 06:48:35 -0000 This revision addresses comments from Brandon and dual allocation related c= omments from Mark. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, October 23, 2017 12:14 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.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 WG of the > IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay= Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-12.txt > Pages : 83 > Date : 2017-10-22 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 > This document obsoletes [RFC5766] and [RFC6156]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-12 >=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