From nobody Wed Aug 3 11:17:12 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DB212D678 for ; Wed, 3 Aug 2016 11:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMYj4rRZM94h for ; Wed, 3 Aug 2016 11:17:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC912D0B4 for ; Wed, 3 Aug 2016 11:17:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 56CB643343F for ; Wed, 3 Aug 2016 18:17:07 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 39C41433410 for ; Wed, 3 Aug 2016 18:17:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470248227; bh=qnmfFV00fSO0DxovOxZyz0vbsFE4VM7gRpwT5GGOkno=; l=6542; h=To:References:From:Date:In-Reply-To:From; b=NT63NSuLfIoV7sm3oj843MLjD711rT4CKbUlqOUDrI7n+Zn4pE4XEzBgasTX7nwEW Ugnv8wf/IPbLocLEMqnJ9HArWSmdk0ygdZEROIdwaO3wkGcjVdgPtBb9/nBDeUZn6X Fl/0fQFKrGBhU+5W58XR+9OasxvDAs69vFZMjN94= Received: from [172.28.118.79] (bowill.kendall.corp.akamai.com [172.28.118.79]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EC4F11FC8B for ; Wed, 3 Aug 2016 18:17:06 +0000 (GMT) To: tram@ietf.org References: From: Brandon Williams Message-ID: <57A23522.1020801@akamai.com> Date: Wed, 3 Aug 2016 14:17:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] TURN server auto-discovery X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 18:17:11 -0000 Hi Olle, Regarding your comment about section 9: > Section 9: > - “Use of STUN authentication is OPTIONAL for TURN servers provided by > the local network or by the access network. A network provided TURN > server MAY be configured to accept Allocation requests without STUN > authentication, and a TURN client MAY be configured to accept > Allocation success responses without STUN authentication from a > network provided TURN server. “ > Is this text normative? If so it’s clearly out of scope for a draft on auto-discovery. > You also need to add text on DNSsec here. > > A lot of this text is good, but I have issues with it being in this draft. Does > this text normatively update another document? It covers how to set up > connections more than how to discover services. Maybe how to trust > the TURN server should be another draft or, if it needs to be in this draft, > should be made in a separate section. If that is the case, the abstract > and introduction section needs to be modified to cover this scope too. As I understand it, this text is meant to be normative, though perhaps just the first sentence. The existing TURN specification requires STUN authentication for TURN. For TURN servers provided by the local or access network, there is a presumption that network has other methods for restricting access and that STUN authentication is not required. Thus this draft intends to make STUN authentication OPTIONAL, but only when the relay is provided by either the local or the access network. The additional sentence is meant, I think, to describe what this means in practice: both the client and the server can be configured to allow unauthenticated TURN messages, and they must both be configured to allow this in order for it to work. As I write this explanation, I realize that the current text doesn't state the motivation. This should be added, I think. Also, maybe the second sentence isn't adequate clarification. Maybe we need something like: The server accepts the unauthenticated Allocate if configured appropriately. The client accepts the unauthenticated Allocate response if configured appropriately, and it now can send unauthenticated TURN messages on the channel. If the client receives an unauthenticated Allocate response but is not configured to accept them, then it ignores the message. Maybe there is a need to provide a fallback mechanism in the case that the client requires auth and the server doesn't. --Brandon On 07/27/2016 04:15 AM, Olle E. Johansson wrote: > Sorry for being late into reviewing this document. If I am too late, my apologies, > but nevertheless here’s a few nits and comments: > > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-08 > > Section 1: > - “Web Real-Time Communication (WebRTC) > [I-D.ietf-rtcweb-overview] usages and related extensions, which are > mostly based on web applications, need this immediately.” > When I read this in ten years time, it is no longer immediately. Please rephrase. > > - “This document describes three discovery mechanisms, so as to maximize > opportunity for discovery, based on the network in which the TURN > client finds itself. “ > A very complicated sentence. Can it be simplified to make reading easier? > > - “For example, in case of Web Real-Time Communication > (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, > which are based on web applications, a Java Script specified TURN > server MUST be considered as local configuration. “ > I think “local” is a bad choice here - maybe “application-provided configuration” > could be an improvement? > > - “A client can choose auto-discovery in the absence of local > configuration, if local configuration doesn't work or on top of local > configuration. “ > I think local security policy may affect choice and maybe also need to override > “local configuration” > > - “An implementation > MAY give the user an opportunity (e.g., by means of configuration > file options or menu items) to specify a TURN server for each address > family.” > How do you define the implementation? The browser, the javascript application > or another TURN user, like a SIP phone? In the case of WebRTC you need > to clarify your terminology - there’s one application running in javascript and > then you have the browser. Also remember that TURN is not only about > browsers :-) > > - “A TURN client that implements the auto discovery algorithm, to > discover TURN servers in the attached network, uses the following > mechanisms for discovery:” > Change the list that follows to use bullets, as you later write that you do not > prescribe a strict order. > > Section 4.1: > This section is a bit open. If I want to write a SIP specific document > specifying a way to use the outbound proxy URI or a service route URI > to use for TURN service discovery - will that be a standalone document > or an update to this document. Maybe some requirements on other > ways to select a domain name would be appropriate. > > Section 4.1.2: > - “JID : 'alice@example.com’” > You have a SIP URI and a bare JID. Maybe consider making it an XMPP URI > by prefixing the JID with “XMPP:” for clarity. > > Section 5: > - “For example, TURN server advertises the following DNS records :” > s/TURN/a TURN/ > > Section 9: > - “Use of STUN authentication is OPTIONAL for TURN servers provided by > the local network or by the access network. A network provided TURN > server MAY be configured to accept Allocation requests without STUN > authentication, and a TURN client MAY be configured to accept > Allocation success responses without STUN authentication from a > network provided TURN server. “ > Is this text normative? If so it’s clearly out of scope for a draft on auto-discovery. > You also need to add text on DNSsec here. > > A lot of this text is good, but I have issues with it being in this draft. Does > this text normatively update another document? It covers how to set up > connections more than how to discover services. Maybe how to trust > the TURN server should be another draft or, if it needs to be in this draft, > should be made in a separate section. If that is the case, the abstract > and introduction section needs to be modified to cover this scope too. > > > /O > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Sat Aug 6 20:29:15 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96612D093 for ; Sat, 6 Aug 2016 20:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ihyewqnCKRD for ; Sat, 6 Aug 2016 20:29:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEA112B024 for ; Sat, 6 Aug 2016 20:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13930; q=dns/txt; s=iport; t=1470540552; x=1471750152; h=from:to:subject:date:message-id:mime-version; bh=3MFfQUE9wctPKrFxqtP8aZNn3xyPnzOTCYekzNns2Xw=; b=ZiK4kj91pAMMK11kCUayaDoX11tTChYl74adNblrc7cFmfpodgSbzyZV 5FlFP0JlZdgURvKrFajkszFlQZ3ZR8+Rm7dSQw8Jqw7V3rAQ6xKyN7eeK WbgQ8KV7aRF6EsdG02epVmEteLJM4cz+0vhX7kwBnL8PJ+n4OsOoTDZDL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAgDoqaZX/4cNJK1dgndOVnwHtACFB?= =?us-ascii?q?4F9JIchOBQBAQEBAQEBXRwLhGUtXgGBACYBBBuIKQ6hUJ9tAQEBAQEBBAEBAQE?= =?us-ascii?q?BAQEbBYYqhE2EKoVxBZN1hUQBgTWEZ4J8hWqPSpArAR42g3puAQEBhjB/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,481,1464652800"; d="scan'208,217";a="137115512" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2016 03:29:11 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u773TBjj032369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 7 Aug 2016 03:29:11 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 6 Aug 2016 22:29:10 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Sat, 6 Aug 2016 22:29:10 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: Review of draft-ietf-tram-stun-pmtud-02 Thread-Index: AdHwWlrSIFhNo2FmSx+I6/nnmmONpQ== Date: Sun, 7 Aug 2016 03:29:10 +0000 Message-ID: <251036f13c0f4415b06c31c5de39a9d3@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.58.230] Content-Type: multipart/alternative; boundary="_000_251036f13c0f4415b06c31c5de39a9d3XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [tram] Review of draft-ietf-tram-stun-pmtud-02 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 03:29:14 -0000 --_000_251036f13c0f4415b06c31c5de39a9d3XCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments 1) A TURN client supporting this STUN usage will add a PMTUD-SUPPORTED attribute to the Allocate Request sent to the TURN server. The TURN server can immediately start to send probes to the TURN client on reception of an Allocation Request with a PMTUD-SUPPORTED attribute. The TURN client will then use the Implicit Mechanism described above to send probes. Comment> The above mechanism can be used by attacks to launch amplification= attack (just like in DNS-over-UDP). 2) An ICE [RFC5245] client supporting this STUN usage will add a PMTUD- SUPPORTED attribute to the Binding Request sent during a connectivity check. The ICE server can immediately start to send probes to the ICE client on reception of a Binding Request with a PMTUD-SUPPORTED attributed. Local candidates receiving Binding Request with the PMTUD-SUPPORTED flag must not start PMTUD with the remote candidate if already done so. The ICE client will then use the Implicit Mechanism described above to send probes. Comments> a) What is the need to immediately send probes ? b) Why not wait until the ICE nomination is complete or until the pair stat= e is changed to Succeeded ? c) SCTP also has probing discussed in https://tools.ietf.org/html/rfc4821#s= ection-10.2, why can't it be used (if media/data channel are multiplexed on the same port) ? d) If DTLS is used, path discovery can happen after DTLS handshake is compl= ete (see https://tools.ietf.org/html/rfc6347#section-4.1.1.1) 3) A client MUST NOT send a probe if it does not have knowledge that the server supports this specification. This is done by an external mechanism specific to each UDP protocol. Section 6 describes some of this mechanisms. Comments> What if man-in-middle attacker changes the request to add PMTUD-S= UPPORTED ? 4) There are two mechanisms for probing, why can't we have just one ? Should both probing mechanisms be implemented ? I think a guidance/recommendation section will help select the appropr= iate probing mechanism. 5) Same comment as above for packet identifier mechanisms. 6) What if the attacker changes the report response from the server ? (I think you should mandate authentication/DTLS). 7) The client SHOULD stop retransmitting after 3 missing responses. comments> a)Why 3 when STUN uses by 7 by default ? b)I don't see any discussion on pacing b/w retransmissions. 8) Security considerations needs to discuss threats in the above comments. 9) Section 5.5, Using Checksum as Packet Identifiers When using checksum as packet identifiers, the client calculate the checksum for each packet sent over UDP and keep this checksum in an ordered list. The server does the same thing and send back this list in the Report Response. Comment> a) what if the packets arrive out-of-order at the server ? b) what is the format of the report response ? c) What is the format of the new attributes defined in this document = ? -Tiru --_000_251036f13c0f4415b06c31c5de39a9d3XCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments

 

1)

 

   A TURN client supporting this STUN usag= e will add a PMTUD-SUPPORTED

   attribute to the Allocate Request sent = to the TURN server.  The TURN

   server can immediately start to send pr= obes to the TURN client on

   reception of an Allocation Request with= a PMTUD-SUPPORTED attribute.

   The TURN client will then use the Impli= cit Mechanism described above

   to send probes.

 

Comment> The above mechanism can be used by attac= ks to launch amplification attack (just like in DNS-over-UDP).

       

2)

 

   An ICE [RFC5245] client supporting this= STUN usage will add a PMTUD-

   SUPPORTED attribute to the Binding Requ= est sent during a connectivity

   check.  The ICE server can immedia= tely start to send probes to the

   ICE client on reception of a Binding Re= quest with a PMTUD-SUPPORTED

   attributed.  Local candidates rece= iving Binding Request with the

   PMTUD-SUPPORTED flag must not start PMT= UD with the remote candidate

   if already done so.  The ICE clien= t will then use the Implicit

   Mechanism described above to send probe= s.

 

Comments>

a) What is the need to immediately send probes ?

b) Why not wait until the ICE nomination is complete= or until the pair state is changed to Succeeded ?

c) SCTP also has probing discussed in https://tools.= ietf.org/html/rfc4821#section-10.2, why can't it be used

   (if media/data channel are multipl= exed on the same port) ?

d) If DTLS is used, path discovery can happen after = DTLS handshake is complete

   (see https://tools.ietf.org/html/r= fc6347#section-4.1.1.1)

 

3)

 

   A client MUST NOT send a probe if it do= es not have knowledge that the

   server supports this specification.&nbs= p; This is done by an external

   mechanism specific to each UDP protocol= .  Section 6 describes some of

   this mechanisms.

 

Comments> What if man-in-middle attacker changes = the request to add PMTUD-SUPPORTED ?

 

4) There are two mechanisms for probing, why can't w= e have just one ?

     Should both probing mechani= sms be implemented ?

     I think a guidance/rec= ommendation section will help select the appropriate probing mechanism.

 

5) Same comment as above for packet identifier mecha= nisms.

 

6) What if the attacker changes the report response = from the server ?

    (I think you should mandate authe= ntication/DTLS).

 

7) The client SHOULD stop retransmitting after 3 mis= sing responses.

 

comments>

a)Why 3 when STUN uses by 7 by default ?<= /p>

b)I don't see any discussion on pacing b/w retransmi= ssions.

 

8) Security considerations needs to discuss threats = in the above comments.

 

9) Section 5.5, Using Checksum as Packet Identifiers=

 

When using checksum as packet identifiers, the clien= t calculate the

checksum for each packet sent over UDP and keep this= checksum in an

ordered list.  The server does the same thing a= nd send back this list

in the Report Response.

 

Comment>

a)     &= nbsp; what if the packets arrive out-of-order at the serv= er ?

b)      what is the format of the report response ?

c)     &= nbsp; What is the format of the new attributes defined in= this document ?

 

-Tiru

--_000_251036f13c0f4415b06c31c5de39a9d3XCHRCD017ciscocom_-- From nobody Sun Aug 7 21:55:13 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BD412D0DE for ; Sun, 7 Aug 2016 21:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uo_U9QAqxKw for ; Sun, 7 Aug 2016 21:55:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556D0126579 for ; Sun, 7 Aug 2016 21:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2271; q=dns/txt; s=iport; t=1470632110; x=1471841710; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=joqNskuBIhjhqtpgJVuO7f2B0gaigDFk8wmPFH9+DdE=; b=SvwStFtq9UooZAuGBKT0652RI0T9rKEJyaIc8dmMgRglYpwd9SEnAdk4 4lMlC8ic2AX86CMTIrj94l1S9NpATl86vvS0d3J4xD7SOkyqAvjMc/K6H BKXjFjySW1G4zkCECS7XIlQ1xp/iVNfVpW3C0NN5oAg08P9M3fbt5JhMm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAgADEKhX/5FdJa1dg0VWgQO5CIF9I?= =?us-ascii?q?IcqOBQBAQEBAQEBXRwLhGU6UQE+QicEiEQOolWfZgEBAQEGAQEBAQEdBYp3hCq?= =?us-ascii?q?FcQWZOQGBNYRniG2PQ5ArAR42g3qHLn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,488,1464652800"; d="scan'208";a="133372400" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2016 04:55:09 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u784t9xp024750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Aug 2016 04:55:09 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 Aug 2016 00:55:08 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Mon, 8 Aug 2016 00:55:08 -0400 From: "Ram Mohan R (rmohanr)" To: "tram@ietf.org" Thread-Topic: Review of draft-ietf-tram-stun-pmtud-02 Thread-Index: AQHR8TEJicyHZyz5hEufl8b60PYF2w== Date: Mon, 8 Aug 2016 04:55:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.41.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <84E2BFEB2D43474C8BFD2AFF12296979@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tram] Review of draft-ietf-tram-stun-pmtud-02 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 04:55:12 -0000 Here is my review of draft-ietf-tram-stun-pmtud draft. Comments: 1)What is behavior of middle boxes like B2BUAs (that may be media aware relay or simple media relay as described in section 4 of https://tools.ietf.org/html/rfc7584) when handling pathMTUD STUN messages ? 2) I also agree to some of the security concerns raised by Tiru in the list. Especially on how we can avoid/detect when some one is using the mechanism described in this draft for mechanism to launch amplification attack or man-in-the-middle attacks. 3)Section 4,5 says server MUST NOT authenticate/challenge client. Why is authentication not recommended here ? If path MTUD is being used between ICE peers, or a STUN client/Server they are likely to have shared secret already (short-term or long-term credentials). Should we not use the existing STUN authentication procedures here as well ? 4) Section 6 talks about different mechanisms for indicating support for supporting the pmtud described in this document by means of having PMTUD-SUPPORTED attribute in STUN/TURN messages. How does the server/client know it is using simple or complete probe mechanisms ? Is it only by looking at the sequence of messages ? 5)Would pmtud probes be done only once when the 5-tuple for sending data is setup (as part of ICE checks, TURN) ? Or would the probes done periodically during a session ? If done periodically it would be good to add how this would interact with Consent freshness STUN messages. Minor comments: 1) Would be good to refer the RFC (rfc5780) that defines the STUN PADDING attribute as you are using that in this document 2)Section 6.2 should be applicable for any STUN client (not for only TURN client) interacting with STUN server. In case of TURN client/server it will be indicated in ALLOCATE request as mentioned in draft. In case of STUN client/Server it will be BindRequest from client to Server. 3)Would be good to have ladder diagrams showing the message flows for both simple and complete probing mechanisms. 4)Why is IDENTIFIERS STUN attribute made as comprehensive-required stun attribute ? That would require all STUN agents to process that attribute and cannot safely ignore if it does not understand. Regards, Ram From nobody Mon Aug 8 04:17:24 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0BC12D806 for ; Mon, 8 Aug 2016 04:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ingate.onmicrosoft.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 XKOGro9b3XGJ for ; Mon, 8 Aug 2016 04:17:19 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50085.outbound.protection.outlook.com [40.107.5.85]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830AB12D79E for ; Mon, 8 Aug 2016 04:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingate.onmicrosoft.com; s=selector1-ingate-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PcONJ1nKPmXtxmli8QeLw+EGCaNwh9CSpamuGmEUOK8=; b=AKLHsx7Z4p9h+Udu3Dy33zJ6vK4K0I+jkn+UMEfezztF2+D+X7RT5yoFTx90iF8OrSrjOo0hcdkTIDaSQ86d+GqbNY/v18TNo5OL+QlcTsLvDrAgaOHDmn/6Ag1KF2DgugdNbywuSL1BNJLECi2iWmvbbo4mwtAPTHLy7SvdqcU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=karl@ingate.com; Received: from Kallei7 (90.227.80.227) by HE1PR01MB1834.eurprd01.prod.exchangelabs.com (10.165.228.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 11:16:55 +0000 From: Karl Stahl To: Date: Mon, 8 Aug 2016 13:16:52 +0200 Message-ID: <003a01d1f166$5fde7df0$1f9b79d0$@stahl@ingate.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01D1F177.23674DF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHRYmh2YFzwmP/IiU6G35xxS4HZOJ8itgmAgAAGa4D//6AewIAB7wkQgRrnwYCAANPk4A== Content-Language: sv X-Originating-IP: [90.227.80.227] X-ClientProxiedBy: AMSPR02CA0049.eurprd02.prod.outlook.com (10.242.225.177) To HE1PR01MB1834.eurprd01.prod.exchangelabs.com (10.165.228.24) X-MS-Office365-Filtering-Correlation-Id: 1a0142fb-768c-4b13-6066-08d3bf7d81f0 X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 2:/i5jMlV8z6MAibu+E6A5KeycRgIpvZg5dkya4ii3HhWiyr2kX3mgR2LphXESOYnsvpujBzxs1hW2uyxSDaBx0PTAI3GzgFnWcbGwE3ZD5aWp+CV5NWcDsRP10SiwMgdr6wfio3ZM+9vqNLLT6pGrxQIYtVsHtsP47XaSSwzcnTfG/UT7B/9hKEfgZfUJ/Ek3; 3:1vp0aDPpWZcVJS0qWVAa1No3hod4JKR2o4Mdhe+n85QUFKtEBbSzXQPKuXx4DQISzkwPYz6Y9abhcX5LpFCg/dyCW02I7JmlCZzuzFA0fax8U2GEWm70MTxtsmCg6SLi; 25:pfRC7TaViknQT+u/exPWdX9u2fWEvv3amHNovuLqDFd1cUs/7uF5otkDpY5l1bqFlv9a4iPlCvCJicAEqbSH9YSctSktQdcxH0aR7ZCtV2UdwJN8fb6uCParkbYWpmCAkSwp4rtg5/1PPNkGOFF4QlC4EzT9TbIHhrDbwtih9b09zs7NT5h2T8v+t5T24mCjaFicUpsLO2+RFCxVbYHMCpxa/Gbe5zNofXxuzvRcuWpwSkrYEIGjjU7oWIZ5IAjJnxg80Oww5+iT1kUkIuXGJjKuocTpo+nv/hhTKeMgkWvyTzKi1IpwcDxU8G6ZFR/PnzWDPlelSzYPdXisP7llpG0VvhsRZIzzqdgBg+6JfmMUNJs7u5hnTn059pP4SATRERfDUb9zS9JC4dRAJDVX2zKPFf87Ozlr2vBfWa18oBU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR01MB1834; X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 31:FdcflaxYfMx+TNXgwe9SdFoF5YXp76+KieSfYIsCUfU8dWTmjFwlNtZ1amtdpcKQ0409Q4tnx+U0sC3ekfuGnRLBaD6kaOLlJZPkDePBDQBpBqWvZnrWfAvqJHy6jgsrvlqK0eg+0jVE+ilvGr5W/uVNXxLsmJWv3r6LW1Vnlx58m2cEz9X03V7RaRB0K2g494MPT0tnX14liKzWrBZxSih6+BXiF213izRDogATHm0=; 4:o8E8uon8qrChPsZIcsUbm70jz7K5YgCyYUByAT906CRNMwO8909o6te/uE5006WthffN1jQhBzKnP3oOov8Zy2TUIf/e0zDd/COzOr7wewh2qgbOZ4HLqYgzwFCaVzWhRC5ru3cTC6+G8SvC7Reqme4ty54zbUJ6pwgMU/cik4x8pAB3vvN0ywlc69E0zxxI/Ou2aFW3YH2M9GWS6MSg4OiaTHzCdnBxKBh5JSUymzvrT/zk/Yvhyfp0n/gX0G1JOe84caCcwOncj7++YF3i8vLTxz53d65rpra9YXJ5d55pG4xBCjRP7VqVzXeBsQnRaykAJG3P+eGTexNYKnSmMZX4mYQYQ5dIJTSnbpkVPHUQTUSeV8DmoWJW5aZaaBOg8RzKLU0S9EDF8PkaHIMPFYpk3knmzjRCeochIJRKZapgd2JgVoL32Adu178XofWI1RQXeD+927obviUwzJBuFHp5cDUGe3mFw0egl5+sz2mGPGvtW/YdWdj4ZUSXu15NR1DJWRaKkvKGYUK+E5RSI4sdoX4U5aG75QH1CcKzwsWwePMRV0tIq+rV/JK+yt5X+Se0PcyO9rqW9O1vT8PJT0bj3/8J+gImO3SN0/l0b2M= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(278428928389397)(192374486261705)(176510541525296)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:HE1PR01MB1834; BCL:0; PCL:0; RULEID:; SRVR:HE1PR01MB1834; X-Forefront-PRVS: 00286C0CA6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7916002)(199003)(189002)(66066001)(84326002)(71636004)(92566002)(586003)(6116002)(790700001)(102836003)(101416001)(3846002)(68736007)(1420700001)(105586002)(77096005)(7846002)(19300405004)(230783001)(50986999)(7826002)(7736002)(9686002)(14726001)(15975445007)(16236675004)(107886002)(110136002)(18717965001)(19580405001)(19580395003)(36756003)(97736004)(2351001)(61296003)(96836002)(33646002)(8676002)(81156014)(450100001)(81166006)(189998001)(106356001)(2906002)(84116002)(19625215002)(50226002)(42186005)(512874002)(106116001)(229853001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR01MB1834; H:Kallei7; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ingate.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR01MB1834; 23:5iD5QxxgVHdg6Uwj9ZQBxUlVOBVPRkN13Og75ZB+i?= =?us-ascii?Q?Ix/M81bPYi1kbFgj/xJjsBwky2ZLgJeWsblZlppuUzKydB4kwp6nNHzm3l1m?= =?us-ascii?Q?nQo+TO5en8AIuY/R1BqVRLqKu3ts5KYcbmkdccbL3D0iQlrkL+PJ1qIR4T/a?= =?us-ascii?Q?bpO0mX0kfMKMpBMn5+m6LRGnuf6IG4cKNAO6i4rEQXXWMLL0XkhqAPj6l9FM?= =?us-ascii?Q?Cgt/4O5fby0j8aEpV9VZOoy4HaQ4VgAsO6QeEaXb1E0U82BreUop5c/Nyb44?= =?us-ascii?Q?OOLDumPuMBJFXJfhsVyQEPZ5nu4J6bWS/af3wR6tnSa8o4F/VNIMlVZywHhG?= =?us-ascii?Q?O2bFBQgsOSsgj8LU20QGlVHOFTrn78ZCT9Cggfr+PfT2NawKxbG2+4QsY5BU?= =?us-ascii?Q?hUvG6eviah62iwApzkfNm3wMJGiFlFJKP0HmcMQVtQoS+XIUeCoDupeRfc98?= =?us-ascii?Q?TzxNg9Eu6yCuX4QuKTbE+WSM2f6moHfkBdaXHfSmewOeBLMacFepTfgVOOof?= =?us-ascii?Q?YQv6HUM7W8VF6UqEcmFUVAkQwAdoKdVPyrFA0Sj6xhPtJSbC/QdZJkapJfHe?= =?us-ascii?Q?vyWAS010BzjVtvmQYbBP+XSgAuj2ANgIPV24uUnZNVTUHZnqiHjRQC/w8SZw?= =?us-ascii?Q?TtdOuz0TFpOTV7AWf3fOsdHCoMLmEFNGucT5PxDOR/CZ10d1Rw/ooUtdIEYh?= =?us-ascii?Q?TTZR6l2ZGQcyrh7m/vChMgfF+jPu2QJ5/inndyoJBnLLJV9UuGDuYQmpWQ7Q?= =?us-ascii?Q?D4C6c6ifbw30HQ5xKbx57/zDaM9RsGj3Krvum7MiX/Gx3yxoaebZlU2sGHG4?= =?us-ascii?Q?8X425TDoQYvc5YIKspCRV1fniEKAekZq2ZpBo6syZODXuhu0Kipp1k+zxBcU?= =?us-ascii?Q?/ZYh+jOJ3uSsVyup/5t+VaONaScc8t01T2w8D3BA7h7uUNUJ+zx5gMqDFWu2?= =?us-ascii?Q?RKYwLXGWeKlDPq+vey3QonSVbUA6HsL0zHbsjxx0Wc9ngOiBnRA6QWZqBWmn?= =?us-ascii?Q?X+LbqGYTY9p9uUtrQQY7Sf51vmfrBretgc5DYqcrW5WYJhXPa+8WvZGClSAw?= =?us-ascii?Q?S6TspXz/Nfkl0GMMa5xK7aOA6ew4vmpkhmupIH8DwH0LVbR9B467hUt+pTEy?= =?us-ascii?Q?i+ZJJdlMLwRVLBy39J3aYqK65+MuFugoyr1z2eqEqYAguy2VNFdpAfEfOwws?= =?us-ascii?Q?fvJOofM1VF9agT2UWHDa4zT7kqv0iovz4iIQtb0Z4r0smh8KnKIBjen45zdm?= =?us-ascii?Q?ZA70QwSNv0z1Bs5SjBM6m3J0JDPqjzhq1x3bYrMoxYQGYbISMml5QAu2LNg9?= =?us-ascii?Q?gzHFhwYbUW4uBuYHOtSdmYUSzSxvMK7b4Czqyc0zCJL?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR01MB1834; 6:pJ/j2bqWjIcfiDoMHVf1dZawgqSFeWqfDDUtOiXnaC3p1zMqgUl3m+Y0S0Ok0H2ZiFKk+rTauRCCDVq/7P6uBK8Y7RByUid80OZ9BKfccdFco2uNnGhaHJOyCfW9ScjLRwyHcsALyE1J7mXiTWrA9TdJ/OFks/99/n5mf4coHp4Ur4VZDVbAaCJ/XPy1FSb0OR4bgn/8MORG9cmRIJKGPuQFTtS9vJ/pgkz3Q5KxINIDbfVs6GM70vmCLvXWiwQrSuzYPRwx+w06kxjXA8HSvUfuFAF5X0F8fH7XHJS1IEMB6HXCxq+UiZJhBmmkzuPd; 5:giSKk097FFzu2VaMAHUmo8RqyJ0M7s3pNGemKjI0ivCECmPIp7oaeU0OgzKVdfln93dmLaOIcdscIF/HvxKXeBO4z4fivXxuBsA2EkdflzkI+aBvSg9vYCCdyuN2nQLc18KrX0f7c6EAfvkU5Y3LVw==; 24:Ya4+8M1V360sE2RnPN2FeXW+y/1lSE/VOxZSTqMsWiQcu6iXPEagr/tyCo6vuav+BaWGNW7LWVMGvl7P3ZXIRMVlSAeawyfPhTMDk80c2GI=; 7:08V37iew2+MDmuf/uBuubD0jiAN8nmL0sf3GUIgCIu4XcXUYPgP6uuO6vF/VrSH80n0CAh8hPra+R0aHCtVLrEAypmRLyaPt9KTQ3A30r/hK+NDU+i4u6HzkZiaK/K5k8xUae+WUgzf7g0H8tc8fE59p/ULPHZ3d7V5SJIgL0pa2sfAYclvX2ON0MZKTV4sdsVyywwxFgOv2REfn3lizuXJK3cBoyucMXYJfXVZZaglkJ86NUaonrY2DarwMzg/u SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ingate.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2016 11:16:55.8290 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR01MB1834 Archived-At: Subject: [tram] Last Call: ; Anycast X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 11:17:22 -0000 ------=_NextPart_000_003B_01D1F177.23674DF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Reading this latest version, under: =20 3. Discovery Procedure I stumble on: =E2=80=9C=E2=80=A6 not all TURN servers may support = anycast.=E2=80=9D =20 This draft is somewhat unclear when talking about discovery and usage, = but since=20 no one suggests that TURN should be used with anycast addressing, this = statement=20 must indicate that the authors have noticed the proposed anycast = discovery method=20 doesn=E2=80=99t work with RFC5766 TURN servers. That has to change. =20 The current draft says: =E2=80=9C 6. Discovery using Anycast =E2=80=A6 When a client requires TURN services, it sends a TURN allocate request to the assigned anycast address. The TURN anycast server responds with a 300 (Try Alternate) error as described in [RFC5766]; The response contains the TURN unicast address in the ALTERNATE- SERVER attribute. For subsequent communication with the TURN server, the client uses the responding server's unicast address.=E2=80=9D =20 An RFC5766 TURN server doesn=E2=80=99t answer one thing (300 Try = Alternate) when addresses=20 by an anycast address and another thing when addresses with its unicast = address=20 (even if such TURN servers could be developed and possibly = standardized=E2=80=A6).=20 =20 Considering that a TURN server also includes a STUN server (when using = the binding request)=20 and that the STUN server also can respond with 300 Try alternate,=20 I suggest the following modified method: =E2=80=9CWhen a client requires TURN services, it sends a STUN binding=20 request to the assigned anycast address. The STUN server=20 responds with a 300 (Try Alternate) error as described in [RFC5389]; =20 The response contains a unicast address in the ALTERNATE- SERVER attribute, which the client compares with the source=20 address of the response and if the addresses are the same,=20 it is an indication to use the TURN server at that address.=20 For subsequent communication with the TURN server, the client=20 uses that responding server's unicast address.=E2=80=9D =20 Or simply, a STUN server pointing out it=E2=80=99s own IP address as the = alternate server,=20 means that it is a network provided TURN server that should be used. =20 =20 Further, this modified anycast method opens up a better way to deal with = the security concern of:=20 =E2=80=9C9. Security Considerations 9.3. Anycast In a network without any TURN server that is aware of the TURN anycast address, outgoing TURN requests could leak out onto the external Internet, possibly revealing information.=E2=80=9D=20 (or resulting in that a far away turn server not meant to be used is = selected) in a better way than=20 =E2=80=9CSensitive clients that do not wish to leak information about = their presence can set an IP TTL on their TURN requests that limits how=20 far they can travel into the public Internet.=E2=80=9D =20 For the use case of draft-ietf-rtcweb-return-01 (a TURN server deployed = on a LAN=20 to remedy firewall traversal and quality problems by taking real-time = traffic through=20 the server path, rather than through the default gateway of the = firewall/router),=20 the network configuration should also be sealed (i.e. the real-time = traffic should be=20 stopped from taking the =E2=80=9CSTUN path=E2=80=9D through the default = gateway (see the return draft=20 for discussion of =E2=80=9Csealed=E2=80=9D versus = =E2=80=9Cleaky=E2=80=9D)) . A sealed network configuration is best = enforced=20 by stopping STUN packets in the router/firewall/default gateway by = detecting the STUN cookie.** =20 In the return use case, the client (the WebRTC browser) could then use = this modified=20 anycast method, after finding that known or application provided STUN = servers give=20 no response and one can be sure that the anycast STUN binding request = goes to=20 a server on the LAN (thus trusted and no leakage of TURN requests).=20 =20 =20 Considering that the (modified) anycast method works on all network = types, and it allows=20 the TURN server network deployment to signal sealed behavior to a = otherwise leaky configured=20 WebRTC endpoint (by stopping STUN packets), this should be the = preferred discovery method=20 for WebRTC endpoints. Web applications that wish to bypass usage of the = network provided=20 TURN server, can propose a (D)TLS-encrypted STUN address (which will not = be stopped=20 since the STUN cookie will not be detected). =20 With the ever more popular and capable WiFi networks, where data and = real-time applications=20 compete about the bandwidth, this modified discovery method opens up for = WiFi routers products=20 that include the TURN server and have a sealed behavior as their default = network configuration.=20 That would be highly desirable for the usage and spread of WebRTC = communication.=20 =20 =20 Further, under: 9. Security Considerations There are discussions of =E2=80=9Cman-in-the-middle attacks=E2=80=9D = and of =E2=80=9Con-path packet injection.=E2=80=9D I think it needs to be clarified that protection against = man-in-the-middle-attacks for real-time traffic=20 through the TURN server, only is required if the application uses = unencrypted media traffic=20 (which is not the case with WebRTC). =20 /Karl =20 =20 * I suggested similar in February, but Brandon Williams (with another = use case in mind than a network provided TURN server that does not need authentication), had = hesitation about=20 authenticating the STUN binding request instead of the TURN allocation = request (while the=20 authors of the draft did not respond at all). However, after a (private) = discussion with Brandon,=20 it seems like his intended D(TLS) authentication can/should be performed = equally well at the=20 unicast address to the TURN server (returned in the Try Alternate = response), which is the same=20 in both methods. =20 ** We have verified that common rule based firewalls (at least Linux = netfilter/IPtables based)=20 can be configured to route the anycast STUN packet, while still stopping = other packets containing=20 the STUN cookie.=20 =20 =20 Fr=C3=A5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 10 februari 2016 10:35 Till: 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew'; 'Benjamin = Schwartz' Kopia: 'Prashanth Patil (praspati)'; 'tram@ietf.org' =C3=84mne: SV: [tram] turn-server-discovery and return =20 I am also positive to the update below. =20 Further,=20 =20 =20 =20 =20 =20 =20 6. Discovery using Anycast needs improvement.=20 It has two flaws that easily can be remedied:=20 =20 Current method :=20 =E2=80=9CWhen a client requires TURN services, it sends a TURN allocate = request to the assigned anycast address. The TURN anycast server = responds with a 300 (Try Alternate) error as described in [RFC5766]; = The response contains the TURN unicast address in the ALTERNATE-SERVER = attribute. For subsequent communication with the TURN server, the = client uses the responding server's unicast address.=E2=80=9D =20 Flaw 1: Turn servers do not respond differently (Try alternate or OK) = dependent on how they are addressed (by an anycast address or by a = unicast address), do they? =20 Flaw 2: As already pointed out under 9. Security Considerations, 9.3. = Anycast =E2=80=9CIn a network without any TURN server that is aware of the TURN = anycast address, outgoing TURN requests could leak out onto the external = Internet, possibly revealing information. (I would also add that a far = away bad TURN server might be used)... Sensitive clients that do not = wish to leak information about their presence can set an IP TTL on their = TURN requests that limits how far they can travel into the public = Internet.=E2=80=9D It would be better, not to have to rely on the TTL limitation. =20 Considering that a TURN server also includes a STUN server (when using = the binding request) and that the STUN server also can respond with 300 = Try alternate, I suggest the following modified method: =E2=80=9CWhen a client requires TURN services, it sends a STUN binding = request to the assigned anycast address. The STUN server responds with = a 300 (Try Alternate) error as described in [RFC5389]; The response = contains a unicast address in the ALTERNATE-SERVER attribute, which the = client compares with the source address of the response and if the = addresses are the same, it is an indication to use the TURN server at = that address. For subsequent communication with the TURN server, the = client uses that responding server's unicast address.=E2=80=9D =20 Or simply, a STUN server pointing out it=E2=80=99s own IP address as the = alternate server, means that server it is a network provided TURN server = that should be used. =20 Flaw 1 does not occur. =20 Flaw 2 is completely avoided if the client only tries this method when = the enterprise/ISP enforces a sealed configuration (according to = [I-D.ietf-rtcweb-return]) by stopping STUN packets in the = router/firewall/default gateway by detecting the STUN cookie. =20 In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its = default leaky behavior, but be signaled by the local TURN server = deployment (stopping STUN packets) to behave sealed, and only in such = case try the (modified) anycast method for TURN discovery. Thus, TURN = requests will never leak out of the local network. =20 We have verified that common rule based firewalls (at least Linux = netfilter/IPtables based) can be configured to route the anycast STUN = packet, while still stopping other packets containing the STUN cookie.=20 =20 Considering that the anycast method works on all network types, and it = allows the TURN server network deployment to automatically signal sealed = behavior to a leaky WebRTC endpoint (by stopping STUN packets), this = should be the preferred discovery method for WebRTC endpoints. A web = application that wish to bypass usage of the network provided TURN = server, can propose a DTLS-encrypted STUN address (which will not be = stopped since the STUN cookie will not be detected). =20 /Karl =20 ------=_NextPart_000_003B_01D1F177.23674DF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Re= ading this latest version, under:  

3.  Discovery Procedure

I = stumble on: =E2=80=9C=E2=80=A6 not all = TURN servers may support anycast.=E2= =80=9D

 

Th= is draft is somewhat unclear when talking about discovery and usage, but = since

no= one suggests that TURN should be used with anycast addressing, this = statement

mu= st indicate that the authors have noticed the proposed anycast discovery = method

do= esn=E2=80=99t work with RFC5766  TURN servers. That has to = change.

 

Th= e current draft says:

&n= bsp;=E2=80=9C 6.  Discovery using Anycast

=E2=80=A6

When a client requires = TURN services, it sends a TURN allocate

request to the assigned anycast address.  The TURN anycast = server

responds with a 300 (Try Alternate) = error as described in [RFC5766];

The response contains the TURN unicast address in the = ALTERNATE-

SERVER attribute.  = For subsequent communication with the TURN = server,

the client uses the = responding server's unicast address.=E2=80=9D

 

An= RFC5766  TURN server doesn=E2=80=99t answer one thing (300 Try = Alternate) when addresses

by= an anycast address and another thing when addresses with its unicast = address

(e= ven if such TURN servers could be developed and possibly = standardized=E2=80=A6).

 

Co= nsidering that a TURN server also includes a STUN server (when using the = binding request)

an= d that the STUN server also can respond with 300 Try alternate, =

I = suggest the following modified method:

=E2=80=9CWhen a client requires TURN services, it = sends a STUN binding

request to the assigned anycast address.  The = STUN server

responds with a 300 (Try Alternate) error as described = in [RFC5389]; 

The response contains a unicast address in the = ALTERNATE-

SERVER = attribute, which the client compares with the source =

address = of the response and if the addresses are the same, =

it is = an indication to use the TURN server at that address. =

For = subsequent communication with the TURN server, the client =

uses = that responding server's unicast = address.=E2=80=9D

 

Or= simply, a STUN server pointing out it=E2=80=99s own IP address as the = alternate server,

me= ans that it is a network provided TURN server that should be = used.

 

 

Fu= rther, this modified anycast method opens up a better way to deal with = the security concern of:

=E2= =80=9C9.  Security Considerations

9.3.  Anycast

   In a network without any TURN server that is aware of = the TURN

   anycast address, = outgoing TURN requests could leak out onto the

   external Internet, possibly revealing = information.=E2=80=9D

(o= r resulting in that a far away turn server not meant to be used is = selected)

in= a better way than

=E2= =80=9CSensitive clients that do not wish to leak information about = their

presence can set an IP TTL on their = TURN requests that limits how

far they can travel into the public Internet.=E2= =80=9D

 

Fo= r the use case of draft-ietf-rtcweb-return-01 (a TURN server deployed on = a LAN

to= remedy firewall traversal and quality problems by taking real-time = traffic through

th= e server path, rather than through the default gateway of the = firewall/router),

th= e network configuration should also be sealed (i.e. the real-time = traffic should be

st= opped from taking the =E2=80=9CSTUN path=E2=80=9D through the default = gateway (see the return draft

fo= r discussion of =E2=80=9Csealed=E2=80=9D versus = =E2=80=9Cleaky=E2=80=9D)) .  A sealed network configuration is best = enforced

by= stopping STUN packets in the router/firewall/default gateway by = detecting the STUN cookie.**

 

In= the return use case, the client (the WebRTC browser) could then use = this modified

an= ycast method, after finding that known or application provided STUN = servers give

no= response and one can be sure that the anycast STUN binding request goes = to

a = server on the LAN (thus trusted and no leakage of TURN requests). =

 

 

Co= nsidering that the (modified) anycast method works on all network types, = and it allows

th= e TURN server network deployment to signal sealed behavior to a = otherwise leaky configured

We= bRTC endpoint (by stopping STUN packets),  this should be the = preferred discovery method

fo= r WebRTC endpoints. Web applications that wish to bypass usage of the = network provided

TU= RN server, can propose a (D)TLS-encrypted STUN address (which will not = be stopped

si= nce the STUN cookie will not be detected).

 

Wi= th the ever more popular and capable WiFi networks, where data and = real-time applications

co= mpete about the bandwidth, this modified discovery method opens up for = WiFi routers products

th= at include the TURN server and have a sealed behavior as their default = network configuration.

Th= at would be highly desirable for the usage and spread of WebRTC = communication.

 

 

Fu= rther, under:

9.  Security = Considerations

Th= ere are discussions of  =E2=80=9Cman-in-the-middle attacks=E2=80=9D = an= d of  =E2=80=9Con-path packet = injection.=E2=80=9D

I = think it needs to be clarified that protection against = man-in-the-middle-attacks for real-time traffic

th= rough the TURN server, only is required if the application uses = unencrypted media traffic

(w= hich is not the case with WebRTC).

 

/K= arl

 

 

* = I suggested similar in February, but Brandon Williams (with another use = case in mind than a

= network provided TURN server that does not need authentication), had = hesitation about

au= thenticating the STUN binding request instead of the TURN allocation = request (while the

au= thors of the draft did not respond at all). However, after a (private) = discussion with Brandon,

it= seems like his intended D(TLS) authentication can/should be performed = equally well at the

un= icast address to the TURN server (returned in the Try Alternate = response), which is the same

in= both methods.

 

**= We have verified that common rule based firewalls (at least Linux = netfilter/IPtables based)

ca= n be configured to route the anycast STUN packet, while still stopping = other packets containing

th= e STUN cookie.

 

 

Fr=C3=A5n: Karl Stahl = [mailto:karl.stahl@intertex.se]=
Skickat: den 10 februari 2016 10:35
Till: = 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew'; 'Benjamin = Schwartz'
Kopia: 'Prashanth Patil (praspati)'; = 'tram@ietf.org'
=C3=84mne: SV: [tram] turn-server-discovery = and return

 

I = am also positive to the update below.

 

Fu= rther,

 

 

 

 

 

 

6.  Discovery using Anycast = ne= eds improvement.

It= has two flaws that easily can be remedied:

 

Cu= rrent method :

=E2=80=9CWhen a client requires TURN services, it = sends a TURN allocate request to the assigned anycast address.  The = TURN anycast server responds with a 300 (Try Alternate) error as = described in [RFC5766];  The response contains the TURN unicast = address in the ALTERNATE-SERVER attribute.  For subsequent = communication with the TURN server, the client uses the responding = server's unicast address.=E2=80=9D

 

Fl= aw 1: Turn servers do not respond differently (Try alternate or OK) = dependent on how they are addressed (by an anycast address or by a = unicast address), do they?

 

Fl= aw 2: As already pointed out under  9.  Security Considerations, = 9.3.  Anycast

=E2= =80=9CIn a = network without any TURN server that is aware of the TURN anycast = address, outgoing TURN requests could leak out onto the external = Internet, possibly revealing information. (I = would also add that a far away bad TURN server might be = used)... = Sensitive clients that do not wish to leak information about their = presence can set an IP TTL on their TURN requests that limits how far = they can travel into the public = Internet.=E2=80=9D

It= would be better, not to have to rely on the TTL = limitation.

 

Co= nsidering that a TURN server also includes a STUN server (when using the = binding request) and that the STUN server also can respond with 300 Try = alternate, I suggest the following modified = method:

=E2=80=9CWhen a client requires TURN services, it = sends a STUN binding request to the assigned anycast address.  The = STUN server responds with a 300 (Try Alternate) error as described in = [RFC5389];  The response contains a unicast address in the = ALTERNATE-SERVER attribute, which the client compares with the source = address of the response and if the addresses are the same, it is an = indication to use the TURN server at that address. For subsequent = communication with the TURN server, the client uses that responding = server's unicast address.=E2=80=9D

 

Or= simply, a STUN server pointing out it=E2=80=99s own IP address as the = alternate server, means that server it is a network provided TURN server = that should be used.

 

Fl= aw 1 does not occur.

 

Fl= aw 2 is completely avoided if  the client only tries this method = when the enterprise/ISP enforces a sealed configuration (according to = [I-D.ietf-rtcweb-return]) = by stopping STUN packets in the router/firewall/default gateway by = detecting the STUN cookie.

 

In= [I-D.ietf-rtcweb-return], = the WebRTC endpoint could then maintain its default leaky behavior, but = be signaled by the local TURN server deployment (stopping STUN packets) = to behave sealed, and only in such case try the (modified) anycast = method for TURN discovery. Thus, TURN requests will never leak out of = the local network.

 

We= have verified that common rule based firewalls (at least Linux = netfilter/IPtables based) can be configured to route the anycast STUN = packet, while still stopping other packets containing the STUN cookie. =

 

Co= nsidering that the anycast method works on all network types, and it = allows the TURN server network deployment to automatically signal sealed = behavior to a leaky WebRTC endpoint (by stopping STUN packets),  = this should be the preferred discovery method for WebRTC endpoints. A = web application that wish to bypass usage of the network provided TURN = server, can propose a DTLS-encrypted STUN address (which will not be = stopped since the STUN cookie will not be = detected).

 

/K= arl

 

------=_NextPart_000_003B_01D1F177.23674DF0-- From nobody Mon Aug 8 10:14:00 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423D512D0BF; Mon, 8 Aug 2016 10:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.267 X-Spam-Level: X-Spam-Status: No, score=-8.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 Ub-RDdoaGibB; Mon, 8 Aug 2016 10:13:30 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A101C12D85A; Mon, 8 Aug 2016 10:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1470676405; x=1502212405; h=from:to:subject:date:message-id:mime-version; bh=d8B6M/FqaU6sQdsieQORVphw1gBXjkRe7FBleKzLCWk=; b=aeyf6Hu6dEiBLIqF18wDMU8zkknLRctLWZtByclyNVbNzNjysbCkuk5h OQAmbKwyKQSQd4khnLR80KmKV4utRG3CIczT30QrLhYE812qQP1hCMJ7E EF/y59smFS9KHWmymhlqtUYWi0wF9aga0lbvbpKaRC5BWV41uBa2mDMOD A=; X-IronPort-AV: E=Sophos;i="5.28,490,1464678000"; d="scan'208,217";a="215069629" Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Aug 2016 10:13:22 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8251"; a="752866584" X-Amp-Result: CLEAN Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Aug 2016 10:13:22 -0700 Received: from [10.64.161.115] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 10:13:21 -0700 From: Pete Resnick To: General Area Review Team , , , IETF Date: Mon, 8 Aug 2016 12:13:20 -0500 Message-ID: <0D5A57AB-E9A5-47C9-AB58-77D32BB97B1B@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_FE76DC6F-4221-4CB9-8435-784656DD1346_=" X-Mailer: MailMate (1.9.4r5239) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: [tram] Gen-ART LC review of draft-ietf-tram-turn-mobility-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 17:13:47 -0000 --=_MailMate_FE76DC6F-4221-4CB9-8435-784656DD1346_= Content-Type: text/plain; format=flowed; markup=markdown I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tram-turn-mobility-03 Reviewer: Pete Resnick Review Date: 2016-08-08 IETF LC End Date: 2016-08-11 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has some minor issues and nits that should be fixed before publication. Major issues: None Minor issues: 3.1.2 - Change "MUST" to "will" both times in the second paragraph. The last sentence of the section I don't understand; it doesn't seem to have any interoperability implications, and I don't see why the client can't examine the ticket in any way it wants. Either justify the sentence or delete it. 3.2.2 - Change "may" to "MAY" in the sixth paragraph. That *is* a protocol option being described there. Nits/editorial comments: 3.1.4 - Change "MAY" to "can" in the second paragraph. I'd also split that sentence into two sentences as the first half has nothing to do with the second half. 3.2.1 - The last sentence of 3.2.1 is confusing until you read 3.2.2 and 3.2.3. I would simply delete the sentence. I don't think it adds anything. 3.4 - Put the "TBD" in there so that the RFC Editor can update. 4 - Put a note to the RFC Editor here to update sections 3.1.4 and 3.4 with the error number. That will make sure it gets updated properly. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --=_MailMate_FE76DC6F-4221-4CB9-8435-784656DD1346_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. The Ge= neral Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Document: draft-ietf-tram-turn-mobility-03
Reviewer: Pete Resnick
Review Date: 2016-08-08
IETF LC End Date: 2016-08-11
IESG Telechat date: Unknown

Summary: This draft is basically ready for publication, b= ut has some minor issues and nits that should be fixed before publication= =2E

Major issues:

None

Minor issues:

3.1.2 - Change "MUST" to "will" both times in the second = paragraph. The last sentence of the section I don't understand; it doesn'= t seem to have any interoperability implications, and I don't see why the= client can't examine the ticket in any way it wants. Either justify the = sentence or delete it.

3.2.2 - Change "may" to "MAY" in the sixth paragraph. Tha= t is a protocol option being described there.

Nits/editorial comments:

3.1.4 - Change "MAY" to "can" in the second paragraph. I'= d also split that sentence into two sentences as the first half has nothi= ng to do with the second half.

3.2.1 - The last sentence of 3.2.1 is confusing until you= read 3.2.2 and 3.2.3. I would simply delete the sentence. I don't think = it adds anything.

3.4 - Put the "TBD" in there so that the RFC Editor can u= pdate.

4 - Put a note to the RFC Editor here to update sections = 3.1.4 and 3.4 with the error number. That will make sure it gets updated = properly.

pr
--
Pete Resnick http://www.= qualcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

--=_MailMate_FE76DC6F-4221-4CB9-8435-784656DD1346_=-- From nobody Mon Aug 8 21:50:21 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF63712D759; Mon, 8 Aug 2016 21:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMsjlo7ci7pJ; Mon, 8 Aug 2016 21:50:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5301F12D63F; Mon, 8 Aug 2016 21:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9966; q=dns/txt; s=iport; t=1470718218; x=1471927818; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8fGkv7VLUe6N6WWjpxGQCvv+NTOkKn4AqikSIdYwqEI=; b=i5Xf1Xr4H5wAIOkXXV7a9UGTTIc9k4fA4Xu8LxlX7ruUOW5oJYlLR0PU dmXCzXhgtUSg8fhkJ5T5E73v5gKPIdqA/r23rycW4AEpZvoDwkG/UEMmJ 1al/6RbD/447tZgX9YgxOGRjvCo9B0oUK/Dj1MEmRipaPW19WjWcEi1lx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgC8X6lX/5NdJa1aAxaCYU5WfAe0E?= =?us-ascii?q?YUHgX0khXkCgUc4FAEBAQEBAQFdJ4ReAQEFLVwCAQgOAwMBAQEoBzIUCQgCBAE?= =?us-ascii?q?SCIgpDsMfAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2EMDABFRGFFAWZOQGGH?= =?us-ascii?q?IhmgXJOhA2DMoVLhmSFUIN3AQ8PNoN6bgGFdn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,493,1464652800"; d="scan'208,217";a="133784248" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2016 04:50:17 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u794oHqn009116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 04:50:17 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 Aug 2016 23:50:16 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Mon, 8 Aug 2016 23:50:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Pete Resnick , General Area Review Team , "draft-ietf-tram-turn-mobility.all@ietf.org" , "tram@ietf.org" , IETF Thread-Topic: Gen-ART LC review of draft-ietf-tram-turn-mobility-03 Thread-Index: AQHR8Zg9AFN8sQqqCkCqzJzOS7OCiaBAB0aQ Date: Tue, 9 Aug 2016 04:50:16 +0000 Message-ID: <38321ad067a84b47a29a525d05185a7e@XCH-RCD-017.cisco.com> References: <0D5A57AB-E9A5-47C9-AB58-77D32BB97B1B@qti.qualcomm.com> In-Reply-To: <0D5A57AB-E9A5-47C9-AB58-77D32BB97B1B@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.32.8] Content-Type: multipart/alternative; boundary="_000_38321ad067a84b47a29a525d05185a7eXCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Gen-ART LC review of draft-ietf-tram-turn-mobility-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 04:50:20 -0000 --_000_38321ad067a84b47a29a525d05185a7eXCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pete, Thanks for the review. Please see inline From: Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Monday, August 8, 2016 10:43 PM To: General Area Review Team ; draft-ietf-tram-turn-mobil= ity.all@ietf.org; tram@ietf.org; IETF Subject: Gen-ART LC review of draft-ietf-tram-turn-mobility-03 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-tram-turn-mobility-03 Reviewer: Pete Resnick Review Date: 2016-08-08 IETF LC End Date: 2016-08-11 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has some minor = issues and nits that should be fixed before publication. Major issues: None Minor issues: 3.1.2 - Change "MUST" to "will" both times in the second paragraph. The las= t sentence of the section I don't understand; it doesn't seem to have any i= nteroperability implications, and I don't see why the client can't examine = the ticket in any way it wants. Either justify the sentence or delete it. [TR] Even if the client examines the ticket there is no guarantee that it w= ill be able decode its fields. This line is added to suggest that there is = no need for the client to examine the ticket. 3.2.2 - Change "may" to "MAY" in the sixth paragraph. That is a protocol op= tion being described there. [TR] Updated. Nits/editorial comments: 3.1.4 - Change "MAY" to "can" in the second paragraph. I'd also split that = sentence into two sentences as the first half has nothing to do with the se= cond half. [TR] Changed. 3.2.1 - The last sentence of 3.2.1 is confusing until you read 3.2.2 and 3.= 2.3. I would simply delete the sentence. I don't think it adds anything. [TR] Sure, deleted. 3.4 - Put the "TBD" in there so that the RFC Editor can update. [TR] Added. 4 - Put a note to the RFC Editor here to update sections 3.1.4 and 3.4 with= the error number. That will make sure it gets updated properly. [TR] Yes, updated. -Tiru pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_38321ad067a84b47a29a525d05185a7eXCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pete,

 

Thanks for the review. Please see inl= ine

 

From: Pete Resnick [mailto:presnick@= qti.qualcomm.com]
Sent: Monday, August 8, 2016 10:43 PM
To: General Area Review Team <gen-art@ietf.org>; draft-ietf-tr= am-turn-mobility.all@ietf.org; tram@ietf.org; IETF <ietf@ietf.org> Subject: Gen-ART LC review of draft-ietf-tram-turn-mobility-03<= /o:p>

 

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

http= ://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Document: draft-ietf-tram-turn-mobility-03
Reviewer: Pete Resnick
Review Date: 2016-08-08
IETF LC End Date: 2016-08-11
IESG Telechat date: Unknown

Summary: This draft is basically ready for publication, but has some min= or issues and nits that should be fixed before publication.

Major issues:

None

Minor issues:

3.1.2 - Change "MUST" to "will" both times in the se= cond paragraph. The last sentence of the section I don't understand; it doe= sn't seem to have any interoperability implications, and I don't see why th= e client can't examine the ticket in any way it wants. Either justify the sentence or delete it.

[TR] Even if the client examines the ticket there is no g= uarantee that it will be able decode its fields. This line is added to sugg= est that there is no need for the client to examine the ticket.

3.2.2 - Change "may" to "MAY" in the sixth paragraph= . That is a protocol option being described there.

[TR] Updated.

Nits/editorial comments:

3.1.4 - Change "MAY" to "can" in the second paragrap= h. I'd also split that sentence into two sentences as the first half has no= thing to do with the second half.

[TR] Changed.

3.2.1 - The last sentence of 3.2.1 is confusing until you read 3.2.2 and= 3.2.3. I would simply delete the sentence. I don't think it adds anything.=

[TR] Sure, deleted.

3.4 - Put the "TBD" in there so that the RFC Editor can update= .

[TR] Added.

4 - Put a note to the RFC Editor here to update sections 3.1.4 and 3.4 w= ith the error number. That will make sure it gets updated properly.

[TR] Yes, updated.

-Tiru

pr
--
Pete Resnick

 

http://www.qualcomm.com= /~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

--_000_38321ad067a84b47a29a525d05185a7eXCHRCD017ciscocom_-- From nobody Tue Aug 9 09:06:08 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2E12B04D; Tue, 9 Aug 2016 09:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.267 X-Spam-Level: X-Spam-Status: No, score=-8.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 qd00DBO8ADDh; Tue, 9 Aug 2016 09:06:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6573612B032; Tue, 9 Aug 2016 09:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1470758763; x=1502294763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=29e9xekSNX5Ax4z3+g/ektDaXesTZVgT1qNPxDymvAs=; b=Wm6nR0RQ4f2H8jkYbB0qTpMR5Cf42R73rSGoeO14QvMGDgeEJ9wgs2w2 bEQWfbcP5w06KU6yX4OcP+fwtdraOu2+He/vVF7amYZdUaZm0p63XTMNj mCsZvXh/ykOvT0Z+ZRnU5usJgfM7VhP8cAqMpp6GP+qISgltxN1uiJUsQ E=; X-IronPort-AV: E=Sophos;i="5.28,495,1464678000"; d="scan'208,217";a="310474869" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2016 09:06:03 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8252"; a="1201736471" X-Amp-Result: CLEAN Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2016 09:06:02 -0700 Received: from [10.64.161.115] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 9 Aug 2016 09:06:01 -0700 From: Pete Resnick To: Tirumaleswar Reddy Date: Tue, 9 Aug 2016 11:05:57 -0500 Message-ID: <0EF98A4A-04FD-4E34-AD1E-A6E5F5D246D9@qti.qualcomm.com> In-Reply-To: <38321ad067a84b47a29a525d05185a7e@XCH-RCD-017.cisco.com> References: <0D5A57AB-E9A5-47C9-AB58-77D32BB97B1B@qti.qualcomm.com> <38321ad067a84b47a29a525d05185a7e@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0ADDBE45-3634-4DEB-813A-98480A2319D9_=" X-Mailer: MailMate (1.9.4r5239) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: General Area Review Team , "draft-ietf-tram-turn-mobility.all@ietf.org" , "tram@ietf.org" , IETF Subject: Re: [tram] Gen-ART LC review of draft-ietf-tram-turn-mobility-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 16:06:05 -0000 --=_MailMate_0ADDBE45-3634-4DEB-813A-98480A2319D9_= Content-Type: text/plain; format=flowed; markup=markdown Thanks for the response Tiru. Trimming down to the one open issue below; everything else looks perfect: On 8 Aug 2016, at 23:50, Tirumaleswar Reddy (tireddy) wrote: >> 3.1.2 - Change "MUST" to "will" both times in the second paragraph. I presume you're OK with those changes? >> The last sentence of the section I don't understand; it doesn't seem >> to have any interoperability implications, and I don't see why the >> client can't examine the ticket in any way it wants. Either justify >> the sentence or delete it. > > [TR] Even if the client examines the ticket there is no guarantee that > it will be able decode its fields. This line is added to suggest that > there is no need for the client to examine the ticket. Well, "no need" is very different than "MUST NOT". If you really want to keep the sentence (and I still think you could just delete it), I would suggest simply changing it to something like: "Note: There is no guarantee that the fields in the ticket are going to be decodable to a client, and therefore attempts by a client to examine the ticket are unlikely to be useful." pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --=_MailMate_0ADDBE45-3634-4DEB-813A-98480A2319D9_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Thanks for the response Tiru. Trimming down to the one op= en issue below; everything else looks perfect:

On 8 Aug 2016, at 23:50, Tirumaleswar Reddy (tireddy) wro= te:

3.1.2 - Change "MUST" to "will" both times in the second = paragraph.

I presume you're OK with those changes?

The last sentence of the section I don't understand; it d= oesn't seem to have any interoperability implications, and I don't see wh= y the client can't examine the ticket in any way it wants. Either justify= the sentence or delete it.

[TR] Even if the client examines the ticket there is no g= uarantee that it will be able decode its fields. This line is added to su= ggest that there is no need for the client to examine the ticket.

Well, "no need" is very different than "MUST NOT". If you= really want to keep the sentence (and I still think you could just delet= e it), I would suggest simply changing it to something like: "Note: There= is no guarantee that the fields in the ticket are going to be decodable = to a client, and therefore attempts by a client to examine the ticket are= unlikely to be useful."

pr
--
Pete Resnick http://www.= qualcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

--=_MailMate_0ADDBE45-3634-4DEB-813A-98480A2319D9_=-- From nobody Tue Aug 9 09:49:17 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81712D518; Tue, 9 Aug 2016 09:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e76WJPWb9fvm; Tue, 9 Aug 2016 09:49:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B039D12D112; Tue, 9 Aug 2016 09:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7217; q=dns/txt; s=iport; t=1470761351; x=1471970951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KMfpKLQfwHtakefzHK5Ya23+NZhT9q3x32a1jOJKXUc=; b=IUYPykmuh9yDmenM2gD7uQT7ZTDO5p2WuHVcx8O8zKI/BHCe8xcMYe9P 2tRtKJ/ucvtby/n2rw+BUPX7jyZFZ6q3sTJWDhSmOQkju8q0GkkP9hDMD Te2hJIoLTCRql+ZlnVMPNhl2+SFokZA1G66+euPZ4+O5ir/h+tNrMyHAi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAgBtCKpX/5xdJa1aAxaCYU5WfAe0F?= =?us-ascii?q?oUHgX0ghX0CgUs4FAEBAQEBAQFdJ4ReAQEFLUwQAgEIDgMEAQEoBzIUCQgCBA4?= =?us-ascii?q?FCIgpDsEdAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2EMDEVEYUUBZk5AY8Cj?= =?us-ascii?q?0qMNIN3AR42g3puhi1/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,495,1464652800"; d="scan'208,217";a="138020626" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2016 16:49:10 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u79GnAn0031640 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 16:49:10 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 Aug 2016 11:49:10 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Tue, 9 Aug 2016 11:49:10 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Pete Resnick Thread-Topic: Gen-ART LC review of draft-ietf-tram-turn-mobility-03 Thread-Index: AQHR8Zg9AFN8sQqqCkCqzJzOS7OCiaBAB0aQgAEZLoD//7aQAA== Date: Tue, 9 Aug 2016 16:49:10 +0000 Message-ID: <92d4a285d1534ba9b58d27941a53b8b7@XCH-RCD-017.cisco.com> References: <0D5A57AB-E9A5-47C9-AB58-77D32BB97B1B@qti.qualcomm.com> <38321ad067a84b47a29a525d05185a7e@XCH-RCD-017.cisco.com> <0EF98A4A-04FD-4E34-AD1E-A6E5F5D246D9@qti.qualcomm.com> In-Reply-To: <0EF98A4A-04FD-4E34-AD1E-A6E5F5D246D9@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.32.8] Content-Type: multipart/alternative; boundary="_000_92d4a285d1534ba9b58d27941a53b8b7XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: General Area Review Team , "draft-ietf-tram-turn-mobility.all@ietf.org" , "tram@ietf.org" , IETF Subject: Re: [tram] Gen-ART LC review of draft-ietf-tram-turn-mobility-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 16:49:13 -0000 --_000_92d4a285d1534ba9b58d27941a53b8b7XCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Tuesday, August 9, 2016 9:36 PM To: Tirumaleswar Reddy (tireddy) Cc: General Area Review Team ; draft-ietf-tram-turn-mobil= ity.all@ietf.org; tram@ietf.org; IETF Subject: Re: Gen-ART LC review of draft-ietf-tram-turn-mobility-03 Thanks for the response Tiru. Trimming down to the one open issue below; ev= erything else looks perfect: On 8 Aug 2016, at 23:50, Tirumaleswar Reddy (tireddy) wrote: 3.1.2 - Change "MUST" to "will" both times in the second paragraph. I presume you're OK with those changes? [TR] Yes. The last sentence of the section I don't understand; it doesn't seem to hav= e any interoperability implications, and I don't see why the client can't e= xamine the ticket in any way it wants. Either justify the sentence or delet= e it. [TR] Even if the client examines the ticket there is no guarantee that it w= ill be able decode its fields. This line is added to suggest that there is = no need for the client to examine the ticket. Well, "no need" is very different than "MUST NOT". If you really want to ke= ep the sentence (and I still think you could just delete it), I would sugge= st simply changing it to something like: "Note: There is no guarantee that = the fields in the ticket are going to be decodable to a client, and therefo= re attempts by a client to examine the ticket are unlikely to be useful." [TR] Works for me, updated. -Tiru pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_92d4a285d1534ba9b58d27941a53b8b7XCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Pete Resnick [mailto:presnick@= qti.qualcomm.com]
Sent: Tuesday, August 9, 2016 9:36 PM
To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>
Cc: General Area Review Team <gen-art@ietf.org>; draft-ietf-tr= am-turn-mobility.all@ietf.org; tram@ietf.org; IETF <ietf@ietf.org> Subject: Re: Gen-ART LC review of draft-ietf-tram-turn-mobility-03

 

Thanks for the response Tiru. Trimming down to the one open issue below;= everything else looks perfect:

On 8 Aug 2016, at 23:50, Tirumaleswar Reddy (tireddy) wrote:<= /p>

3.1.2 - Change "MUST" to "will" both times in the se= cond paragraph.

I presume you're OK with those changes?

[TR] Yes.

The last sentence of the section I don't understand; it doesn't seem to = have any interoperability implications, and I don't see why the client can'= t examine the ticket in any way it wants. Either justify the sentence or de= lete it.

[TR] Even if the client examines the ticket there is no guarantee that i= t will be able decode its fields. This line is added to suggest that there = is no need for the client to examine the ticket.

Well, "no need" is very different than "MUST NOT". I= f you really want to keep the sentence (and I still think you could just de= lete it), I would suggest simply changing it to something like: "Note:= There is no guarantee that the fields in the ticket are going to be decodable to a client, and therefore attempts by a client to e= xamine the ticket are unlikely to be useful."

[TR] Works for me, updated.

-Tiru

pr
--
Pete Resnick http://www.qu= alcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

--_000_92d4a285d1534ba9b58d27941a53b8b7XCHRCD017ciscocom_-- From nobody Tue Aug 9 19:24:24 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17312D0A1; Tue, 9 Aug 2016 19:24:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147079585996.30564.18061551420206432052.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 19:24:19 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-04.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 02:24:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized of the IETF. Title : Mobility with TURN Authors : Dan Wing Prashanth Patil Tirumaleswar Reddy Paal-Erik Martinsen Filename : draft-ietf-tram-turn-mobility-04.txt Pages : 13 Date : 2016-08-09 Abstract: It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-mobility-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 9 19:33:34 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF75812D0A1 for ; Tue, 9 Aug 2016 19:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.769 X-Spam-Level: X-Spam-Status: No, score=-15.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_AwlZW_TVQo for ; Tue, 9 Aug 2016 19:33:31 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8AE12B057 for ; Tue, 9 Aug 2016 19:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2325; q=dns/txt; s=iport; t=1470796411; x=1472006011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hmDLVbJYvO0ovyA752ZvBwrv77H3jCiuYYQNIIA1Hk0=; b=YseRRMCAhddIneRUl2wN1EYCjRiDxjbz2o5JxChnx6yipZrbw5AwJi+e N9IQpXqy/7JuBns+mPo8WK3t+cbbJenMJEyMPw8OL0CEXt9V5rs/3S6DS IB0b7hhX1GSIYRFKX/2Wbf7kV2p90gf4hSG39NhuBAcbWDi4XGy23rJ0W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AgBDkapX/4gNJK1dg0VWfAe5HoF9J?= =?us-ascii?q?IV5AoFWOBQBAQEBAQEBXRwLhF4BAQUBATg0CwwEAgEIEQQBAR8JBycLFAkIAgQ?= =?us-ascii?q?OBQgTiBYOwWsBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYQqhXEFmTkBhhyIZ?= =?us-ascii?q?oFyToQNiH2MNIN3AR42g3puhi1/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,497,1464652800"; d="scan'208";a="309027444" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2016 02:33:30 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7A2XUJq011627 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Aug 2016 02:33:30 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 Aug 2016 21:33:29 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Tue, 9 Aug 2016 21:33:29 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-04.txt Thread-Index: AQHR8q5Zisw3g5cbG06+vrck11Fh7KBBd9Ow Date: Wed, 10 Aug 2016 02:33:29 +0000 Message-ID: <02ac7b3dfe504eb9bd97b23665b5f3dd@XCH-RCD-017.cisco.com> References: <147079585996.30564.18061551420206432052.idtracker@ietfa.amsl.com> In-Reply-To: <147079585996.30564.18061551420206432052.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.55.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'presnick@qti.qualcomm.com'" , "david.waltermire@nist.gov" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-04.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 02:33:33 -0000 This revision addresses comments received during Gen-Art and SecDir review. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, August 10, 2016 7:54 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized of the IETF. >=20 > Title : Mobility with TURN > Authors : Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Paal-Erik Martinsen > Filename : draft-ietf-tram-turn-mobility-04.txt > Pages : 13 > Date : 2016-08-09 >=20 > Abstract: > It is desirable to minimize traffic disruption caused by changing IP > address during a mobility event. One mechanism to minimize > disruption is to expose a shorter network path to the mobility event > so only the local network elements are aware of the changed IP > address but the remote peer is unaware of the changed IP address. >=20 > This draft provides such an IP address mobility solution using > Traversal Using Relays around NAT (TURN). This is achieved by > allowing a client to retain an allocation on the TURN server when the > IP address of the client changes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-mobility-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Aug 16 23:57:15 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9393412B057 for ; Tue, 16 Aug 2016 23:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVrJVBAUVvCQ for ; Tue, 16 Aug 2016 23:57:11 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 F0D6712B019 for ; Tue, 16 Aug 2016 23:57:10 -0700 (PDT) Received: from [10.59.1.234] (ip3-149.zitius.riksnet.nu [95.109.58.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id E0890426A; Wed, 17 Aug 2016 08:57:06 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <57A23522.1020801@akamai.com> Date: Wed, 17 Aug 2016 08:57:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7EA89B24-C334-499D-B4B7-E948A487DD16@edvina.net> References: <57A23522.1020801@akamai.com> To: Brandon Williams X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson , tram@ietf.org Subject: Re: [tram] TURN server auto-discovery X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 06:57:14 -0000 > On 03 Aug 2016, at 20:17, Brandon Williams = wrote: >=20 > Hi Olle, >=20 > Regarding your comment about section 9: >=20 > > Section 9: > > - =93Use of STUN authentication is OPTIONAL for TURN servers = provided by > > the local network or by the access network. A network provided = TURN > > server MAY be configured to accept Allocation requests without = STUN > > authentication, and a TURN client MAY be configured to accept > > Allocation success responses without STUN authentication from a > > network provided TURN server. =93 > > Is this text normative? If so it=92s clearly out of scope for a = draft on auto-discovery. > > You also need to add text on DNSsec here. > > > > A lot of this text is good, but I have issues with it being in this = draft. Does > > this text normatively update another document? It covers how to set = up > > connections more than how to discover services. Maybe how to trust > > the TURN server should be another draft or, if it needs to be in = this draft, > > should be made in a separate section. If that is the case, the = abstract > > and introduction section needs to be modified to cover this scope = too. >=20 > As I understand it, this text is meant to be normative, though perhaps = just the first sentence. The existing TURN specification requires STUN = authentication for TURN. For TURN servers provided by the local or = access network, there is a presumption that network has other methods = for restricting access and that STUN authentication is not required. = Thus this draft intends to make STUN authentication OPTIONAL, but only = when the relay is provided by either the local or the access network. Ok, I see the intent. I am not sure I agree that encouraging the thought = that there=92s still a secure internal network and a hostile outside = network. This needs a larger discussion with security people involved. >=20 > The additional sentence is meant, I think, to describe what this means = in practice: both the client and the server can be configured to allow = unauthenticated TURN messages, and they must both be configured to allow = this in order for it to work. That is a big change. >=20 > As I write this explanation, I realize that the current text doesn't = state the motivation. This should be added, I think. Also, maybe the = second sentence isn't adequate clarification. Maybe we need something = like: The server accepts the unauthenticated Allocate if configured = appropriately. The client accepts the unauthenticated Allocate response = if configured appropriately, and it now can send unauthenticated TURN = messages on the channel. If the client receives an unauthenticated = Allocate response but is not configured to accept them, then it ignores = the message. Maybe there is a need to provide a fallback mechanism in = the case that the client requires auth and the server doesn=92t. My backbone feeling is that this change is way to big to be part of = autodiscovery. Personally I do not think it=92s a good thing. Even in an internal network, there has to be = provisioning of account information and we should encourage that instead of disabling authentication. Sorry for the late response, have been enjoying a summer holiday :-) /O >=20 > --Brandon >=20 > On 07/27/2016 04:15 AM, Olle E. Johansson wrote: >> Sorry for being late into reviewing this document. If I am too late, = my apologies, >> but nevertheless here=92s a few nits and comments: >>=20 >> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-08 >>=20 >> Section 1: >> - =93Web Real-Time Communication (WebRTC) >> [I-D.ietf-rtcweb-overview] usages and related extensions, which = are >> mostly based on web applications, need this immediately.=94 >> When I read this in ten years time, it is no longer immediately. = Please rephrase. >>=20 >> - =93This document describes three discovery mechanisms, so as to = maximize >> opportunity for discovery, based on the network in which the TURN >> client finds itself. =93 >> A very complicated sentence. Can it be simplified to make reading = easier? >>=20 >> - =93For example, in case of Web Real-Time Communication >> (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, >> which are based on web applications, a Java Script specified TURN >> server MUST be considered as local configuration. =93 >> I think =93local=94 is a bad choice here - maybe = =93application-provided configuration=94 >> could be an improvement? >>=20 >> - =93A client can choose auto-discovery in the absence of local >> configuration, if local configuration doesn't work or on top of local >> configuration. =93 >> I think local security policy may affect choice and maybe also need = to override >> =93local configuration=94 >>=20 >> - =93An implementation >> MAY give the user an opportunity (e.g., by means of configuration >> file options or menu items) to specify a TURN server for each = address >> family.=94 >> How do you define the implementation? The browser, the javascript = application >> or another TURN user, like a SIP phone? In the case of WebRTC you = need >> to clarify your terminology - there=92s one application running in = javascript and >> then you have the browser. Also remember that TURN is not only about >> browsers :-) >>=20 >> - =93A TURN client that implements the auto discovery algorithm, to >> discover TURN servers in the attached network, uses the following >> mechanisms for discovery:=94 >> Change the list that follows to use bullets, as you later write that = you do not >> prescribe a strict order. >>=20 >> Section 4.1: >> This section is a bit open. If I want to write a SIP specific = document >> specifying a way to use the outbound proxy URI or a service route URI >> to use for TURN service discovery - will that be a standalone = document >> or an update to this document. Maybe some requirements on other >> ways to select a domain name would be appropriate. >>=20 >> Section 4.1.2: >> - =93JID : 'alice@example.com=92=94 >> You have a SIP URI and a bare JID. Maybe consider making it an XMPP = URI >> by prefixing the JID with =93XMPP:=94 for clarity. >>=20 >> Section 5: >> - =93For example, TURN server advertises the following DNS records :=94= >> s/TURN/a TURN/ >>=20 >> Section 9: >> - =93Use of STUN authentication is OPTIONAL for TURN servers provided = by >> the local network or by the access network. A network provided = TURN >> server MAY be configured to accept Allocation requests without = STUN >> authentication, and a TURN client MAY be configured to accept >> Allocation success responses without STUN authentication from a >> network provided TURN server. =93 >> Is this text normative? If so it=92s clearly out of scope for a draft = on auto-discovery. >> You also need to add text on DNSsec here. >>=20 >> A lot of this text is good, but I have issues with it being in this = draft. Does >> this text normatively update another document? It covers how to set = up >> connections more than how to discover services. Maybe how to trust >> the TURN server should be another draft or, if it needs to be in this = draft, >> should be made in a separate section. If that is the case, the = abstract >> and introduction section needs to be modified to cover this scope = too. >>=20 >>=20 >> /O >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 18 18:13:20 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCCB12D0E9; Thu, 18 Aug 2016 18:13:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147156919521.27836.3349394775180577505.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 18:13:15 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-05.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 01:13:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized of the IETF. Title : Mobility with TURN Authors : Tirumaleswar Reddy Dan Wing Prashanth Patil Paal-Erik Martinsen Filename : draft-ietf-tram-turn-mobility-05.txt Pages : 13 Date : 2016-08-18 Abstract: It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-mobility-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 18 18:16:11 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588CB12D182 for ; Thu, 18 Aug 2016 18:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOTvTEhPuE57 for ; Thu, 18 Aug 2016 18:16:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8012C12D135 for ; Thu, 18 Aug 2016 18:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2315; q=dns/txt; s=iport; t=1471569366; x=1472778966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EMAY7hOpR2Dbjks9UiMbTTJHSbHoUwnPqboJBpo5ha4=; b=DbwvdO19sWjYTOTpxs5HiRBgBHqorjbXWHJZFnEyCzPHxdX8BePEKa/H 5lIsgupBTr/Nm2ZNWH890Mqw7h8GEGVbVMyYf2Q7ijiqxwibFmGlRkQmH s1GN0qkdoKots6LCMBQmTBXYJZkxiSPG8jPWHldkJTQR20aScsc3Mlv1b Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgDtXLZX/4cNJK1eg0RWfAe3ZIF9J?= =?us-ascii?q?IV5AoFqOBQCAQEBAQEBAV4cC4ReAQEFAQE4NAsMBAIBCBEEAQEfCQcnCxQJCAI?= =?us-ascii?q?EDgUIE4gWDrx/AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2EKoVxBZlFAYYfi?= =?us-ascii?q?HeBck6EDokDjD2DdwEeNoN6boYufwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,542,1464652800"; d="scan'208";a="311851906" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2016 01:16:05 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7J1G599007948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Aug 2016 01:16:05 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 Aug 2016 20:16:04 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Thu, 18 Aug 2016 20:16:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-05.txt Thread-Index: AQHR+bbxkLBYuTPsPUO4QhnElB+YAqBPeoZg Date: Fri, 19 Aug 2016 01:16:04 +0000 Message-ID: <8c861fc77454431fa21ca4e2e79fae09@XCH-RCD-017.cisco.com> References: <147156919521.27836.3349394775180577505.idtracker@ietfa.amsl.com> In-Reply-To: <147156919521.27836.3349394775180577505.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.50.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Antoni Przygienda Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-05.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 01:16:08 -0000 This revision addresses comments received as part of RTG DIR Review. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, August 19, 2016 6:43 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized of the IETF. >=20 > Title : Mobility with TURN > Authors : Tirumaleswar Reddy > Dan Wing > Prashanth Patil > Paal-Erik Martinsen > Filename : draft-ietf-tram-turn-mobility-05.txt > Pages : 13 > Date : 2016-08-18 >=20 > Abstract: > It is desirable to minimize traffic disruption caused by changing IP > address during a mobility event. One mechanism to minimize > disruption is to expose a shorter network path to the mobility event > so only the local network elements are aware of the changed IP > address but the remote peer is unaware of the changed IP address. >=20 > This draft provides such an IP address mobility solution using > Traversal Using Relays around NAT (TURN). This is achieved by > allowing a client to retain an allocation on the TURN server when the > IP address of the client changes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-mobility-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Aug 18 18:34:25 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90FC12D182 for ; Thu, 18 Aug 2016 18:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 fJSdtQurYpZy for ; Thu, 18 Aug 2016 18:34:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0105.outbound.protection.outlook.com [104.47.41.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92435128E19 for ; Thu, 18 Aug 2016 18:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V5+QwJmx5d0rQofsnNertIwViEEdM1bAsHhvmUFB9RQ=; b=KMh6+Ph7xcWF33t1liLzKZC1hTAXGDtpyiJ4/x0uEZDDrLywXbbIM1yr4M3vgd299Ja8+fypoRSls8dgACA4vPMYmqJY/rkBqpuoWtWvOeu/hVwUh4PaBuBOvUtCWRlfwTLw6CAy3Bw7D3EjN4SLKLE4AWIQEnq5B6IQKtmr3x8= Received: from BN3PR0501MB1476.namprd05.prod.outlook.com (10.160.117.20) by BN3PR0501MB1474.namprd05.prod.outlook.com (10.160.117.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Fri, 19 Aug 2016 01:34:18 +0000 Received: from BN3PR0501MB1476.namprd05.prod.outlook.com ([10.160.117.20]) by BN3PR0501MB1476.namprd05.prod.outlook.com ([10.160.117.20]) with mapi id 15.01.0557.009; Fri, 19 Aug 2016 01:34:18 +0000 From: Antoni Przygienda To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-mobility-05.txt Thread-Index: AQHR+bbxkLBYuTPsPUO4QhnElB+YAqBPeoZg//+QTIA= Date: Fri, 19 Aug 2016 01:34:18 +0000 Message-ID: References: <147156919521.27836.3349394775180577505.idtracker@ietfa.amsl.com> <8c861fc77454431fa21ca4e2e79fae09@XCH-RCD-017.cisco.com> In-Reply-To: <8c861fc77454431fa21ca4e2e79fae09@XCH-RCD-017.cisco.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=prz@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-ms-office365-filtering-correlation-id: 8ea0bc84-fb09-4786-2efa-08d3c7d0f026 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1474; 6:GejI7KFELz8Pp8GFAE0VyVtSOWLG/7/n+FoIaBni1WsQD9UTiOfjxwK250HEClcKyZfEjT4RRrBwkKOqO4eq/PiWu7w/xLtAZYtN/JVSOtohXAiow8rIrCYM4v7GKnh4YGUI1pOFynGpDS8pYMLViq/q5PW1SYgCoB6+qH92GSTAyMeKKii6YrzHTvXZioT243LFeUl7Rs64eg9iuiaB02AsY2Bz2xSLNxpXK2spTUOGXiil9W+d+UzR38LVwQcQaIt8dCDf/nCwZR4y8KYYJscmLjv71zfApl0UYNPuqVqovb4RevwqqqHitP35A1Lb47jQb0sXXnpXNM4PgSOiPw==; 5:TN4wzy7ZUNHiCBH1GhjDwrvN2lIgK+iSbBKbZXNH1cTeHO7YtAYx6bBfUBXtW2qCw9xAvlfF8SaLIeWaxQvS9scv4AKgXsR/fwUo4hVAtrd9Zku0tA9cyMb+MSkzEWiuje0LcDUECUKkBDI+FeoDzg==; 24:qFTFaWT+/wlKLNI9FXInUrRPuKpsVr9wgXq1DOYux+i6fsky/NFkjna763E21sbJyEGEYSNaKQVdBUPIl9FfZsF1Xqu7uINMTD0I/ZXWdLw=; 7:Ku0zbuLOOzhKYwwBVbmiRMJfQ7L/pU5aoMufs1mnXlThwqYGty9wN0p/filGBr3S5xKrIFp1JCoBSv7N6+hJdS8KiGTod8zvf6AswrGpY1TapF4qvsN/CsOeU/Glbngw2zs51AqvvGr6396JNhvIAFQvTBpk+2lnUVOm8exWTKJWPX9BiUIS1Mo4UZyiCoAe5CJztt9NwtZ6gdxV+vceZMfy6eO008fT1HqgFUEiODBmQt/6va9CrqPUZXtA6pKn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1474; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(131327999870524)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN3PR0501MB1474; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1474; x-forefront-prvs: 0039C6E5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377424004)(199003)(13464003)(377454003)(2906002)(106116001)(2900100001)(10400500002)(50986999)(82746002)(7736002)(305945005)(102836003)(8936002)(6116002)(33656002)(7846002)(99286002)(81166006)(8676002)(105586002)(3846002)(81156014)(97736004)(107886002)(586003)(66066001)(92566002)(189998001)(2501003)(19580395003)(2950100001)(87936001)(68736007)(230783001)(106356001)(5002640100001)(36756003)(122556002)(11100500001)(15975445007)(5001770100001)(19580405001)(86362001)(54356999)(77096005)(3660700001)(83716003)(101416001)(3280700002)(76176999)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1474; H:BN3PR0501MB1476.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9F1B555AF40A8B4E98989FCCB57A2E9C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2016 01:34:18.4280 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1474 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-05.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 01:34:24 -0000 TG9va2VkIEAgaXQuIFRoYW5rcy4gQWxsIGNvbW1lbnRzIGFkZHJlc3NlZCBhZGVxdWF0ZWx5IA0K DQp0aGFua3MNCg0KLS0tIHRvbnkNCiANCjx0aXJlZGR5QGNpc2NvLmNvbT4gc3Bha2U6DQoNCiAg ICBUaGlzIHJldmlzaW9uIGFkZHJlc3NlcyBjb21tZW50cyByZWNlaXZlZCBhcyBwYXJ0IG9mIFJU RyBESVIgUmV2aWV3Lg0KICAgIA0KICAgIC1UaXJ1DQogICAgDQogICAgPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LQ0KICAgID4gZHJhZnRzQGlldGYub3JnDQogICAg PiBTZW50OiBGcmlkYXksIEF1Z3VzdCAxOSwgMjAxNiA2OjQzIEFNDQogICAgPiBUbzogaS1kLWFu bm91bmNlQGlldGYub3JnDQogICAgPiBDYzogdHJhbUBpZXRmLm9yZw0KICAgID4gU3ViamVjdDog W3RyYW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHJhbS10dXJuLW1vYmlsaXR5LTA1LnR4dA0K ICAgID4gDQogICAgPiANCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRVUk4gUmV2aXNlZCBhbmQgTW9kZXJuaXplZCBv ZiB0aGUgSUVURi4NCiAgICA+IA0KICAgID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNb2Jp bGl0eSB3aXRoIFRVUk4NCiAgICA+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogVGlydW1hbGVz d2FyIFJlZGR5DQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgIERhbiBXaW5nDQogICAg PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFByYXNoYW50aCBQYXRpbA0KICAgID4gICAgICAg ICAgICAgICAgICAgICAgICAgICBQYWFsLUVyaWsgTWFydGluc2VuDQogICAgPiAJRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi10cmFtLXR1cm4tbW9iaWxpdHktMDUudHh0DQogICAgPiAJUGFn ZXMgICAgICAgICAgIDogMTMNCiAgICA+IAlEYXRlICAgICAgICAgICAgOiAyMDE2LTA4LTE4DQog ICAgPiANCiAgICA+IEFic3RyYWN0Og0KICAgID4gICAgSXQgaXMgZGVzaXJhYmxlIHRvIG1pbmlt aXplIHRyYWZmaWMgZGlzcnVwdGlvbiBjYXVzZWQgYnkgY2hhbmdpbmcgSVANCiAgICA+ICAgIGFk ZHJlc3MgZHVyaW5nIGEgbW9iaWxpdHkgZXZlbnQuICBPbmUgbWVjaGFuaXNtIHRvIG1pbmltaXpl DQogICAgPiAgICBkaXNydXB0aW9uIGlzIHRvIGV4cG9zZSBhIHNob3J0ZXIgbmV0d29yayBwYXRo IHRvIHRoZSBtb2JpbGl0eSBldmVudA0KICAgID4gICAgc28gb25seSB0aGUgbG9jYWwgbmV0d29y ayBlbGVtZW50cyBhcmUgYXdhcmUgb2YgdGhlIGNoYW5nZWQgSVANCiAgICA+ICAgIGFkZHJlc3Mg YnV0IHRoZSByZW1vdGUgcGVlciBpcyB1bmF3YXJlIG9mIHRoZSBjaGFuZ2VkIElQIGFkZHJlc3Mu DQogICAgPiANCiAgICA+ICAgIFRoaXMgZHJhZnQgcHJvdmlkZXMgc3VjaCBhbiBJUCBhZGRyZXNz IG1vYmlsaXR5IHNvbHV0aW9uIHVzaW5nDQogICAgPiAgICBUcmF2ZXJzYWwgVXNpbmcgUmVsYXlz IGFyb3VuZCBOQVQgKFRVUk4pLiAgVGhpcyBpcyBhY2hpZXZlZCBieQ0KICAgID4gICAgYWxsb3dp bmcgYSBjbGllbnQgdG8gcmV0YWluIGFuIGFsbG9jYXRpb24gb24gdGhlIFRVUk4gc2VydmVyIHdo ZW4gdGhlDQogICAgPiAgICBJUCBhZGRyZXNzIG9mIHRoZSBjbGllbnQgY2hhbmdlcy4NCiAgICA+ IA0KICAgID4gDQogICAgPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdHJhbS10dXJuLW1vYmlsaXR5Lw0KICAgID4gDQogICAgPiBUaGVyZSdzIGFsc28gYSBo dG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eS0wNQ0KICAgID4gDQogICAgPiBB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgPiBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm4tbW9i aWxpdHktMDUNCiAgICA+IA0KICAgID4gDQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAg PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KICAgID4gDQogICAgPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgID4gdHJhbSBtYWlsaW5nIGxpc3QNCiAgICA+IHRyYW1A aWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bQ0KICAgIA0KDQoNCg== From nobody Mon Aug 22 21:03:20 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FD212D869 for ; Mon, 22 Aug 2016 21:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-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 uGkM6e51jgFV for ; Mon, 22 Aug 2016 21:03:18 -0700 (PDT) Received: from tsinghua.org.cn (unknown [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id C5F6E12D177 for ; Mon, 22 Aug 2016 21:03:16 -0700 (PDT) Received: from wangaj (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06CLWQAYwbtXBMlqDA==.6768S2; Tue, 23 Aug 2016 11:21:11 +0800 (CST) From: "Aijun Wang" To: References: <147156919521.27836.3349394775180577505.idtracker@ietfa.amsl.com> <8c861fc77454431fa21ca4e2e79fae09@XCH-RCD-017.cisco.com> In-Reply-To: Date: Tue, 23 Aug 2016 12:02:54 +0800 Message-ID: <002001d1fcf3$425e64f0$c71b2ed0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHR+bbxkLBYuTPsPUO4QhnElB+YAqBPeoZg//+QTICABuAh8A== Content-Language: zh-cn X-CM-TRANSID: Z0GX06CLWQAYwbtXBMlqDA==.6768S2 X-Coremail-Antispam: 1U3129KBjvJXoW7ZF4kGFWkCw47WrWfXFy7ZFb_yoW8JFy3pF WUuF40qa4kGryIk397Zwn3Za4Y9as3Ww4DC3srtr17ZrZ0yF97ta4aqw1YvFy5uryxXFsF vw4Y9Fy5C3WkZFJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUojjgDUUUU Archived-At: Cc: leo.liubing@huawei.com, 'Justin Uberti' Subject: [tram] OARS----An alternative solution for peer-to-peer communcation under complex network environment X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 04:03:20 -0000 Hi, All technical gurus within TRAM: We had made one presentation for introducing OARS on IETF Berlin meeting and get some feedbacks on the meeting. Here we want to ask more comments for this draft. The reason that we propose the new solution are the followings: 1) With the advent of SDN concept within IP network, it is possible that we can simplify the procedure for peer to peer communication under complex network environment between same or different address family hosts. 2) Peer-to-peer Application providers need one general solution to cover several communication scenarios, not the different solution for different scenario. 3) Service Provider can explore the capability of the existing network devices for the data exchange between communication peers. We are eager to hear more comments from every guru within TRAM and look forward to more cooperator to forward this draft. Any comments are welcome. the general introduction slide is located here: https://www.ietf.org/proceedings/96/slides/slides-96-tram-1.pdf and the detail content of the draft is located here: https://datatracker.ietf.org/doc/draft-wang-tram-oars/. Best Regards. Aijun Wang China Telecom Beijing Research Institute Network R&D and Operation Support Department From nobody Tue Aug 23 04:17:50 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FB912D091; Tue, 23 Aug 2016 04:17:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147195106809.22366.15113856087900048492.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2016 04:17:48 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-path-data-05.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 11:17:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized of the IETF. Title : Measurement of Round Trip Time and Fractional Loss Using STUN Authors : Paal-Erik Martinsen Tirumaleswar Reddy Dan Wing Varun Singh Filename : draft-ietf-tram-stun-path-data-05.txt Pages : 9 Date : 2016-08-23 Abstract: A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stun-path-data-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-path-data-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 23 07:01:36 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2801612D50D; Tue, 23 Aug 2016 07:01:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147196089515.30842.18175298284480540787.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2016 07:01:35 -0700 Archived-At: Cc: tram-chairs@ietf.org, tram@ietf.org, sperreault@jive.com, spencerdawkins.ietf@gmail.com, The IESG , draft-ietf-tram-stun-path-data@ietf.org, rfc-editor@rfc-editor.org Subject: [tram] Protocol Action: 'Measurement of Round Trip Time and Fractional Loss Using STUN' to Proposed Standard (draft-ietf-tram-stun-path-data-05.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:01:35 -0000 The IESG has approved the following document: - 'Measurement of Round Trip Time and Fractional Loss Using STUN' (draft-ietf-tram-stun-path-data-05.txt) as Proposed Standard This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ Technical Summary This document describes a mechanism for an endpoint to discover the path characteristics using Session Traversal Utilities for NAT (STUN) messages. The measurement information can then be used to influence the endpoint's Interactive Connectivity Establishment (ICE) candidate pair selection algorithm. Working Group Summary The proces for this document was straightforward. No controversy, good discussion, easy consensus. Strong consensus from the whole working group. Document Quality Web browser vendors have participated actively in the discussion with usage by their WebRTC implementation in mind. Personnel Document Shepherd: Simon Perreault Responsible Area Director: Spencer Dawkins From nobody Tue Aug 23 09:31:26 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB5712B063; Tue, 23 Aug 2016 09:31:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147196988511.30755.8924574442582411134.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2016 09:31:25 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-09.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 16:31:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized of the IETF. Title : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-09.txt Pages : 15 Date : 2016-08-23 Abstract: Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 23 09:34:18 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB3612D5C2 for ; Tue, 23 Aug 2016 09:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vt3BHms1NHV for ; Tue, 23 Aug 2016 09:34:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1AB12D5B9 for ; Tue, 23 Aug 2016 09:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2298; q=dns/txt; s=iport; t=1471970055; x=1473179655; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YAyDedAhbVbn7EFCh6EbevT5sJ2EtdrMMTEv4Q01pKA=; b=F1AEO2RWG1aaWyX2NsjH9G27W+xiuTACBUH9IUA8YuCwf2gVwWL2BKgZ QGx7o4GKycMS9cGVjDbUSkn40DrQQPtNSQQ6hXzef4RQM3hTVSKjSf0Gl GCMSI497cGYxdf3CTKpIUUpcrZhkVf/JSS4tWIM41mMB6zcrbr2X9qiAe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgDUerxX/4QNJK1dgykBAQEBARxWf?= =?us-ascii?q?Ae4A4F9JoV3AoFqOBQCAQEBAQEBAV4cC4RgAQEFAQE4NBcEAgEIEQQBAR8JByc?= =?us-ascii?q?LFAkIAgQTCIgpDr1NAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYthE2EHA6FcQWZS?= =?us-ascii?q?AGGH4h6gXROhA6JB4xAg3gBHjaDenCETEZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,566,1464652800"; d="scan'208";a="143049228" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2016 16:34:14 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7NGYEWb011571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Aug 2016 16:34:14 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 11:34:13 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Tue, 23 Aug 2016 11:34:13 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-09.txt Thread-Index: AQHR/VvQ/Sto8pSLa02lgU8u2XEOuqBWvW6w Date: Tue, 23 Aug 2016 16:34:13 +0000 Message-ID: <6ac01b45af8e49e0bc149fe82da7f916@XCH-RCD-017.cisco.com> References: <147196988511.30755.8924574442582411134.idtracker@ietfa.amsl.com> In-Reply-To: <147196988511.30755.8924574442582411134.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.78.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-09.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 16:34:17 -0000 This revision addresses comments from Gen-ART and SecDir reviews. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, August 23, 2016 10:01 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized of the IETF. >=20 > Title : TURN Server Auto Discovery > Authors : Prashanth Patil > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-tram-turn-server-discovery-09.txt > Pages : 15 > Date : 2016-08-23 >=20 > Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control of > the application or TURN service provider, and not the enterprise, > ISP, or the network in which the client is located. Enterprises and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes three such mechanisms for > TURN server discovery. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-server-discovery= -09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Aug 29 06:50:02 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C44126579; Mon, 29 Aug 2016 06:49:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147247859789.14154.18257109792324801465.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 06:49:57 -0700 Archived-At: Cc: sperreault@jive.com, draft-ietf-tram-turn-server-discovery@ietf.org, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Kathleen Moriarty's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 13:49:58 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tram-turn-server-discovery-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be easy to resolve. In reading the draft, it doesn't cover any mechanism for the TURN server to limit what clients can discover it. For the second and third method, it seems like there are possible ways to do this. Could these be added to the security considerations? You'd need to state that this isn't possible with the first method. If there is a reason why it is always okay to discover a TURN server, please let me know why this is not appropriate to add. Thanks. From nobody Tue Aug 30 08:47:59 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 672D112D937; Tue, 30 Aug 2016 08:47:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147257207739.23660.18103753025088809393.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 08:47:57 -0700 Archived-At: Cc: sperreault@jive.com, tram@ietf.org, draft-ietf-tram-turn-mobility@ietf.org, tram-chairs@ietf.org Subject: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 15:47:57 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tram-turn-mobility-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 3 = The diagram needs a caption and some explanation. Why does the first Allocate request result in a 401 error? This is not discussed anywhere in the document. = Appendix A = In the data structure there is a "state" field but the text below it refers to an "encrypted_state" field. From nobody Tue Aug 30 18:15:59 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C77BB12D79D; Tue, 30 Aug 2016 18:15:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147260615677.23780.12323446975574787038.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 18:15:56 -0700 Archived-At: Cc: sperreault@jive.com, draft-ietf-tram-turn-server-discovery@ietf.org, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Terry Manderson's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 01:15:57 -0000 Terry Manderson has entered the following ballot position for draft-ietf-tram-turn-server-discovery-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- in requesting special use assignments, please read the registries and provide guidance on the scope of the allocations i.e. o Source - A boolean value indicating whether an address from the allocated special-purpose address block is valid when used as the source address of an IP datagram that transits two devices. o Destination - A boolean value indicating whether an address from the allocated special-purpose address block is valid when used as the destination address of an IP datagram that transits two devices. o Forwardable - A boolean value indicating whether a router may forward an IP datagram whose destination address is drawn from the allocated special-purpose address block between external interfaces. o Global - A boolean value indicating whether an IP datagram whose destination address is drawn from the allocated special-purpose address block is forwardable beyond a specified administrative domain. From nobody Tue Aug 30 19:36:20 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803B112D95F; Tue, 30 Aug 2016 19:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpT1ToNQ82wO; Tue, 30 Aug 2016 19:36:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6CC12D92F; Tue, 30 Aug 2016 19:36:10 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7V2a59o016821 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Aug 2016 21:36:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Alissa Cooper" Date: Tue, 30 Aug 2016 21:36:05 -0500 Message-ID: <816D7FAD-E2A4-4E48-998F-D8A0902C1481@nostrum.com> In-Reply-To: <147257207739.23660.18103753025088809393.idtracker@ietfa.amsl.com> References: <147257207739.23660.18103753025088809393.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-tram-turn-mobility@ietf.org, sperreault@jive.com, tram-chairs@ietf.org, The IESG , tram@ietf.org Subject: Re: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 02:36:12 -0000 On 30 Aug 2016, at 10:47, Alissa Cooper wrote: > = Section 3 = > > The diagram needs a caption and some explanation. Why does the first > Allocate request result in a 401 error? This is not discussed anywhere > in > the document. Hi, IIUC, the 401 is inherited from normal TURN behavior (using the STUN long-term credential stuff.) But I agree that some explanation of the steps would be helpful. Ben. From nobody Tue Aug 30 19:41:32 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D254A12D7B1; Tue, 30 Aug 2016 19:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv5vnm2qPilD; Tue, 30 Aug 2016 19:41:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A7E12B019; Tue, 30 Aug 2016 19:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3676; q=dns/txt; s=iport; t=1472611290; x=1473820890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lvTktvYGOUBk0zBdsxCG9fKaBGl4WMlCC6Umd6Gu78I=; b=f58Wxc7iKswZlAYqGdOCVatlrSrnVl02pnGOE5Sn38obQZeuOc7sc+QS W4KOGTO2BUkn1QqMl27/WauuOuqclNgM5UXpiCtxfOaOTEUcEBrVpI5og ZZreF52UeXGYgjN9Xq0heEDWqtHeyrZzy1clslQu5MtaWwZ2faba+Ey4d Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAgDrQsZX/4UNJK1cg00BAQEBAR5Xf?= =?us-ascii?q?Ae2MIIPggEkhXkCHIFAOBQBAgEBAQEBAQFeJ4RhAQEEASMRRQUHBAIBCBEEAQE?= =?us-ascii?q?DAiMDAgICMBQBCAgCBAENBQiINAgOriOPIAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RcFgQOFK4RNhBIRAQYGgxKCWgWILYtchUcBhh+JCYF0hF2JDYxIg3gBHjaCfYE?= =?us-ascii?q?1cAGETIEgfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,260,1470700800"; d="scan'208";a="141772793" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2016 02:41:29 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u7V2fSPQ011656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 02:41:29 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 21:41:28 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Tue, 30 Aug 2016 21:41:28 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) Thread-Index: AQHSAtXlNVTLm5miKEOPYpg7I2xxy6BiU8kQ Date: Wed, 31 Aug 2016 02:41:28 +0000 Message-ID: <61243e50ae334424b753e4485e315cb9@XCH-RCD-017.cisco.com> References: <147257207739.23660.18103753025088809393.idtracker@ietfa.amsl.com> In-Reply-To: <147257207739.23660.18103753025088809393.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.80.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "tram@ietf.org" , "draft-ietf-tram-turn-mobility@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 02:41:32 -0000 SGkgQWxpc3NhLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxpc3NhIENvb3BlciBbbWFp bHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYg OToxOCBQTQ0KPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRm LXRyYW0tdHVybi1tb2JpbGl0eUBpZXRmLm9yZzsgU2ltb24gUGVycmVhdWx0DQo+IDxzcGVycmVh dWx0QGppdmUuY29tPjsgdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IHNwZXJyZWF1bHRAaml2ZS5jb207 DQo+IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogQWxpc3NhIENvb3BlcidzIE5vIE9iamVjdGlv biBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eS0wNToNCj4gKHdpdGggQ09NTUVOVCkN Cj4gDQo+IEFsaXNzYSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtdHJhbS10dXJuLW1vYmlsaXR5LTA1OiBObyBPYmplY3Rp b24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBp bnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4g cGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu DQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiA9IFNlY3Rpb24gMyA9DQo+ IA0KPiBUaGUgZGlhZ3JhbSBuZWVkcyBhIGNhcHRpb24gYW5kIHNvbWUgZXhwbGFuYXRpb24uIFdo eSBkb2VzIHRoZSBmaXJzdA0KPiBBbGxvY2F0ZSByZXF1ZXN0IHJlc3VsdCBpbiBhIDQwMSBlcnJv cj8gDQoNCjQwMSBlcnJvciBpcyByZXR1cm5lZCBieSB0aGUgc2VydmVyIGJlY2F1c2Ugb2YgU1RV TidzIGxvbmctdGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbS4NCg0KPiBUaGlzIGlzIG5vdCBkaXNj dXNzZWQgYW55d2hlcmUgaW4gdGhlDQo+IGRvY3VtZW50Lg0KDQpBZGRlZCBjYXB0aW9uICJNb2Jp bGl0eSB1c2luZyBUVVJOICIgd2l0aCB0aGUgZm9sbG93aW5nIGV4cGxhbmF0aW9uOg0KDQogICBJ biBGaWd1cmUgMSwgdGhlIGNsaWVudCBzZW5kcyBhbiBBbGxvY2F0ZSByZXF1ZXN0IHdpdGggYW4g TU9CSUxJVFktDQogICBUSUNLRVQgYXR0cmlidXRlIHRvIHRoZSBzZXJ2ZXIgd2l0aG91dCBjcmVk ZW50aWFscy4gIFNpbmNlIHRoZSBzZXJ2ZXINCiAgIHJlcXVpcmVzIHRoYXQgYWxsIHJlcXVlc3Rz IGJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgU1RVTidzIGxvbmctdGVybQ0KICAgY3JlZGVudGlhbCBt ZWNoYW5pc20sIHRoZSBzZXJ2ZXIgcmVqZWN0cyB0aGUgcmVxdWVzdCB3aXRoIGEgNDAxDQogICAo VW5hdXRob3JpemVkKSBlcnJvciBjb2RlLiAgVGhlIGNsaWVudCB0aGVuIHRyaWVzIGFnYWluLCB0 aGlzIHRpbWUNCiAgIGluY2x1ZGluZyBjcmVkZW50aWFscyAobm90IHNob3duKS4gIFRoaXMgdGlt ZSwgdGhlIHNlcnZlciBhY2NlcHRzIHRoZQ0KICAgQWxsb2NhdGUgcmVxdWVzdCBhbmQgcmV0dXJu cyBhbiBBbGxvY2F0ZSBzdWNjZXNzIHJlc3BvbnNlIGFuZCBhDQogICB0aWNrZXQgaW5zaWRlIHRo ZSBNT0JJTElUWS1USUNLRVQgYXR0cmlidXRlLiAgU29tZXRpbWUgbGF0ZXIsIHRoZQ0KICAgY2xp ZW50IElQIGFkZHJlc3MgY2hhbmdlcyBhbmQgZGVjaWRlcyB0byByZWZyZXNoIHRoZSBhbGxvY2F0 aW9uIGFuZA0KICAgdGh1cyBzZW5kcyBhIFJlZnJlc2ggcmVxdWVzdCB0byB0aGUgc2VydmVyIHdp dGggTU9CSUxJVFktVElDS0VUDQogICBhdHRyaWJ1dGUgY29udGFpbmluZyB0aGUgdGlja2V0IGl0 IGhhZCByZWNlaXZlZCBmcm9tIHRoZSBzZXJ2ZXIuICBUaGUNCiAgIHJlZnJlc2ggaXMgYWNjZXB0 ZWQgYW5kIHRoZSBzZXJ2ZXIgcmVwbGllcyB3aXRoIGEgUmVmcmVzaCBzdWNjZXNzDQogICByZXNw b25zZSBhbmQgYSBuZXcgdGlja2V0IGluc2lkZSB0aGUgTU9CSUxJVFktVElDS0VUIGF0dHJpYnV0 ZS4NCg0KICANCj4gDQo+ID0gQXBwZW5kaXggQSA9DQo+IA0KPiBJbiB0aGUgZGF0YSBzdHJ1Y3R1 cmUgdGhlcmUgaXMgYSAic3RhdGUiIGZpZWxkIGJ1dCB0aGUgdGV4dCBiZWxvdyBpdCByZWZlcnMg dG8gYW4NCj4gImVuY3J5cHRlZF9zdGF0ZSIgZmllbGQuDQoNCkZpeGVkLg0KDQotVGlydQ0KDQo+ IA0KDQo= From nobody Tue Aug 30 19:53:10 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFD912D08F; Tue, 30 Aug 2016 19:53:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147261198339.23733.485728558413099888.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 19:53:03 -0700 Archived-At: Cc: sperreault@jive.com, tram@ietf.org, draft-ietf-tram-turn-mobility@ietf.org, tram-chairs@ietf.org Subject: [tram] Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 02:53:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tram-turn-mobility-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I have a few minor comments and (mostly) questions: - General: I wonder if this should consider the potential for allocation flapping, e.g. if a client is sitting on the border between two wireless networks. Is this an issue, and is their any reasonable guidance that could be offered? - 3.1.2, 2nd paragraph: I'm curious why the server disallows this mechanism would explicitly reject a request with the MOBILITY-TICKET attribute rather than ignoring it as if it didn't understand it? Is there an advantage in letting the client know that the server undertands the extension but chooses not to use it, verses simply not understanding it? - 3.1.4: If the client receives "Mobility Forbidden", is it allowed (or encouraged) to retry without mobility? - 3.2.2: I'm (also) curious why the server rejects a refresh request with the original 5-tuple and the mobility ticket. Also, during the transition window (before it gets a Send Indication or ChannelData message on the new allocation), am I correct to assume that the server forwards inbound data _only_ to the old client address? That is, not both? If so, I think that could use some reinforcement. - 5.1: Does MICE here refer to the draft in it's current state, or an earlier version? (assuming there is any material difference.) Editorial: -1, 2nd paragraph: "the TURN client has to request for a new allocation" s/request for a new/request a new -- "new relayed candidate address would have to be tricked" s/tricked/trickled From nobody Tue Aug 30 21:17:16 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55112D901; Tue, 30 Aug 2016 21:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw7IQKEoWzD1; Tue, 30 Aug 2016 21:17:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9770512D0D1; Tue, 30 Aug 2016 21:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4804; q=dns/txt; s=iport; t=1472617027; x=1473826627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P+ECpCcoCZmhwaTso0KisAffXun89N6fM2m1iPclePc=; b=YomGqVEbCUe9T0kxFmK1xXUK3lYiG5C++t6ow1760YGrwNI8YeAfQNI9 2AKluWlA035nV9HoarkRD11fEJ8ZmKfuW3/ynlp6poC5gZwQw7uEIgcmP RhaB6GTTV9cpIaa1Rj08VjxZzPjAhoRhhhZ1C6BmHZ57YKsXXFhB1Inay c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAgA+WcZX/4kNJK1cg00BAQEBAR5Xf?= =?us-ascii?q?Ae2MIIPggEkhXkCHIFAOBQBAgEBAQEBAQFeJ4RhAQEEASMRRQUHBAIBCBEEAQE?= =?us-ascii?q?DAiMDAgICMBQBCAgCBAENBQiINAgOrimPIgEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RcFgQOFK4RNhBIRAQYGgxKCWgWILYtchUcBhh+JCYF0hF2JDYxIg3gBHjaCfYE?= =?us-ascii?q?1cAGEPQcIF4EJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,260,1470700800"; d="scan'208";a="146438203" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2016 04:17:06 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7V4H6rG004227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 04:17:06 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 23:17:05 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Tue, 30 Aug 2016 23:17:05 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) Thread-Index: AQHSAzLNyPRDT0/o2Uyyk4xEajFhoKBiYoVg Date: Wed, 31 Aug 2016 04:17:05 +0000 Message-ID: <6feac4b7b9e24641af8b02eb560b7987@XCH-RCD-017.cisco.com> References: <147261198339.23733.485728558413099888.idtracker@ietfa.amsl.com> In-Reply-To: <147261198339.23733.485728558413099888.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.80.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "tram@ietf.org" , "draft-ietf-tram-turn-mobility@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 04:17:09 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIFBsZWFzZSBzZWUgaW5saW5lLg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRv OmJlbkBub3N0cnVtLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgODoy MyBBTQ0KPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLXRy YW0tdHVybi1tb2JpbGl0eUBpZXRmLm9yZzsgU2ltb24gUGVycmVhdWx0DQo+IDxzcGVycmVhdWx0 QGppdmUuY29tPjsgdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IHNwZXJyZWF1bHRAaml2ZS5jb207DQo+ IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogQmVuIENhbXBiZWxsJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtdHJhbS10dXJuLW1vYmlsaXR5LTA1Og0KPiAod2l0aCBDT01NRU5UKQ0KPiAN Cj4gQmVuIENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KPiBkcmFmdC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eS0wNTogTm8gT2JqZWN0aW9uDQo+ IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFn cmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiAN Cj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10cmFtLXR1cm4tbW9iaWxpdHkvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSGksIEkgaGF2ZSBhIGZldyBtaW5v ciBjb21tZW50cyBhbmQgKG1vc3RseSkgcXVlc3Rpb25zOg0KPiANCj4gLSBHZW5lcmFsOiBJIHdv bmRlciBpZiB0aGlzIHNob3VsZCBjb25zaWRlciB0aGUgcG90ZW50aWFsIGZvciBhbGxvY2F0aW9u IGZsYXBwaW5nLA0KPiBlLmcuIGlmIGEgY2xpZW50IGlzIHNpdHRpbmcgb24gdGhlIGJvcmRlciBi ZXR3ZWVuIHR3byB3aXJlbGVzcyBuZXR3b3Jrcy4gSXMgdGhpcw0KPiBhbiBpc3N1ZSwgYW5kIGlz IHRoZWlyIGFueSByZWFzb25hYmxlIGd1aWRhbmNlIHRoYXQgY291bGQgYmUgb2ZmZXJlZD8NCg0K SSBhbSBub3Qgc3VyZSBvbiBzcGVjaWZpYyBndWlkYW5jZSwgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzY0MTkjc2VjdGlvbi0zIGRpc2N1c3NlcyBiZWhhdmlvciBvZiB2YXJpb3VzIE1v YmlsZSBPUyBhbmQgdGhleSBzZWVtIHRvIHVzZSBkaWZmZXJlbnQgdGVjaG5pcXVlcyB0byBwaWNr IGEgaW50ZXJmYWNlLg0KDQo+IA0KPiAtIDMuMS4yLCAybmQgcGFyYWdyYXBoOg0KPiBJJ20gY3Vy aW91cyB3aHkgdGhlIHNlcnZlciBkaXNhbGxvd3MgdGhpcyBtZWNoYW5pc20gd291bGQgZXhwbGlj aXRseSByZWplY3QgYQ0KPiByZXF1ZXN0IHdpdGggdGhlIE1PQklMSVRZLVRJQ0tFVCBhdHRyaWJ1 dGUgcmF0aGVyIHRoYW4gaWdub3JpbmcgaXQgYXMgaWYgaXQNCj4gZGlkbid0IHVuZGVyc3RhbmQg aXQ/IElzIHRoZXJlIGFuIGFkdmFudGFnZSBpbiBsZXR0aW5nIHRoZSBjbGllbnQga25vdyB0aGF0 IHRoZQ0KPiBzZXJ2ZXIgdW5kZXJ0YW5kcyB0aGUgZXh0ZW5zaW9uIGJ1dCBjaG9vc2VzIG5vdCB0 byB1c2UgaXQsIHZlcnNlcyBzaW1wbHkgbm90DQo+IHVuZGVyc3RhbmRpbmcgaXQ/DQoNClllcywg aWYgdGhlIGNsaWVudCB3YW50cyBtb2JpbGl0eSB0aGVuIGNhbiBnaXZlIGhpZ2hlciBwcmlvcml0 eSB0byBUVVJOIHNlcnZlcnMgdGhhdCBzdXBwb3J0IHRoaXMgZXh0ZW5zaW9uLg0KIA0KPiANCj4g LSAzLjEuNDogSWYgdGhlIGNsaWVudCByZWNlaXZlcyAiTW9iaWxpdHkgRm9yYmlkZGVuIiwgaXMg aXQgYWxsb3dlZCAob3INCj4gZW5jb3VyYWdlZCkgdG8gcmV0cnkgd2l0aG91dCBtb2JpbGl0eT8N Cg0KWWVzLCB0aGUgY2xpZW50IGNhbiBpbW1lZGlhdGVseSByZXRyeSB3aXRob3V0IG1vYmlsaXR5 Lg0KDQo+IA0KPiAtIDMuMi4yOg0KPiANCj4gSSdtIChhbHNvKSBjdXJpb3VzIHdoeSB0aGUgc2Vy dmVyIHJlamVjdHMgYSByZWZyZXNoIHJlcXVlc3Qgd2l0aCB0aGUgb3JpZ2luYWwgNS0NCj4gdHVw bGUgYW5kIHRoZSBtb2JpbGl0eSB0aWNrZXQuDQoNClRoZSBzZXJ2ZXIgcmVqZWN0cyB0aGUgcmVx dWVzdCBiZWNhdXNlIHRoZSBjbGllbnQgaXMgbWlzYmVoYXZpbmcgKE5vIG5lZWQgZm9yIHRoZSBj bGllbnQgdG8gc2VuZCByZWZyZXNoIHJlcXVlc3Qgd2l0aCBtb2JpbGl0eSB0aWNrZXQgb24gdGhl IG9yaWdpbmFsIDUtdHVwbGUpLiANCg0KPiANCj4gQWxzbywgZHVyaW5nIHRoZSB0cmFuc2l0aW9u IHdpbmRvdyAoYmVmb3JlIGl0IGdldHMgYSBTZW5kIEluZGljYXRpb24gb3INCj4gQ2hhbm5lbERh dGEgbWVzc2FnZSBvbiB0aGUgbmV3IGFsbG9jYXRpb24pLCBhbSBJIGNvcnJlY3QgdG8gYXNzdW1l IHRoYXQgdGhlDQo+IHNlcnZlciBmb3J3YXJkcyBpbmJvdW5kIGRhdGEgX29ubHlfIHRvIHRoZSBv bGQgY2xpZW50IGFkZHJlc3M/IA0KDQpZZXMuDQoNCj4gVGhhdCBpcywgbm90DQo+IGJvdGg/IElm IHNvLCBJIHRoaW5rIHRoYXQgY291bGQgdXNlIHNvbWUgcmVpbmZvcmNlbWVudC4NCj4gDQo+IC0g NS4xOiBEb2VzIE1JQ0UgaGVyZSByZWZlciB0byB0aGUgZHJhZnQgaW4gaXQncyBjdXJyZW50IHN0 YXRlLCBvciBhbiBlYXJsaWVyDQo+IHZlcnNpb24/IChhc3N1bWluZyB0aGVyZSBpcyBhbnkgbWF0 ZXJpYWwgZGlmZmVyZW5jZS4pDQoNCk1vYmlsaXR5IHdpdGggSUNFIChNSUNFKSB3YXMgaW5pdGlh bGx5IHByb3Bvc2VkIGluIE1NVVNJQyBXRywgDQpyZW1vdmVkIE1JQ0UgZnJvbSB0aGlzIHNlY3Rp b24uIA0KDQo+IA0KPiBFZGl0b3JpYWw6DQo+IA0KPiAtMSwgMm5kIHBhcmFncmFwaDogInRoZSBU VVJOIGNsaWVudCBoYXMgdG8gcmVxdWVzdCBmb3IgYSBuZXcNCj4gICAgYWxsb2NhdGlvbiINCj4g cy9yZXF1ZXN0IGZvciBhIG5ldy9yZXF1ZXN0IGEgbmV3DQo+IC0tICJuZXcgcmVsYXllZCBjYW5k aWRhdGUgYWRkcmVzcyB3b3VsZCBoYXZlIHRvIGJlIHRyaWNrZWQiDQo+IHMvdHJpY2tlZC90cmlj a2xlZA0KDQpGaXhlZC4NCg0KLVRpcnUNCg0KPiANCg0K From nobody Tue Aug 30 21:33:04 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8F12D828; Tue, 30 Aug 2016 21:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSM28pHrnQDq; Tue, 30 Aug 2016 21:33:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E533812D0C6; Tue, 30 Aug 2016 21:33:00 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7V4WtKM030463 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Aug 2016 23:32:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Tirumaleswar Reddy" Date: Tue, 30 Aug 2016 23:32:54 -0500 Message-ID: In-Reply-To: <6feac4b7b9e24641af8b02eb560b7987@XCH-RCD-017.cisco.com> References: <147261198339.23733.485728558413099888.idtracker@ietfa.amsl.com> <6feac4b7b9e24641af8b02eb560b7987@XCH-RCD-017.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "tram-chairs@ietf.org" , Simon Perreault , "tram@ietf.org" , The IESG , "draft-ietf-tram-turn-mobility@ietf.org" Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 04:33:02 -0000 Hi, thanks for the quick response. Also inline: On 30 Aug 2016, at 23:17, Tirumaleswar Reddy (tireddy) wrote: > Hi Ben, > > Thanks for the review, Please see inline. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Hi, I have a few minor comments and (mostly) questions: >> >> - General: I wonder if this should consider the potential for >> allocation flapping, >> e.g. if a client is sitting on the border between two wireless >> networks. Is this >> an issue, and is their any reasonable guidance that could be offered? > > I am not sure on specific guidance, > https://tools.ietf.org/html/rfc6419#section-3 discusses behavior of > various Mobile OS and they seem to use different techniques to pick a > interface. > I can accept there may not be anything useful to say here. >> >> - 3.1.2, 2nd paragraph: >> I'm curious why the server disallows this mechanism would explicitly >> reject a >> request with the MOBILITY-TICKET attribute rather than ignoring it as >> if it >> didn't understand it? Is there an advantage in letting the client >> know that the >> server undertands the extension but chooses not to use it, verses >> simply not >> understanding it? > > Yes, if the client wants mobility then can give higher priority to > TURN servers that support this extension. Higher priority to TURN servers that support the extension but won't let them use it? :-) > >> >> - 3.1.4: If the client receives "Mobility Forbidden", is it allowed >> (or >> encouraged) to retry without mobility? > > Yes, the client can immediately retry without mobility. I think some clarification would be useful here. While the text says they should not immediately retry an "identical" request, I think some readers might incorrectly interpret that as "identical other than the mobility ticket". > >> >> - 3.2.2: >> >> I'm (also) curious why the server rejects a refresh request with the >> original 5- >> tuple and the mobility ticket. > > The server rejects the request because the client is misbehaving (No > need for the client to send refresh request with mobility ticket on > the original 5-tuple). I'll accept the working group knows more than I do about this, so no further response is necessary. But it seems to me that if the client was allowed to send the ticket anytime, it wouldn't have to care about whether any given refresh happened to use a new 5-tuple. > >> >> Also, during the transition window (before it gets a Send Indication >> or >> ChannelData message on the new allocation), am I correct to assume >> that the >> server forwards inbound data _only_ to the old client address? > > Yes. > >> That is, not >> both? If so, I think that could use some reinforcement. >> >> - 5.1: Does MICE here refer to the draft in it's current state, or an >> earlier >> version? (assuming there is any material difference.) > > Mobility with ICE (MICE) was initially proposed in MMUSIC WG, > removed MICE from this section. I understand the MICE history--I guess my question was more about whether the spec had drifted enough from the MICE proposal to matter. [...] From nobody Tue Aug 30 22:38:00 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299A712B037; Tue, 30 Aug 2016 22:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPjmOz9m2aAC; Tue, 30 Aug 2016 22:37:56 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D69127A90; Tue, 30 Aug 2016 22:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4315; q=dns/txt; s=iport; t=1472621876; x=1473831476; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y+osw3bSgBiU6UIzw+4pGWpkyzLT/psHbBHkmWZGqzg=; b=EpZ7VSWdVQ4ezEx8pyXelRwGCvgk5kxFWxZ2v5xWVl5CYDxNOXcqKM0z FVdY/Xfpp347a5fpSk9bNvof6ZCFjklJE3hT1xvHFAo9ueswBwiVUiMPB WqaydcYhpr6HX6oCEhi3LbcLwYTTFcEIZocHqTmCg+5VWh0RwJ9trOEix 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgDea8ZX/5xdJa1cg00BAQEBAR5Xf?= =?us-ascii?q?Ae2L4IPggEkhXkCgVA4FAECAQEBAQEBAV4nhGEBAQU6PwwEAgEIEQQBAQEeCQc?= =?us-ascii?q?yFAkIAgQOBQiIPg69WwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhjCETYQqBoVsB?= =?us-ascii?q?YgtkSMBhh+JCYF0hF2JDYxIg3gBHjaCfoE1cIQ+B4EofwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,260,1470700800"; d="scan'208";a="317387075" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 05:37:55 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7V5bt7x016970 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 05:37:55 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 00:37:54 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 00:37:54 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ben Campbell Thread-Topic: Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) Thread-Index: AQHSAzLNyPRDT0/o2Uyyk4xEajFhoKBiYoVggABsYgD//7h5QA== Date: Wed, 31 Aug 2016 05:37:54 +0000 Message-ID: <4bdd79aa4b404048b8cfe610e36ab2d8@XCH-RCD-017.cisco.com> References: <147261198339.23733.485728558413099888.idtracker@ietfa.amsl.com> <6feac4b7b9e24641af8b02eb560b7987@XCH-RCD-017.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.80.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tram-chairs@ietf.org" , Simon Perreault , "tram@ietf.org" , The IESG , "draft-ietf-tram-turn-mobility@ietf.org" Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 05:37:58 -0000 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, August 31, 2016 10:03 AM > To: Tirumaleswar Reddy (tireddy) > Cc: The IESG ; draft-ietf-tram-turn-mobility@ietf.org; Sim= on > Perreault ; tram-chairs@ietf.org; tram@ietf.org > Subject: Re: Ben Campbell's No Objection on draft-ietf-tram-turn-mobility= -05: > (with COMMENT) >=20 > Hi, thanks for the quick response. Also inline: >=20 > On 30 Aug 2016, at 23:17, Tirumaleswar Reddy (tireddy) wrote: >=20 > > Hi Ben, > > > > Thanks for the review, Please see inline. > >> > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> Hi, I have a few minor comments and (mostly) questions: > >> > >> - General: I wonder if this should consider the potential for > >> allocation flapping, e.g. if a client is sitting on the border > >> between two wireless networks. Is this an issue, and is their any > >> reasonable guidance that could be offered? > > > > I am not sure on specific guidance, > > https://tools.ietf.org/html/rfc6419#section-3 discusses behavior of > > various Mobile OS and they seem to use different techniques to pick a > > interface. > > >=20 > I can accept there may not be anything useful to say here. >=20 > >> > >> - 3.1.2, 2nd paragraph: > >> I'm curious why the server disallows this mechanism would explicitly > >> reject a > >> request with the MOBILITY-TICKET attribute rather than ignoring it as > >> if it > >> didn't understand it? Is there an advantage in letting the client > >> know that the > >> server undertands the extension but chooses not to use it, verses > >> simply not > >> understanding it? > > > > Yes, if the client wants mobility then can give higher priority to > > TURN servers that support this extension. >=20 > Higher priority to TURN servers that support the extension but won't let > them use it? :-) I meant there is a good chance they may enable the extension sometime in ne= ar future :) >=20 > > > >> > >> - 3.1.4: If the client receives "Mobility Forbidden", is it allowed > >> (or > >> encouraged) to retry without mobility? > > > > Yes, the client can immediately retry without mobility. >=20 > I think some clarification would be useful here. While the text says > they should not immediately retry an "identical" request, I think some > readers might incorrectly interpret that as "identical other than the > mobility ticket". Fixed. Updated line to say the following instead: The client SHOULD NOT retry to send Allocate request containing MOBILITY-TI= CKET with this server until it believes the problem has been fixed. >=20 > > > >> > >> - 3.2.2: > >> > >> I'm (also) curious why the server rejects a refresh request with the > >> original 5- > >> tuple and the mobility ticket. > > > > The server rejects the request because the client is misbehaving (No > > need for the client to send refresh request with mobility ticket on > > the original 5-tuple). >=20 > I'll accept the working group knows more than I do about this, so no > further response is necessary. But it seems to me that if the client was > allowed to send the ticket anytime, it wouldn't have to care about > whether any given refresh happened to use a new 5-tuple. >=20 > > > >> > >> Also, during the transition window (before it gets a Send Indication > >> or > >> ChannelData message on the new allocation), am I correct to assume > >> that the > >> server forwards inbound data _only_ to the old client address? > > > > Yes. > > > >> That is, not > >> both? If so, I think that could use some reinforcement. > >> > >> - 5.1: Does MICE here refer to the draft in it's current state, or an > >> earlier > >> version? (assuming there is any material difference.) > > > > Mobility with ICE (MICE) was initially proposed in MMUSIC WG, > > removed MICE from this section. >=20 > I understand the MICE history--I guess my question was more about > whether the spec had drifted enough from the MICE proposal to matter. Yes, there are lots of changes. -Tiru >=20 > [...] From nobody Tue Aug 30 22:51:53 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7CB12D091; Tue, 30 Aug 2016 22:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47QW8R9p8gpH; Tue, 30 Aug 2016 22:51:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D26E12B05B; Tue, 30 Aug 2016 22:51:43 -0700 (PDT) Received: from [10.0.1.12] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7V5pcCe038357 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2016 00:51:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.12] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPhone Mail (13G36) In-Reply-To: <4bdd79aa4b404048b8cfe610e36ab2d8@XCH-RCD-017.cisco.com> Date: Wed, 31 Aug 2016 00:51:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1E804478-0C8A-4D88-A8C2-1D07E83A0986@nostrum.com> References: <147261198339.23733.485728558413099888.idtracker@ietfa.amsl.com> <6feac4b7b9e24641af8b02eb560b7987@XCH-RCD-017.cisco.com> <4bdd79aa4b404048b8cfe610e36ab2d8@XCH-RCD-017.cisco.com> To: "Tirumaleswar Reddy (tireddy)" Archived-At: Cc: "tram-chairs@ietf.org" , Simon Perreault , "tram@ietf.org" , The IESG , "draft-ietf-tram-turn-mobility@ietf.org" Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 05:51:46 -0000 On Aug 31, 2016, at 12:37 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, August 31, 2016 10:03 AM >> To: Tirumaleswar Reddy (tireddy) >> Cc: The IESG ; draft-ietf-tram-turn-mobility@ietf.org; Sim= on >> Perreault ; tram-chairs@ietf.org; tram@ietf.org >> Subject: Re: Ben Campbell's No Objection on draft-ietf-tram-turn-mobility= -05: >> (with COMMENT) >>=20 >> Hi, thanks for the quick response. Also inline: >>=20 >>> On 30 Aug 2016, at 23:17, Tirumaleswar Reddy (tireddy) wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for the review, Please see inline. >>>>=20 >>>>=20 >>>> --------------------------------------------------------------------- >>>> - >>>> COMMENT: >>>> --------------------------------------------------------------------- >>>> - >>>>=20 >>>> Hi, I have a few minor comments and (mostly) questions: >>>>=20 >>>> - General: I wonder if this should consider the potential for >>>> allocation flapping, e.g. if a client is sitting on the border >>>> between two wireless networks. Is this an issue, and is their any >>>> reasonable guidance that could be offered? >>>=20 >>> I am not sure on specific guidance, >>> https://tools.ietf.org/html/rfc6419#section-3 discusses behavior of >>> various Mobile OS and they seem to use different techniques to pick a >>> interface. >>=20 >> I can accept there may not be anything useful to say here. >>=20 >>>>=20 >>>> - 3.1.2, 2nd paragraph: >>>> I'm curious why the server disallows this mechanism would explicitly >>>> reject a >>>> request with the MOBILITY-TICKET attribute rather than ignoring it as >>>> if it >>>> didn't understand it? Is there an advantage in letting the client >>>> know that the >>>> server undertands the extension but chooses not to use it, verses >>>> simply not >>>> understanding it? >>>=20 >>> Yes, if the client wants mobility then can give higher priority to >>> TURN servers that support this extension. >>=20 >> Higher priority to TURN servers that support the extension but won't let >> them use it? :-) >=20 > I meant there is a good chance they may enable the extension sometime in n= ear future :) That's reasonable. >=20 >>=20 >>>=20 >>>>=20 >>>> - 3.1.4: If the client receives "Mobility Forbidden", is it allowed >>>> (or >>>> encouraged) to retry without mobility? >>>=20 >>> Yes, the client can immediately retry without mobility. >>=20 >> I think some clarification would be useful here. While the text says >> they should not immediately retry an "identical" request, I think some >> readers might incorrectly interpret that as "identical other than the >> mobility ticket". >=20 > Fixed. Updated line to say the following instead: > The client SHOULD NOT retry to send Allocate request containing MOBILITY-T= ICKET with this server until it believes the problem has been fixed. >=20 Works for me. >>=20 >>>=20 >>>>=20 >>>> - 3.2.2: >>>>=20 >>>> I'm (also) curious why the server rejects a refresh request with the >>>> original 5- >>>> tuple and the mobility ticket. >>>=20 >>> The server rejects the request because the client is misbehaving (No >>> need for the client to send refresh request with mobility ticket on >>> the original 5-tuple). >>=20 >> I'll accept the working group knows more than I do about this, so no >> further response is necessary. But it seems to me that if the client was >> allowed to send the ticket anytime, it wouldn't have to care about >> whether any given refresh happened to use a new 5-tuple. BTW I talked myself out of this one. It saves the client work by transferrin= g it to the server, which is assumedly much busier. Never mind. >>=20 >>>=20 >>>>=20 >>>> Also, during the transition window (before it gets a Send Indication >>>> or >>>> ChannelData message on the new allocation), am I correct to assume >>>> that the >>>> server forwards inbound data _only_ to the old client address? >>>=20 >>> Yes. >>>=20 >>>> That is, not >>>> both? If so, I think that could use some reinforcement. >>>>=20 >>>> - 5.1: Does MICE here refer to the draft in it's current state, or an >>>> earlier >>>> version? (assuming there is any material difference.) >>>=20 >>> Mobility with ICE (MICE) was initially proposed in MMUSIC WG, >>> removed MICE from this section. >>=20 >> I understand the MICE history--I guess my question was more about >> whether the spec had drifted enough from the MICE proposal to matter. >=20 > Yes, there are lots of changes. >=20 > -Tiru >=20 >>=20 >> [...] From nobody Tue Aug 30 23:36:38 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D27812D10E; Tue, 30 Aug 2016 23:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tijIMsVvJc4G; Tue, 30 Aug 2016 23:36:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A63412B053; Tue, 30 Aug 2016 23:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3212; q=dns/txt; s=iport; t=1472625395; x=1473834995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kiOr2X1NIL/2Go4ICOL4qvrFtKMNSc/cGNdMFvnxbH0=; b=GOFzQ+i/Q21OhUEie85n3LuMwI8Sb79oUd2zDWOBizbpqR42aGp3NpSU bu3Lgj+eGchA7Bmvm22REv7dQi1IbnZ91rhbt4A4xhMIjvPwABJ+6FiRp WYiZvWYL/vLJxLDXsF+o7WHZMGsdeHrjJNHhSDQXV4krB/LNvg6wvSIjK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAgA+esZX/49dJa1cg00BAQEBAR5Xf?= =?us-ascii?q?Ae2L4IPggEkhXkCHIE0OBQBAgEBAQEBAQFeJ4RhAQEFIxFFDAQCAQgRBAEBAwI?= =?us-ascii?q?jAwICAjAUAQgIAgQBDQUIiD4OrkCPIgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFg?= =?us-ascii?q?QWFK4RNhBEBEQEGgxiCWgWILZEjAYYfiQmBdIRdgzSFWYxIg3gBHjaCfoE1cAG?= =?us-ascii?q?ETIEgfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,261,1470700800"; d="scan'208";a="317573643" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 06:36:34 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7V6aYdu009883 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 06:36:34 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 01:36:33 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 01:36:33 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Terry Manderson , The IESG Thread-Topic: Terry Manderson's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) Thread-Index: AQHSAyU8g8ykTjiXp0+N/r0bBlFgp6BinXkw Date: Wed, 31 Aug 2016 06:36:33 +0000 Message-ID: References: <147260615677.23780.12323446975574787038.idtracker@ietfa.amsl.com> In-Reply-To: <147260615677.23780.12323446975574787038.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.80.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-server-discovery@ietf.org" , "tram@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Terry Manderson's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 06:36:37 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUZXJyeSBNYW5kZXJzb24gW21h aWx0bzp0ZXJyeS5tYW5kZXJzb25AaWNhbm4ub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCAzMSwgMjAxNiA2OjQ2IEFNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6 IGRyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3ZlcnlAaWV0Zi5vcmc7IFNpbW9uIFBl cnJlYXVsdA0KPiA8c3BlcnJlYXVsdEBqaXZlLmNvbT47IHRyYW0tY2hhaXJzQGlldGYub3JnOyBz cGVycmVhdWx0QGppdmUuY29tOw0KPiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFRlcnJ5IE1h bmRlcnNvbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2VydmVyLWRpc2NvdmVy eS0NCj4gMDk6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiBUZXJyeSBNYW5kZXJzb24gaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtdHJhbS10 dXJuLXNlcnZlci1kaXNjb3ZlcnktMDk6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFp bA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBh bG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2 ZXItZGlzY292ZXJ5Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IGluIHJlcXVlc3Rpbmcgc3BlY2lhbCB1c2UgYXNzaWdubWVu dHMsIHBsZWFzZSByZWFkIHRoZSByZWdpc3RyaWVzIGFuZCBwcm92aWRlDQo+IGd1aWRhbmNlIG9u IHRoZSBzY29wZSBvZiB0aGUgYWxsb2NhdGlvbnMgaS5lLg0KPiANCj4gICAgbyAgU291cmNlIC0g QSBib29sZWFuIHZhbHVlIGluZGljYXRpbmcgd2hldGhlciBhbiBhZGRyZXNzIGZyb20gdGhlDQo+ ICAgICAgIGFsbG9jYXRlZCBzcGVjaWFsLXB1cnBvc2UgYWRkcmVzcyBibG9jayBpcyB2YWxpZCB3 aGVuIHVzZWQgYXMgdGhlDQo+ICAgICAgIHNvdXJjZSBhZGRyZXNzIG9mIGFuIElQIGRhdGFncmFt IHRoYXQgdHJhbnNpdHMgdHdvIGRldmljZXMuDQo+IA0KPiAgICBvICBEZXN0aW5hdGlvbiAtIEEg Ym9vbGVhbiB2YWx1ZSBpbmRpY2F0aW5nIHdoZXRoZXIgYW4gYWRkcmVzcyBmcm9tDQo+ICAgICAg IHRoZSBhbGxvY2F0ZWQgc3BlY2lhbC1wdXJwb3NlIGFkZHJlc3MgYmxvY2sgaXMgdmFsaWQgd2hl biB1c2VkIGFzDQo+ICAgICAgIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIGFuIElQIGRhdGFn cmFtIHRoYXQgdHJhbnNpdHMgdHdvDQo+ICAgICAgIGRldmljZXMuDQo+IA0KPiAgICBvICBGb3J3 YXJkYWJsZSAtIEEgYm9vbGVhbiB2YWx1ZSBpbmRpY2F0aW5nIHdoZXRoZXIgYSByb3V0ZXIgbWF5 DQo+ICAgICAgIGZvcndhcmQgYW4gSVAgZGF0YWdyYW0gd2hvc2UgZGVzdGluYXRpb24gYWRkcmVz cyBpcyBkcmF3biBmcm9tIHRoZQ0KPiAgICAgICBhbGxvY2F0ZWQgc3BlY2lhbC1wdXJwb3NlIGFk ZHJlc3MgYmxvY2sgYmV0d2VlbiBleHRlcm5hbA0KPiAgICAgICBpbnRlcmZhY2VzLg0KPiANCj4g ICAgbyAgR2xvYmFsIC0gQSBib29sZWFuIHZhbHVlIGluZGljYXRpbmcgd2hldGhlciBhbiBJUCBk YXRhZ3JhbSB3aG9zZQ0KPiAgICAgICBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGRyYXduIGZyb20g dGhlIGFsbG9jYXRlZCBzcGVjaWFsLXB1cnBvc2UNCj4gICAgICAgYWRkcmVzcyBibG9jayBpcyBm b3J3YXJkYWJsZSBiZXlvbmQgYSBzcGVjaWZpZWQgYWRtaW5pc3RyYXRpdmUNCj4gICAgICAgZG9t YWluLg0KDQpUaGFua3MsIHVwZGF0ZWQgZHJhZnQuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+ IA0KPiANCg0K From nobody Wed Aug 31 00:02:57 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E498F12D7FE; Wed, 31 Aug 2016 00:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYtomEXxm0FQ; Wed, 31 Aug 2016 00:02:46 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A8D12B01F; Wed, 31 Aug 2016 00:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1472626965; x=1473836565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XoiUbSbAHQn+Z9Nrb1T/tJvwECJ2HiGI6VWsfmP5h+4=; b=cptQQM0ZkK9o+Y/EsAdtxdffjNbq/H6eyZ2JCKNUHwRWK0TOevqqDRJ2 uYf566VRYy9nmbvcRJW74g8h3imAiGstxGPLxNz8aGGxs1FTXjjaGu3On +4AkN9XZ4Gw6BuKZaSeLrZN+gBSyqKWN0OuNobVRyhvFs+MVTAIYKKcb3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgDFf8ZX/5xdJa1cg00BAQEBAR5Xf?= =?us-ascii?q?AesCYomgg+CASSFeQIcgTQ4FAECAQEBAQEBAV4nhGEBAQUjEUUMBAIBCBEEAQE?= =?us-ascii?q?DAiMDAgICHxEUAQgIAgQBDQUIiCQDFw6uQotYDYM9AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBFwWBBYUrhE2CQ4FPCwYBBoMYgloFiC2QbzQBhh+GPoJLgXSEXYkNiD+?= =?us-ascii?q?ECYN4AR42gn6BNXABhD4OF4EJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,261,1470700800"; d="scan'208";a="316871679" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 07:02:44 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7V72iGx025262 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 07:02:44 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 02:02:43 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 02:02:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) Thread-Index: AQHSAfw9GKziJUsFG0mb9R1x8tRHg6BipUYw Date: Wed, 31 Aug 2016 07:02:43 +0000 Message-ID: References: <147247859789.14154.18257109792324801465.idtracker@ietfa.amsl.com> In-Reply-To: <147247859789.14154.18257109792324801465.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.80.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-server-discovery@ietf.org" , "tram@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Kathleen Moriarty's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 07:02:50 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBb bWFpbHRvOkthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBNb25kYXks IEF1Z3VzdCAyOSwgMjAxNiA3OjIwIFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4N Cj4gQ2M6IGRyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3ZlcnlAaWV0Zi5vcmc7IFNp bW9uIFBlcnJlYXVsdA0KPiA8c3BlcnJlYXVsdEBqaXZlLmNvbT47IHRyYW0tY2hhaXJzQGlldGYu b3JnOyBzcGVycmVhdWx0QGppdmUuY29tOw0KPiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IEth dGhsZWVuIE1vcmlhcnR5J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXIt ZGlzY292ZXJ5LQ0KPiAwOTogKHdpdGggRElTQ1VTUykNCj4gDQo+IEthdGhsZWVuIE1vcmlhcnR5 IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1p ZXRmLXRyYW0tdHVybi1zZXJ2ZXItZGlzY292ZXJ5LTA5OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFt LXR1cm4tc2VydmVyLWRpc2NvdmVyeS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBE SVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGlzIHNob3VsZCBiZSBlYXN5IHRvIHJl c29sdmUuICBJbiByZWFkaW5nIHRoZSBkcmFmdCwgaXQgZG9lc24ndCBjb3ZlciBhbnkNCj4gbWVj aGFuaXNtIGZvciB0aGUgVFVSTiBzZXJ2ZXIgdG8gbGltaXQgd2hhdCBjbGllbnRzIGNhbiBkaXNj b3ZlciBpdC4NCj4gRm9yIHRoZSBzZWNvbmQgYW5kIHRoaXJkIG1ldGhvZCwgaXQgc2VlbXMgbGlr ZSB0aGVyZSBhcmUgcG9zc2libGUgd2F5cyB0byBkbw0KPiB0aGlzLiAgQ291bGQgdGhlc2UgYmUg YWRkZWQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPyAgWW91J2QgbmVlZCB0bw0KPiBz dGF0ZSB0aGF0IHRoaXMgaXNuJ3QgcG9zc2libGUgd2l0aCB0aGUgZmlyc3QgbWV0aG9kLiAgSWYg dGhlcmUgaXMgYSByZWFzb24gd2h5IGl0IGlzDQo+IGFsd2F5cyBva2F5IHRvIGRpc2NvdmVyIGEg VFVSTiBzZXJ2ZXIsIHBsZWFzZSBsZXQgbWUga25vdyB3aHkgdGhpcyBpcyBub3QNCj4gYXBwcm9w cmlhdGUgdG8gYWRkLiAgVGhhbmtzLg0KDQpJIGRvbid0IHNlZSBhIHJlYXNvbiB3aHkgVFVSTiBz ZXJ2ZXIgZGlzY292ZXJ5IHNob3VsZCBiZSByZXN0cmljdGVkIG9ubHkgdG8gc3BlY2lmaWMgY2xp ZW50cy4gUGxlYXNlIGV4cGxhaW4gdGhlIHNjZW5hcmlvcyBmb3IgaW1wb3Npbmcgc3VjaCByZXN0 cmljdGlvbnMuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IA0KPiANCg0K From nobody Wed Aug 31 06:58:26 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14A12D52B; Wed, 31 Aug 2016 06:58:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147265190126.13212.8151251515502207847.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 06:58:21 -0700 Archived-At: Cc: sperreault@jive.com, draft-ietf-tram-turn-server-discovery@ietf.org, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-server-discovery-09: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 13:58:21 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tram-turn-server-discovery-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 6 = "Using the TURN anycast address, the only two things that need to be deployed in the network are the two things that actually use TURN." This is a bit opaque. I would suggest adding the qualifier "for discovery" somewhere in this sentence. = Section 7.2 = "WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms described in this specification as an enterprise/gateway server, in accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return]." I think this needs to be re-phrased to include auto-discovery of a TURN server hosted by any access network, not just an enterprise network. = Section 9 = "Any discovered TURN server outside the criteria is considered untrusted and is not used for privacy sensitive communication." This is stated as a fact, but I would have thought it's more of a recommendation to implementers, e.g., servers outside the criteria ought to be considered untrusted and therefore not used. From nobody Wed Aug 31 08:41:23 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B1312D53D; Wed, 31 Aug 2016 08:41:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147265807396.13320.16720268350417791956.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 08:41:13 -0700 Archived-At: Cc: sperreault@jive.com, draft-ietf-tram-turn-server-discovery@ietf.org, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:41:15 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tram-turn-server-discovery-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In Section 9: o For certificate-based authentication, a pre-populated trust anchor store [RFC6024] allows a TURN client to perform path validation for the server certificate obtained during the (D)TLS handshake. If the client used a domain name to discover the TURN server, that domain name also provides a mechanism for validation of the TURN server. The client MUST use the rules and guidelines given in section 6 of [RFC6125] to validate the TURN server identity. I am glad that you are referencing RFC 6125, but unfortunately you don't provide enough details. Please add details as specified in Section 3 of RFC 6125 to your document. From nobody Wed Aug 31 08:42:22 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B012D532; Wed, 31 Aug 2016 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0OaqEwRsMiI; Wed, 31 Aug 2016 08:42:13 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574DD12D5A2; Wed, 31 Aug 2016 08:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3220; q=dns/txt; s=iport; t=1472657082; x=1473866682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kwgy+7+QT1zjPTUYOHa9BjIJ/FKexTpuae5lnn0s/8o=; b=eeE3DWZoiEpmz6DOPOlVEBP6B3QhD++RKCqB32pnlv2b5ukQlpFjUI+Q kwTyKKoLjSAcEXgb8q0Qww1fsG7ZW7NQPUnz7L9DkKmn0/Wj7bj2peL2L MegzOelg7RhpCT49o0mny8k9I/w6JmzRSU/9HR+1I+ZPW83KwG0pPE9S5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAgAw9sZX/49dJa1dg00BAQEBAR5Xf?= =?us-ascii?q?AeDQLJQgg+CASSFeQIcgS04FAECAQEBAQEBAV4nhGEBAQUjEUUMBAIBCBEEAQE?= =?us-ascii?q?DAiMDAgICMBQBCAgCBAENBQiIPg6uZI8mAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWBBYUqhE2EEhEBBoMYgloFiC2LXIVHAYYfiQmBdIRdiQ2MSIN4AR42gnqBNXA?= =?us-ascii?q?BhEyBIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,262,1470700800"; d="scan'208";a="316918426" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 15:24:41 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7VFOfJI030417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 15:24:41 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 10:24:40 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 10:24:40 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's No Objection on draft-ietf-tram-turn-server-discovery-09: (with COMMENT) Thread-Index: AQHSA4+9mQG9hN8p/kKWoH4ieIViGKBjKE2A Date: Wed, 31 Aug 2016 15:24:40 +0000 Message-ID: <5299e3989fd749ab991cf0a4832717da@XCH-RCD-017.cisco.com> References: <147265190126.13212.8151251515502207847.idtracker@ietfa.amsl.com> In-Reply-To: <147265190126.13212.8151251515502207847.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.62.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-server-discovery@ietf.org" , "tram@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Alissa Cooper's No Objection on draft-ietf-tram-turn-server-discovery-09: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:42:15 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWls dG86YWxpc3NhQGNvb3BlcncuaW5dDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2 IDc6MjggUE0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0 Zi10cmFtLXR1cm4tc2VydmVyLWRpc2NvdmVyeUBpZXRmLm9yZzsgU2ltb24gUGVycmVhdWx0DQo+ IDxzcGVycmVhdWx0QGppdmUuY29tPjsgdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IHNwZXJyZWF1bHRA aml2ZS5jb207DQo+IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogQWxpc3NhIENvb3BlcidzIE5v IE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXItDQo+IGRpc2NvdmVyeS0w OTogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEFsaXNzYSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZl ci1kaXNjb3ZlcnktMDk6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+ IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1k aXNjb3ZlcnkvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gPSBTZWN0aW9uIDYgPQ0KPiANCj4gIlVzaW5nIHRoZSBUVVJODQo+ ICAgIGFueWNhc3QgYWRkcmVzcywgdGhlIG9ubHkgdHdvIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUg ZGVwbG95ZWQgaW4gdGhlDQo+ICAgIG5ldHdvcmsgYXJlIHRoZSB0d28gdGhpbmdzIHRoYXQgYWN0 dWFsbHkgdXNlIFRVUk4uIg0KPiANCj4gVGhpcyBpcyBhIGJpdCBvcGFxdWUuIEkgd291bGQgc3Vn Z2VzdCBhZGRpbmcgdGhlIHF1YWxpZmllciAiZm9yIGRpc2NvdmVyeSINCj4gc29tZXdoZXJlIGlu IHRoaXMgc2VudGVuY2UuDQoNCkFkZGVkLg0KDQo+IA0KPiA9IFNlY3Rpb24gNy4yID0NCj4gDQo+ ICJXZWJSVEMgZW5kcG9pbnRzIFNIT1VMRCB0cmVhdCBhbnkgVFVSTiBzZXJ2ZXIgZGlzY292ZXJl ZCB0aHJvdWdoIHRoZQ0KPiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGlzIHNwZWNpZmljYXRp b24gYXMgYW4gZW50ZXJwcmlzZS9nYXRld2F5IHNlcnZlciwNCj4gaW4gYWNjb3JkYW5jZSB3aXRo IFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOIFtJLUQuaWV0Zi1ydGN3ZWItcmV0dXJuXS4i DQo+IA0KPiBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgcmUtcGhyYXNlZCB0byBpbmNsdWRlIGF1 dG8tZGlzY292ZXJ5IG9mIGEgVFVSTiBzZXJ2ZXINCj4gaG9zdGVkIGJ5IGFueSBhY2Nlc3MgbmV0 d29yaywgbm90IGp1c3QgYW4gZW50ZXJwcmlzZSBuZXR3b3JrLg0KDQpZZXMsIHVwZGF0ZWQuDQoN Cj4gDQo+ID0gU2VjdGlvbiA5ID0NCj4gDQo+ICJBbnkgZGlzY292ZXJlZCBUVVJOIHNlcnZlcg0K PiAgICBvdXRzaWRlIHRoZSBjcml0ZXJpYSBpcyBjb25zaWRlcmVkIHVudHJ1c3RlZCBhbmQgaXMg bm90IHVzZWQgZm9yDQo+ICAgIHByaXZhY3kgc2Vuc2l0aXZlIGNvbW11bmljYXRpb24uIg0KPiAN Cj4gVGhpcyBpcyBzdGF0ZWQgYXMgYSBmYWN0LCBidXQgSSB3b3VsZCBoYXZlIHRob3VnaHQgaXQn cyBtb3JlIG9mIGENCj4gcmVjb21tZW5kYXRpb24gdG8gaW1wbGVtZW50ZXJzLCBlLmcuLCBzZXJ2 ZXJzIG91dHNpZGUgdGhlIGNyaXRlcmlhIG91Z2h0IHRvDQo+IGJlIGNvbnNpZGVyZWQgdW50cnVz dGVkIGFuZCB0aGVyZWZvcmUgbm90IHVzZWQuDQoNCk9rYXksIGZpeGVkLg0KDQpDaGVlcnMsDQot VGlydQ0KDQo+IA0KDQo= From nobody Wed Aug 31 10:50:54 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF012D5DE; Wed, 31 Aug 2016 10:50:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147266585183.31972.12785596914482997600.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 10:50:51 -0700 Archived-At: Cc: sperreault@jive.com, tram@ietf.org, draft-ietf-tram-turn-mobility@ietf.org, tram-chairs@ietf.org Subject: [tram] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tram-turn-mobility-05=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:50:52 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tram-turn-mobility-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is the following scenario worth to be discussed in the doc? A client receives a MOBILITY-TICKET from the server but when it tries to send a Refresh Request the server ignors the ticket and sets up a new association (maybe because the server seemlessly migrated to a machine that does not support/understand MOBILITY-TICKETs or because of policy reasons) and therefore also does not send a new MOBILITY-TICKET back. I guess in this case the client would probably still want to communication with the destination server and just start a new transport connection, right? From nobody Wed Aug 31 18:24:34 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A412B03A; Wed, 31 Aug 2016 18:24:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147269306853.31916.11958166980739260630.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 18:24:28 -0700 Archived-At: Cc: sperreault@jive.com, draft-ietf-tram-turn-server-discovery@ietf.org, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:24:28 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tram-turn-server-discovery-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- -9, first paragraph says: "Use of Session Traversal Utilities for NAT (STUN) [RFC5389] authentication is OPTIONAL for TURN servers provided by the local network or by the access network. A network provided TURN server MAY be configured to accept Allocation requests without STUN authentication, and a TURN client MAY be configured to accept Allocation success responses without STUN authentication from a network provided TURN server. " This seems to relax the MUST level requirement in RFC 5766 that says TURN MUST use STUN long-term credential authentication, or use some other equally strong mechanism. From a purely process perpective, this would either require an update to 5766, or it would require an argument that the local/access network is somehow equally protected. I think the latter would only be true if the access network has some sort of protection beyond just being the access network (e.g. a vpn, ipsec, or physical isolation.) I don't recall seeing text that suggested any of those. But in any case, I think relaxing that requirement needs some discussion about how the server or client can be sure that all communication is in fact constrained to the local network. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - general: I agree with the DISCUSS positions from Terry, Alexey, and Kathleen. -3, paragraph 1: Are the MUST and MAY in this paragraph _new_ requirements, or just statements of fact about previously existing requirements? If the latter, they should not use 2119 keywords. -4.1.2, first paragraph: It would be helpful to have a discussion about clients that may support multiple users, potentially with different domains, or for a single user to use different domains for different services. -4.2, general: Do I correctly understand that most of this section describes the results of applying RFC 5928 procedures to the extracted domain name? If so, is it not enough reference 5928 and leave it at that? -4.2, last paragraph, last sentence: Is this requirement new to this draft, or something from 5928? If the latter, please use descriptive language. -9, paragraph 5: "Any discovered TURN server outside the criteria is considered untrusted and is not used for privacy sensitive communication." It seems like this needs stronger guidance, maybe even "MUST NOT be used..." - Informational References: I-D.ietf-rtcweb-return and RFC 6125 are cited as part of normative requirements, which makes them by definition need to be normative references. I-D.ietf-tram-turn-mobility, RFC6024, and RFC7250 are borderline; I think one could make an argument that one needs to read them to fully understand this draft. Editorial: -3, last paragraph: "MAY optionally" is redundant. -5.1, first paragraph, first sentence: I got lost in the nested “or”s. Please consider breaking this up into a few simpler sentences. - Figure 1: Why merge the query and reply for the A/AAAA query but not the other queries? -6, first paragraph, last sentence: I'm not sure what that sentence means. From nobody Wed Aug 31 19:52:57 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4362812D7EE; Wed, 31 Aug 2016 19:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP6WqQRZv5Qn; Wed, 31 Aug 2016 19:52:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E51312D7E2; Wed, 31 Aug 2016 19:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2344; q=dns/txt; s=iport; t=1472698374; x=1473907974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qyd6MkNRgbBuBkLouXqDYVODQZqx0S47eTKHK6EPhvw=; b=K25mqfj2FBReKBn/upqDXafeZhJmFS7QCtaGDHetPvf/DnZN2eRmupTH yBh9LozfKEYAVB4XOiF5/7dTwjY8v/9tWtES9L+l//TyS0NhCOQq8l5Kk sIrJEOiPHnPXs2WxFVLAC4p6CrvU4H9D/NIzBE6VTz2iIpFxF7lLg4Xt0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAgAol8dX/4MNJK1dg1ABAQEBAR5Xf?= =?us-ascii?q?Ae2EoIPggEkhXgCgU44FAECAQEBAQEBAV4nhGEBAQV5DAQCAQgOAwQBASgHMhQ?= =?us-ascii?q?JCAIEAQ0FCIhADrp+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGL4RNhBIRAQYGQ?= =?us-ascii?q?oUqBYgthjGKcgGGH4kKgXSEXYkNjEiDeAEeNoJ8gTVwAYRMgSB/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,264,1470700800"; d="scan'208";a="144210671" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2016 02:52:53 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u812qr6h004038 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 02:52:53 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 21:52:52 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 21:52:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Mirja Kuehlewind , The IESG Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-tram-turn-m?= =?iso-8859-1?Q?obility-05:_(with_COMMENT)?= Thread-Index: AQHSA7A5OrjPMRj10EyfKqHpfAiZ56Bj4Byw Date: Thu, 1 Sep 2016 02:52:52 +0000 Message-ID: <03dee07ec1db4647ade4bd88c6d60676@XCH-RCD-017.cisco.com> References: <147266585183.31972.12785596914482997600.idtracker@ietfa.amsl.com> In-Reply-To: <147266585183.31972.12785596914482997600.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.43.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "tram@ietf.org" , "draft-ietf-tram-turn-mobility@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tram-turn-mobility-05=3A_=28with_COMMENT=29?= X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 02:52:56 -0000 > -----Original Message----- > From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net] > Sent: Wednesday, August 31, 2016 11:21 PM > To: The IESG > Cc: draft-ietf-tram-turn-mobility@ietf.org; Simon Perreault > ; tram-chairs@ietf.org; sperreault@jive.com; > tram@ietf.org > Subject: Mirja K=FChlewind's No Objection on draft-ietf-tram-turn-mobilit= y-05: > (with COMMENT) >=20 > Mirja K=FChlewind has entered the following ballot position for > draft-ietf-tram-turn-mobility-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Is the following scenario worth to be discussed in the doc? >=20 > A client receives a MOBILITY-TICKET from the server but when it tries to = send > a Refresh Request the server ignors the ticket and sets up a new associat= ion > (maybe because the server seemlessly migrated to a machine that does not > support/understand MOBILITY-TICKETs or because of policy > reasons) and therefore also does not send a new MOBILITY-TICKET back. I > guess in this case the client would probably still want to communication = with > the destination server and just start a new transport connection, right? Yes, server will throw an error and client will have to start a new allocat= ion. It's an corner case, but probably worth discussing.=20 I can add the following lines to Section 3.2.2:=20 If the server configuration changes to forbid mobility or the server transp= arently fails-over to another server instance that does support MOBILITY-TI= CKET then the server rejects the Refresh request with a Mobility Forbidden= error code and the client starts afresh with a new allocation. -Tiru >=20 From nobody Wed Aug 31 20:44:39 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0112B059; Wed, 31 Aug 2016 20:44:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147270147784.31911.9367466767917892200.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 20:44:37 -0700 Archived-At: Cc: sperreault@jive.com, tram@ietf.org, draft-ietf-tram-turn-mobility@ietf.org, tram-chairs@ietf.org Subject: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 03:44:38 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-tram-turn-mobility-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3 In the figure (without number/title) why is there an Allocate failure in the second message? I could not find the associated text. * Section 3.2.1 The section on sending a Refresh when the IP address does not change needs a little bit more tightening. Given that the server would reject the request with a mobility ticket in this case, it would be good to put in an explicit restriction to not add the mobility ticket in the following statement OLD: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766] NEW: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it MUST send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute. From nobody Wed Aug 31 20:48:42 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5D12D08F; Wed, 31 Aug 2016 20:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAHDVUEfgLrt; Wed, 31 Aug 2016 20:48:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C308128B44; Wed, 31 Aug 2016 20:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3038; q=dns/txt; s=iport; t=1472701713; x=1473911313; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tf9pOA3al1fT2LyUCGgPn5DZpxYxbwdgt/pnGIVZhBs=; b=U5axNuJV0lXzoB6oJ6LjxXRJUzCo0UxlgdJxrFN73howL8mNi5dNAQjt GYUAVbGKlPyLSMlvk6DcZzWbh7lXo0f9Dlg0/+CENLWQpCbKMFQeq6Lkc Izkfl5c/wIAm7dTSR+Xo4wZvDKsOHXlyMXRISTGmS8+hvfchm40phiT8n A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgDvo8dX/4sNJK1UCYNQAQEBAQEeV?= =?us-ascii?q?3wHthKCD4IBJIV4AhyBMjgUAQIBAQEBAQEBXieEYQEBBSMRRQwEAgEIDgMEAQE?= =?us-ascii?q?DAiMDAgICMBQBCAgCBAENBQiIQA6uGYxtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWBBYUqhE2EEgcKAQaDGIJaBYgthXeLLAGGH4kKgXSEXYkNjEiDeAEeNoJ8gTV?= =?us-ascii?q?wAYQ/DRcHgQJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,265,1470700800"; d="scan'208";a="317330597" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2016 03:48:32 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u813mWio027782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 03:48:32 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 22:48:31 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 22:48:31 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alexey Melnikov , The IESG Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) Thread-Index: AQHSA54fDJMoqK9Hq0C6sHCN+3QJCaBj/4Yw Date: Thu, 1 Sep 2016 03:48:31 +0000 Message-ID: <21b2559f2a234c64b47595eb4615c661@XCH-RCD-017.cisco.com> References: <147265807396.13320.16720268350417791956.idtracker@ietfa.amsl.com> In-Reply-To: <147265807396.13320.16720268350417791956.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.43.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-server-discovery@ietf.org" , "tram@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 03:48:36 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4ZXkgTWVsbmlrb3YgW21h aWx0bzphYW1lbG5pa292QGZhc3RtYWlsLmZtXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAz MSwgMjAxNiA5OjExIFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRy YWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3ZlcnlAaWV0Zi5vcmc7IFNpbW9uIFBlcnJl YXVsdA0KPiA8c3BlcnJlYXVsdEBqaXZlLmNvbT47IHRyYW0tY2hhaXJzQGlldGYub3JnOyBzcGVy cmVhdWx0QGppdmUuY29tOw0KPiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IEFsZXhleSBNZWxu aWtvdidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2VydmVyLWRpc2NvdmVyeS0N Cj4gMDk6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiBBbGV4ZXkgTWVsbmlrb3YgaGFzIGVudGVyZWQg dGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtdHJhbS10dXJu LXNlcnZlci1kaXNjb3ZlcnktMDk6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0K PiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0 byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0K PiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9u ZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXIt ZGlzY292ZXJ5Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IEluIFNlY3Rpb24gOToNCj4gDQo+IG8gIEZvciBjZXJ0aWZpY2F0 ZS1iYXNlZCBhdXRoZW50aWNhdGlvbiwgYSBwcmUtcG9wdWxhdGVkIHRydXN0IGFuY2hvcg0KPiAg ICAgICBzdG9yZSBbUkZDNjAyNF0gYWxsb3dzIGEgVFVSTiBjbGllbnQgdG8gcGVyZm9ybSBwYXRo IHZhbGlkYXRpb24NCj4gICAgICAgZm9yIHRoZSBzZXJ2ZXIgY2VydGlmaWNhdGUgb2J0YWluZWQg ZHVyaW5nIHRoZSAoRClUTFMgaGFuZHNoYWtlLg0KPiANCj4gICAgICAgSWYgdGhlIGNsaWVudCB1 c2VkIGEgZG9tYWluIG5hbWUgdG8gZGlzY292ZXIgdGhlIFRVUk4gc2VydmVyLCB0aGF0DQo+ICAg ICAgIGRvbWFpbiBuYW1lIGFsc28gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIHZhbGlkYXRpb24g b2YgdGhlIFRVUk4NCj4gICAgICAgc2VydmVyLiAgVGhlIGNsaWVudCBNVVNUIHVzZSB0aGUgcnVs ZXMgYW5kIGd1aWRlbGluZXMgZ2l2ZW4gaW4NCj4gICAgICAgc2VjdGlvbiA2IG9mIFtSRkM2MTI1 XSB0byB2YWxpZGF0ZSB0aGUgVFVSTiBzZXJ2ZXIgaWRlbnRpdHkuDQo+IA0KPiBJIGFtIGdsYWQg dGhhdCB5b3UgYXJlIHJlZmVyZW5jaW5nIFJGQyA2MTI1LCBidXQgdW5mb3J0dW5hdGVseSB5b3Ug ZG9uJ3QNCj4gcHJvdmlkZSBlbm91Z2ggZGV0YWlscy4gUGxlYXNlIGFkZCBkZXRhaWxzIGFzIHNw ZWNpZmllZCBpbiBTZWN0aW9uIDMgb2YgUkZDDQo+IDYxMjUgdG8geW91ciBkb2N1bWVudC4NCg0K U3VyZSwgd2lsbCBhZGQgdGhlIGZvbGxvd2luZyBsaW5lczoNCkNlcnRpZmljYXRpb24gYXV0aG9y aXRpZXMgdGhhdCBpc3N1ZSBUVVJOIHNlcnZlciBjZXJ0aWZpY2F0ZXMgU0hPVUxEIHN1cHBvcnQg dGhlIEROUy1JRCBhbmQgU1JWLUlEIGlkZW50aWZpZXIgdHlwZXMuIFRVUk4gc2VydmljZSBwcm92 aWRlcnMgU0hPVUxEIGluY2x1ZGUgdGhlIEROUy1JRCBhbmQgU1JWLUlEIGlkZW50aWZpZXIgdHlw ZXMgaW4gY2VydGlmaWNhdGUgcmVxdWVzdHMuDQoNCi1UaXJ1DQoNCj4gDQo+IA0KPiANCg0K From nobody Wed Aug 31 21:11:21 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC6312D79D; Wed, 31 Aug 2016 21:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nynle6sXxW4; Wed, 31 Aug 2016 21:11:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8909412D736; Wed, 31 Aug 2016 21:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4356; q=dns/txt; s=iport; t=1472703078; x=1473912678; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9RF+OImSUKF6tUyCG57m3BJGhsYM0QX9S8pEE9ZiApQ=; b=AMwJTxZJyrIDgz+nSzlsM3PVyXUL8m7xZMUZm0LLqDjub0Zp2vtaeW41 MheBaEbgKARX6LXfrjyQJoWwQHgwD40kXKPxD39KIc/CO9V/xTSEOKKei 0nS4htdOtGhzP/3qyU0Dl5aym2nK9jzLdk/lI1jt17HK4XrCUfUkAKkkB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgAKqsdX/4gNJK1dg1ABAQEBAR5Xf?= =?us-ascii?q?Ae2EoIPggEkhXgCHIEwOBQBAgEBAQEBAQFeJ4RhAQEFIxFFDAQCAQgRBAEBAwI?= =?us-ascii?q?jAwICAjAUAQgIAgQBDQUIiEAOrhmMbQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFg?= =?us-ascii?q?QWFKoRNhBIRAQYGgxKCWgWILZEjAYYfiQqBdIRdiQ2GcIVYg3gBHjaCfIE1cAG?= =?us-ascii?q?ETIEgfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,265,1470700800"; d="scan'208";a="318048116" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2016 04:11:05 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u814B4NX006477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 04:11:05 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 23:11:04 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 23:11:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Suresh Krishnan , The IESG Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) Thread-Index: AQHSBAMrTLs/rXhQoEuKlPgUHNa6ZKBkBL2g Date: Thu, 1 Sep 2016 04:11:04 +0000 Message-ID: References: <147270147784.31911.9367466767917892200.idtracker@ietfa.amsl.com> In-Reply-To: <147270147784.31911.9367466767917892200.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.43.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sperreault@jive.com" , "tram@ietf.org" , "draft-ietf-tram-turn-mobility@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 04:11:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdXJlc2ggS3Jpc2huYW4gW21h aWx0bzpzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgU2Vw dGVtYmVyIDEsIDIwMTYgOToxNSBBTQ0KPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ IENjOiBkcmFmdC1pZXRmLXRyYW0tdHVybi1tb2JpbGl0eUBpZXRmLm9yZzsgU2ltb24gUGVycmVh dWx0DQo+IDxzcGVycmVhdWx0QGppdmUuY29tPjsgdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IHNwZXJy ZWF1bHRAaml2ZS5jb207DQo+IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogU3VyZXNoIEtyaXNo bmFuJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuLW1vYmlsaXR5LTA1Og0K PiAod2l0aCBDT01NRU5UKQ0KPiANCj4gU3VyZXNoIEtyaXNobmFuIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXRyYW0tdHVybi1tb2Jp bGl0eS0wNTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVw IHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVz c2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRo aXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNl IHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp dGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBv dGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm4tbW9iaWxpdHkvDQo+IA0K PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAN Cj4gKiBTZWN0aW9uIDMNCj4gDQo+IEluIHRoZSBmaWd1cmUgKHdpdGhvdXQgbnVtYmVyL3RpdGxl KSB3aHkgaXMgdGhlcmUgYW4gQWxsb2NhdGUgZmFpbHVyZSBpbiB0aGUNCj4gc2Vjb25kIG1lc3Nh Z2U/IEkgY291bGQgbm90IGZpbmQgdGhlIGFzc29jaWF0ZWQgdGV4dC4NCg0KQWRkZWQgdGl0bGUg YW5kIG51bWJlciB0byBmaWd1cmUsIGFuZCBhc3NvY2lhdGVkIHRleHQ6DQoNCiAgIEluIEZpZ3Vy ZSAxLCB0aGUgY2xpZW50IHNlbmRzIGFuIEFsbG9jYXRlIHJlcXVlc3Qgd2l0aCBhbiBNT0JJTElU WS0NCiAgIFRJQ0tFVCBhdHRyaWJ1dGUgdG8gdGhlIHNlcnZlciB3aXRob3V0IGNyZWRlbnRpYWxz LiAgU2luY2UgdGhlIHNlcnZlcg0KICAgcmVxdWlyZXMgdGhhdCBhbGwgcmVxdWVzdHMgYmUgYXV0 aGVudGljYXRlZCB1c2luZyBTVFVOJ3MgbG9uZy10ZXJtDQogICBjcmVkZW50aWFsIG1lY2hhbmlz bSwgdGhlIHNlcnZlciByZWplY3RzIHRoZSByZXF1ZXN0IHdpdGggYSA0MDENCiAgIChVbmF1dGhv cml6ZWQpIGVycm9yIGNvZGUuICBUaGUgY2xpZW50IHRoZW4gdHJpZXMgYWdhaW4sIHRoaXMgdGlt ZQ0KICAgaW5jbHVkaW5nIGNyZWRlbnRpYWxzIChub3Qgc2hvd24pLiAgVGhpcyB0aW1lLCB0aGUg c2VydmVyIGFjY2VwdHMgdGhlDQogICBBbGxvY2F0ZSByZXF1ZXN0IGFuZCByZXR1cm5zIGFuIEFs bG9jYXRlIHN1Y2Nlc3MgcmVzcG9uc2UgYW5kIGENCiAgIHRpY2tldCBpbnNpZGUgdGhlIE1PQklM SVRZLVRJQ0tFVCBhdHRyaWJ1dGUuICBTb21ldGltZSBsYXRlciwgdGhlDQogICBjbGllbnQgSVAg YWRkcmVzcyBjaGFuZ2VzIGFuZCBkZWNpZGVzIHRvIHJlZnJlc2ggdGhlIGFsbG9jYXRpb24gYW5k DQogICB0aHVzIHNlbmRzIGEgUmVmcmVzaCByZXF1ZXN0IHRvIHRoZSBzZXJ2ZXIgd2l0aCBNT0JJ TElUWS1USUNLRVQNCiAgIGF0dHJpYnV0ZSBjb250YWluaW5nIHRoZSB0aWNrZXQgaXQgaGFkIHJl Y2VpdmVkIGZyb20gdGhlIHNlcnZlci4gIFRoZQ0KICAgcmVmcmVzaCBpcyBhY2NlcHRlZCBhbmQg dGhlIHNlcnZlciByZXBsaWVzIHdpdGggYSBSZWZyZXNoIHN1Y2Nlc3MNCiAgIHJlc3BvbnNlIGFu ZCBhIG5ldyB0aWNrZXQgaW5zaWRlIHRoZSBNT0JJTElUWS1USUNLRVQgYXR0cmlidXRlLg0KDQo+ IA0KPiAqIFNlY3Rpb24gMy4yLjENCj4gDQo+IFRoZSBzZWN0aW9uIG9uIHNlbmRpbmcgYSBSZWZy ZXNoIHdoZW4gdGhlIElQIGFkZHJlc3MgZG9lcyBub3QgY2hhbmdlIG5lZWRzDQo+IGEgbGl0dGxl IGJpdCBtb3JlIHRpZ2h0ZW5pbmcuIEdpdmVuIHRoYXQgdGhlIHNlcnZlciB3b3VsZCByZWplY3Qg dGhlIHJlcXVlc3Qgd2l0aA0KPiBhIG1vYmlsaXR5IHRpY2tldCBpbiB0aGlzIGNhc2UsIGl0IHdv dWxkIGJlIGdvb2QgdG8gcHV0IGluIGFuIGV4cGxpY2l0IHJlc3RyaWN0aW9uDQo+IHRvIG5vdCBh ZGQgdGhlIG1vYmlsaXR5IHRpY2tldCBpbiB0aGUgZm9sbG93aW5nIHN0YXRlbWVudA0KPiANCj4g T0xEOg0KPiBJZiBhIGNsaWVudCB3YW50cyB0byByZWZyZXNoIGFuIGV4aXN0aW5nIGFsbG9jYXRp b24gYW5kIHVwZGF0ZSBpdHMgdGltZS10by1leHBpcnkNCj4gb3IgZGVsZXRlIGFuIGV4aXN0aW5n IGFsbG9jYXRpb24sIGl0IHdpbGwgc2VuZCBhIFJlZnJlc2ggUmVxdWVzdCBhcyBkZXNjcmliZWQg aW4NCj4gU2VjdGlvbiA3LjEgb2YgW1JGQzU3NjZdDQo+IA0KPiBORVc6DQo+IElmIGEgY2xpZW50 IHdhbnRzIHRvIHJlZnJlc2ggYW4gZXhpc3RpbmcgYWxsb2NhdGlvbiBhbmQgdXBkYXRlIGl0cyB0 aW1lLXRvLWV4cGlyeQ0KPiBvciBkZWxldGUgYW4gZXhpc3RpbmcgYWxsb2NhdGlvbiwgaXQgTVVT VCBzZW5kIGEgUmVmcmVzaCBSZXF1ZXN0IGFzIGRlc2NyaWJlZA0KPiBpbiBTZWN0aW9uIDcuMSBv ZiBbUkZDNTc2Nl0gYW5kIE1VU1QgTk9UIGluY2x1ZGUgYSBNT0JJTElUWS1USUNLRVQNCj4gYXR0 cmlidXRlLg0KDQpUaGFua3MsIHVwZGF0ZWQuDQoNCi1UaXJ1DQoNCj4gDQoNCg== From nobody Wed Aug 31 21:18:31 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3D12D7BB; Wed, 31 Aug 2016 21:18:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147270350795.31961.8306227467315681365.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 21:18:27 -0700 Archived-At: Cc: sperreault@jive.com, draft-ietf-tram-turn-server-discovery@ietf.org, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 04:18:28 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-tram-turn-server-discovery-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 4.1.1. The DHCP procedure is underspecified. I think this can be easily fixed but it requires some work. Please describe what sort of messages you would be using. i.e. are you going for a stateful exchange to piggy pack with other address and config information or are you going for a stateless Information-request based exchange(Most likely). Is there an ORO? If so, what options are requested in the ORO? Are there multiple request-response round trips as implied by the text? From nobody Wed Aug 31 21:44:00 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12912D7D1; Wed, 31 Aug 2016 21:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZpe9oaburoF; Wed, 31 Aug 2016 21:43:52 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 4235C12B00E; Wed, 31 Aug 2016 21:43:52 -0700 (PDT) X-AuditID: c6180641-e87ff70000000a0b-fe-57c75da44e33 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 0C.7E.02571.4AD57C75; Thu, 1 Sep 2016 00:43:49 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 00:43:50 -0400 From: Suresh Krishnan To: "Tirumaleswar Reddy (tireddy)" , The IESG Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) Thread-Index: AQHSBAMtQ5ZkzWBILUW+y70Uiyr1Tw== Date: Thu, 1 Sep 2016 04:43:49 +0000 Message-ID: References: <147270147784.31911.9367466767917892200.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPn+7S2OPhBp3/pSzev5jKajHjz0Rm i+tXQi1O7N7GaLH850o2iw9rL7A5sHlM+b2R1WPJkp9MHv/mPGUOYI7isklJzcksSy3St0vg yuht+cZe8F+24uszhwbGBxJdjJwcEgImElcubGfrYuTiEBLYwChxcM4hRghnGaPE4qVNjCBV bEBVG3Z+ZgKxRQSCJPou/GYBsZkFLjFKrNhYBGILCyRKNC6Zyw5RkyTRfH8OK4StJ/Fy4w6w ehYBFYmN06cydzFycPAK+Eo8a5GH2NXBKPH9xnpmkBpGATGJ76fWMEHMF5e49WQ+E8SlAhJL 9pxnhrBFJV4+/scKYStJfPw9nx2iXkdiwe5PbBC2tsSyha/B6nkFBCVOznzCMoFRZBaSsbOQ tMxC0jILScsCRpZVjBylxQU5uelGhpsYgVFyTILNcQfj3l7PQ4wCHIxKPLwLVh0LF2JNLCuu zD3EKMHBrCTCa7TxeLgQb0piZVVqUX58UWlOavEhRmkOFiVxXv2XiuFCAumJJanZqakFqUUw WSYOTqkGxgn31/HPFz+uof581rIzlzb9qVC3FmNaUXFR83kXU+XLN7UT/q24xM37Zk5LmsX5 n6+j9s8wO1G/NqV+jt/5iAdMB66EXXjYxvDXvnIT96bdXit/HpZi/qk4caFMBjvjDQsJ3Zz3 tzZelVdldtETmbArTb9O2VvWYuEkTWnpJ6svX1zbzuQtx6vEUpyRaKjFXFScCADWdCyPjgIA AA== Archived-At: Cc: Simon Perreault , "tram@ietf.org" , "draft-ietf-tram-turn-mobility@ietf.org" , "tram-chairs@ietf.org" Subject: Re: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 04:43:54 -0000 Thanks Tiru for taking care of both the points. The proposed =0A= changes/additions look good to me.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 09/01/2016 12:11 AM, Tirumaleswar Reddy (tireddy) wrote:=0A= >> -----Original Message-----=0A= >> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=0A= >> Sent: Thursday, September 1, 2016 9:15 AM=0A= >> To: The IESG =0A= >> Cc: draft-ietf-tram-turn-mobility@ietf.org; Simon Perreault=0A= >> ; tram-chairs@ietf.org; sperreault@jive.com;=0A= >> tram@ietf.org=0A= >> Subject: Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility= -05:=0A= >> (with COMMENT)=0A= >>=0A= >> Suresh Krishnan has entered the following ballot position for=0A= >> draft-ietf-tram-turn-mobility-05: No Objection=0A= >>=0A= >> When responding, please keep the subject line intact and reply to all em= ail=0A= >> addresses included in the To and CC lines. (Feel free to cut this introd= uctory=0A= >> paragraph, however.)=0A= >>=0A= >>=0A= >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l=0A= >> for more information about IESG DISCUSS and COMMENT positions.=0A= >>=0A= >>=0A= >> The document, along with other ballot positions, can be found here:=0A= >> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/=0A= >>=0A= >>=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> COMMENT:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> * Section 3=0A= >>=0A= >> In the figure (without number/title) why is there an Allocate failure in= the=0A= >> second message? I could not find the associated text.=0A= >=0A= > Added title and number to figure, and associated text:=0A= >=0A= > In Figure 1, the client sends an Allocate request with an MOBILITY-=0A= > TICKET attribute to the server without credentials. Since the server= =0A= > requires that all requests be authenticated using STUN's long-term=0A= > credential mechanism, the server rejects the request with a 401=0A= > (Unauthorized) error code. The client then tries again, this time=0A= > including credentials (not shown). This time, the server accepts the= =0A= > Allocate request and returns an Allocate success response and a=0A= > ticket inside the MOBILITY-TICKET attribute. Sometime later, the=0A= > client IP address changes and decides to refresh the allocation and=0A= > thus sends a Refresh request to the server with MOBILITY-TICKET=0A= > attribute containing the ticket it had received from the server. The= =0A= > refresh is accepted and the server replies with a Refresh success=0A= > response and a new ticket inside the MOBILITY-TICKET attribute.=0A= >=0A= >>=0A= >> * Section 3.2.1=0A= >>=0A= >> The section on sending a Refresh when the IP address does not change nee= ds=0A= >> a little bit more tightening. Given that the server would reject the req= uest with=0A= >> a mobility ticket in this case, it would be good to put in an explicit r= estriction=0A= >> to not add the mobility ticket in the following statement=0A= >>=0A= >> OLD:=0A= >> If a client wants to refresh an existing allocation and update its time-= to-expiry=0A= >> or delete an existing allocation, it will send a Refresh Request as desc= ribed in=0A= >> Section 7.1 of [RFC5766]=0A= >>=0A= >> NEW:=0A= >> If a client wants to refresh an existing allocation and update its time-= to-expiry=0A= >> or delete an existing allocation, it MUST send a Refresh Request as desc= ribed=0A= >> in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET=0A= >> attribute.=0A= >=0A= > Thanks, updated.=0A= >=0A= > -Tiru=0A= >=0A= >>=0A= >=0A= >=0A= =0A= From nobody Wed Aug 31 23:17:59 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9812D0ED; Wed, 31 Aug 2016 23:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyDvSZvy6G-J; Wed, 31 Aug 2016 23:17:51 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6A13012D0C6; Wed, 31 Aug 2016 23:17:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4B2272CC9B; Thu, 1 Sep 2016 09:17:49 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGVokUgly6Qy; Thu, 1 Sep 2016 09:17:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B32312CC40; Thu, 1 Sep 2016 09:17:48 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0454021F-C799-4535-813B-FE66689BDB3E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <92d4a285d1534ba9b58d27941a53b8b7@XCH-RCD-017.cisco.com> Date: Thu, 1 Sep 2016 09:17:46 +0300 Message-Id: <5EBA2646-C826-4768-AC75-B670EE6A6EEF@piuha.net> References: <0D5A57AB-E9A5-47C9-AB58-77D32BB97B1B@qti.qualcomm.com> <38321ad067a84b47a29a525d05185a7e@XCH-RCD-017.cisco.com> <0EF98A4A-04FD-4E34-AD1E-A6E5F5D246D9@qti.qualcomm.com> <92d4a285d1534ba9b58d27941a53b8b7@XCH-RCD-017.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF , Pete Resnick , "draft-ietf-tram-turn-mobility.all@ietf.org" , General Area Review Team , "tram@ietf.org" Subject: Re: [tram] [Gen-art] Gen-ART LC review of draft-ietf-tram-turn-mobility-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 06:17:54 -0000 --Apple-Mail=_0454021F-C799-4535-813B-FE66689BDB3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pete, Tiru, Thanks for the reviews & updates. Much appreciated. I have balloted no = objection for this document. Jari --Apple-Mail=_0454021F-C799-4535-813B-FE66689BDB3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXx8gLAAoJEM80gCTQU46qbXoP/iwcWta2h4Ih1fJRvwHpIFnY CCUCbEYxUkYcQfBO4jA4K0wqQVScFD+Bnz66f7FRoIg2iEVf/5vVKLILI0zFBkGx 44wk15HcPKaozwVyqKE4en8SFzwlhzVwGBu82SsG7Iknn4uV1YnLm2rZxFA9s96t z7Y4nz9NoWkvH/loFTCXw2bBJvEA7yLQwoouS6x8vAXGoHWgdGCZUItxOYCmb3tI 6M7R2zzaLe67cgzcMHxYjbsa1593LnEnC4Ek1wktsfiESBBSMGtPe3OeLh9eQ4+B RbH5EePp0zsgU4MaOz/B1Minl2K19+CfUCBvSRtBsx9+7mW+3ftTJuY6WjcugtUk kZTA6r54PKDNQXd6FllJ7YTdx0UlYAESOYPQd6ADJIwlOWxtRNdIUH5OE5h7YTHT h2Hl1ZMUAepS23D7AQ+HltR5MFzdRpSZksbB3p5zLUtsYHg93snr7XBICkvx2VP/ AtVk+tsp+R5Llfr7MpCjMkh+GTTw9cyw93s1wQg+Opi9E1Zfff8CsZWW1BWGcyYU 7/RqeGAbBVVGPtK3W/zAKLT6hEISFx8myX5zF6YiMAht57CA0UWIeJPFxx71TYA4 M9wQPiYGuAmoEZ+gFfJSMTwo/riysLQaaaXVquQg5E2Mp14A3zFI29snSWMU2t9r t4bArKuEiL2Wp8SFqTjU =66VN -----END PGP SIGNATURE----- --Apple-Mail=_0454021F-C799-4535-813B-FE66689BDB3E-- From nobody Wed Aug 31 23:45:58 2016 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2490D12D0C9 for ; Wed, 31 Aug 2016 23:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm3QhydhHi2V for ; Wed, 31 Aug 2016 23:45:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3228112D0C6 for ; Wed, 31 Aug 2016 23:45:55 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-3a-57c7ce99ea7c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 60.22.06563.99EC7C75; Thu, 1 Sep 2016 08:45:45 +0200 (CEST) Received: from [131.160.126.239] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.301.0; Thu, 1 Sep 2016 08:45:38 +0200 To: References: <3d8524a8-95bb-d63e-0c97-9e56140fde9b@ericsson.com> <9338c4b8-3664-83a2-8e8f-d72f0ecac034@ericsson.com> From: Gonzalo Camarillo Message-ID: Date: Thu, 1 Sep 2016 09:45:38 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9338c4b8-3664-83a2-8e8f-d72f0ecac034@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM2K7uu7Cc8fDDX6d0rC4fiXU4sPaC2wO TB5Llvxk8vg35ylzAFMUl01Kak5mWWqRvl0CV8aCVZ2sBe2cFSeX3mJrYJzD3sXIySEhYCJx ZeYbVhBbSGA9o8SufrUuRi4gew2jxNbfZ8ASwgK+EqfbLrOB2CICwhJzD95lgWgolVh6by5Y DbOApsTJU48ZQWw2AQuJLbfug9XwCthLdP4+wQRiswioSFx7sw6ohoNDVCBGYn1fAkSJoMTJ mU9YQMKcAg4SV88kQ0w0kDiyaA7UdHmJ7W/nMENs1ZZY/qyFZQKjwCwk3bOQtMxC0rKAkXkV o2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBAHtzyW3cH4+rXjocYBTgYlXh4FaSPhwuxJpYV V+YeYpTgYFYS4d1zAijEm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFM lomDU6qBMXf/mkf1rm79h4Tlvsoodk2yvditnPRdw5dhNjtr2J7N82p/PlNeLOc3e+WLStH9 0VObPgb5rOO7ufv4q5ZJa4v9Tng+1pz1wjROUGUh672Mdx8/2fFYGa41M5uUVVD1+HGwy+wD 3QLdOtkbnj/0SHDjPLNi61XvXZVTn/86PaWqOfuNsazwMyWW4oxEQy3mouJEAFX7ByFEAgAA Archived-At: Cc: Simon Perreault Subject: Re: [tram] Dedicated reviewers needed for draft-ietf-tram-stun-pmtud X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 06:45:57 -0000 Tiru, Ram: thanks for your reviews! Marc, Gonzalo: could you please address the comments you have received? Cheers, Gonzalo On 26/07/2016 7:58 PM, Gonzalo Camarillo wrote: > Hi, > > per our session in Berlin, we are still looking for volunteers to review > this draft. Please, contact the chairs if you would like to volunteer. > > Thanks, > > Gonzalo > > On 07/07/2016 9:06 AM, Gonzalo Camarillo wrote: >> Folks, >> >> we would like to get the following draft in a good-enough shape so that >> we can start its WGLC in the near future. For that, we need at least two >> dedicated reviewers: >> >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ >> >> If you would like to volunteer to review this draft, please let the >> chairs know. >> >> We are after a general review of the draft. In addition, we would like >> the dedicated reviewers to provide input on the two proposed Probing >> Mechanisms (Simple and Complete). >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >